MLVPN
MLVPN copied to clipboard
zehome
[WARN/tuntap] cannot send packet: too big
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.
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....)
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.
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?
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.
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)
(BTW, I added the proposed patch to my pull request https://github.com/zehome/MLVPN/pull/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)
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)
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
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....
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
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
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...
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
server: 1400
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.1 P-t-P:172.16.16.1 Mask:255.255.255.252
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1400 Metric:1
the errors are only on client (debian 7) Maybe it's not a problem to have debian 7 client, and debian 8 server, i've compil MLVPN
but it's strange to have different mtu on client / server, no? (var mtu on mlvpn.conf is not set on client and server)
setting the MTU to 1200, and adding some output, I see mlvpn: Setting MTU on mlvpn0 to 1200: Success but then when I check the interface ifconfig mlvpn0 mlvpn0 ... MTU:1432 I think something is broken around the place where the MTU is set
mmhhh... setting mtu (client) to 1200 launch mlvpn with --debug -v
2016-12-14T13:25:12 [ DBG] absolute maximum mtu: 1444 2016-12-14T13:25:12 [INFO/config] new password set 2016-12-14T13:25:12 [INFO/config] adsl1 tunnel added 2016-12-14T13:25:12 [INFO/config] adsl2 tunnel added 2016-12-14T13:25:12 [INFO] created interface `mlvpn0' 2016-12-14T13:25:12 [ DBG/wrr] adsl2 weight = 36.363636 (800000 2200000) 2016-12-14T13:25:12 [ DBG/wrr] adsl1 weight = 63.636364 (1400000 2200000) 2016-12-14T13:25:12 [INFO] adsl1 bind to 192.168.1.245 2016-12-14T13:25:12 [ DBG/protocol] adsl1 mlvpn_rtun_challenge_send 2016-12-14T13:25:12 [INFO] adsl2 bind to 192.168.2.245 2016-12-14T13:25:12 [ DBG/protocol] adsl2 mlvpn_rtun_challenge_send 2016-12-14T13:25:12 [ DBG/net] > adsl2 sent 46 bytes (size=2, type=0, seq=0, reorder=1) 2016-12-14T13:25:12 [ DBG/net] > adsl1 sent 46 bytes (size=2, type=0, seq=0, reorder=1) 2016-12-14T13:25:13 [ DBG/rtt] 28ms srtt 28ms loss ratio: 0 2016-12-14T13:25:13 [ DBG/net] < adsl1 recv 46 bytes (type=1, seq=0, reorder=1) 2016-12-14T13:25:13 [INFO/protocol] adsl1 authenticated 2016-12-14T13:25:13 [ DBG/rtt] 56ms srtt 56ms loss ratio: 0 2016-12-14T13:25:13 [ DBG/net] < adsl2 recv 46 bytes (type=1, seq=0, reorder=1) 2016-12-14T13:25:13 [INFO/protocol] adsl2 authenticated 2016-12-14T13:25:13 [ DBG/net] > adsl2 sent 96 bytes (size=52, type=3, seq=0, reorder=1) 2016-12-14T13:25:13 [ DBG/rtt] 16ms srtt 51ms loss ratio: 0
see first line, and yes ifconfig said mtu to 1372
redundantly, the mtg is being set by the code when the mlvpn device is brought up, but then it is likely re-set when the statuscommand is run (you should check what you have put in there) That was my confusion, but for me, the status command is correctly setting the MTU on the device to whatever I have set the MTU on the tunnel to in the conf file - which is less than the absolute maximum, so I dont see why you get 'long' packets still....
mhhhh.... i set mss to 1350 with iptables on Client AND Server. web surf seem to be ok, and more faster. No error