Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#847135: openconnect: vpn connection mtu too big
343 views
Skip to first unread message
martin
Dec 5, 2016, 5:10:02 PM12/5/16
to
Package: openconnect
Version: 7.07-1
Severity: important
Dear Maintainer,
* What led up to the situation?
Connecting to the VPN
Any connection sending large amounds of data fails
http downloads of any non trivial file, opening a remote desktop connection
* What exactly did you do (or not do) that was effective (or ineffective)?
connections fail when sending large data as the packet size is too bug
* What was the outcome of this action?
Connections seem to hand or fail
* What outcome did you expect instead?
Successful data transfer
Please see this for discussion of the problem:
https://bbs.archlinux.org/viewtopic.php?id=200183
Adding the script as proposed at the top of the thread works well as does just
setting the MTU to a lower value after connecting
ip link set vpn0 mtu 1186
please could we fix this, it took a little tracking down and I imagine others
might find this harder to find.
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.8.3 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages openconnect depends on:
ii libc6 2.24-5
ii libgnutls30 3.5.6-7
ii libopenconnect5 7.07-1
ii libproxy1v5 0.4.13-1.1
ii libxml2 2.9.4+dfsg1-2.1
ii vpnc-scripts 0.1~git20150318-1
openconnect recommends no packages.
openconnect suggests no packages.
-- no debconf information
Version: 7.07-1
Severity: important
Dear Maintainer,
* What led up to the situation?
Connecting to the VPN
Any connection sending large amounds of data fails
http downloads of any non trivial file, opening a remote desktop connection
* What exactly did you do (or not do) that was effective (or ineffective)?
connections fail when sending large data as the packet size is too bug
* What was the outcome of this action?
Connections seem to hand or fail
* What outcome did you expect instead?
Successful data transfer
Please see this for discussion of the problem:
https://bbs.archlinux.org/viewtopic.php?id=200183
Adding the script as proposed at the top of the thread works well as does just
setting the MTU to a lower value after connecting
ip link set vpn0 mtu 1186
please could we fix this, it took a little tracking down and I imagine others
might find this harder to find.
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.8.3 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages openconnect depends on:
ii libc6 2.24-5
ii libgnutls30 3.5.6-7
ii libopenconnect5 7.07-1
ii libproxy1v5 0.4.13-1.1
ii libxml2 2.9.4+dfsg1-2.1
ii vpnc-scripts 0.1~git20150318-1
openconnect recommends no packages.
openconnect suggests no packages.
-- no debconf information
David Woodhouse
Dec 5, 2016, 5:30:02 PM12/5/16
to
Hm, if you use OpenConnect on the command line do you see the same
problem? What MTU does OpenConnect actually ask for? And if you update
to the latest version from git (which I really ought to release as 7.08
some time soon) does that fix it?
The Arch bug you link is ancient; that sounds like it's from the days
when NetworkManager didn't actually honour the MTU that OpenConnect
requested. That shouldn't be the case nowadays.
--
dwmw2
problem? What MTU does OpenConnect actually ask for? And if you update
to the latest version from git (which I really ought to release as 7.08
some time soon) does that fix it?
The Arch bug you link is ancient; that sounds like it's from the days
when NetworkManager didn't actually honour the MTU that OpenConnect
requested. That shouldn't be the case nowadays.
--
dwmw2
Martin
Dec 6, 2016, 3:00:02 AM12/6/16
to
including the bug tacker this time (and extra notes at the end):
From the command line on 7.08 I get:
Established DTLS connection (using GnuTLS). Ciphersuite
(DTLS0.9)-(DHE-RSA-4294967237)-(AES-128-CBC)-(SHA1).
Too long time in MTU detect loop; MTU set to 1401.
Detected MTU of 1401 bytes (was 1406)
However the newer version works fine after this and the old version doesn't
Though obviously the MTU is wrong but the new version does somehow cope.
I'll try and find time to investigate why it's timing out detecting the MTU
From the command line on 7.08 I get:
Established DTLS connection (using GnuTLS). Ciphersuite
(DTLS0.9)-(DHE-RSA-4294967237)-(AES-128-CBC)-(SHA1).
Too long time in MTU detect loop; MTU set to 1401.
Detected MTU of 1401 bytes (was 1406)
However the newer version works fine after this and the old version doesn't
Though obviously the MTU is wrong but the new version does somehow cope.
I'll try and find time to investigate why it's timing out detecting the MTU
David Woodhouse
Dec 6, 2016, 5:10:02 AM12/6/16
to
information about what it's doing.
--
dwmw2
Martin
Dec 6, 2016, 4:50:03 PM12/6/16
to
Please would you consider packaging the newer version as I doubt I'll be
the only person to hit this and the new version does make it all simply
work.
The current packaged version seems to drop packets with it's MTU, I see
missed sequences in the packet trace and retransmissions but I never get
the missed packets back. The connections either drop or sit there
waiting...
Though the new version seems to ignore the interface mtu setting when
choosing the MTU, it does seems to work which makes me very happy.
interfaces:
2: wlp58s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc mq state UP
mode DORMANT group default qlen 1000
3: vpn0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1401 qdisc
pfifo_fast state UP mode DEFAULT group default qlen 500
I would have expected the vpn connection to have a smaller mtu than that
of the network interface it was running over.
Also I wouldn't be surprised if our VPN end point had firewalls that
prevented easy MTU discovery.
Thanks,
M
the only person to hit this and the new version does make it all simply
work.
The current packaged version seems to drop packets with it's MTU, I see
missed sequences in the packet trace and retransmissions but I never get
the missed packets back. The connections either drop or sit there
waiting...
Though the new version seems to ignore the interface mtu setting when
choosing the MTU, it does seems to work which makes me very happy.
interfaces:
2: wlp58s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc mq state UP
mode DORMANT group default qlen 1000
3: vpn0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1401 qdisc
pfifo_fast state UP mode DEFAULT group default qlen 500
I would have expected the vpn connection to have a smaller mtu than that
of the network interface it was running over.
Also I wouldn't be surprised if our VPN end point had firewalls that
prevented easy MTU discovery.
Thanks,
M
Mike Miller
Dec 9, 2016, 5:40:03 PM12/9/16
to
Control: tags -1 + fixed-upstream
On Tue, Dec 06, 2016 at 21:38:50 -0000, Martin wrote:
> Please would you consider packaging the newer version as I doubt I'll be
> the only person to hit this and the new version does make it all simply
> work.
>
> The current packaged version seems to drop packets with it's MTU, I see
> missed sequences in the packet trace and retransmissions but I never get
> the missed packets back. The connections either drop or sit there
> waiting...
>
>
> Though the new version seems to ignore the interface mtu setting when
> choosing the MTU, it does seems to work which makes me very happy.
So you believe git master fixes this issue for you and if/when 7.08
becomes available you would consider this resolved?
Thanks,
--
mike
On Tue, Dec 06, 2016 at 21:38:50 -0000, Martin wrote:
> Please would you consider packaging the newer version as I doubt I'll be
> the only person to hit this and the new version does make it all simply
> work.
>
> The current packaged version seems to drop packets with it's MTU, I see
> missed sequences in the packet trace and retransmissions but I never get
> the missed packets back. The connections either drop or sit there
> waiting...
>
>
> Though the new version seems to ignore the interface mtu setting when
> choosing the MTU, it does seems to work which makes me very happy.
becomes available you would consider this resolved?
Thanks,
--
mike
Martin
Dec 10, 2016, 7:40:03 AM12/10/16
to
> So you believe git master fixes this issue for you and if/when 7.08
> becomes available you would consider this resolved?
Yes, happy to close with the new version.
> becomes available you would consider this resolved?
Thanks,
M
Martin
Dec 10, 2016, 8:00:03 AM12/10/16
to
> So you believe git master fixes this issue for you and if/when 7.08
> becomes available you would consider this resolved?
been working well
Thanks,
M
Steinar H. Gunderson
Dec 19, 2016, 4:10:03 AM12/19/16
to
severity 847135 grave
thanks
On Mon, Dec 05, 2016 at 09:04:57PM +0000, martin wrote:
> * What led up to the situation?
> Connecting to the VPN
> Any connection sending large amounds of data fails
> http downloads of any non trivial file, opening a remote desktop connection
Hi,
I'm seeing this, too, and it makes VPN completely unusable for me (upgraded
from 7.06). I'm a bit surprised this was allowed to go into testing, but
stretch should definitely not be released with such a bug; upgrading to RC.
> Adding the script as proposed at the top of the thread works well as does just
> setting the MTU to a lower value after connecting
>
> ip link set vpn0 mtu 1186
This workaround works for me; thanks for figuring it out. :-)
/* Steinar */
--
Homepage: https://www.sesse.net/
thanks
On Mon, Dec 05, 2016 at 09:04:57PM +0000, martin wrote:
> * What led up to the situation?
> Connecting to the VPN
> Any connection sending large amounds of data fails
> http downloads of any non trivial file, opening a remote desktop connection
I'm seeing this, too, and it makes VPN completely unusable for me (upgraded
from 7.06). I'm a bit surprised this was allowed to go into testing, but
stretch should definitely not be released with such a bug; upgrading to RC.
> Adding the script as proposed at the top of the thread works well as does just
> setting the MTU to a lower value after connecting
>
> ip link set vpn0 mtu 1186
/* Steinar */
--
Homepage: https://www.sesse.net/
Mike Miller
Jan 31, 2018, 5:10:03 PM1/31/18
to
On Wed, Dec 13, 2017 at 14:06:03 +0100, Adam Cecile wrote:
> Hello,
Hi,
> 7.08 still have the issue. I cannot push a docker image through openconnect.
> It stalls around 50Mbytes.
Upstream has kindly asked for more information on your issue, can you
please provide a response to
http://lists.infradead.org/pipermail/openconnect-devel/2017-December/004618.html
?
--
mike
> Hello,
Hi,
> 7.08 still have the issue. I cannot push a docker image through openconnect.
> It stalls around 50Mbytes.
Upstream has kindly asked for more information on your issue, can you
please provide a response to
http://lists.infradead.org/pipermail/openconnect-devel/2017-December/004618.html
?
--
mike
0 new messages