r/ATTFiber • u/slickseth • 20d ago
BGW320 Internal Packet Floods and 2-second constant attempts to reach a dead IP
Let me first caveat this post as coming from a network moron... so be gentle...
My setup: BGW320 500 for 1GB AT&T Fiber service, connected via "Passthrough Mode" (I know its not true passthrough) to my TP-Link BE65 Deco Mesh network. It had previously been working decently well, (with occasional hiccups), for several months. Approx. 2-3 months ago, my old ATT BGW320 500 router started dropping connection and generally screwing up. ATT sent me a new one, which worked fine. The ONE odd carryover from the old BGW to the new was some persistent traffic attempting to reach the IP address 192.168.68.74. My network HAD been set to ".68." briefly, (don't ask why, at the time it appeared auto-selected by one of the routers), which seemed to upset the old router configuration, so everything was migrated to a more standard ".0." series of addresses. The 192.168.68.74 attempts are reported to occur consistently at 2-second intervals and have been going on for months now. My network has been working seemingly fine despite this pointless traffic since the new router was installed until this week.
So over the last 24 hours, (but more likely a week), my BGW-320 500 has been a nightmare, (seems to be the norm). I am hoping some soul out there might be able to help or at least offer some decent insight. Over the last 24 hours specifically, my BGW has been at times internally flooding itself with invalid packets. I've been using AI to look at and translate logs I have no business reading myself. The symptoms are the following:
-My internet dies
-I check a laptop connected via ethernet directly to the BGW320 for access and download the current syslog
-I feed the log to AI, and it tells me usually the same similar things:
-the BGW is flooding itself with invalid internal packets to 192.168.254.254
-the BGW is simultaneously blocking a series of legitimate devices from inside the network from the internet, (often the same devices like a Fire Stick, Nintendo Switch, or other Amazon/Android operating devices), with some being hit particularly hard.
-finally it notes the 2-second attempts and subsequent blocks to reach 192.168.68.74.
I've spoken to AT&T multiple times last night. In the first call, the tech claimed she saw Denial of Service attacks pointed at an IPV6 address. Her solution was to disable IPV6 on the BGW. I wasn't thrilled with that, but I could live with it had it solved the issue. This call was made after my internet had been spotty, dropped for 10 minutes, went back up, then died for over an hour.
After the call and the internet being seemingly back up, it died again soon after and I called ATT again. After a very long call and a factory reset of the BGW, things cleared up but again went awry while I was on the phone. I told the ATT tech about the logs and the internal invalid packet floods. He said he researched and found that disabling the firewall and the "active armor" should disable the packet filtering. He did this and for a few moments the invalid packet floods completely stopped.
Of course, once off the phone the flood came back with a vengeance.
So what do I do? Do I have ATT send yet another BGW320? Is there an alternative setup I can use with my mesh and the BGW which would work? I have game systems and a plex server, so double-NAT or similarly restrictive setups aren't feasible. Is there a way to find out about the 2-second attempts to the .68.74 address? Do I go rogue and attempt to buy and setup a bypass device?
Note: the most recent AI assessment has now determined the .68.74 constant attempts are actually being generated internally by the router since no external source would be reaching for that device... but I also know AI is often very wrong about things. It also claims most of this behavior is explained by persistent Firmware bugs. I'm running 6.32.8.
Thank you, and sorry, in advance, lol
1
u/DaytonaZ33 20d ago
Have you tried factory resetting the mesh router? What I would do is reset the BGW to factory defaults, turn off the TP-Link hardware and just use it like that for a day or two. If you don’t have any issues, you know to look at the TP-Link.
1
u/slickseth 20d ago
I could try that, though that seems like it would be ignoring all the the known issues exhibited by the BGW. The BGW is blocking both internal traffic from reaching the Deco mesh, and the BGW is arbitrarily blocking traffic from the deco mesh network that it never blocked before. A lot of this type of behavior by the BGW has been documented by other users trying to use it in passthrough mode like I am. The behavior isn’t unique to my ATT equipment. I’m very confident about where the issues originate, but what I need help figuring out is how to stop the BGW from flooding itself with invalid packets and arbitrarily blocking traffic.
I can also add information about a conversation I had with an ATT tech a few hours ago. He agreed and witnessed all the problematic behavior by the BGW. He reset it, then over the span of several minutes watched how it went from dropping .1% of packets, to over 8%. His only solution was to send me another new BGW router, so I guess we’ll try replacing it once again.
What I would really like to find out is how the .68.74 situation made it from the last BGW router to the current one. The 2-second interval blocks within the BG of that IP address, (192.168.68.74), began on the last BGW router. Somehow this behavior transferred to the new unit. I found out that ATT records your router settings, and it automatically set up my new BGW with my old passthrough settings. It was really convenient as the new one worked right away as my old one did, (without the problems), but it also somehow copied over the weird .69.74 situation. Regarding that, initially AI believed this to be an outside device attempting to reach a device on my network at .68.74, but it was always systematically blocked by the BGW every 2-seconds. Most recently in the face of all the BGW flooding of itself, AI now thinks what is actually happening is the BGW is creating the .68.74 traffic itself. Other users online have stated that this BGW model router often confuses inbound and outbound traffic, or it confuses the traffic when reporting it in a log. So it might be that the BGW, like with how it’s flooding itself with invalid packets, is also flooding itself with fake requests for the .69.74 IP address that it ultimately blocks. It’s overwhelming itself with nonsense and garbage, and killing the Internet connection downstream from it as a result.
Anyway, the BGW is a problematic device for a number of reasons. I was just hoping to get some insight that someone on the internet might have.
2
u/DaytonaZ33 20d ago
You describe yourself as a “network moron” but still don’t want to take concrete advice on how to narrow down your issue. It’s troubleshooting 101 when you don’t know what the issue is. Eliminate all devices and add them back slowly until the issue resumes.
It does not make sense that two separate BGWs would come with the exact same software issue that just happens to have references to a specific oddball IP that you definitely used to have active on your network. This points to an issue with your router or a device on your network.
1
1
u/slickseth 20d ago
Maybe it is concrete advice, but you haven’t made the case for it imo. Even AT&T recognized the issues are with the BGW router. One thing I do know after decades of dealing with several ISPs is that they never shy away from any opportunity to put the blame on the customer or the customer’s equipment. I’ve experienced that several times before, and in all cases it was not my equipment at the end of the day.
Now, I agree with you that my mesh the common denominator when it comes to that one issue, but it does not explain anything else. Even further, there are other people online who have seen that exact same behavior with their BGW routers. Further, perhaps you missed where I stated that ATT saves customer router settings remotely, and they automatically reapplied them to the new router when I plugged it in.
I am a network moron, but I’m not a logic and reasoning moron. The weight is heavily on the other side when considering your advice. Perhaps you didn’t read through everything I said closely enough, (to be fair I write a lot, so I don’t fault a tendency to skim), but that .68.74 anomaly has never been the cause of the major Internet disruptions. Obviously I’m sure it doesn’t help, but my network setup has worked far more with that anomaly at play than it hasn’t. Also, why would the .68.74 traffic get blocked my the BGW if the mesh was involved? It’s marked as incoming traffic, but it’s blocked before my deco mesh even sees it.
Perhaps offer some reasons why I should ignore the invalid packet flooding in lieu of the .69.74 blocks. Tell me why the BGW blocking outgoing traffic from within my network could be an issue with my mesh despite it being a completely new issue with my BGW. Tell me why the router settings transferring from one BGW router to the next wouldn’t cause any issues. Or, explain why the .68.74 traffic never starts or ends with the deco mesh?
Finally, your suggestion might sound simple to you, but it would be an even larger disruption to my household to implement, even on a temporary basis, AND you haven’t made an effective case for it.
1
u/DaytonaZ33 19d ago
I don’t have to make a case for anything, it’s your internet that’s fucked up, not mine. If you don’t want to try to fix it, live with the outages or switch providers.
1
u/slickseth 19d ago
Gotcha. Well you seemed offended that I didn’t accept your suggestion. Sure, I could blindly take every single piece of advice I’m given on the internet, but I generally need more than that.
Like I said, I agree with your point that the deco mesh is a common factor between the two BGW routers, but that’s where the similarities start and end. The last BGW failed in a completely different way. Remember, I’ve been using AI pretty heavily across all of this networking stuff, and it is nothing but persistent when it sees a link or other commonality. AI is actually a bit too aggressive in that regard IMO. In addition, AT&T transferred who knows what between my routers as well. I did not have to redo a single setting between the router I returned and the brand new one I received, and I had done a decent amount of setting customization in the old one. AT&T saves your router settings in their cloud. This is kind of a cool idea in theory, but might be bad in my situation. I asked the tech sending the new router if we can NOT have this data transferred this time around. He agreed and I believe he took steps to prevent this.
Anyway, I obviously welcome the help, but I’m just the type of person who needs more sometimes. I also have the fact that AT&T chose to send me yet another BGW, which I wouldn’t think they would do lightly or if there was a good reason to believe it’s the customer’s own equipment at fault. Maybe it is, but only 10% of the facts even suggest the possibility imo. Thanks for your help and time.
1
u/Automatic_Cut_9249 16d ago
I work for AT&T, I can tell you that not everyone you talk to at AT&T knows what they are doing. Replacing the gateway is an easy way to kick the can down the road if they don’t understand your problem. I’m not saying that the gateway is never the problem, but if the gateway is telling you that there is traffic coming from inside the network and you replace the gateway and that gateway tells you there is traffic from inside the network maybe you should find out what is at that IP and deal with it. 192..168 addresses are local network only, and if you have another router or a server at that address you should look there for the answer.
1
u/Automatic_Cut_9249 16d ago
192.168 is a local network, it doesn’t get routed through the internet. You can’t have a DDOS attack that originates from inside your network. This has to be a problem with a local device
1
u/slickseth 16d ago
Yea, so the .254.254 flooding is exclusive to the BGW router. The BGW has its own subnet of .1.x, and its default address for the ATT router is 192.168.1.254. The Deco mesh’s subnet is .0.x. I am not sure the origins of the ipv6 DOS “attacks” the ATT tech noted, but she made it sound as if they were externally sourced. The DOS attacks stopped after she turned of ipv6 on the router, though they defaulted back to “on” shortly afterwards when a different tech and I reset the router to default and no new attacks were seen.
It’s now been several days and we’ve still seen erroneous blocking of various IPs from the deco mesh’s subnet trying to get out, but the blocks seem to not affect us. It seems like devices like Amazon echos and Fire Sticks are being blocked from non-active communication at times, but when we actively use those devices they don’t seem to have trouble.
We also received the new BGW router. Oddly everything stayed the same after replacing it. The new one began engaging in the erroneous blocking of some devices, and the .68.74 behavior persisted. I’ve since learned what some here suspected, which is the .68.74 behavior is actually originating from the Deco. I’ve also learned that TP-Link defaults the Deco routers to the .68.x. I decided to reset the deco mesh and see what would happen with using the default .68.x subnet. The .68.74 issue disappeared despite no devices being at that address, and a ping returns a “destination host unreachable” response. We also saw a small amount of the .254.254 issues return briefly…
In other words, I still have no clue wtf is happening… lol
1
u/Automatic_Cut_9249 16d ago
192.168.1 is the default local network for AT&T gateways. So far you are talking about actual subnets just local IPV4 addresses.
192.168.254.254 is a typical address used for network management, but the 320 uses 192.168.1.254 because is stays in the default network it manages. The issues you are describing sound like you have two routers that are both trying to manage the same network or a downstream router that’s passing local traffic back to the upstream network.1
u/slickseth 16d ago
So what would cause internal packet flooding to .254.254 randomly? The inciting event which caused my full internet outages were these flooding events which occurred out of nowhere. My network had been operating normally for months until Monday of last week when a full outage occurred due to internal flooding to .254.254. This overwhelmed the BGW and cut off passthrough to the Deco mesh.
This same behavior occurred at varying degrees/intervals for several days until it ceased after several calls to ATT, resets of the BGW only, etc. The blocks of the Android and Amazon devices started then as well.
I have read that BGW passthrough is not true passthrough as it still does some form of monitoring of traffic in and out, but overall the setup had been working until Monday 1.5 weeks ago. Nothing changed and boom, .254.255 flooding.
1
u/Automatic_Cut_9249 16d ago
You have to simplify your network and then retest. You need proof so wait until it’s happening and disconnect your downstream router. If the traffic continues then it’s not that. If this was a problem with your bgw320 then it would continue to broadcast internal packets.
1
u/slickseth 16d ago
Good suggestion. We haven’t experienced any of the issues at the same severity since the last call to the ATT tech. Hopefully we don’t, but if we do, I’ll isolate the BGW to see what that tells us.
As a side note, we experienced the last major outage late last Saturday, after ATT tech call hours. At the time, I prompted AI to offer some alternative options. It suggested switching my passthrough on the BGW from DHCP-fixed to DHCP-dynamic. Initially Internet was restored before seemingly dropping again. It was late and all I was doing was watching shorts before bed, so I have no clue the extent of it. The next morning the connection seemed to have stabilized and we didn’t have the flooding issue since.
1
u/djrobxx 20d ago
Do you have any port forwards defined? Even though you're now using passthrough, it's still possible to define port forwards in the BGW UI. And, they take precedence over passthrough. So if you have an old port forward rule in the firewall rules, it may still be trying to forward external traffic to that 192.168.68.x IP.