#82 closed Bug / Defect (worksforme)
OpenVPN generates flood of CTL MAC Pause packets
Reported by: | myce | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Networking | Version: | OpenVPN 2.1.0 / 2.1.1 (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | |
Cc: |
Description
On a router using OpenVPN 2.1-RC3 the following happens:
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:)
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.
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.
Change History (3)
comment:1 Changed 14 years ago by
comment:2 Changed 12 years ago by
Resolution: | → worksforme |
---|---|
Status: | new → closed |
No comments from the reporter, closing the bug.
comment:3 Changed 6 years ago by
The article is very nice i found a lot of informative information http://vucredits.com i have if you want full enjoy then try to imvu game i sure like it.
I doubt you've been using 2.1-RC3 ... as we've not really released 2.2-RC officially. Except of having a few Windows versions with 2.2-RC-preview, to see if our new building system have worked or not.
However, can you provide more config information? It would be good if it is possible to figure out the minimal OpenVPN configuration which causes this to happen. Then it's easier to see which code paths to look at in the source.
Also try this on a OpenVPN 2.1 release. This is to identify if it is a regression or an older bug.