Router Unknown Transmitting

Hi Everyone,

I have a Buffalo Wireless Router, running with a DD-WRT v23 SP2
firmware. I installed it today after my venerable WRT54G finally
passed.

While the Buffalo is operating fine, I am concerned about a constant
transmitting of packets going on, even after all my wireless devices
have been shut down. It appears that every 3 seconds or so, the
wireless LED flickers, and after looking at the router via DD-WRT, it
is transmitting 3-4 packets every 3-4 seconds.I tried disabling the
broadcast of the SSID, but to no avail. Possible good sign, is that
there does not appear to be any packets received while this goes on.

Does anyone have any ideas as to what might be causing this, as while
it appears to be harmless, I'd prefer to not be transmitting whatever
in such a constant fashion.

Thanks for your help,
mick

Mikester <none@email.com> hath wroth:

>I have a Buffalo Wireless Router, running with a DD-WRT v23 SP2
>firmware.

Any particular model number? Just curious.
Also, just for curiosity, that's the exact firmware version? Click on
the link the box on the right of the main "Status -> Sys Info" web
page. I'm running:
DD-WRT v23 SP3 (07/21/07) std (SVN revision 7509)
DD-WRT v23 SP2 (09/13/06) std (SVN revision 3927)

>I installed it today after my venerable WRT54G finally
>passed.

Are you sure it's dead? Have you tried punch and hold reset to
default and trying again? I've seen far too many dead wall warts.
Check the power supply with a volts guesser.

>While the Buffalo is operating fine, I am concerned about a constant
>transmitting of packets going on, even after all my wireless devices
>have been shut down. It appears that every 3 seconds or so, the
>wireless LED flickers, and after looking at the router via DD-WRT, it
>is transmitting 3-4 packets every 3-4 seconds.

It transmits far more junk than that. First, let me explain how the
light works. The beacon interval is 10 times per second. To keep the
light from flashing almost constantly, the light only comes on when
the packet size is above some threshold. The problem is that the
threshold will vary radically between different firmware
implementations. There are also versions that flash the light even
when the xmitter is disabled as the circuit is driven by the digital
logic, and not by the RF from the transmitter. Basically, it's a
psychology problem. Users want to see the light, but not too often.

>I tried disabling the
>broadcast of the SSID, but to no avail. Possible good sign, is that
>there does not appear to be any packets received while this goes on.

Well, it's possible that you're looking at the digital drive from the
logic instead of the actual xmitter RF. It doesn't take much to build
an RF detector. Some of the more sensitive microwave oven detectors
will do it. Do you have an oscilloscope, microwave diode detector,
and some discrete parts hanging around?

>Does anyone have any ideas as to what might be causing this, as while
>it appears to be harmless, I'd prefer to not be transmitting whatever
>in such a constant fashion.

Well, I assume you don't want it transmitting normally when nobody is
using the system. I don't think that's possible. As a quick check,
disconnect *ALL* the CAT5 cables going to your unspecified Buffalo.
Still see flashing? If not, then the flashing LED was the result of
broadcasts, ARP requests, connectivity checks, keep alive's, server
announcements, and a mess of other broadcasts that announce the
presence of a device or program.

Now, with the CAT5 cables still disconnected, try turning off the
power to the Buffalo and then back on. Still flashing? If so,
there's probably some program running on the router that's belching
broadcasts. If the flashing went away, then there was some service,
that had lost its connection to one of your wireless clients (laptop)
and was trying to reconnect or determine its status.

If you leave the xmitter enabled, I don't think you'll be able to get
the router to shut up. They system is just too busy to do that.
However, I am concerned that the light is flashing when the xmitter is
disabled in the firmware. Sniffers, such as Ethereal and Wireshark
can be used to determine what is being transmitted, but with the
xmitter off, NOTHING should be transmitted.

I just had a thought. Perhaps the light is responding to receive
packets and not transmit. Turning off the radio in firmware might
turn off the transmitter, but leave the receiver enabled. I'll test
that here and see what happens.

--
Jeff Liebermann jeffl@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On Tue, 14 Aug 2007 04:45:28 -0700, Jeff Liebermann <jeffl@cruzio.com>
wrote:

