Two Linux boxes, each plugged in via Ethernet to a BATMAN node (two nodes). The nodes talk batman-advanced to each other via WiFi. The Linux boxes can ping each other all day long. Both Linux boxes have Apache running. Downloading a file via HTTP works only if the file is smaller than or equal to exactly 1,145 bytes. TFTP file transfers are halting, but they get through (4 megabytes took a couple of minutes).
This happens with both r1176 and r1298 on OpenWrt.
On Saturday 20 June 2009 00:17:23 Jacob Marble wrote:
Two Linux boxes, each plugged in via Ethernet to a BATMAN node (two nodes). The nodes talk batman-advanced to each other via WiFi. The Linux boxes can ping each other all day long. Both Linux boxes have Apache running. Downloading a file via HTTP works only if the file is smaller than or equal to exactly 1,145 bytes. TFTP file transfers are halting, but they get through (4 megabytes took a couple of minutes).
This happens with both r1176 and r1298 on OpenWrt.
Sry, haven't followed your other mails so I don't know your whole setup. It looks like a mtu problem for me. Please try to set the mtu a lot lower on your eth devices. You can do a ping test with `ping -s TESTSIZEINBYTE -M dont IPTOSENDIPPACKET` - dont forget to add the 28 extra bytes needed for the whole headers inside the ethernet frame. So `ping -s 1472 -M do 192.168.1.1` would send a 1500 bytes package. You can also set the mtu on your wifi devices higher (and bat0 devices). So for example wifi device to 1524 and bat0 to 1500 (like the eth devices). Also check if you have bridge mtu patch from Simon[1] (included in linux 2.6.27) when you are bridging some of the devices. Also check that icmp "Destination Unreachable" - "Fragmentation required, and DF flag set" isn't filtered anywhere.
Regards, Sven
[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=...
On Fri, Jun 19, 2009 at 7:23 PM, Sven Eckelmannsven.eckelmann@gmx.de wrote:
On Saturday 20 June 2009 00:17:23 Jacob Marble wrote:
Two Linux boxes, each plugged in via Ethernet to a BATMAN node (two nodes). The nodes talk batman-advanced to each other via WiFi. The Linux boxes can ping each other all day long. Both Linux boxes have Apache running. Downloading a file via HTTP works only if the file is smaller than or equal to exactly 1,145 bytes. TFTP file transfers are halting, but they get through (4 megabytes took a couple of minutes).
This happens with both r1176 and r1298 on OpenWrt.
Sry, haven't followed your other mails so I don't know your whole setup. It looks like a mtu problem for me. Please try to set the mtu a lot lower on your eth devices. You can do a ping test with `ping -s TESTSIZEINBYTE -M dont IPTOSENDIPPACKET` - dont forget to add the 28 extra bytes needed for the whole headers inside the ethernet frame. So `ping -s 1472 -M do 192.168.1.1` would send a 1500 bytes package. You can also set the mtu on your wifi devices higher (and bat0 devices). So for example wifi device to 1524 and bat0 to 1500 (like the eth devices). Also check if you have bridge mtu patch from Simon[1] (included in linux 2.6.27) when you are bridging some of the devices. Also check that icmp "Destination Unreachable" - "Fragmentation required, and DF flag set" isn't filtered anywhere.
The nodes running batman-advanced are OpenWrt 8.09.1, which uses kernel 2.6.26.8. The patch is *not* in there, so I have re-flashed (again) with OpenWrt SVN, which uses... 2.6.28.10. Um, if the patch isn't in OpenWrt stable releases, then maybe something should be said on open-mesh.net? Also, I need to make a big fat note in my howto.
The setup is two Ubiquiti NanoStation2 nodes, which have one wifi device and one Ethernet device each. Atheros 231x SoC. ath0 = wifi0, ahdemo, channel = 1 bat0 interfaces = ath0 br-lan (bridge) = bat0 + eth0, IP address set on this device only
The Linux workstations are attached via Ethernet, running Ubuntu.
The MTU, by default, is 1500 on eth0, ath0, wifi0 The MTU, by default, is 1476 on bat0, br-lan
Ping from Linux workstation to Linux workstation works as long as the -s flag is 1448 or less. 1448 = 1476 - 28 The -M do doesn't seem to change anything.
HTTP transfers still don't go through when they are larger than ~1400 bytes. I'll go play with the MTUs now.
On Monday 22 June 2009 21:57:07 Jacob Marble wrote: [...]
You can also set the mtu on your wifi devices higher (and bat0 devices). So for example wifi device to 1524 and bat0 to 1500 (like the eth devices). Also check if you have bridge mtu patch from Simon[1] (included in linux 2.6.27) when you are bridging some of the devices. Also check that icmp "Destination Unreachable" - "Fragmentation required, and DF flag set" isn't filtered anywhere.
[...]
The Linux workstations are attached via Ethernet, running Ubuntu.
The MTU, by default, is 1500 on eth0, ath0, wifi0 The MTU, by default, is 1476 on bat0, br-lan
Ping from Linux workstation to Linux workstation works as long as the -s flag is 1448 or less. 1448 = 1476 - 28 The -M do doesn't seem to change anything.
HTTP transfers still don't go through when they are larger than ~1400 bytes. I'll go play with the MTUs now.
Ok, setting mtu of ath0's to 1524 and of bat0 to 1500 should help here. Just for the sake of completeness: Is there bridging involved in the workstations or any icmp filtering on the workstations/nanostations?
Regards, Sven
On Mon, Jun 22, 2009 at 2:24 PM, Sven Eckelmannsven.eckelmann@gmx.de wrote:
On Monday 22 June 2009 21:57:07 Jacob Marble wrote: [...]
You can also set the mtu on your wifi devices higher (and bat0 devices). So for example wifi device to 1524 and bat0 to 1500 (like the eth devices). Also check if you have bridge mtu patch from Simon[1] (included in linux 2.6.27) when you are bridging some of the devices. Also check that icmp "Destination Unreachable" - "Fragmentation required, and DF flag set" isn't filtered anywhere.
[...]
The Linux workstations are attached via Ethernet, running Ubuntu.
The MTU, by default, is 1500 on eth0, ath0, wifi0 The MTU, by default, is 1476 on bat0, br-lan
Ping from Linux workstation to Linux workstation works as long as the -s flag is 1448 or less. 1448 = 1476 - 28 The -M do doesn't seem to change anything.
HTTP transfers still don't go through when they are larger than ~1400 bytes. I'll go play with the MTUs now.
Ok, setting mtu of ath0's to 1524 and of bat0 to 1500 should help here. Just for the sake of completeness: Is there bridging involved in the workstations or any icmp filtering on the workstations/nanostations?
Regards, Sven
Yes. However, I can't set the MTU any higher than 1476 on the bat0 interface:
root@OpenWrt:~# ifconfig bat0 mtu 1500 ifconfig: SIOCSIFMTU: Invalid argument root@OpenWrt:~# ifconfig bat0 mtu 1477 ifconfig: SIOCSIFMTU: Invalid argument root@OpenWrt:~# ifconfig bat0 mtu 1476 root@OpenWrt:~#
The same thing goes for the br-lan interface, I assume because brctl uses the lowest MTU of all bridged interfaces as its max MTU.
On Monday 22 June 2009 22:47:30 Jacob Marble wrote:
Yes. However, I can't set the MTU any higher than 1476 on the bat0 interface:
root@OpenWrt:~# ifconfig bat0 mtu 1500 ifconfig: SIOCSIFMTU: Invalid argument root@OpenWrt:~# ifconfig bat0 mtu 1477 ifconfig: SIOCSIFMTU: Invalid argument root@OpenWrt:~# ifconfig bat0 mtu 1476 root@OpenWrt:~#
Have you set the mtu of all included interfaces in the bat0 interface to mtu 1500 before? I mean all interfaces in /proc/net/batman-adv/interfaces
Regards, Sven
On Mon, Jun 22, 2009 at 2:24 PM, Sven Eckelmannsven.eckelmann@gmx.de wrote:
Ok, setting mtu of ath0's to 1524 and of bat0 to 1500 should help here. Just for the sake of completeness: Is there bridging involved in the workstations or any icmp filtering on the workstations/nanostations?
This is working:
ath0 Link encap:Ethernet HWaddr 00:15:6D:A7:6A:9E UP BROADCAST RUNNING MULTICAST MTU:1524 Metric:1 RX packets:17374 errors:0 dropped:3 overruns:0 frame:0 TX packets:8607 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:888966 (868.1 KiB) TX bytes:500867 (489.1 KiB)
bat0 Link encap:Ethernet HWaddr 00:FF:54:AD:F9:38 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:294 errors:0 dropped:0 overruns:0 frame:0 TX packets:201 errors:0 dropped:17 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:37915 (37.0 KiB) TX bytes:37156 (36.2 KiB)
br-lan Link encap:Ethernet HWaddr 00:15:6D:A8:6A:9E inet addr:192.168.1.102 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:291 errors:0 dropped:0 overruns:0 frame:0 TX packets:161 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:20754 (20.2 KiB) TX bytes:20798 (20.3 KiB)
eth0 Link encap:Ethernet HWaddr 00:15:6D:A8:6A:9E UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4489 errors:0 dropped:0 overruns:0 frame:0 TX packets:1076 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:404668 (395.1 KiB) TX bytes:131363 (128.2 KiB) Interrupt:4 Base address:0x1000
wifi0 Link encap:UNSPEC HWaddr 00-15-6D-A7-6A-9E-00-00-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:53947 errors:0 dropped:0 overruns:0 frame:486 TX packets:9433 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:195 RX bytes:8828675 (8.4 MiB) TX bytes:741681 (724.2 KiB) Interrupt:3 Memory:b0000000-b000ffff
when you say dont go thru, what exactly are they not passing through, which interface or meaning thru the DSL / internet link, we need to try to detmine also the bottleneck of the issue, so what interface is data not passing through, and icmp tests wount decipher much in regards to MTU.... tcpdump however might tell us where the traffic is getting stopped at
On 6/22/09, Jacob Marble jacobmarble@gmail.com wrote:
On Fri, Jun 19, 2009 at 7:23 PM, Sven Eckelmannsven.eckelmann@gmx.de wrote:
On Saturday 20 June 2009 00:17:23 Jacob Marble wrote:
Two Linux boxes, each plugged in via Ethernet to a BATMAN node (two nodes). The nodes talk batman-advanced to each other via WiFi. The Linux boxes can ping each other all day long. Both Linux boxes have Apache running. Downloading a file via HTTP works only if the file is smaller than or equal to exactly 1,145 bytes. TFTP file transfers are halting, but they get through (4 megabytes took a couple of minutes).
This happens with both r1176 and r1298 on OpenWrt.
Sry, haven't followed your other mails so I don't know your whole setup.
It
looks like a mtu problem for me. Please try to set the mtu a lot lower on
your
eth devices. You can do a ping test with `ping -s TESTSIZEINBYTE -M dont IPTOSENDIPPACKET` - dont forget to add the 28 extra bytes needed for the
whole
headers inside the ethernet frame. So `ping -s 1472 -M do 192.168.1.1`
would
send a 1500 bytes package. You can also set the mtu on your wifi devices higher (and bat0 devices).
So
for example wifi device to 1524 and bat0 to 1500 (like the eth devices). Also check if you have bridge mtu patch from Simon[1] (included in linux 2.6.27) when you are bridging some of the devices. Also check that icmp "Destination Unreachable" - "Fragmentation required, and DF flag set"
isn't
filtered anywhere.
The nodes running batman-advanced are OpenWrt 8.09.1, which uses kernel 2.6.26.8. The patch is *not* in there, so I have re-flashed (again) with OpenWrt SVN, which uses... 2.6.28.10. Um, if the patch isn't in OpenWrt stable releases, then maybe something should be said on open-mesh.net? Also, I need to make a big fat note in my howto.
The setup is two Ubiquiti NanoStation2 nodes, which have one wifi device and one Ethernet device each. Atheros 231x SoC. ath0 = wifi0, ahdemo, channel = 1 bat0 interfaces = ath0 br-lan (bridge) = bat0 + eth0, IP address set on this device only
The Linux workstations are attached via Ethernet, running Ubuntu.
The MTU, by default, is 1500 on eth0, ath0, wifi0 The MTU, by default, is 1476 on bat0, br-lan
Ping from Linux workstation to Linux workstation works as long as the -s flag is 1448 or less. 1448 = 1476 - 28 The -M do doesn't seem to change anything.
HTTP transfers still don't go through when they are larger than ~1400 bytes. I'll go play with the MTUs now.
B.A.T.M.A.N mailing list B.A.T.M.A.N@lists.open-mesh.net https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
On Monday 22 June 2009 22:31:57 Outback Dingo wrote:
when you say dont go thru, what exactly are they not passing through, which interface or meaning thru the DSL / internet link, we need to try to detmine also the bottleneck of the issue, so what interface is data not passing through, and icmp tests wount decipher much in regards to MTU.... tcpdump however might tell us where the traffic is getting stopped at
I would guess that the data gets stopped at the bat0 interface. Lets say that the workstation sends a big sized ethernet frame (aka 1500 bytes) with ip data. Then it comes to the workstation over the eth0 interface which accepts frames till the size of 1500 bytes (everything happy until now). The bridge now sends it to the bat0 interface.... and oh noes, this fails because the bat0 only accepts ethernet frames of the size of 1476 bytes (see the mtu of the ath0 - 24 bytes for bat-adv stuff). The bridge should now send information (icmp packet) back the path that it cannot send the ethernet frame through this chokepoint[1]. This doesn't seem to happen here or isn't recognized by the client.
Regards, Sven
[1] ftp://ftp.rfc-editor.org/in-notes/rfc1191.txt
On Mon, Jun 22, 2009 at 2:46 PM, Sven Eckelmannsven.eckelmann@gmx.de wrote:
On Monday 22 June 2009 22:31:57 Outback Dingo wrote:
when you say dont go thru, what exactly are they not passing through, which interface or meaning thru the DSL / internet link, we need to try to detmine also the bottleneck of the issue, so what interface is data not passing through, and icmp tests wount decipher much in regards to MTU.... tcpdump however might tell us where the traffic is getting stopped at
I would guess that the data gets stopped at the bat0 interface. Lets say that the workstation sends a big sized ethernet frame (aka 1500 bytes) with ip data. Then it comes to the workstation over the eth0 interface which accepts frames till the size of 1500 bytes (everything happy until now). The bridge now sends it to the bat0 interface.... and oh noes, this fails because the bat0 only accepts ethernet frames of the size of 1476 bytes (see the mtu of the ath0 - 24 bytes for bat-adv stuff). The bridge should now send information (icmp packet) back the path that it cannot send the ethernet frame through this chokepoint[1]. This doesn't seem to happen here or isn't recognized by the client.
Regards, Sven
[1] ftp://ftp.rfc-editor.org/in-notes/rfc1191.txt
OK, what if I set the MTU of ath0 higher? Lemme see.
On Mon, Jun 22, 2009 at 2:51 PM, Sven Eckelmannsven.eckelmann@gmx.de wrote:
On Monday 22 June 2009 22:48:21 Jacob Marble wrote:
OK, what if I set the MTU of ath0 higher? Lemme see.
You must also set the mtu of the bat0 higher (to 1500 to be more exact) when you set the ath0 mtu to 1524 - it will not be increased automatically.
Right, and OpenWrt's uci is being quite problematic about this. I setup the interfaces' MTU with uci and the MTU for bat0 only "sticks" if I reboot the unit; "/etc/init.d/network restart" leaves bat0 at 1476. *poor me*
On Mon, Jun 22, 2009 at 2:48 PM, Jacob Marblejacobmarble@gmail.com wrote:
On Mon, Jun 22, 2009 at 2:46 PM, Sven Eckelmannsven.eckelmann@gmx.de wrote:
On Monday 22 June 2009 22:31:57 Outback Dingo wrote:
when you say dont go thru, what exactly are they not passing through, which interface or meaning thru the DSL / internet link, we need to try to detmine also the bottleneck of the issue, so what interface is data not passing through, and icmp tests wount decipher much in regards to MTU.... tcpdump however might tell us where the traffic is getting stopped at
I would guess that the data gets stopped at the bat0 interface. Lets say that the workstation sends a big sized ethernet frame (aka 1500 bytes) with ip data. Then it comes to the workstation over the eth0 interface which accepts frames till the size of 1500 bytes (everything happy until now). The bridge now sends it to the bat0 interface.... and oh noes, this fails because the bat0 only accepts ethernet frames of the size of 1476 bytes (see the mtu of the ath0 - 24 bytes for bat-adv stuff). The bridge should now send information (icmp packet) back the path that it cannot send the ethernet frame through this chokepoint[1]. This doesn't seem to happen here or isn't recognized by the client.
Regards, Sven
[1] ftp://ftp.rfc-editor.org/in-notes/rfc1191.txt
OK, what if I set the MTU of ath0 higher? Lemme see.
And now I see that that's what you were saying before. And it works. I'm downloading a 600 MB file via HTTP just fine now.
b.a.t.m.a.n@lists.open-mesh.org
-
Jacob Marble -
Outback Dingo -
Sven Eckelmann