On Wed, 2013-06-19 at 17:23 +0200, Thomas Richter wrote: > If this is of any help: This is a DSL line by the German Telekom, which > is up to my knowledge PPPoe between my router and their system. But what > the MTU is, or whether MTU actually applies to this technology I do not > know. Your MTU is likely to be 1492. There's 8 bytes of overhead for the PPP part of PPPoE, which we subtract from the normal Ethernet MTU of 1500. I note that then you are missing the incoming DTLS packets, you are *actually* receiving one fragment out of the pair. This is often a symptom of a poor network connection or driver. What's "special" about fragmented packets (if they're fragmented locally) is that they are sent in *quick* succession, really closely together. And often the second one is lost. However, in your case in the problematic period I'm looking at (07:36:52) you are receiving the *second* fragment out of each packet (offset 744 onwards), not the first. Which is really weird. That's almost as if some firewall kicked in and started rejecting the start of those packets (which contains the UDP port number etc.) but still had to allow the fragments because it didn't know whether it could drop them. Or something weird like that. Can you get a packet capture from the public-facing side of your home network, on the outbound interface of your DSL router? Or as far "upstream" as you can, preferably on the outside of your NAT? It would be interesting to get a packet capture from a router at the VPN server end if you can, too. We'd check that they really are *sending* the offending packets, and whether they're receiving any ICMP responses. > > It's entirely possible that some complete retard would respond to this > > breakage by deciding to fragment *all* outbound packets to a maximum of > > 750 bytes, instead of fixing the broken firewall. > > > > It isn't necessarily related to your local network at all. It *might* > > have been doing that before, on your working system. It probably was. > > Anyhow, I kept playing a bit, and set the MTU to 700 manually in a test > script. Result is that network connectivity becomes normal. So indeed, > packet segmentation *is* the source of the evil. How precise is that? Does 700 work and 701 fail with missing packets? I'd have thought it would be higher. > However, why did this work before, I don't know. Can you make one of your machines fail again by downgrading (perhaps just openconnect and openssl) to what you had before? Even if you just install the old openconnect and relevant libraries in a chroot? It would be very interesting to compare. > and - probably more important - how I can make it work with the network manager? Simple answer: mv /usr/sbin/openconnect /usr/sbin/openconnect.real cat >> /usr/sbin/openconnect <<EOF #!/bin/sh exec $0.real --mtu=700 "$@" EOF chmod +x /usr/sbin/openconnect Ideally, we should add an option to the NetworkManager config properly, for this and --no-dtls. And/or maybe just an arbitrary 'passthrough' of manually-entered options to add to the openconnect command line. > Neither do I. Did openconnect possibly adjust the MTU dynamically in > earlier releases? No. ISTR your "upgraded" machines are still on the pathetically ancient 3.20 release; I dread to think what you were using before that. Perhaps it was *so* old that it didn't do DTLS at all? Newer versions will attempt to do some slightly more complex MTU negotiation with the server (if the server is new enough to support that), but it's all a bit hit-and-miss. The Cisco scheme for doing this is very unreliable, and made even more so because we're not sure we fully understand it. I'd certainly suggest trying 5.01 and seeing what happens with it. When you're on the university network and things are working, do you *still* see these weirdly fragmented packets? Alternatively, if you're at home and you do something else to trigger incoming UDP packets from elsewhere, are *they* weirdly fragmented and sometimes missing? -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20130619/a117a330/attachment.bin>
