Jump to content

ingenium

S4GRU Premier Sponsor
  • Content Count

    1,436
  • Joined

  • Last visited

  • Days Won

    10

ingenium last won the day on September 7

ingenium had the most liked content!

Community Reputation

1,148 Wireless Expert

3 Followers

About ingenium

  • Rank
    Member Level: 4G WiMax

Profile Information

  • Phones/Devices
    Google Pixel 3 XL
  • Gender
    Male
  • Location
    San Francisco, CA & Pittsburgh, PA
  • Here for...
    4G Information

Recent Profile Visitors

4,473 profile views
  1. It's hard to make further suggestions without being able to play with your router directly and see exactly what settings are enabled and disabled, or getting a packet capture to see what's happening. Lilotimz's suggestion is probably your best bet for now. Sent from my Pixel 3 XL using Tapatalk
  2. ingenium

    Pixel 4/4XL

    I believe it is live in some non-Samsung markets, but I'm not sure. It's been coming soon for a while now. Sent from my Pixel 3 XL using Tapatalk
  3. ingenium

    Pixel 4/4XL

    Yes. The Pixel 3 can do TDD-FDD CA I believe, as well as many other devices. The way it would work is B25 or B26 is the PCC and is used for upload (no UL CA). Then B41 is used as the SCC for supplemental download. Presumably they can prioritize B41 on the downlink over the PCC (to keep B25 capacity for when B41 is too weak), but I'm not sure if this is actually possible. Either way, in some markets where B25 is 15x15 and B41 coverage is very good, B25 is can be unused and has tons of capacity. Same for B26. It would also help at events where the network puts everyone on B41 which is unusable from congestion, but B25 and 26 are wide open. That's a decent amount of extra capacity to add. Sent from my Pixel 3 XL using Tapatalk
  4. Did you try Calyx? That was one person reporting potential throttling (I was one of the commenters on the post) over a year ago, and I was still unthrottled when I last used Calyx a few months ago. I suspect his site just got congested (which happened on my site as well. Verified with my Sprint phone getting the same performance). Calyx is coded as a "Spectrum Mobile Broadband 30GB" plan, which should not be throttled or deprioritized. It is a metered plan just like the one you're on now. It incurs overages after 30GB (expensive on paper, like $20 or $30/GB) in theory, but Calyx / Mobile Citizen have basically an unlimited bucket that these overages come from.@lilotimz can explain it better, but basically Sprint doesn't charge them for the overages. Sprint would need to re-code the plan I believe to throttle it, since the Spectrum Mobile Broadband plan is not throttled since it charges for overages. Even if it did start getting deprioritized, if you can get a Magic Box and have it get a usable signal, it should bypass deprioritization. The deprioritization is done on a per eNB basis. Since you will be the only person on the MB eNB, it will be seen as uncongested and not deprioritized. In theory the MB is actually prioritized over other devices on the macro / donor. If your setup is working for you and you're happy with it, that's fantastic and is what really matters. But there may be ways to save you a substantial amount of money for basically the same service (that is less complex), which is why we're suggesting them. Sent from my Pixel 3 XL using Tapatalk
  5. ingenium

    Pixel 4/4XL

    Hopefully. Though it won't help upload failing due to low signal, which is very common. We need FDD-TDD CA. When they deploy that it's going to make such a big difference. Sent from my Pixel 3 XL using Tapatalk
  6. Interesting. If I have a very weak LTE signal on wifi calling, it will sometimes drop LTE (or rather, it doesn't try to get it back once it drops on its own). If a call comes in, then I think it reconnects to LTE to allow a handoff to the macro if wifi drops. Otherwise, I maintain LTE with wifi preferred. It just doesn't update very often in SCP. Sent from my Pixel 3 XL using Tapatalk
  7. We'd need to see how the Eero software is configured. It just seems like something isn't right with your setup, and I'm not sure what it is. Can you post the IP addresses of a few devices connected to the switch? Just to make sure that everything is getting a local IP. I would delete the forwards. What IP are you forwarding them to? Remember the Airave 4 has two IPs, so either way you'd only be able to forward to either CDMA or LTE, not both. They each use an independent ipsec tunnel using ports 500 and 4500. So at best the forwards would only work for one. Sent from my Pixel 3 XL using Tapatalk
  8. It should be supported day 1. If you have an old phone you can swap to, it's a 5 minute process to switch to eSIM. Definitely worth it if you ever use a SIM from another carrier. Sent from my Pixel 3 XL using Tapatalk
  9. You shouldn't need to port forward. And in fact, you can't with the 4. It's assigned two IP addresses, one for LTE and one for CDMA. Both use all of those ports, and you can only forward to one IP. I hate that Sprint gave that forwarding advice. It may break other things (53 is DNS and 68 is DHCP). What they meant to say was make sure that those 4 ports aren't blocked outbound on your firewall. Which unless you're on an enterprise, corporate, or public network, they won't be. You would have had to explicitly block them. Outbound on those ports is always allowed by default. Sent from my Pixel 3 XL using Tapatalk
  10. I don't think so. This would break Vowifi -> VoLTE handoffs. I don't experience this on my 3, nor do other people. It could be that LTE is too weak at your location and not stable? I say that based on how low the signal bars are for you while one 1x. Sent from my Pixel 3 XL using Tapatalk
  11. The eSIM works on phones purchased from Google. I'm using it on mine. The issue is that you can't migrate directly from physical SIM to eSIM on the same phone. You have to first swap to a different/old device, remove the physical SIM from your 3, and then setup the eSIM on it (select add, then select Sprint). The phone will have you sign into your Sprint account and select which line you want to use, and that's basically it. The issue I believe is because the IMEI is already in use and tied to the physical SIM, so it won't let you swap the IMEI to eSIM while in use. By swapping to a different device first, it frees up the IMEI to be linked to your eSIM. Sent from my Pixel 3 XL using Tapatalk
  12. Why don't you just sign up for a plan with Calyx institute? It's $500/year I think and is unlimited on Sprint. No deprioritization. You can get a Sierra Wireless modem and put it in a USB enclosure, and then just stick the SIM in it. You don't need to do a device swap with Sprint. Or get the AT&T iPad plan (use an IMEI generator to get an iPad 4 IMEI). $35/month, also unlimited, but subject to deprioritization. My parents do about 200GB/month over it and haven't seen any deprioritization (they're in a rural area on an uncongested tower). There are ways to get unlimited plans without overages where you don't have to mess with load balancing and expensive plans. Edit: Check out this thread for more information on hardware and such https://s4gru.com/forums/topic/7844-build-your-own-devices-routers-relays-iot-etc there are a few of us that can give you advice. For my build, I picked up two of these antennas from LTEfix https://ltefix.com/shop/antennas/4g-lte-antennas/directional-panel/700-2700mhz-15dbi-4g-lte-directional-antenna/ for use with my Sierra Wireless MC7455. They work great. While the MC7455 is the only Sierra Wireless modem that supports all 3 Sprint bands, I wouldn't recommend it for Sprint because it has a bug that causes it to disconnect 1-2 times a day, requiring the modem to be power cycled. Other Sierra Wireless models don't have this issue, and you can get one with 3xCA B41 if you don't need B25.
  13. I guess it comes down to what the default behavior is on most consumer hardware. I'm not sure if the DMZ there is isolated from the main network? My understanding on consumer hardware is that it's assigned a LAN IP, but all non forwarded ports on the WAN IP go to the DMZ device. It's a hack to avoid port forwarding or when you don't know which ports to forward, and is a security issue. Or at least that's the way I've seen it behave on a lot of residential routers. On more enterprise hardware, I know DMZ behaves as you said, offering an isolated place to put untrusted equipment away from your primary network. Basically acting as a separate vlan. But I'm guessing for the average user, their DMZ won't behave this way unfortunately. For anyone with capable hardware, I would recommend putting the Airave on its own vlan, with access to your other vlans blocked. That's the way I run mine. Sent from my Pixel 3 XL using Tapatalk
  14. Calling+ is not a good proxy for VoLTE. It's night and day difference. VoLTE will never suffer from congestion. Calling+ is impacted severely by it. If you're moving (such as in a car), I've noticed the network will move you to B26 to minimize handoffs and cutouts while on a VoLTE call (remember, congestion doesn't affect VoLTE. It's as though B26 is unloaded). The network doesn't know you're on a Calling+ call, so you'll get stuck with B41 unusual upload, etc, and the call will cut out. As an example, I was in a subway station waiting for a train. There was a DAS with B25 and B26 only. Data was literally unusable. I couldn't even send a message in a chat. 0 throughput. Yet a VoLTE call I did was crystal clear. Read my wall post if you want a technical breakdown of the difference https://s4gru.com/entry/439-sprints-casting-call-of-voice-over-actors-an-in-depth-analysis-of-volte-calling-and-vowifi/ Sent from my Pixel 3 XL using Tapatalk
  15. Partially. On the 3, because it had broken IMS on LTE after the final software update (broke calls and texts on eCSFB devices), I blocked the LTE ipsec tunnel at the firewall. This resulted in LTE being disabled and it regularly tried to re-establish the tunnel. If I removed the firewall rule, LTE would come back up in a few minutes. I tried the same on the 4 (I forget the reason why), which was easier since the CDMA and LTE sides are assigned separate IP addresses. On the 3 I had to block by destination IP address (the LTE tunnel used a hard coded IP address. This isn't the case on the 4). If communication is interrupted, the Airave will repeatedly try to re-establish the tunnel. I'm not sure if Sprint's side tries to do anything. I'm sure if the NAT entries are still there, Sprint's side would be able to bring the tunnel back up (or at least trigger the Airave to re-establish it), but since the Airave tries regularly anyway I'm not sure if this would have much benefit other than making it reconnect a few minutes faster. Sent from my Pixel 3 XL using Tapatalk
×
×
  • Create New...