Helpful Links

Gateway encapsulating packets in VLAN ID 0 from wifi to wired

Contributor

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?

1,145 Views
Message 1 of 4
Expert

Re: Gateway encapsulating packets in VLAN ID 0 from wifi to wired

The RG should not add 802.1q VLAN tags to any packet on any interface. If your RG is doing this, then there is corruption in its firmware.

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

Message 2 of 4
Contributor

Re: Gateway encapsulating packets in VLAN ID 0 from wifi to wired

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.

Message 3 of 4
Highlighted
Expert

Re: Gateway encapsulating packets in VLAN ID 0 from wifi to wired

To be more specific, it's not really the firmware itself that I believe is corrupted, but the configuration information stored inside the RG in non-volatile RAM.

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.
Tags (1)
Message 4 of 4
You must type a description before you click preview or reply.
Share this topic
Announcements

Welcome to the internet boards! Check out our troubleshooting articles below and don’t forget to search the forums - your question may have been answered already!

Service acting up? Click here to troubleshoot now!

For DSL related issues. We highly recommend chatting with our teams to address this as quickly as possible.

Additional Support