Posts by Chris Rogers2

Jack Cook7 said:Check this out

I'm hitting a wall here—whenever I run ping -l 1434 google.com, I get hit with multiple timeouts in a row.

If I try ping -f -l 1434 google.com, I'm seeing 3 losses on one go, and then 4 losses for the next 5 attempts.

But if I drop it down to ping -f -l 1432 google.com, everything works perfectly fine.

That right there? That's where your packets are getting shredded. You're basically hitting a ceiling between 1432 and 1434 bytes for the IP packet size at Layer 3. Just remember, the actual Layer 2 frame is always going to be a bit beefier because of all that extra IP overhead.

And honestly, Google.com doesn't matter here—it’s not affecting your actual performance. These jumbo frame limitations usually pop up on local networks since you're running on an Ethernet setup. A frame size can't just sail right through a router if it's too big.

Try using a ping with the -f flag to hunt down the absolute max IP packet size you can push to your specific game server.

Also, do some digging to find the average packet size your game app is actually spitting out. It’s probably buried in one of those endless readme.txt files that nobody ever bothers to read.

I couldn't find anything useful in the app texts or logs besides total transmitted packets, overhead, and stuff like that, so I just grabbed a Wireshark capture of some gameplay. Ping was steady at 42-43.

Basically, most of the packets (UDP) range from 57 bytes on the wire (15 bytes of data) to 72 bytes on the wire (30 bytes of data), making up about 70% of the traffic. Then, from 73 bytes on the wire (31 data) up to 212 on the wire (170 data), that’s another 20%. The remaining 10% are the outliers, ranging from 218 on the wire (176 data) up to 789 on the wire (747 data).

The absolute max I captured was 909 bytes on the wire, which is 867 bytes of data.

Sent you the log via DM.

Jack Cook7 said:Honestly, a simple ping has saved my skin a few times. I was mentioning before that you can actually crank up the IP packet size in a ping up to 64k, which lets you mess around with IP packet fragmentation at Layer 3—and that’s directly tied to how big the Layer 2 frames are.

Size = l (length)

Try to hunt down the IP address for a standard gaming server or even a streaming server. Once you have it, start pinging them using non-default sizes to see what happens to your round-trip time. Watch how things change when you bump the packet size from the standard 32 bytes all the way up to the 64k limit.

Here’s an example:
default;
ping -l 32 (IP address)

ping -l 64

ping -l 128, and just keep going until you hit 65535.

The network starts behaving totally differently once you cross certain thresholds. It really comes down to those "jumbo frames"—basically Ethernet frames that are bigger than the usual 1512-byte max. People use larger frames for things like streaming or heavy email traffic because there's way less overhead involved.

Also, try running a ping test where you tell it *not* to fragment anything. IP packets get "broken up" for all sorts of reasons, usually because different links along the path don't agree on the frame size. If you're using GRE, it gets even messier because those fragmented packets have to be resequenced back into their original order. I’ve dealt with situations where the end-to-end ping size was barely hitting 500 bytes. Once I finally got my ISP to align their links properly, everything smoothed out massively.

To disable fragmentation:

ping -f

Example for a standard Ethernet packet:

ping -f -l 1512 (IP address)

If the ping tells you it can't go through, then boom—you've found a fragmentation issue.

When you're gaming, the secret sauce is knowing the default IP packet size for that specific game or server so you can optimize the end-to-end transfer. Every single time a packet gets "split," you're looking at extra latency.

I can't ping the game server because they've disabled ICMP/ping requests to their servers. I reached out to support to see if they have a diagnostic tool or if they can give me an IP I actually *can* ping.

But check this out: I can't ping google.com with anything over 1432 bytes ( ping -l 1434 google.com )

When I run ping -l 1434 google.com, I get multiple timeouts in a row.

Running ping -f -l 1434 google.com gives me 3 losses on 1 sent, and then 4 losses on the next 5 tries.

However, ping -f -l 1432 google.com works perfectly:

