[WARN/tuntap] cannot send packet: too big

[TKR-US]

Bonjour,

j'aggrege 2 lignes vdsl d'un meme fournisseur, qui ont une latence identique, mais un débit différent (problème que je dois voir car ce n'est pas normal).
Ligne 1: 34.4 Mbps / 11.2 Mbps (réel)
Ligne 2: 22.24 Mbps / 7 Mbps (réel)

Total réel obtenu: 44 Mbps / 16.8 Mbps
-> beaucoup de perte sur le download pour le moment...

Mais je vois quand je passe en mode débug des lignes du type:
2016-12-13T06:48:04 [WARN/tuntap] cannot send packet: too big 1500/1444. truncating
2016-12-13T06:48:05 [WARN/tuntap] cannot send packet: too big 1492/1444. truncating
2016-12-13T06:48:05 [WARN/tuntap] cannot send packet: too big 1477/1444. truncating

Et ce, que je touche ou non à MTU dans la conf mlvpn.

Dans iptables j'ai un
iptables -A POSTROUTING -t mangle -p tcp --tcp-flags SYN,RST SYN -o mlvpn0 -j TCPMSS --set-mss 1350

De ce que je comprends, il essaie d'envoyer un packet > 1444, mais je n'arrive pas a voir ce que je peux faire pour l'empecher d'envoyer un paquet > à la MTU

Une idée? Cela a visiblement pour conséquence de problème pour le "surf" classique, plus que pour le téléchargement un fichier, et du coup ca a tendance à créer des timeout.

[markfoodyburton]

Looking at the code, to me there would seem to be a bug
https://github.com/zehome/MLVPN/blob/master/src/tuntap_linux.c#L19
I'm assuming your using Linux (the same applies to all the other platforms)
Can you try changing this line to read
ret = read(tuntap->fd, &data, tuntap->maxmtu);

(It would seem that the code fetches a 'default sized' block, and then complains when that turns out to be larger than the mtg size that it can actually handle.... doesn't make sense to me.... anyway, if that fixes it for you, then I can try and roll a patch, but I dont have access to anything but Linux, so I'm reluctant to patch BSD and Darwin variants....)

[markfoodyburton]

Hopefully @zehome can confirm this anyway :-)

[TKR-US]

Hi

I change it on server and client.. now wait and see :)

[zehome]

Ok that's an error in the code, but I don't that it will the problem @BzH35 had.

En français, c'est une erreur dans le code ce que pointe @markfoodyburton mais je ne pense pas que cela résolve le problème de @BzH35.

[markfoodyburton]

On the assumption that @BzH35 was streaming through a high bandwidth (and high MTU) network, then I would guess it's more than possible that there would be large packets available, hence the error?

[zehome]

The thing is the tuntap interface is set to a lower MTU than what mlvpn can transmit through the network.
By setting through the OS the MTU on an interface, the OS can't exceed that MTU, so it should not be possible to receive a packet bigger than that.

[markfoodyburton]

see what you mean, it's opened with tuntap->maxmtu, is the read combining packets?
(BTW - where do you fill packets to send on the tunnel, I dont see how that works)

[markfoodyburton]

(BTW, I added the proposed patch to my pull request #69 , but it would be good to gave @BzH35's feedback to know if it fixed it, and it would be better to understand why)

[zehome]

basically, what I understand is that a read on tuntap will always read one and only one packet. (with or without Packet Information (PI))

So, if MTU on the tuntap device is 1200.
The router receives a 1500 bytes packet from another interface from a client PC, to send through MLVPN.
The router has to either fragment the packet to send to the tuntap device or drop the packet.

On the other hand, if the MTU is not the same on client and server side, then problems will occur:

• Remote side sends "raw" 1400bytes of IP packet with payload encapsulated in MLVPN UDP protocol.
• Local side receives the encapsulated packet, mlvpn decapsulate it then finds that the payload is 1400bytes, but the local tuntap is 1350.. MLVPN must drop the packet (and log a warning)

[zehome]

After thinking, I think i'll revert the read(fd, tuntap->maxmtu) thing because doing so will just silently corrupt received packets. I think it's preferrable to not be able to send it on the other side and log an error

[markfoodyburton]

If your right (on the tuntap side), then I agree, if we read 'only' maxmtu bytes, but there is a bigger packet there, then we will have silently truncated the packet, further more, we will have left some data in the tuntap interface, which will probably destroy the tunnel from then on? (We would be somehow out of sync ?). But then - I'd really like to understand how this can happen in the first place, as it sounds suspiciously like it could be related to a problem I'm seeing where a tunnel "dies" even though data seems to be able to flow through the interface freely....

[TKR-US]

i confirm, it's hide the real problem. Maybe i've some packets dropped, because we have problem with "classic" surf, lot of timeout on websites, we must doing lot of F5 :(

I remove the line on tuntap_linux.c

[TKR-US]

and now :
2016-12-14T11:12:33 [WARN/tuntap] cannot send packet: too big 1476/1444. truncating
2016-12-14T11:12:33 [WARN/tuntap] cannot send packet: too big 1476/1444. truncating
2016-12-14T11:12:33 [WARN/tuntap] cannot send packet: too big 1476/1444. truncating
2016-12-14T11:12:33 [WARN/tuntap] cannot send packet: too big 1476/1444. truncating
2016-12-14T11:12:33 [WARN/tuntap] cannot send packet: too big 1476/1444. truncating
2016-12-14T11:12:33 [WARN/tuntap] cannot send packet: too big 1476/1444. truncating
2016-12-14T11:13:15 [WARN/tuntap] cannot send packet: too big 1500/1444. truncating
2016-12-14T11:13:15 [WARN/tuntap] cannot send packet: too big 1500/1444. truncating
2016-12-14T11:13:18 [WARN/tuntap] cannot send packet: too big 1470/1444. truncating
2016-12-14T11:13:18 [WARN/tuntap] cannot send packet: too big 1470/1444. truncating
2016-12-14T11:13:18 [WARN/tuntap] cannot send packet: too big 1470/1444. truncating

[markfoodyburton]

Just to be sure, can you do an ifconfig on the mlvpn device when it's up, and tell us what the MTU is listed as...

[TKR-US]

mlvpn0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.16.2 P-t-P:172.16.16.2 Mask:255.255.255.252
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1372 Metric:1