>Mikester <none@email.com> hath wroth:
>
>>I have a Buffalo Wireless Router, running with a DD-WRT v23 SP2
>>firmware.
>
>Any particular model number? Just curious.
>Also, just for curiosity, that's the exact firmware version? Click on
>the link the box on the right of the main "Status -> Sys Info" web
>page. I'm running:
> DD-WRT v23 SP3 (07/21/07) std (SVN revision 7509)
> DD-WRT v23 SP2 (09/13/06) std (SVN revision 3927)
>
>>I installed it today after my venerable WRT54G finally
>>passed.
>
>Are you sure it's dead? Have you tried punch and hold reset to
>default and trying again? I've seen far too many dead wall warts.
>Check the power supply with a volts guesser.
>
>>While the Buffalo is operating fine, I am concerned about a constant
>>transmitting of packets going on, even after all my wireless devices
>>have been shut down. It appears that every 3 seconds or so, the
>>wireless LED flickers, and after looking at the router via DD-WRT, it
>>is transmitting 3-4 packets every 3-4 seconds.
>
>It transmits far more junk than that. First, let me explain how the
>light works. The beacon interval is 10 times per second. To keep the
>light from flashing almost constantly, the light only comes on when
>the packet size is above some threshold. The problem is that the
>threshold will vary radically between different firmware
>implementations. There are also versions that flash the light even
>when the xmitter is disabled as the circuit is driven by the digital
>logic, and not by the RF from the transmitter. Basically, it's a
>psychology problem. Users want to see the light, but not too often.
>
>>I tried disabling the
>>broadcast of the SSID, but to no avail. Possible good sign, is that
>>there does not appear to be any packets received while this goes on.
>
>Well, it's possible that you're looking at the digital drive from the
>logic instead of the actual xmitter RF. It doesn't take much to build
>an RF detector. Some of the more sensitive microwave oven detectors
>will do it. Do you have an oscilloscope, microwave diode detector,
>and some discrete parts hanging around?
>
>>Does anyone have any ideas as to what might be causing this, as while
>>it appears to be harmless, I'd prefer to not be transmitting whatever
>>in such a constant fashion.
>
>Well, I assume you don't want it transmitting normally when nobody is
>using the system. I don't think that's possible. As a quick check,
>disconnect *ALL* the CAT5 cables going to your unspecified Buffalo.
>Still see flashing? If not, then the flashing LED was the result of
>broadcasts, ARP requests, connectivity checks, keep alive's, server
>announcements, and a mess of other broadcasts that announce the
>presence of a device or program.
>
>Now, with the CAT5 cables still disconnected, try turning off the
>power to the Buffalo and then back on. Still flashing? If so,
>there's probably some program running on the router that's belching
>broadcasts. If the flashing went away, then there was some service,
>that had lost its connection to one of your wireless clients (laptop)
>and was trying to reconnect or determine its status.
>
>If you leave the xmitter enabled, I don't think you'll be able to get
>the router to shut up. They system is just too busy to do that.
>However, I am concerned that the light is flashing when the xmitter is
>disabled in the firmware. Sniffers, such as Ethereal and Wireshark
>can be used to determine what is being transmitted, but with the
>xmitter off, NOTHING should be transmitted.
>
>I just had a thought. Perhaps the light is responding to receive
>packets and not transmit. Turning off the radio in firmware might
>turn off the transmitter, but leave the receiver enabled. I'll test
>that here and see what happens.


Hi Jeff,

First off, let me thank you for offering some assistance. It is
certainly appreciated.

I will try to quickly answer some of your questions pertaining to the
hw/sw, and I'll try to perform some of the troubleshooting tasks later
tonite.

As for the Buffalo Wireless Router, it is a model WHR-G54S.
As for the DD-WRT firmware, it is v23 SP2 (09/15/06) std

Thanks for your help again, and looking forward to your test results
also.

Take Care,
mikester

Hi Jeff,

Put an Etheeal test on the Buffalo WHR-G54S router, from a desktop PC
wired to the router. It appears that the rogue packets are
'Spanning-tree-(for-bridges)_00' with Protocol Info of 'STP'.

This certainly constitutes the great majority of packets going out.
Are these normal type packets that should be transmitted? Could you
provide some info as to their purpose, and validity? In your opinion,
is this activity normal/expected?

Again, Thanks for your help

take care,
mikester