Pinging google.com [142.251.208.110] with 1432 bytes of data:
Reply from 142.251.208.110: bytes=68 (sent 1432) time=30ms TTL=118
Reply from 142.251.208.110: bytes=68 (sent 1432) time=28ms TTL=118
Reply from 142.251.208.110: bytes=68 (sent 1432) time=29ms TTL=118
Reply from 142.251.208.110: bytes=68 (sent 1432) time=29ms TTL=118

Ping statistics for 142.251.208.110:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 28ms, Maximum = 30ms, Average = 29ms

And ping -l 1432 google.com runs smooth:
inging google.com [142.251.208.110] with 1432 bytes of data:
Reply from 142.251.208.110: bytes=68 (sent 1432) time=32ms TTL=118
Reply from 142.251.208.110: bytes=68 (sent 1432) time=27ms TTL=118
Reply from 142.251.208.110: bytes=68 (sent 1432) time=25ms TTL=118
Reply from 142.251.208.110: bytes=68 (sent 1432) time=26ms TTL=118

Ping statistics for 142.251.208.110:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 25ms, Maximum = 32ms, Average = 27ms

Not sure if that’ll actually do anything for you

Jack Cook7 said:So I was doing a little deep dive into that HA35 router. Honestly, it’s pretty much like any other piece of gear designed for big telecom companies to blast out to homes everywhere—you just can't find much info on it. Sure, you can track down the User's manual if you look hard enough, but it’s super thin. It barely tells you anything!

The trick with these kinds of devices is that they work on different permission tiers. Cisco calls them "levels." Level 15 is the big boss—that’s full root access where you own the whole thing. Then you've got the user mode you're stuck in, which is usually level 2; it lets you dabble in some admin stuff, but you aren't running the show. If you're down at level 0, you're basically just a passenger—you can use the device to pass traffic through, but you can't see or touch a single setting. You can actually customize the other levels to fit specific admin roles, too. The main thing to remember? A lower level can't peek at or mess with anything from a higher level. Period.

Look, what you're seeing when you log into the HA35 is basically just Level 2 access. It’s a super limited set of router commands that only lets you mess with the bare essentials. It's all laid out in the User's manual if you want to dig into it. As for the Operations manual—the one that actually gives you Level 15 privileges? Yeah, good luck finding that one anywhere. It's nowhere to be found.

Look, if you want to mess with the heavy-duty stuff—I'm talking GRE tunneling, configuring VLANs per port, tweaking traffic priorities, or deciding exactly which data flows through which link—you’re gonna need Level 15, aka root access. And let me tell you, AT&T isn't just going to hand that over to you. They won't. For a million different reasons, they keep those keys locked tight. Sure, you could try to crack it, but why even bother? It’s a total waste of time. The second they run their next automated maintenance cycle, they’ll just wipe your changes and reset everything back to how they want it. Same deal if you try to factory reset the router using the firmware defaults. You'll just end up right back where you started.

Look, there's really only one way to go about this: you’d have to crack the router and swap out that root password entirely. It’s basically a way to effectively snatch the hardware away from AT&T. But honestly? I wouldn't recommend it. Since they technically own the thing until you buy it out, messing with it feels a bit like breaking into someone else's apartment. Plus, once you go down that rabbit hole, you're on your own—you lose all technical support from the provider and won't even have a User's manual to fall back on.

Another way to play it is to just grab an equivalent DSL/LTE router and start messing around with it. You know, see what sticks. But honestly? That’s really only for the folks who already know their way around routing and aren't afraid to break things.

The big thing you gotta do here is move that IPTV over to the LTE—maybe even throw the VoIP and video on there too—so you can save the DSL strictly for gaming. With how things are set up right now, it’s just not happening. I actually tried killing the DSL link to see if it would force the switch, but the TV went totally dead. Turns out the current settings are basically hard-blocking any IPTV traffic coming through the LTE. Total bummer.

