Bug 693235
Summary: | SIOCSIFMTU: Invalid argument | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Daniel Mach <dmach> | ||||||
Component: | vpnc | Assignee: | Christian Krause <chkr> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 15 | CC: | chrissharp09, fedora, nbansal, rjones, rom | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2011-11-18 15:16:09 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Daniel Mach
2011-04-03 19:58:18 UTC
Get the same error. Bug seems to be in vpnc-script an rpm that provides /etc/vpnc/vpnc-script but it is not in the list of components here on bugzilla, when the script invokes do_ifconfig do_ifconfig() { if [ -n "$INTERNAL_IP4_MTU" ]; then MTU=$INTERNAL_IP4_MTU elif [ -n "$IPROUTE" ]; then MTU=$(($($IPROUTE route get "$VPNGATEWAY" | sed -ne 's/^.*mtu \([[:digit:]]\+\).*$/\1/p') - 88)) else MTU=1412 fi # Point to point interface require a netmask of 255.255.255.255 on some systems ifconfig "$TUNDEV" inet "$INTERNAL_IP4_ADDRESS" $ifconfig_syntax_ptp "$INTERNAL_IP4_ADDRESS" netmask 255.255.255.255 mtu ${MTU} up In my case INTERNAL_IP4_MTU is not set, IPROUTE is /sbin/ip and it's output does not contain an mtu value, thus MTU is set to -88 and the suceeding ifconfig fails. I'm working around it by setting INTERNAL_IP4_MTU to 1500. I don't see a flag in man ip that will make the get command return the mtu. Here are the rpms from a fresh f14->f15 yum upgrade: vpnc-script-0.5.3-9.fc15.noarch vpnc-0.5.3-9.fc15.i686 though as I said in #1, the problem seems to be in vpnc-script. Created attachment 501246 [details]
A description what fails
I get the same error message (SIOCSIFMTU), also Fedora 15 [rom@nova ~]$ rpm -q vpnc-script vpnc vpnc-script-0.5.3-9.fc15.noarch vpnc-0.5.3-9.fc15.x86_64 [rom@nova ~]$ rpm -qV vpnc-script vpnc ?........ c /etc/vpnc/default.conf Mine on the other hand does not work as expected after the error. It behaves like it has a misconfigured MTU (which it likely does). If I ssh to a remote server over the VPN, and issue a command with short output, everything works as it should, if I issue a command with long output the ssh session closes. I assume the reason for this, is the MTU setting on the VPN tunnel ends up being 1500 when the MTU on the physical device (eth0) is also 1500, add in the the overhead of the VPN session (I assume that is the purpose of the "- 88" in the expression in the script), and the packet doesn't get though. Add this line at the top of the script INTERNAL_IP4_MTU=1500 which will then be reduced by 88 later on, and you should be fine. Actually, it takes INTERNAL_IP4_MTU literal if it's set (not reduced by 88), setting to 1500 removed the error message, but did not fix the issue of ssh sessions closing when I issue commands with long output. Setting INTERNAL_IP4_MTU to 1412 does fix both issues. Work-arounds are nice (and very much appreciated), but, updated packages are better. Now that the issue is more than just the error message, does that change the priority of addressing this? I poked around a bit with the ip route get command, and I can see on older Fedora boxes it does return MTU, on Fedora 15 it doesn't. I'll try more later to find a real fix, if I can find one, I'll post it. You're right! Either the MTU on my device is larger than 1500 or I haven't experienced the bug. Not sure what you call long output but I usually open a vpn connection to work then lots of rdesktop windows that I assume have large data transfers and never had the line drop on me. On the xterm where I did the vpn-connect I usually open a gnuclient connection to my xemacs running on another F15 machine at work and that one never drops either. I'm wondering if support of MTU's larger than 1500 on the remote end of the VPN may also be a factor. I would not be surprised if jumbo frames where turned on somewhere on the network at my work (intentionally). Long output would be greater than 1412 characters in this case. Pretty easy to do. Created attachment 515615 [details]
Proposed fix.
Reworked expression in script to extract the MTU from the newer version of iproute-2
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. I have fixed the issue in RAWHIDE. The update will be available in F16 and F15 shortly. vpnc-0.5.3-13.svn457.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/vpnc-0.5.3-13.svn457.fc16 vpnc-0.5.3-13.svn457.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/vpnc-0.5.3-13.svn457.fc15 vpnc-0.5.3-13.svn457.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report. vpnc-0.5.3-13.svn457.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. |