And a new try to send the log, previous was rather big and didn't get sent. This one is shorter and missing all the multicast traffic.
-Juha
On Tuesday 19 January 2010 22:58:06 Juha Ylönen wrote:
And a new try to send the log, previous was rather big and didn't get sent. This one is shorter and missing all the multicast traffic.
This log only contains packets from the Intel notebook. It seems the messages from the ARM device never leave the wifi card.
Before we dive into debugging the code I'd suggest you send us your complete interface configuration. Maybe the problem is much more simple than it seems. Complete configuration means: brctl show, ifconfig, cat /proc/net/batman- adv/interfaces (or batctl if) and ping output.
Regards, Marek
-------- Original-Nachricht --------
Datum: Wed, 20 Jan 2010 10:15:59 +0800 Von: Marek Lindner lindner_marek@yahoo.de
Complete configuration means: brctl show, ifconfig, cat /proc/net/batman- adv/interfaces (or batctl if) and ping output.
Could be the first one in the list as brctl fails. CONFIG_BRIDGE is not configured in the device kernel. Is batman-adv dependent on this? I'll recompile the kernel and see what happens (it's a slow process), in the meanwhile, what other kernel configurations are needed for batman-adv?
-Juha
On Wednesday 20 January 2010 17:29:04 Juha Ylönen wrote:
Could be the first one in the list as brctl fails. CONFIG_BRIDGE is not configured in the device kernel. Is batman-adv dependent on this? I'll recompile the kernel and see what happens (it's a slow process), in the meanwhile, what other kernel configurations are needed for batman-adv?
No, it is not required but bridging is the best way to connect batman-adv with non-mesh participants, therefore many people use bridging. It is easy to add the wrong interface to the wrong bridge and then strange things happen which is way it is on my checklist. ;)
Regards, Marek
On Wed, Jan 20, 2010 at 10:29:04AM +0100, "Juha Yl?nen" wrote:
-------- Original-Nachricht --------
Datum: Wed, 20 Jan 2010 10:15:59 +0800 Von: Marek Lindner lindner_marek@yahoo.de
Complete configuration means: brctl show, ifconfig, cat /proc/net/batman- adv/interfaces (or batctl if) and ping output.
Could be the first one in the list as brctl fails. CONFIG_BRIDGE is not configured in the device kernel. Is batman-adv dependent on this? I'll recompile the kernel and see what happens (it's a slow process), in the meanwhile, what other kernel configurations are needed for batman-adv?
Bridging is not a requirement.
However many uses typically use bridging to build bigger networks. They bridge bat0 with eth0 to form one big layer 2 network.
However you don't have to do this. I've run OSPF on the bat0 interface and just routed traffic over it just like any other network link in the network.
Andrew
Juha Ylönen wrote:
-------- Original-Nachricht --------
Datum: Wed, 20 Jan 2010 10:15:59 +0800 Von: Marek Lindner lindner_marek@yahoo.de
Complete configuration means: brctl show, ifconfig, cat /proc/net/batman- adv/interfaces (or batctl if) and ping output.
Could be the first one in the list as brctl fails. CONFIG_BRIDGE is not configured in the device kernel. Is batman-adv dependent on this? I'll recompile the kernel and see what happens (it's a slow process), in the meanwhile, what other kernel configurations are needed for batman-adv?
No, bridge stuff is not really a dependency. Only many configurations use is to bridge the bat0 and for example the ethernet interface together. The dependencies of 0.2 are currently PROC_FS and PACKET.
Just as side note for the futyre: Configure the mtu of bat0 to match the mtu of your other devices in the bridge or otherwise big packets will be dropped while bridging.
@Andrew: We don't depend on PACKET after the merge of the skb based transfers. Please remove it from Kconfig - we need NET instead.
Best regards, Sven
-------- Original-Nachricht --------
Datum: Wed, 20 Jan 2010 10:15:59 +0800 Von: Marek Lindner lindner_marek@yahoo.de
Before we dive into debugging the code I'd suggest you send us your complete interface configuration. Maybe the problem is much more simple than it seems. Complete configuration means: brctl show, ifconfig, cat /proc/net/batman- adv/interfaces (or batctl if) and ping output.
Here we go: --- ##x> brctl show bridge name bridge id STP enabled interfaces ##> cat interfaces [ active] eth1 00:11:f6:83:af:ab ##> ifconfig bat0 Link encap:Ethernet HWaddr 32:21:CA:8E:37:DC inet addr:10.0.1.39 Bcast:10.255.255.255 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1476 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:468 (468.0 B)
eth1 Link encap:Ethernet HWaddr 00:11:F6:83:AF:AB UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:179 errors:0 dropped:0 overruns:0 frame:0 TX packets:268 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:6086 (5.9 KiB) TX bytes:10450 (10.2 KiB)
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
##> route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.0.0 * 255.0.0.0 U 0 0 0 bat0 ##> ping 10.0.1.40 PING 10.0.1.40 (10.0.1.40): 56 data bytes
--- 10.0.1.40 ping statistics --- 10 packets transmitted, 0 packets received, 100% packet loss ---
I also checked the return value for dev_queue_xmit in send.c and it was 0.
-Juha
-Juha
Hey,
0 bat0 ##> ping 10.0.1.40 PING 10.0.1.40 (10.0.1.40): 56 data bytes
--- 10.0.1.40 ping statistics --- 10 packets transmitted, 0 packets received, 100% packet loss
actually, I meant the ping that you said would work and expected the config from both ends. Otherwise we can't see much. We know that the ping over batman does not work because the routes are not there ...
It might be useful to join us on irc to speed things up. Is that an option for you ? We idle in #batman on irc.freenode.org.
Cheers, Marek
-------- Original-Nachricht --------
Datum: Thu, 21 Jan 2010 06:32:19 +0800 Von: Marek Lindner lindner_marek@yahoo.de
Hi,
Ok, here's another set: ---IN ARM DEVICE--- ##> ifconfig bat0 Link encap:Ethernet HWaddr BE:8F:67:10:32:A9 inet addr:10.1.1.33 Bcast:10.255.255.255 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1476 Metric:1 RX packets:12 errors:0 dropped:0 overruns:0 frame:0 TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:768 (768.0 B) TX bytes:378 (378.0 B)
eth1 Link encap:Ethernet HWaddr 00:11:F6:83:AF:1C inet addr:10.0.1.33 Bcast:10.0.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9842 errors:0 dropped:0 overruns:0 frame:0 TX packets:17276 errors:5 dropped:0 overruns:0 carrier:5 collisions:0 txqueuelen:1000 RX bytes:320656 (313.1 KiB) TX bytes:3038557 (2.8 MiB)
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:7 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:784 (784.0 B) TX bytes:784 (784.0 B) ##> cat /proc/net/batman-adv/interfaces [ active] eth1 00:11:f6:83:af:1c ##> cat /proc/net/batman-adv/originators Originator (#/255) Nexthop [outgoingIF]: Potential nexthops ... [B.A.T.M.A.N. adv 0.3.0-alpha r1559, MainIF/MAC: eth1/00:11:f6:83:af:1c] No batman nodes in range ... ##> route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.1.0 * 255.255.255.0 U 0 0 0 eth1 10.0.0.0 * 255.0.0.0 U 0 0 0 bat0 224.0.0.0 * 240.0.0.0 U 0 0 0 eth1 ##> ping -c 3 10.0.1.40 PING 10.0.1.40 (10.0.1.40): 56 data bytes 64 bytes from 10.0.1.40: seq=0 ttl=64 time=19.123 ms 64 bytes from 10.0.1.40: seq=1 ttl=64 time=7.077 ms 64 bytes from 10.0.1.40: seq=2 ttl=64 time=7.239 ms
--- 10.0.1.40 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 7.077/11.146/19.123 ms --- And the same set from the laptop counterpart: ---LAPTOP--- ylo@ylo-laptop:~$ ifconfig bat0 Link encap:Ethernet HWaddr 26:22:26:1b:f4:f5 inet addr:10.1.1.40 Bcast:10.255.255.255 Mask:255.0.0.0 inet6 addr: fe80::2422:26ff:fe1b:f4f5/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1476 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:936 (936.0 B)
eth0 Link encap:Ethernet HWaddr 00:24:7e:68:bf:10 inet addr:10.10.10.126 Bcast:10.10.10.255 Mask:255.255.255.0 inet6 addr: fe80::224:7eff:fe68:bf10/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1370811 errors:0 dropped:0 overruns:0 frame:0 TX packets:613889 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:1847455539 (1.8 GB) TX bytes:54536457 (54.5 MB) Memory:fc000000-fc020000
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:3060 errors:0 dropped:0 overruns:0 frame:0 TX packets:3060 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:817467 (817.4 KB) TX bytes:817467 (817.4 KB)
wlan0 Link encap:Ethernet HWaddr 00:22:fa:dc:9a:ce inet addr:10.0.1.40 Bcast:10.0.1.255 Mask:255.255.255.0 inet6 addr: fe80::222:faff:fedc:9ace/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:37473 errors:0 dropped:0 overruns:0 frame:0 TX packets:5862 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:10662970 (10.6 MB) TX bytes:539481 (539.4 KB)
wmaster0 Link encap:UNSPEC HWaddr 00-22-FA-DC-9A-CE-61-63-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) ylo@ylo-laptop:~$ cat /proc/net/batman-adv/interfaces [ active] wlan0 00:22:fa:dc:9a:ce ylo@ylo-laptop:~$ cat /proc/net/batman-adv/originators Originator (#/255) Nexthop [outgoingIF]: Potential nexthops ... [B.A.T.M.A.N. adv 0.3.0-alpha r1559, MainIF/MAC: wlan0/00:22:fa:dc:9a:ce] No batman nodes in range ... ylo@ylo-laptop:~$ route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.1.0 * 255.255.255.0 U 0 0 0 wlan0 10.10.10.0 * 255.255.255.0 U 0 0 0 eth0 link-local * 255.255.0.0 U 1000 0 0 eth0 10.0.0.0 * 255.0.0.0 U 0 0 0 bat0 default 10.10.10.1 0.0.0.0 UG 100 0 0 eth0 ylo@ylo-laptop:~$ ping -c 3 10.0.1.33 PING 10.0.1.33 (10.0.1.33) 56(84) bytes of data. 64 bytes from 10.0.1.33: icmp_seq=1 ttl=64 time=6.08 ms 64 bytes from 10.0.1.33: icmp_seq=2 ttl=64 time=5.71 ms 64 bytes from 10.0.1.33: icmp_seq=3 ttl=64 time=5.59 ms
--- 10.0.1.33 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 5.596/5.797/6.082/0.224 ms ---
It might be useful to join us on irc to speed things up. Is that an option for you ? We idle in #batman on irc.freenode.org.
Yeah, I've been lurking there for a while, but being so much on/off from the computer lately it's been easier to email. I'll certainly begin bugging You through irc once I have time to sit down for a while..=)
-Juha
Juha Ylönen wrote:
Yeah, I've been lurking there for a while, but being so much on/off from the computer lately it's been easier to email. I'll certainly begin bugging You through irc once I have time to sit down for a while..=)
It would help a lot. We are currently waiting for a lot more information from you.
I think it isn't really a big endian vs. little endian problem. I have installed batman-adv 1559 on a powerpc and on my amd64. Both can talk to each other without problems.
Do you have any filters installed which could filter out the ethernet frames? Does your hardware on arm transport non-standard ethernet types? A tcpdump on both sides which we can compare would help a lot.
I usually use a small test program to send raw ethernet packets from one host to another (one sided ping test). It helps a lot to find one directional problems.
On one side you must use `./rawsend DEVICE` and on the other `./rawsend DEVICE TARGET-MAC`
Best regards, Sven
On 01/21/2010 06:12 AM, "Juha Ylönen" wrote: [snip]
---IN ARM DEVICE--- ##> route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.1.0 * 255.255.255.0 U 0 0 0 eth1 10.0.0.0 * 255.0.0.0 U 0 0 0 bat0 224.0.0.0 * 240.0.0.0 U 0 0 0 eth1
[snip]
In the laptop you have:
ylo@ylo-laptop:~$ route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.1.0 * 255.255.255.0 U 0 0 0 wlan0 10.10.10.0 * 255.255.255.0 U 0 0 0 eth0 link-local * 255.255.0.0 U 1000 0 0 eth0 10.0.0.0 * 255.0.0.0 U 0 0 0 bat0 default 10.10.10.1 0.0.0.0 UG 100 0 0 eth0
Your routes are all messed up. You have class C addresses subsumed inside class A address space, which causes undefined behavior.
Give your routes different address spaces, something like one in the 192.168.xx.xx, another 172.16.xx.xx, and the 10.xx.xx.xx so the routes can be sorted out properly.
Also, why does the laptop wlan0 have an IP address? If it is part of the mesh through bat0 it should not have an IP address, only add it as an interface to bat0.
Gus
Gus Wirth wrote:
Your routes are all messed up. You have class C addresses subsumed inside class A address space, which causes undefined behavior.
Give your routes different address spaces, something like one in the 192.168.xx.xx, another 172.16.xx.xx, and the 10.xx.xx.xx so the routes can be sorted out properly.
Also, why does the laptop wlan0 have an IP address? If it is part of the mesh through bat0 it should not have an IP address, only add it as an interface to bat0.
Yes, but doesn't explain why there is no batman-adv packet from ARM reaching the laptop and the other way around. batman-adv is a layer bellow and has nearly nothing to do with the stuff which runs over it (the only thing which accesses the layer over it should be the gateway stuff).
@Juha, I found time and looked a little bit at the stuff which came from the ARM in the last log. Wireshark means that it is a Raw ethernet packet. And thinks that the stuff attached is a IPX packet.... but reading the raw data reveals that it should be the batman-packet.... with extra data between the ethernet header and the actual batman-adv packet. So the problem looks to me a little bit like hardware of the arm does something very stupid to our packets.
I've attach a small picture to explain what I mean. The green part it the normal receiver and sender stuff for ethernet. The orange part is not explainable for me... Have we forgot some alignment stuff? Is your card adding some extra data? I am not sure what that could mean right now. The red thing is the ethernet type for batman-adv, pink the type of batman-adv packet, yellow the protocol version and light blue the flags for that packet. I don't know more color - so just marked the rest of the packet blue. The amount of bytes are correct and it looks fine to me.
As anyone a good idea? Maybe a small capture of a normal ping test and a rawsend test between the both could help to understand the problem better. And can you maybe tell us what kind of hardware is used inside the arm for the eth1 device?
Best regards, Sven
Hello,
maybe just an idea, but could it be that we have a regression from the skb patch that some skb headers are wrong?
An idea would be to compare the behaviour with the batman-adv 0.2 release or an revision < 1517, which still uses raw sockets instead of working directly on the skb.
regards, Simon
On Thu, Jan 21, 2010 at 07:32:10PM +0100, Sven Eckelmann wrote:
Gus Wirth wrote:
Your routes are all messed up. You have class C addresses subsumed inside class A address space, which causes undefined behavior.
Give your routes different address spaces, something like one in the 192.168.xx.xx, another 172.16.xx.xx, and the 10.xx.xx.xx so the routes can be sorted out properly.
Also, why does the laptop wlan0 have an IP address? If it is part of the mesh through bat0 it should not have an IP address, only add it as an interface to bat0.
Yes, but doesn't explain why there is no batman-adv packet from ARM reaching the laptop and the other way around. batman-adv is a layer bellow and has nearly nothing to do with the stuff which runs over it (the only thing which accesses the layer over it should be the gateway stuff).
@Juha, I found time and looked a little bit at the stuff which came from the ARM in the last log. Wireshark means that it is a Raw ethernet packet. And thinks that the stuff attached is a IPX packet.... but reading the raw data reveals that it should be the batman-packet.... with extra data between the ethernet header and the actual batman-adv packet. So the problem looks to me a little bit like hardware of the arm does something very stupid to our packets.
I've attach a small picture to explain what I mean. The green part it the normal receiver and sender stuff for ethernet. The orange part is not explainable for me... Have we forgot some alignment stuff? Is your card adding some extra data? I am not sure what that could mean right now. The red thing is the ethernet type for batman-adv, pink the type of batman-adv packet, yellow the protocol version and light blue the flags for that packet. I don't know more color - so just marked the rest of the packet blue. The amount of bytes are correct and it looks fine to me.
As anyone a good idea? Maybe a small capture of a normal ping test and a rawsend test between the both could help to understand the problem better. And can you maybe tell us what kind of hardware is used inside the arm for the eth1 device?
Best regards, Sven
-------- Original-Nachricht --------
Datum: Fri, 22 Jan 2010 19:26:19 +0100 Von: Simon Wunderlich simon.wunderlich@s2003.tu-chemnitz.de
maybe just an idea, but could it be that we have a regression from the skb patch that some skb headers are wrong?
An idea would be to compare the behaviour with the batman-adv 0.2 release or an revision < 1517, which still uses raw sockets instead of working directly on the skb.
Hi,
I've been trying out with 0.2 release and with latest trunk, with same behaviour.
-Juha
b.a.t.m.a.n@lists.open-mesh.org
-
"Juha Ylönen" -
Andrew Lunn -
Gus Wirth -
Marek Lindner -
Simon Wunderlich -
Sven Eckelmann