The real question is where the bottleneck actually is. See, GRE works by bundling two or more links into one single virtual connection, and then it just manages the bandwidth—kicking links into gear whenever it feels like it. The whole algorithm behind how that happens is constantly shifting, and honestly, it depends entirely on what kind of links you’re playing with. It’s a totally different ballgame when you’re pairing up four 1Gbps Ethernet lines versus trying to mash some DSL with an LTE connection. At the end of the day, both of those are basically just dial-up setups that spin up a connection only when they need to.

Theoretically speaking, your router is the one calling the shots here. It’s all about those bandwidth thresholds, RTT thresholds, and those specific Binding filters that dictate which port hits which link—basically deciding which connection takes priority, whether you call it primary, least cost, or whatever. Honestly, I'm stumped on how to help you there, though. There isn't anything in the HA35 User's manual about tweaking those settings, and frankly, I'm not even sure if you can change them at all with this specific configuration.

In the worst-case scenario, the ISP basically runs the whole show. They control every single bit of traffic flowing through the line, which means they can even force your IPTV to run over LTE if they feel like it. On top of that, they won't let you touch anything involving GRE tunnels—they’ll just block all that traffic on those specific ports before you even get a chance to try.

Man, there’s honestly nothing you could’ve done about that mess during the game. It clearly wasn't on your end. See, since your setup runs on dual links—both DSL and LTE—the ISP has the exact same thing going on at their headquarters. They’ve got the DSLAM and the LTE base station both feeding into the same hub. That hub uses a beefier router to run a GRE tunnel straight to every single individual user out there. With everyone jumping online for the big game, that router just got slammed. It likely choked out the DSL, then the LTE, and then the whole router probably just hit a wall and rebooted. Once that happens, you’re stuck waiting ten minutes or so for everything to kick back in. Tough luck!

It’s the same old story—they won't let you kill the interlacing on your TV because it would absolutely wreck your connection, the DSLAM, and the ISP's router all at once. It isn't just about your setup, man; you're talking about hundreds of other users sharing that same hardware. Turning that stuff off would spike the load for everyone on that router big time.

And honestly? I don't think timing in the game is your actual headache. You're probably playing just fine while IPTV is running in the background. The real killer is the congestion happening somewhere else entirely—not on your end, but likely at the ISP's GRE router. Whether the bottleneck is right there at the router, deeper in the backbone, or even on the transit link connecting your provider to the one hosting the IPTV stream or linking you to other players... who knows? The ISP isn't going to give you a straight answer; they really don't care enough to dig into it for you.

Your best bet is to play around with whatever settings you actually have access to. Mess with the bandwidth threshold, the RTT threshold, or those Binding filters—maybe you'll stumble onto a sweet spot that works better for you. You could also try toggling the firewall for outbound traffic to block everything that isn't strictly necessary.

I'm gonna do a little more digging to see if I can track down a User's manual for the HA35.

PS: I found this Maintenance manual for the HA35 that lists some default passwords on page 9. Most likely, they've already been changed, but maybe you could try a factory reset and go from there.
https://drive.google.com/drive/folde...xWVnCsUlK41Vca

from: https://forum.openwrt.org/t/unlockin...-dsl-lte/34302

Thanks for the help and for taking the time. I actually turned interlacing back on the other day because it was better; since the TV was running at 1080p, it freed up a few Mbps. I'll flip through that manual and see what I can find. If I get lucky, maybe I'll run into someone I know who works at AT&T and pick their brain. Thanks again!

Jack Cook7 said:Think of RTT (round trip time) as being similar to ping latency, but there's a catch. Ping operates at Layer 3 via ICMP, whereas RTT hits you right at Layer 7 on the application layer. That makes it a way better metric since it’s directly tied to the GRE—you know, that bonding protocol that mashes multiple links into one big pipe.

You really ought to be using an RTT threshold to trigger when the LTE kicks in. If you set that limit at 500ms, you're basically saying the LTE shouldn't even bother waking up until the DSL is seriously choked out.

Alright, so is there any way I can use a filter or something to reserve just a few Mbps of my DSL for browsing? Honestly, I don't give a damn about download speeds; I just need my ping to stay low.

