Does OpenVPN generate MAC Pause (01:80:c2:00:00:01) packets?

myce · Post by **myce** » Tue Jan 25, 2011 10:41 am

Hello,

I have the following problem on a router (Speedport W500V with this firmware http://bitswitcher.sourceforge.net/):

Some time (minutes to an hour) after the OpenVPN daemon is started, the network does no longer react and all that is seen on eth0 is MAC Pause packets:
(Captured with Wireshark:)

Code: Select all

0000   01 80 c2 00 00 01 01 80 c2 00 00 01 88 08 00 01  ................
0010   ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0020   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0030   00 00 00 00 00 00 00 00 00 00 00 00              ............

Ethernet II, Src: Spanning-tree-(for-bridges)_01 (01:80:c2:00:00:01), Dst: Spanning-tree-(for-bridges)_01 (01:80:c2:00:00:01)
    Destination: Spanning-tree-(for-bridges)_01 (01:80:c2:00:00:01)
        Address: Spanning-tree-(for-bridges)_01 (01:80:c2:00:00:01)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: Spanning-tree-(for-bridges)_01 (01:80:c2:00:00:01)
        Address: Spanning-tree-(for-bridges)_01 (01:80:c2:00:00:01)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: MAC Control (0x8808)
MAC Control
    Pause: 0x0001
    Quanta: 65535

These packets are generated in an endless loop which can only be stopped by killing the OpenVPN daemon. Which leads me to think that it is indeed the OpenVPN daemon who generates these packets. Am I right here? I couldn't yet find the appropriate part in the sources.
What can I do about this?

BTW: Besides just waiting for it to happen, I can provoke this by sending many packets to the router in quick succession. Which makes me think that the daemon detects some kind of overrun and requests a slowdown. The sensible thing to do, I'd say. The only problem is that it doesn't break out of this loop.
Maybe I should mention that during the tests no OpenVPN connection was active, i.e. the daemon was basically idle.

Regards,
M. Hamer

Post by **gladiatr72** » Wed Jan 26, 2011 3:17 pm

Please post your (comment-stripped) configuration. I have some ideas, but I need to see what kind of config you're running. Also, what OS/version/distro are you running? If it is linux, please include the output of 'brctl show', 'ifconfig -a' and 'netstat -rn'.

-Stephen

myce · Post by **myce** » Thu Jan 27, 2011 9:54 am

Hello Stephen,

thanks for your offer to help.
Here is my configuration:

Code: Select all

tls-server
dev tap0
proto tcp-server
port 1194
persist-key
persist-tun
ca /opt/openvpn/keys/ca.crt
cert /opt/openvpn/keys/vpnserver_cert.crt
key /opt/openvpn/keys/vpnserver_cert.key
dh /opt/openvpn/keys/dh1024.pem
tls-auth /opt/openvpn/keys/tls_auth_shared.key
verb 3

It is a router running version 0.3.8 of this firmware (http://bitswitcher.sourceforge.net/(Sorry, page is in German only))
uname -a gives

Code: Select all

Linux BS 2.6.8.1 #29 Wed Aug 18 12:07:03 CEST 2010 mips unknown

brctl show:

Code: Select all

bridge name     bridge id               STP enabled     interfaces
br0             8000.001638b818ac       no              eth0
                                                        wl0
                                                        nas_1_32
                                                        tap0

ifconfig -a:

Code: Select all

atm0      Link encap:UNSPEC  HWaddr 00-60-10-00-31-00-10-00-00-00-00-00-00-00-00-00
          [NO FLAGS]  MTU:0  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:766287504 (730.7 MiB)  TX bytes:54061200 (51.5 MiB)

br0       Link encap:Ethernet  HWaddr 00:16:38:B8:18:AC
          inet addr:192.168.100.1  Bcast:192.168.100.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:309177 errors:0 dropped:0 overruns:0 frame:0
          TX packets:509909 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:23526782 (22.4 MiB)  TX bytes:705639692 (672.9 MiB)

cpcs0     Link encap:UNSPEC  HWaddr 88-D0-FF-FF-FF-00-10-00-00-00-00-00-00-00-00-00
          [NO FLAGS]  MTU:65535  Metric:1
          RX packets:0 errors:1811 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:766287504 (730.7 MiB)  TX bytes:54061200 (51.5 MiB)

dsl0      Link encap:UNSPEC  HWaddr 88-D0-00-00-00-00-10-00-00-00-00-00-00-00-00-00
          [NO FLAGS]  MTU:0  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 00:16:38:B8:18:AC
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:229945 errors:0 dropped:0 overruns:0 frame:0
          TX packets:384161 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:26827770 (25.5 MiB)  TX bytes:535481283 (510.6 MiB)
          Interrupt:28 Base address:0x6000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:23 errors:0 dropped:0 overruns:0 frame:0
          TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:9756 (9.5 KiB)  TX bytes:9756 (9.5 KiB)

nas_1_32  Link encap:Ethernet  HWaddr 00:16:38:B8:18:AE
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:568311 errors:0 dropped:0 overruns:0 frame:0
          TX packets:353210 errors:0 dropped:4934 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:743011962 (708.5 MiB)  TX bytes:46283096 (44.1 MiB)

ppp_1_32_ Link encap:Point-to-Point Protocol
          inet addr:84.60.48.206  P-t-P:84.60.0.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:552009 errors:0 dropped:0 overruns:0 frame:0
          TX packets:336876 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:737845798 (703.6 MiB)  TX bytes:34359484 (32.7 MiB)

tap0      Link encap:Ethernet  HWaddr 00:FF:8C:A2:25:C1
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:41515 errors:0 dropped:0 overruns:0 frame:0
          TX packets:31098 errors:0 dropped:2728 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:36604854 (34.9 MiB)  TX bytes:9314815 (8.8 MiB)

wl0       Link encap:Ethernet  HWaddr 00:16:38:B8:18:AD
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:101246 errors:0 dropped:0 overruns:0 frame:1207485
          TX packets:165439 errors:23 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:11176667 (10.6 MiB)  TX bytes:211918063 (202.1 MiB)
          Interrupt:32

netstat -rn

Code: Select all

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
84.60.0.1       0.0.0.0         255.255.255.255 UH        0 0          0 ppp_1_32_1
192.168.100.0   0.0.0.0         255.255.255.0   U         0 0          0 br0
0.0.0.0         84.60.0.1       0.0.0.0         UG        0 0          0 ppp_1_32_1

The Version of OpenVPN in use is 2.1_rc13

-Mike

Post by **gladiatr72** » Wed Feb 09, 2011 3:25 pm

Greetings,

Apologies for the delay in responding!

The MAC Control pause frames are an element of the spanning tree algorithm. Unless you've got another switch in the mix, other than the build-in on, the only possible part to this setup that could be generating STP frames is the bridge device itself.

I'm not an STP expert, by any stretch, but I believe these are generated in response to a switching loop. Some device that is attached to the bridge is receiving its own broadcast (ethernet) frame from another "port" on the bridge.

Can you tell me a bit more about what sort of devices you have plugged into your router?

-Stephen

myce · Post by **myce** » Thu Feb 10, 2011 11:22 am

Hi,

during testing I tried to get as many factors out of the way as possible. So I reduced the setup to just a PC and the router.
Being neither a bridge nor a STP expert myself I assumed that these packets would not be generated by the bridge itself, as brctl says "STP enabled: no" (see my previous post).
The fact that generation of the packets stops as soon as I kill the OpenVPN-daemon led me to the assumption that the STP-packets were generated by the daemon itself. Can you rule this out? (Coming back to the initial question of the thread ("Does OpenVPN generate...?")) If you are sure the packets aren't coming from the daemon, I'll have to try and broaden my knowledge on bridges...

Regards
Mike

Post by **janjust** » Thu Feb 10, 2011 11:31 am

OpenVPN does not generate MAC Pause packets by itself, at least I have never seen it anywhere in the source code.

The fact that you see these packets after OpenVPN starts is more likely related to the fact that OpenVPN forwards (and broadcasts) all traffic from the remote end - if there are STP packets generated there by a switch then OpenVPN will happily forward them. This happens regardless of whether STP is enabled on the bridge or not.

HTH,

JJK

myce · Post by **myce** » Fri Feb 11, 2011 9:15 am

janjust wrote:OpenVPN does not generate MAC Pause packets by itself, at least I have never seen it anywhere in the source code.

If we can rule out OpenVPN and the bridge (due to STP being disabled) for generating the packets, I'm quite confused as there don't seem to be any other components involved. (See below)

janjust wrote:The fact that you see these packets after OpenVPN starts is more likely related to the fact that OpenVPN forwards (and broadcasts) all traffic from the remote end - if there are STP packets generated there by a switch then OpenVPN will happily forward them. This happens regardless of whether STP is enabled on the bridge or not.

The daemon was running but idle. I.e. there was no active OpenVPN connection. So it can't have forwarded them from anywhere.

When I described the setup in the previous post, I probably should have explicitly stated that the WAN-side of the router is not connected to anything in the test setup.
The problem occured with the router being integrated in the network with DSL connected on one side and my network with some switches on the other side. When I ran into the problem, I unplugged one device after the other until I ended up with just the PC running wireshark and some script to generate packets and the router, still being able to reproduce the problem.
Next I replaced the router in the test network with an identical model and rebuilt the production network with OpenVPN disabled. The test network still showed the problem and the production network is running stable since then. (But without OpenVPN)

Could the problem be that there was no active OpenVPN connection? Might the packets get generated (by the daemon or the bridge or whoever) since the daemon sees packets on the internal network, realizes that it can't send them anywhere and requests a slowdown (maybe after some buffer fills up)?

Regards,
Mike

Post by **janjust** » Fri Feb 11, 2011 11:13 am

MAC Pause frames are normally generated by switches that wish to slow down incoming traffic , e.g. if traffic is coming on one port at 1 Gbps but it needs to go out a 100 Mbps port the buffers on the switch can fill up too quickly. In that case the switch can send the MAC Pause frames. Linux clients can send similar frames if configured correctly, I'm not sure if Windows has this built in also.

Perhaps a switch or router on your LAN is being flooded with packets due to a STP loop when the bridge is enabled and OpenVPN is active, but not connected?

HTH,

JJK

myce · Post by **myce** » Fri Feb 11, 2011 2:31 pm

janjust wrote:MAC Pause frames are normally generated by switches that wish to slow down incoming traffic , e.g. if traffic is coming on one port at 1 Gbps but it needs to go out a 100 Mbps port the buffers on the switch can fill up too quickly. In that case the switch can send the MAC Pause frames.

Yes, I'm aware of that.

janjust wrote: Perhaps a switch or router on your LAN is being flooded with packets due to a STP loop when the bridge is enabled and OpenVPN is active, but not connected?

As I tried to explain already: I thinned out the network until it just consisted of the PC doing the logging and the router running OpenVPN. There is no other router/switch that could generate the packets.

--Mike

OpenVPN Support Forum

Does OpenVPN generate MAC Pause (01:80:c2:00:00:01) packets?

Does OpenVPN generate MAC Pause (01:80:c2:00:00:01) packets?

Re: Does OpenVPN generate MAC Pause (01:80:c2:00:00:01) pack

Re: Does OpenVPN generate MAC Pause (01:80:c2:00:00:01) pack

Re: Does OpenVPN generate MAC Pause (01:80:c2:00:00:01) pack

Re: Does OpenVPN generate MAC Pause (01:80:c2:00:00:01) pack

Re: Does OpenVPN generate MAC Pause (01:80:c2:00:00:01) pack

Re: Does OpenVPN generate MAC Pause (01:80:c2:00:00:01) pack

Re: Does OpenVPN generate MAC Pause (01:80:c2:00:00:01) pack

Re: Does OpenVPN generate MAC Pause (01:80:c2:00:00:01) pack