Contributor
•
2 Messages
Gateway encapsulating packets in VLAN ID 0 from wifi to wired
I have the following RG for my U-Verse internet service:
Model 3800HGV-B
Serial Number **** [edited for privacy]
Hardware Version 2700-100531-006
Software Version 6.9.1.42-plus.tm
I discovered that I can no longer communicate from my wifi-connected laptop through the RG to a home automation controller on the wired network because the packets get encapsulated in an 802.1Q (VLAN) header with ID 0. It looks like this encapsulation happens for packets going from the wifi side to any device on the wired network, but the Mac Mini seems to tolerate the additional encapsulation so communication still works. VLAN ID 0 is supposed to be treated as an untagged packet, but apparently the home automation controller is not prepared for this. I used to be able to communicate with this controller using all the same devices in the same configuration, but it has been some months since I last needed to do so, therefore I can't say when this behavior changed. I suspect that a software update to the RG caused the change. Is there a way to turn off this behavior?
Accepted Solution
Official Solution
SomeJoe7777
Expert
•
9.4K Messages
10 years ago
The firmware in the 2Wire/Pace gateways is not built by AT&T, it is 2Wire/Pace code. 2Wire/Pace's firmware has a huge number of capabilities because they provide gateways to many Internet providers, all of whom want their customers to have a different feature set available. VLAN capability is one of the things that the firmware can do, but that AT&T is not using and has locked the users out of. However, if the configuration information has become corrupted, then the firmware might be attempting to do something with VLAN tagging, even though it shouldn't.
A factory reset will clear the configuration information in non-volatile RAM and return the unit to the factory defaults.
0
0
SomeJoe7777
Expert
•
9.4K Messages
10 years ago
I recommend you reset the RG to factory defaults using the last button at the bottom of this page:
http://192.168.1.254/xslt?PAGE=C_5_7
0
0
slcasner
Contributor
•
2 Messages
10 years ago
Thanks for your suggestion, but I doubt that random corruption of the firmware would cause a specific behavior like this to be introduced. I think the 802.1q tagging with ID 0 is intentional to allow priority assignment to different packet streams. I found the following description of the feature in Cisco routers with a diagram that fits this scenario:
VLAN 0 Priority Tagging Overview
The tagging should not be applied where traffic enters the RG from the wireless side, it should be applied when the traffic is heading out the broadband interface. I say that's a bug in the implementation.
Does RTFD put back the original firmware? Probably not. But even if it did, since AT&T has control to download new firmware any time they want to, I can't prevent this problem from returning.
0
0