Mikester <none@email.com> hath wroth:

>Put an Etheeal test on the Buffalo WHR-G54S router, from a desktop PC
>wired to the router. It appears that the rogue packets are
>'Spanning-tree-(for-bridges)_00' with Protocol Info of 'STP'.
>
>This certainly constitutes the great majority of packets going out.
>Are these normal type packets that should be transmitted? Could you
>provide some info as to their purpose, and validity? In your opinion,
>is this activity normal/expected?

Ummm... maybe. I'm not very good at protocol disection. What you
have to remember is that wireless that 802.11 wireless is
fundamentallyl bridging. Everything happens at layer 2. The router
layer 3 section is just tacked onto the end of one of the switched
ports and is largely independent of the wireless sections. If you
remove or disable the router section, you're left with a "wireless
ethernet bridge".

What you're seeing are the packets and protocols that make bridging
work. In this case, you're seeing some of the BPDU broadcasts
required by the STP (spanning tree protocol) which is used to prevent
bridging loops. See:
<http://en.wikipedia.org/wiki/Spanning_tree_protocol>
Basically a BPDU broadcast contains the local bridge ID address, and a
list of connected devices and priorities. The processor chews on
these and builds a minimum hop tree through which to switch the
packets (and prevent bridge loops). The default for these BPDU
broadcasts is about 2 seconds after some preset delay. I think these
2 second broadcasts is what you're seeing.

I'm not 100.0% sure that you're seeing exactly the same broadcasts
over the wireless bridge as you are over the wired. However, it's
highly likely.

You only need STP if you have more than one route to a destination.
STP (spanning tree protocol) can be disabled on the main WAN setup
page. (STP should be disabled for Comcast cable):
<http://www.dd-wrt.com/wiki/index.php/Spanning_Tree_Protocol>

--
Jeff Liebermann jeffl@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

Hi Jeff,

Thanks for your help. After reviewing the info re: the STP protocol,
it appeared that it wasn't a necessity in my environment here. I moved
to disable the STP proocol in DD-WRT, and rebooted everything.
The spnning-tree packets are no longer being sent out every 2 seconds,
and the LED no longer blinks. Ethereal analysis of the wireless router
now shows all as quiet.

Thanks again for your help!

mikester




On Tue, 14 Aug 2007 20:16:32 -0700, Jeff Liebermann <jeffl@cruzio.com>
wrote:

>Mikester <none@email.com> hath wroth:
>
>>Put an Etheeal test on the Buffalo WHR-G54S router, from a desktop PC
>>wired to the router. It appears that the rogue packets are
>>'Spanning-tree-(for-bridges)_00' with Protocol Info of 'STP'.
>>
>>This certainly constitutes the great majority of packets going out.
>>Are these normal type packets that should be transmitted? Could you
>>provide some info as to their purpose, and validity? In your opinion,
>>is this activity normal/expected?
>
>Ummm... maybe. I'm not very good at protocol disection. What you
>have to remember is that wireless that 802.11 wireless is
>fundamentallyl bridging. Everything happens at layer 2. The router
>layer 3 section is just tacked onto the end of one of the switched
>ports and is largely independent of the wireless sections. If you
>remove or disable the router section, you're left with a "wireless
>ethernet bridge".
>
>What you're seeing are the packets and protocols that make bridging
>work. In this case, you're seeing some of the BPDU broadcasts
>required by the STP (spanning tree protocol) which is used to prevent
>bridging loops. See:
><http://en.wikipedia.org/wiki/Spanning_tree_protocol>
>Basically a BPDU broadcast contains the local bridge ID address, and a
>list of connected devices and priorities. The processor chews on
>these and builds a minimum hop tree through which to switch the
>packets (and prevent bridge loops). The default for these BPDU
>broadcasts is about 2 seconds after some preset delay. I think these
>2 second broadcasts is what you're seeing.
>
>I'm not 100.0% sure that you're seeing exactly the same broadcasts
>over the wireless bridge as you are over the wired. However, it's
>highly likely.
>
>You only need STP if you have more than one route to a destination.
>STP (spanning tree protocol) can be disabled on the main WAN setup
>page. (STP should be disabled for Comcast cable):
><http://www.dd-wrt.com/wiki/index.php/Spanning_Tree_Protocol>