Page 1 of 1
Does OpenVPN generate MAC Pause (01:80:c2:00:00:01) packets?
Posted: Tue Jan 25, 2011 10:41 am
by myce
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
Re: Does OpenVPN generate MAC Pause (01:80:c2:00:00:01) pack
Posted: Wed Jan 26, 2011 3:17 pm
by gladiatr72
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
Re: Does OpenVPN generate MAC Pause (01:80:c2:00:00:01) pack
Posted: Thu Jan 27, 2011 9:54 am
by myce
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
Re: Does OpenVPN generate MAC Pause (01:80:c2:00:00:01) pack
Posted: Wed Feb 09, 2011 3:25 pm
by gladiatr72
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
Re: Does OpenVPN generate MAC Pause (01:80:c2:00:00:01) pack
Posted: Thu Feb 10, 2011 11:22 am
by myce
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
Re: Does OpenVPN generate MAC Pause (01:80:c2:00:00:01) pack
Posted: Thu Feb 10, 2011 11:31 am
by janjust
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
Re: Does OpenVPN generate MAC Pause (01:80:c2:00:00:01) pack
Posted: Fri Feb 11, 2011 9:15 am
by myce
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
Re: Does OpenVPN generate MAC Pause (01:80:c2:00:00:01) pack
Posted: Fri Feb 11, 2011 11:13 am
by janjust
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
Re: Does OpenVPN generate MAC Pause (01:80:c2:00:00:01) pack
Posted: Fri Feb 11, 2011 2:31 pm
by myce
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