Bug 693235

Summary: SIOCSIFMTU: Invalid argument
Product: [Fedora] Fedora Reporter: Daniel Mach <dmach>
Component: vpncAssignee: Christian Krause <chkr>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: 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 Flags
A description what fails
none
Proposed fix. none

Description Daniel Mach 2011-04-03 19:58:18 UTC
When I start vpnc, I get:
'SIOCSIFMTU: Invalid argument' error message

vpnc works as expected after that

selinux is in permissive
vpnc version is vpnc-0.5.3-9.fc15.i686


Here's a relevant part of strace output:
ioctl(4, SIOCSIFADDR, {ifr_name="tun0", ifr_addr={AF_INET, inet_addr("...")}}) = 0
ioctl(4, SIOCGIFFLAGS, {ifr_name="tun0", ifr_flags=IFF_POINTOPOINT|IFF_NOARP|IFF_MULTICAST}) = 0
ioctl(4, SIOCSIFFLAGS, {ifr_name="tun0", ifr_flags=IFF_UP|IFF_POINTOPOINT|IFF_RUNNING|IFF_NOARP|IFF_MULTICAST}) = 0
ioctl(4, SIOCSIFDSTADDR, {ifr_name="tun0", ifr_dstaddr={AF_INET, inet_addr("...")}}) = 0
ioctl(4, SIOCGIFFLAGS, {ifr_name="tun0", ifr_flags=IFF_UP|IFF_POINTOPOINT|IFF_RUNNING|IFF_NOARP|IFF_MULTICAST}) = 0
ioctl(4, SIOCSIFFLAGS, {ifr_name="tun0", ifr_flags=IFF_UP|IFF_POINTOPOINT|IFF_RUNNING|IFF_NOARP|IFF_MULTICAST}) = 0
ioctl(4, SIOCSIFNETMASK, {ifr_name="tun0", ifr_netmask={AF_INET, inet_addr("...")}}) = 0
ioctl(4, SIOCGIFADDR, {ifr_name="tun0", ifr_addr={AF_INET, inet_addr("...")}}) = 0
ioctl(4, SIOCSIFBRDADDR, {ifr_name="tun0", ifr_broadaddr={AF_INET, inet_addr("...")}}) = 0
ioctl(4, SIOCSIFMTU, {ifr_name="tun0", ???}) = -1 EINVAL (Invalid argument)

Comment 1 Henrique Martins 2011-05-26 05:16:54 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.

Comment 2 Henrique Martins 2011-05-26 05:32:27 UTC
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.

Comment 3 Jens Hektor 2011-05-27 04:58:38 UTC
Created attachment 501246 [details]
A description what fails

Comment 4 Fred Wittekind IV 2011-07-26 16:02:58 UTC
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.

Comment 5 Henrique Martins 2011-07-26 16:24:26 UTC
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.

Comment 6 Fred Wittekind IV 2011-07-26 21:50:22 UTC
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.

Comment 7 Henrique Martins 2011-07-26 22:00:57 UTC
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.

Comment 8 Fred Wittekind IV 2011-07-27 01:43:31 UTC
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.

Comment 9 Fred Wittekind IV 2011-07-28 02:07:35 UTC
Created attachment 515615 [details]
Proposed fix.

Reworked expression in script to extract the MTU from the newer version of iproute-2

Comment 10 Fedora Admin XMLRPC Client 2011-08-31 00:43:31 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 11 Christian Krause 2011-09-11 15:22:53 UTC
I have fixed the issue in RAWHIDE. The update will be available in F16 and F15 shortly.

Comment 12 Fedora Update System 2011-09-11 16:32:51 UTC
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

Comment 13 Fedora Update System 2011-09-11 16:35:14 UTC
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

Comment 14 Fedora Update System 2011-09-25 23:18:28 UTC
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.

Comment 15 Fedora Update System 2011-09-30 19:07:04 UTC
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.