Jack Cook7 said:So, if the TV is fine, the bottleneck isn't on your end. The real question is whether there's a massive congestion issue at the DSLAM or within the ISP's routing, or if it's happening at the LTE base stations, or maybe even deeper in their core network.

That "spike" you're seeing is most likely what happens in-game when the system flips from DSL over to LTE. Your TV stays glued to the DSL line, while everything else jumps over to LTE. That’s where the Binding filter comes in—it basically dictates which traffic goes where.

Your RTT is sitting at 500ms. Man, that's a bit high.

When the connection dropped yesterday, was it the TV or your gaming session that cut out?

Yeah, exactly. They’ve got congestion or some technical glitch, so they flip me over to mobile data, and that's where I run into trouble. They swapped out my DSLAM about two weeks ago; they moved me to a different box because I've been riding their asses for years over the old one that would die every time it rained.

Yesterday everything just tanked. Ping shot up to 1800, froze for 5 seconds, and the TV started buffering. After that, things seemed fine for a few minutes, then the whole internet died—TV and everything.

How does the RTT threshold actually work? Right now it says RTT is 21, but what happens when the ping jumps to 500?

Jack Cook7 said:Honestly, port forwarding doesn't do much for me. I think having some actual "Bandwidth control" would be way more useful.

Regarding the bonding, it shows the type as LTEDSL and the "available bandwidth 15279"

RTT switch: 0
Current RTT: 47
RTT threshold: 500
Bandwidth statistics interval: 10
Available bandwidth: 15297
Error message:None

So this is the "Bonding Information." Is that seriously just 15 Mbps? Or are we talking 15 MB/s?
Looks like they're using GRE for the bonding.

Any way to check the routing rules? They might have just handled everything with static routes.

Yep, they've got static routes—about ten of them:

View on imgur

Probably Mbps, because on a good day, Speedtest pulls around 20-something Mbps download, and 20-28 Mbps upload (which is plenty for me). Right now, I'm hitting 15 Mbps on Speedtest.

Jack Cook7 said:So, you're running without DirecTV?

Nah, DirecTV works fine.

Jack Cook7 said:Try running a ping test from your PC using 64kB packets toward an external host, maybe something over at DirecTV.

ping -l 64000

Give it a shot, and try disabling fragmentation just to see if it actually works; it really should for streaming:

ping -f -l 64000

Right now the ping is fine—I'm seeing 42-43 in-game—but there have been days where I can't get anything under 120 for two or three days straight. Or it'll be good and then suddenly spike, probably when it switches over to mobile data. Yesterday afternoon was a total disaster; the connection just completely died on me. Probably because everyone was watching the game and the lines were totally slammed.

Jack Cook7 said:Look, kid, it sounds like they did the exact opposite of what you actually wanted.

I poked around that router a bit, but I couldn't find an Operator's manual, just the User's one.

It uses "bonding"—basically pairing up links, like DSL and LTE. I haven't figured out exactly how it handles it on the Huawei HA35 yet, but there are usually a few ways it works.

It looks like the DSL/wired connection is dedicated specifically to the DirecTV traffic, meaning those VLAN IPTV VDSL setups where the DSL port and the LAN 2 port live.

Everything else stays in VOIP (phone) and the Internet VLAN, which map to their own LAN ports. It seems like the bonding is set up so they can failover from DSL to LTE. There might even be a load threshold on the DSL connection that triggers the LTE kick-in.

That’s probably why your TV dies when you pull the DSL connection, while your PC and phone just hop over to LTE.

Now, you should be able to see the configuration details under "Bonding tunnel" and "Bonding Information," if they aren't locked away. Some versions even have "Bonding Filtering" or something similar that dictates which traffic gets access to which link. Can you actually find those settings on the router, or are they hidden?

My guess is this stuff is configured via the command line, along with all the priorities and thresholds.

By the way, does he get lag in his games only when the TV is on, or is it happening all the time?

View on imgur

Regarding the bonding, it says the type is LTEDSL and "available bandwidth 15279"

