search

zehome / MLVPN

Multi-link VPN (ADSL/SDSL/xDSL/Network aggregation / bonding)
http://www.mlvpn.fr/
BSD 2-Clause "Simplified" License
518 stars 127 forks source link

[WARN/tuntap] cannot send packet: too big #91

Open TKR-US opened 7 years ago

TKR-US commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Hopefully @zehome can confirm this anyway :-)

TKR-US commented 7 years ago

Hi

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

zehome commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

(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)

zehome commented 7 years ago

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:

zehome commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

TKR-US commented 7 years ago

on the mlvpn.conf, mtu= is disable by #

zehome commented 7 years ago

can you show us both sides please

TKR-US commented 7 years ago

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

markfoodyburton commented 7 years ago

What OS/version are you running?

TKR-US commented 7 years ago

server: debian 8 client: debian 7

MLVPN: mlvpn version master-5ac9ec4.

TKR-US commented 7 years ago

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)

markfoodyburton commented 7 years ago

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

TKR-US commented 7 years ago

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

markfoodyburton commented 7 years ago

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....

TKR-US commented 7 years ago

mhhhh.... i set mss to 1350 with iptables on Client AND Server. web surf seem to be ok, and more faster. No error