Fix changing the MTU for tun/tap devices via TUNSIFINFO/TAPSIFINFO iotcl

[tuexen]

Summary

For changing the MTU on tun devices, it should not matter whether it is done via using ifconfig, which uses a SIOCSIFMTU ioctl() command or doing it using a TUNSIFINFO ioctl() command.
Without this patch, for IPv6 the new MTU is not used when creating routes. Especially, when initiating TCP connections after increasing the MTU, the old MTU is still used to compute the MSS.

Please note the the code change is inspired by if.c.

As suggested by ae@, add a corresponding fix to the tap interface.

Test Plan

Verify that the following two packetdrill tests pass:

65535.pkt2 KBDownload

9000.pkt2 KBDownload

[ae]

It seems the problem, when old MTU is used after changing MTU on interface, also affects all tunneling interfaces gif, gre, ipsec etc. Also, for me it would be better to hide AF-related things like nd6_setmtu() in the rt_updatemtu() implementation.

[tuexen]

Why are also other tunnelling interfaces except for if_tap.c affected? Do they have a socket option to change the MTU? Right now, rt_updatemtu() seems only to be called from if.c, so integrating nd6_setmtu() into rt_updatemtu() can be done. But this would be a separate cleanup in my view.
So I can update the patch to cover also if_tap.c, but for the other tunnelling interfaces could you elaborate why they are also affected?

[ae]

In D17180#367402, @tuexen wrote:

So I can update the patch to cover also if_tap.c, but for the other tunnelling interfaces could you elaborate why they are also affected?

Maybe this is another problem. But that is what I meant:

# ifconfig gif0 create inet 192.168.0.3/24 192.168.0.6 tunnel 10.9.8.3 10.9.8.6
# ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
	options=80000<LINKSTATE>
	tunnel inet 10.9.8.3 --> 10.9.8.6
	inet 192.168.0.3 --> 192.168.0.6 netmask 0xffffff00 
	inet6 fe80::56ee:75ff:fead:8cc7%gif0 prefixlen 64 scopeid 0x7 
	groups: gif 
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
# netstat -rnWf inet | egrep "gif0|Mtu"
Destination        Gateway            Flags       Use    Mtu      Netif Expire
192.168.0.6        link#7             UH            0   1280       gif0
# ifconfig gif0 mtu 4000
# netstat -rnWf inet | egrep "gif0|Mtu"
Destination        Gateway            Flags       Use    Mtu      Netif Expire
192.168.0.6        link#7             UH            0   1280       gif0
# ifconfig gif0 down up
# netstat -rnWf inet | egrep "gif0|Mtu"
Destination        Gateway            Flags       Use    Mtu      Netif Expire
192.168.0.6        link#7             UH            0   4000       gif0

lev@ recently did some performance tests and result was not so expected, but when we did ifconfig gif0 down up, iperf showed better result with updated MTU.

[tuexen]

Now I see what you are referring to. Thanks for the clarification. But this is a different issue. The tun/tap interfaces look like an interface and also like a socket. Setting the MTU via the interface way works as expected. The problem is only when changing it via the socket interface. The other tunnelling interfaces only look like interfaces and share a common method for changing the MTU. This works for the tun/tap interfaces but your example shows that there is an issue related to the outer/inner stuff. I might be able to look into this, but this is definitely a different issue.

[tuexen]

Add corresponding changes to the tap interface.

[bz]

Ok, I started three times already and got an INTR every time; let me ask the question: why are we doing this all manually here rather than calling the (from here) the generic ioctl to set the MTU and avoid the code duplication?

[tuexen]

Avoid code duplication as suggested by bz@.

[tuexen]

In D17180#369833, @bz wrote:

Ok, I started three times already and got an INTR every time; let me ask the question: why are we doing this all manually here rather than calling the (from here) the generic ioctl to set the MTU and avoid the code duplication?

In the beginning I was only touching if_tun.c, but since it now also touches if_tab.c, it makes much more sense to avoid code duplication. So I changed the patch, however, I have to expose ifhwioctl().
Are you now fine with the patch?