RTT switch:
0
Current RTT:
47
RTT threshold:
500
Bandwidth statistics interval:
10
Available bandwidth:
15297
Error message:
None

Roger Castillo9 said:Look, if it actually is possible to change that, there’s a massive reason why it’s set up this way—with the TV running on the fixed line instead of mobile. It’s not like the provider just picked that at random for no reason.

TV is one of those services that doesn't need insane download bandwidth (and the upload is basically nothing), but that download speed absolutely has to be consistent. ADSL/VDSL is perfect for that because it has those exact traits: the download isn't huge, the upload is pretty terrible, but both are steady. Since you're on a copper medium, that connection is essentially dedicated to you—at least for that "last mile" part of the network, anyway; aggregation is a whole different story.

On the flip side, standard internet traffic is way more "bursty." It's interactive, it needs upload, and it actually fits the characteristics of a mobile network much better. In a mobile setup, tons of users are statistically sharing much higher capacities—we're talking a few hundred megs on the downlink and a bit less on the uplink. But because everyone is sharing, the capacity available to a single user fluctuates wildly, so you end up hitting moments where you just don't have enough juice left for the TV.

That’s exactly why providers usually only offer TV over mobile as an OTT service. The "real" IPTV stuff is almost always reserved for phone lines, cable, or fiber (even though, honestly, a typical speed test might show the phone line having a much lower nominal speed).

I'm guessing you're a gamer, so the higher latency on mobile is what's killing you. That's just how the technology works, though I'll admit 5G is a bit better. Just keep in mind, though, that measuring ping with 32-byte packets isn't always a great way to judge actual latency. It mostly just measures the "propagation" part of the delay, not the "serialization" component, which gets worse as your bandwidth drops.

So, if your DSL throughput is low—which happens all the time on the upload side—your effective latency (that actual time-to-content) might actually be worse than mobile, even if the ping numbers don't show it.

Look, whenever I fire up a game and my ping jumps from 42 to 120+, it happens every single time it starts drizzling outside. And regardless of what you say about latency not showing it, I can clearly see my connection is trash by the packet loss.

I get that it was designed this way on purpose, but as a customer, I'm not feeling it. My internet was better before they shoved this hybrid router down my throat, and it was even better back when I could disable interleaving—something AT&T won't let you do anymore because of DirecTV. Not to mention how they use this mobile backup and hybrid router setup to mask technical failures and sheer laziness.

Jack Cook7 said:Alright, looking at that second screenshot, it's obvious the Roku is sitting on the IPTV VDSL VLAN since the traffic spiked immediately. You've definitely got multiple VLANs running.

1. Does that Roku always have to be plugged into one specific physical port on the router?

2. Could you try this experiment: while the TV is running, just pull the plug on the main wired internet interface (basically kill the wired connection). Theoretically, after a few seconds, everything should kick over to the 4G backup (the "mobile" interface, right?). Grab a screen recording of the traffic during that switch.

The Roku needs to be plugged into LAN 2, right?

Connection's still holding up before the line expires. TV is working fine, and I’ve even got a 1080p 60 FPS stream running on my PC.

I can't see the image you linked, so I don't have any text to work with! Drop the content here and I'll get to work on it.

So, I went ahead and reset the DSL line on my router, and now my DirecTV is completely dead. It won't connect at all. Meanwhile, the internet on my PC is working perfectly fine—I’ve even got a stream running right now without a single hiccup. What gives?

I can't see the image you're trying to share. It looks like the link is broken or the upload didn't go through. Try posting it again so I can actually take a look.

Totally blanked on checking the mobile broadband settings, so here’s a screenshot of the router right after the reset while the external line is still dead. The router rebooted just fine and I'm getting smooth 1080p 60 FPS streaming, but the TV is still throwing that "x306 service currently unavailable" error, and my phone is acting up too.

I can't see the image you linked. Drop the details or a description here and I'll get on it.

Internet VLAN status: disconnected.
The IPTV VDSL VLAN is showing as disconnected.
VOIP_VDSL status says disconnected.
VDSL Management just dropped.
Mobile connected, IPv4

