batman-adv on different archs
Hi,
I've been trying to get my embedded project included in my mesh, but no success yet. Could anyone give a pointers what is going wrong?
I have batman-adv compiled on my laptop, and also for testing purposes on another laptop, they see each other and everything is fine. I used the same sources and compiled it cleanly on each.
The problem comes when I try to add my little ARM based linux box onto the group. Again same sources used (latest stable from the wiki), crosscompiles fine and I can load the module as normal on the box. Setup goes as it should on both the device and the laptop, and both systems seems to be running smoothly. But my laptop can only see the other laptop, and the device doesn't see anyone. The wireless net is working and I can ping each device directly if I assign IP's to the 'real' interfaces, but through bat0 nothing is found. Any idea what is going wrong?
---
I've also played with the batman daemon on the device, with it I the laptop and device can see each other just fine. The problem there is that apparently it doesn't really support multicast forwarding? i.e. If I have 3 devices A-B-C, where A does not have direct link to C (batman routes through B), sending a multicast from A can be received in B and vice versa, also same for C-B, but no messages from A to C. Will I have the same problem with batman-adv? Or can this be fixed on the daemon?
Best Regards
Juha
Signature · 2 lines
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Quoted 9 lines
The problem comes when I try to add my little ARM based linux box onto the group. Again same sources used (latest stable from the wiki), crosscompiles fine and I can load the module as normal on the box. Setup goes as it should on both the device and the laptop, and both systems seems to be running smoothly. But my laptop can only see the other laptop, and the device doesn't see anyone. The wireless net is working and I can ping each device directly if I assign IP's to the 'real' interfaces, but through bat0 nothing is found. Any idea what is going wrong?
What do you see in /proc/net/batman-adv/originiators on the three devices?
Is the ARM device running in big endian or little endian mode?
Any kernel messages?
You may want to rebuild the modules with debugging enabled, see the README and then enable it as described in the README.
Andrew
Hi,
And thanks for quick responses. Some comments below.
-------- Original-Nachricht --------
Quoted 5 lines
Datum: Mon, 18 Jan 2010 12:39:54 +0100
Von: Andrew Lunn <[email protected]>What do you see in
/proc/net/batman-adv/originiatorson the three devices?
Here's what I see (or not see) in the laptop:
##:~$ cat /proc/net/batman-adv/interfaces [ active] wlan0 00:22:fa:dc:9a:ce ##:~$ cat /proc/net/batman-adv/originators Originator (#/255) Nexthop [outgoingIF]: Potential nexthops ... [B.A.T.M.A.N. adv 0.2, MainIF/MAC: wlan0/00:22:fa:dc:9a:ce] No batman nodes in range ...
and in the device:
##> 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.2, MainIF/MAC: eth1/00:11:f6:83:af:1c]
No batman nodes in range ...
Quoted 1 line
Is the ARM device running in big endian or little endian mode?
The device is liitle endian. Could it be a problem in endianness? IIRC network stuff is usually big endian?
Quoted 4 lines
Any kernel messages?
You may want to rebuild the modules with debugging enabled, see the README and then enable it as described in the README.
I couldn't find any info on debug build in the README, and some instructions I came across in the wiki didn't really work, so I went and modified log.c directly to printk everything that is passed to debug_log.
In result I got a screenfulls of messages:
---
batman-adv: Received BATMAN packet via NB: 00:22:fa:dc:9a:ce, IF: eth1 [00:11:f6:83:af:1c] (from OG: 00:22:fa:dc:9a:ce, via prev OG: 00:22:fa:dc:9a:ce, seqno 30765, tq 255, TTL 50, V 8, IDF 0)
batman-adv: updating last_seqno: old 30764, new 30765
batman-adv: bidirectional: orig = 00:22:fa:dc:9a:ce neigh = 00:22:fa:dc:9a:ce => own_bcast = 0, real recv = 63, local tq: 0, asym_penalty: 255, total tq: 0
batman-adv: Forwarding packet: tq_orig: 0, tq_avg: 0, tq_forw: 0, ttl_orig: 49, ttl_forw: 49
batman-adv: Forwarding packet: rebroadcast neighbour packet with direct link flag
batman-adv: Forwarding packet (originator 00:22:fa:dc:9a:ce, seqno 30765, TQ 0, TTL 49, IDF on) on interface eth1 [00:11:f6:83:af:1c]
batman-adv: Sending own packet (originator 00:11:f6:83:af:1c, seqno 1569, TQ 255, TTL 50, IDF off) on interface eth1 [00:11:f6:83:af:1c]
batman-adv: Received BATMAN packet via NB: 00:22:fa:dc:9a:ce, IF: eth1 [00:11:f6:83:af:1c] (from OG: 00:22:fa:dc:9a:ce, via prev OG: 00:22:fa:dc:9a:ce, seqno 30766, tq 255, TTL 50, V 8, IDF 0)
batman-adv: updating last_seqno: old 30765, new 30766
batman-adv: bidirectional: orig = 00:22:fa:dc:9a:ce neigh = 00:22:fa:dc:9a:ce => own_bcast = 0, real recv = 63, local tq: 0, asym_penalty: 255, total tq: 0
batman-adv: Forwarding packet: tq_orig: 0, tq_avg: 0, tq_forw: 0, ttl_orig: 49, ttl_forw: 49
batman-adv: Forwarding packet: rebroadcast neighbour packet with direct link flag
batman-adv: Forwarding packet (originator 00:22:fa:dc:9a:ce, seqno 30766, TQ 0, TTL 49, IDF on) on interface eth1 [00:11:f6:83:af:1c]
batman-adv: Sending own packet (originator 00:11:f6:83:af:1c, seqno 1570, TQ 255, TTL 50, IDF off) on interface eth1 [00:11:f6:83:af:1c]
batman-adv: Received BATMAN packet via NB: 00:22:fa:dc:9a:ce, IF: eth1 [00:11:f6:83:af:1c] (from OG: 00:22:fa:dc:9a:ce, via prev OG: 00:22:fa:dc:9a:ce, seqno 30767, tq 255, TTL 50, V 8, IDF 0)
batman-adv: updating last_seqno: old 30766, new 30767
batman-adv: bidirectional: orig = 00:22:fa:dc:9a:ce neigh = 00:22:fa:dc:9a:ce => own_bcast = 0, real recv = 63, local tq: 0, asym_penalty: 255, total tq: 0
batman-adv: Forwarding packet: tq_orig: 0, tq_avg: 0, tq_forw: 0, ttl_orig: 49, ttl_forw: 49
batman-adv: Forwarding packet: rebroadcast neighbour packet with direct link flag
batman-adv: Forwarding packet (originator 00:22:fa:dc:9a:ce, seqno 30767, TQ 0, TTL 49, IDF on) on interface eth1 [00:11:f6:83:af:1c]
batman-adv: Sending own packet (originator 00:11:f6:83:af:1c, seqno 1571, TQ 255, TTL 50, IDF off) on interface eth1 [00:11:f6:83:af:1c]
batman-adv: Received BATMAN packet via NB: 00:22:fa:dc:9a:ce, IF: eth1 [00:11:f6:83:af:1c] (from OG: 00:22:fa:dc:9a:ce, via prev OG: 00:22:fa:dc:9a:ce, seqno 30768, tq 255, TTL 50, V 8, IDF 0)
batman-adv: updating last_seqno: old 30767, new 30768
batman-adv: bidirectional: orig = 00:22:fa:dc:9a:ce neigh = 00:22:fa:dc:9a:ce => own_bcast = 0, real recv = 63, local tq: 0, asym_penalty: 255, total tq: 0
batman-adv: Forwarding packet: tq_orig: 0, tq_avg: 0, tq_forw: 0, ttl_orig: 49, ttl_forw: 49
batman-adv: Forwarding packet: rebroadcast neighbour packet with direct link flag
batman-adv: Forwarding packet (originator 00:22:fa:dc:9a:ce, seqno 30768, TQ 0, TTL 49, IDF on) on interface eth1 [00:11:f6:83:af:1c]
batman-adv: Sending own packet (originator 00:11:f6:83:af:1c, seqno 1572, TQ 255, TTL 50, IDF off) on interface eth1 [00:11:f6:83:af:1c]
batman-adv: Received BATMAN packet via NB: 00:22:fa:dc:9a:ce, IF: eth1 [00:11:f6:83:af:1c] (from OG: 00:22:fa:dc:9a:ce, via prev OG: 00:22:fa:dc:9a:ce, seqno 30769, tq 255, TTL 50, V 8, IDF 0)
batman-adv: updating last_seqno: old 30768, new 30769
batman-adv: bidirectional: orig = 00:22:fa:dc:9a:ce neigh = 00:22:fa:dc:9a:ce => own_bcast = 0, real recv = 63, local tq: 0, asym_penalty: 255, total tq: 0
batman-adv: Forwarding packet: tq_orig: 0, tq_avg: 0, tq_forw: 0, ttl_orig: 49, ttl_forw: 49
batman-adv: Forwarding packet: rebroadcast neighbour packet with direct link flag
batman-adv: Forwarding packet (originator 00:22:fa:dc:9a:ce, seqno 30769, TQ 0, TTL 49, IDF on) on interface eth1 [00:11:f6:83:af:1c]
batman-adv: Sending own packet (originator 00:11:f6:83:af:1c, seqno 1573, TQ 255, TTL 50, IDF off) on interface eth1 [00:11:f6:83:af:1c]
batman-adv: Received BATMAN packet via NB: 00:22:fa:dc:9a:ce, IF: eth1 [00:11:f6:83:af:1c] (from OG: 00:22:fa:dc:9a:ce, via prev OG: 00:22:fa:dc:9a:ce, seqno 30770, tq 255, TTL 50, V 8, IDF 0)
batman-adv: updating last_seqno: old 30769, new 30770
batman-adv: bidirectional: orig = 00:22:fa:dc:9a:ce neigh = 00:22:fa:dc:9a:ce => own_bcast = 0, real recv = 63, local tq: 0, asym_penalty: 255, total tq: 0
---
Interestingly there seems to be packets coming and going from my laptop?
-Juha
Signature · 2 lines
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Quoted 2 lines · On Monday 18 January 2010 21:29:35 Juha Ylönen wrote:
I couldn't find any info on debug build in the README, and some
instructions I came across in the wiki didn't really work,
Could you please let us know what part of the wiki does not work as expected ? Only then we can improve it. :)
Quoted 2 lines
so I went and modified
log.cdirectly to printk everything that is passed todebug_log.
Actually, there is a debug level which you can modify to obtain the same result ... ;)
Quoted 5 lines
batman-adv: bidirectional: orig = 00:22:fa:dc:9a:ce neigh =
00:22:fa:dc:9a:ce =>own_bcast= 0, real recv = 63, local tq: 0,
asym_penalty: 255, total tq: 0 ---Interestingly there seems to be packets coming and going from my laptop?
Yes, the devices are talking to each other. "real recv" indicates you received the other node's messages but the other node does not repeat our own broadcasts (see "own_bcast"). Would be interesting to see the log from the other side. It looks like the messages get dropped there.
Regards,
Marek
Quoted 4 lines
Yes, the devices are talking to each other. "real recv" indicates you received the other node's messages but the other node does not repeat our own broadcasts (see "
own_bcast"). Would be interesting to see the log from the other side. It looks like the messages get dropped there.
It would also be good to know the MAC addresses for the two laptops and the ARM board, so we know what messages are coming from where.
Andrew
-------- Original-Nachricht --------
Quoted 5 lines
Datum: Mon, 18 Jan 2010 14:51:20 +0100
Von: Andrew Lunn <[email protected]>It would also be good to know the MAC addresses for the two laptops and the ARM board, so we know what messages are coming from where.
On the laptop:
HWaddr 00:22:fa:dc:9a:ce
and the device:
HWaddr 00:11:F6:83:AF:1C
No other laptop at this configuration, I don't have it with me at the moment.
-Juha
Signature · 2 lines
Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02
-------- Original-Nachricht --------
Quoted 6 lines
Datum: Mon, 18 Jan 2010 21:38:32 +0800
Von: Marek Lindner <[email protected]>Could you please let us know what part of the wiki does not work as expected ?
Only then we can improve it. :)
Ah yes, the instructions were actually were in the repository version of the README file, but not in my version of the sources. The sources I have the README is dated 07-11-2009, should I try later version?
Quoted 5 lines
Yes, the devices are talking to each other. "real recv" indicates you received
the other node's messages but the other node does not repeat our own broadcasts (see "own_bcast"). Would be interesting to see the log from the other side. It looks like the messages get dropped there.
The log on the laptop side is pretty sparse:
[23707.971949] batman-adv: B.A.T.M.A.N. advanced 0.2 (compatibility version 8) loaded [23727.025361] batman-adv: Adding interface: wlan0 [23727.028964] batman-adv: Interface activated: wlan0 [23727.028983] batman-adv: Creating new local hna entry: de:ba:6c:f3:8d:53 [23728.028287] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 1, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23729.008099] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 2, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23729.988106] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 3, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23730.968098] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 4, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23731.948075] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 5, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23732.928870] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 6, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23733.908100] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 7, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23734.908149] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 8, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23735.888136] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 9, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23736.868083] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 10, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23737.848084] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 11, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23738.848080] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 12, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23739.848080] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 13, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23740.828084] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 14, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23741.808080] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 15, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23742.808208] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 16, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23743.788082] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 17, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23744.788081] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 18, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23745.788083] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 19, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23746.788079] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 20, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23747.768130] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 21, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23748.768129] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 22, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23749.768280] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 23, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23750.748081] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 24, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23751.728082] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 25, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23752.728083] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 26, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23753.708077] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 27, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce]
i.e. no sign of any other packages than own. On the device side the log is in the same format as the one I sent yesterday. I'll try with the latest version from the repository next.
-Juha
Signature · 2 lines
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
Quoted 3 lines · On Tuesday 19 January 2010 15:43:34 Juha Ylönen wrote:
Ah yes, the instructions were actually were in the repository version of
the README file, but not in my version of the sources. The sources I have the README is dated 07-11-2009, should I try later version?
Well, the README that is part of the source package matches the sources you have. The trunk README might have changed since the last release ...
Quoted 11 lines
The log on the laptop side is pretty sparse:
[23707.971949] batman-adv: B.A.T.M.A.N. advanced 0.2 (compatibility version 8) loaded [23727.025361] batman-adv: Adding interface: wlan0 [23727.028964] batman-adv: Interface activated: wlan0 [23727.028983] batman-adv: Creating new local hna entry: de:ba:6c:f3:8d:53 [23728.028287] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 1, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23729.008099] batman-adv: Sending own packet (originator 00:22:fa:dc:9a:ce, seqno 2, TQ 255, TTL 50, IDF off) on interface wlan0 [00:22:fa:dc:9a:ce] [23729.988106]
Quoted 3 lines
i.e. no sign of any other packages than own. On the device side the log is
in the same format as the one I sent yesterday. I'll try with the latest version from the repository next.
It confirmed what we saw in the other logs: This device (the laptop?) does not see the packets from the other side, therefore the protocol correctly assumes a dead link. There might be 2 reasons: either the wifi layer does not really work or batman-adv drops the packets without any further warning. You can try the latest trunk and/or run batctl/wireshark on the laptop to deep-inspect the packets. Feel free to share the logs with us.
Regards,
Marek
-------- Original-Nachricht --------
Quoted 12 lines
Datum: Tue, 19 Jan 2010 20:07:38 +0800
Von: Marek Lindner <[email protected]>It confirmed what we saw in the other logs: This device (the laptop?) does not
see the packets from the other side, therefore the protocol correctly assumes
a dead link. There might be 2 reasons: either the wifi layer does not really
work or batman-adv drops the packets without any further warning. You can try the latest trunk and/or run batctl/wireshark on the laptop to deep-inspect the packets. Feel free to share the logs with us.
I got the latest trunk up and running, some changes were required to get it to crosscompile for ARM (and 2.6.24 kernel). Same behaviour as before, device log shows a lot of activity, but laptop batman doesn't seem to be doing much anything. I tried the wireshark and got a log ok (which shows a lot of multicast traffic from the device until I disabled the service) but I'm at loss to decipher possible batman packages. What should they look like in wireshark? I only noticed couple of IPX packages from device to (broadcast?) but nothing else. I attached the log file, is anyone able to say if there are batman packages included?
-Juha
Signature · 2 lines
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser
Quoted 9 lines · Juha Ylönen
I got the latest trunk up and running, some changes were required to get it
to crosscompile for ARM (and 2.6.24 kernel). Same behaviour as before, device log shows a lot of activity, but laptop batman doesn't seem to be doing much anything. I tried the wireshark and got a log ok (which shows a lot of multicast traffic from the device until I disabled the service) but I'm at loss to decipher possible batman packages. What should they look like in wireshark? I only noticed couple of IPX packages from device to (broadcast?) but nothing else. I attached the log file, is anyone able to say if there are batman packages included?
There is a dissector for wireshark at
http://gitorious.org/wireshark-batman-plugins/wireshark-batman-adv
(compatible with 0.2, but haven't added new code to make it compatible with new functionality in trunk). I will add support for protocol version 9 after finishing some other non-paid work.
Your log is for version 9 of the protocol (trunk). So it is harder to read :)
As far as I can see only data from 00:22:fa:dc:9a:ce can be seen (send from us aka laptop?). Have you tested if the adhoc connection between this two devices (arm <-> laptop) is really working (just set up the adhoc network as usual and then give them an ip instead of adding to /proc/net/batman-adv/interfaces. A simple ping test should be sufficient to say that it works(tm)).
Best regards,
Sven
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 10 lines · Juha Ylönen
Quoted 9 lines
As far as I can see only data from 00:22:fa:dc:9a:ce can be seen (send from us
aka laptop?). Have you tested if the adhoc connection between this two devices
(arm <-> laptop) is really working (just set up the adhoc network as usual and
then give them an ip instead of adding to/proc/net/batman-adv/interfaces. A
simple ping test should be sufficient to say that it works(tm)).
Quoted 6 lines
Yes, ad-hoc itself works pretty well. the device boots up to his default
ad-hoc, and I've sent the module over with scp and did some configuring over ssh. I did run couple of tests with IP disabled in the interfaces (set up exactly as in the readme) but recently I've just kept them in the default setup with IP's, will it cause problems? The problem existed with non-IP interfaces too.
batman-adv works on a lower level - so it shouldn't be a really problem in that situation. Maybe you can "tcpdump -s 0 -w test.dump" on the arm too. I am currently not sure why the arm cannot or doesn't send packets at all. The logs in [email protected] say that it was send, but I currently don't understand why they don't reach their destination. Maybe a dump from the arm reveals the problem - or at least we know if data gets send at all or if the data is stopped somewhere else.
Best regards,
Sven
Hello,
just as a side note, would you mind sharing your changes which were required to cross compile for ARM? batman-adv is supposed to support 2.6.24, and if there is any trouble with this on ARM i'd like to add support for it.
Thank you very much,
Simon
Quoted 21 lines · Juha Ylönen
-------- Original-Nachricht --------
Quoted 12 lines
Datum: Tue, 19 Jan 2010 20:07:38 +0800
Von: Marek Lindner <[email protected]>It confirmed what we saw in the other logs: This device (the laptop?) does not
see the packets from the other side, therefore the protocol correctly assumes
a dead link. There might be 2 reasons: either the wifi layer does not really
work or batman-adv drops the packets without any further warning. You can try the latest trunk and/or run batctl/wireshark on the laptop to deep-inspect the packets. Feel free to share the logs with us.I got the latest trunk up and running, some changes were required to get it to crosscompile for ARM (and 2.6.24 kernel). Same behaviour as before, device log shows a lot of activity, but laptop batman doesn't seem to be doing much anything. I tried the wireshark and got a log ok (which shows a lot of multicast traffic from the device until I disabled the service) but I'm at loss to decipher possible batman packages. What should they look like in wireshark? I only noticed couple of IPX packages from device to (broadcast?) but nothing else. I attached the log file, is anyone able to say if there are batman packages included?
-Juha
Signature · 2 lines
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser
-------- Original-Nachricht --------
Quoted 8 lines
Datum: Tue, 19 Jan 2010 20:37:01 +0100
Von: Simon Wunderlich <[email protected]>just as a side note, would you mind sharing your changes which were required to cross compile
for ARM? batman-adv is supposed to support 2.6.24, and if there is any trouble with this
on ARM i'd like to add support for it.
Hi,
I just took a fresh checkout and now it compiles without problems. The errors I got were in gateway functionality, so I guess they were under development?
It's still complining about the bat_printk:
make[2]: *** No rule to make target /home/ylo/batman-adv/trunk/batman-adv-kernelland-ARM/bat_printk.o', needed by /home/ylo/batman-adv/trunk/batman-adv-kernelland-ARM/batman-adv.o'. Stop.
but that's the same on x86, and I just removed bat_printk.o from the targets.
-Juha
Signature · 2 lines
Hilfe für Haiti! Spende per SMS: Sende UI HAITI an die Nummer 81190. Von 5 Euro je SMS (zzgl. SMS-Gebühr) gehen 4,83 Euro an UNICEF.
Hi,
Quoted 3 lines
I just took a fresh checkout and now it compiles without problems. The
errors I got were in gateway functionality, so I guess they were under development?
yap. If you want something more stable stay with the last release.
Quoted 5 lines
It's still complining about the
bat_printk:
make[2]: *** No rule to make target
/home/ylo/batman-adv/trunk/batman-adv-kernelland-ARM/bat_printk.o', needed by/home/ylo/batman-adv/trunk/batman-adv-kernelland-ARM/batman-adv.o'. Stop.
That was fixed today (revision 1559).
Regards,
Marek
Hi,
Quoted 8 lines
The problem comes when I try to add my little ARM based linux box onto the
group. Again same sources used (latest stable from the wiki), crosscompiles fine and I can load the module as normal on the box. Setup goes as it should on both the device and the laptop, and both systems seems to be running smoothly. But my laptop can only see the other laptop, and the device doesn't see anyone. The wireless net is working and I can ping each device directly if I assign IP's to the 'real' interfaces, but through bat0 nothing is found. Any idea what is going wrong?
as soon as normal pings work batman-adv should also work. From what you describe I can't see any obvious mistake. Did you try to peek into the debug logs or capture some packets to see whether the nodes are communicating correctly ?
Quoted 7 lines
I've also played with the batman daemon on the device, with it I the laptop
and device can see each other just fine. The problem there is that apparently it doesn't really support multicast forwarding? i.e. If I have 3 devices A-B-C, where A does not have direct link to C (batman routes through B), sending a multicast from A can be received in B and vice versa, also same for C-B, but no messages from A to C. Will I have the same problem with batman-adv? Or can this be fixed on the daemon?
The daemon operates on layer 3, therefore multicast forwarding can't work.
Some other layer 3 routing daemons try to support multicast by hacking a layer 2 tunneling into the daemon. The performance is poor at the expense of CPU load but give it a try yourself in case this is no problem.
However, batman-adv supports multicast out of the box.
Regards,
Marek