AT&T hybrid router: Internet priority and ping issues

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?

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.

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.

Chris Rogers2 said: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.

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

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!

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.

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

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.

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.

Chris Rogers2 said: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.

Whoops, turns out 100M is actually a bit much for me...🙂

Anyway, you've basically done all the heavy lifting with the analysis already. The real takeaway here is that gaming UDP packets are tiny. Most frames—whether they're running over local Ethernet or some LTE/broadband connection—are basically empty shells, which means huge overhead (even if WAN frames aren't strictly fixed lengths). Even the biggest UDP packet stays within that 1432-byte end-to-end limit, so we aren't dealing with any fragmentation issues.

What we're still guessing at is whether those UDP packets are splitting across both links during edge cases. If they are, you might run into resequencing headaches, but honestly, the game's own TCP/IP stack usually handles that. Typically, if you're pushing UDP over LTE but receiving it over broadband, you'll get hit with a massive RTT difference between the two paths. The big question is: is the router shifting the entire connection/UDP port XX over to LTE, or is it just dumping the "extra" traffic onto LTE? We just don't know.

Then you've got IPTV streaming (and VoIP), which wants the exact opposite—bigger, jumbo frames. On decent layer 2+ manageable gear, Ethernet usually lets you push 8K to 9K packets, and high-end switches or routers can even handle up to 64K.

So, theoretically, you could tweak the settings on your PC to drop the Ethernet frame size from the standard 1512 down to something like 1024, and crank the TV up to 8192 to boost performance for both.

But man, we're back to square one: you don't have root access to the router. You can optimize things locally all you want, but it doesn't mean squat once the frame hits the broadband or LTE link. The router is just going to repackage everything into whatever frame size it agreed upon with the ISP's equipment or the cell tower, and you've got zero say in that process.

Sadly, I don't see any way to squeeze more performance out of this unless you've got full control over the router.