Edit: that VDSL Management thing might be for bonding or tunneling, whatever way it actually works.

Jack Cook7 said:Gotcha.

So, basically, you’ve got two separate virtual networks running in your house—one dedicated to DirecTV, which only has one fixed device (your Roku) plugged into a specific physical ethernet port, and then a second one for everything else, covering all the other ports and the WiFi?

If that's how it's set up, we can totally fix this using two VLANs. One VLAN is for DirecTV—looks like that one's already there, labeled VDSL Management. The second VLAN would be for everything else.

Can you double-check if the actual physical port where your Roku is plugged in belongs to that specific VLAN (VDSL Management)?

The plan is to have the router route traffic from VLAN 1 (DirecTV) over to the mobile interface (like 4G?), while VLAN 2 (everything else) stays on the wired interface (VDSL).
It honestly looks like DirecTV set it up the exact opposite way by default.

I'm not exactly sure how to verify this, but I've got access to the router settings via the admin password. I unplugged my Roku from the router (LAN 2) and rebooted everything, yet VDSL Management and IPTV still show as connected—so that's probably just showing what's linked from the router outward. But honestly, what you're saying about it being the exact opposite is likely right. AT&T keeps insisting I can't pull this off and that DirecTV absolutely has to be hardwired.

Here’s the traffic straight from the router. DirecTV is leaking, which means the TV isn't actually being routed through the device right now:

I can't see any images or links here, man. You gotta drop the actual text if you want me to take a look at it.

Here’s the speed test I ran about two minutes after plugging the Roku into the router and getting it up and running.

I can't see the image you're trying to show me. If you want me to take a look at those screenshots or whatever you've got there, you'll need to actually upload them or provide a link I can access. Give me something to work with!

Jack Cook7 said:Alright, so the TV box is using DirecTV (basically the IPTV VDSL setup), while everything else—like the phone and the PC—is just hitting the regular internet?

Or are you actually browsing the web through the TV too?

Exactly. I don't use the internet on the TV. Just browsing and gaming on my laptop. My setup is running Killer WiFi 6 AX1650x and a Killer E2500 Ethernet card.

Jack Cook7 said:What kind of gear are you rocking right now, and what exactly is plugged into it?

The router is a Huawei HA35 and the Roku is a GX-HT501EL. I've got that Roku on the VLAN IPTV VDSL, a VOIP phone on VDSL, and my PC hooked up via WiFi. If it helps, "VDSL Management" is also listed in the router settings. Everything is running on IPv4.

Is there any way to prioritize web traffic over Max TV when I'm using the wired connection on my AT&T hybrid router? Basically, I want the TV to pull from the cellular data while the actual internet traffic stays on the hardline.

Hey, I'm looking to drop about $1,000 on a new laptop. I'm stuck between the new Acer Helios 300 and the Lenovo Y540. Specs are basically identical, but the Y540 has a 12ms response time while the Helios supposedly hits 3ms (allegedly—I can't find any official benchmarks yet...) though it's also $667 more expensive.

There’s an i5 version of the Helios right around that $1,000 mark, but I'm worried about the CPU bottlenecking. Is it even worth it?

Helios 300 i7: https://www.amazon.com/laptops/helios-i7

Lenovo Y540: https://www.bestbuy.com/lenovo-y540

Helios 300 i5: https://www.bhphotovideo.com/helios-i5

Look, an extra $200 isn't nothing, but the screen matters to me. Plus, the Helios seems to have better cooling (running about 5-6°F cooler than the Y540 with the same undervolt). On the flip side, I can't disable Optimus on the Helios, so the GPU always runs through the Intel chip, whereas the Lenovo lets you bypass it and run straight off the Nvidia card. I've also heard rumors that Lenovo is dealing with some BIOS and fan speed issues right now (maybe once they patch that, the temp difference won't matter as much).

Help me pick one, or if anyone has a better suggestion? Or should I just wait a month or two for the Black Friday sales?