[B.A.T.M.A.N.] batman-adv on different archs

[B.A.T.M.A.N.] batman-adv on different archs

["Juha Ylönen"]

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
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Re: [B.A.T.M.A.N.] batman-adv on different archs

[Andrew Lunn]

> 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

Re: [B.A.T.M.A.N.] batman-adv on different archs

[Marek Lindner]

Hi,

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


> 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

Re: [B.A.T.M.A.N.] batman-adv on different archs

["Juha Ylönen"]

Hi, 

And thanks for quick responses. Some comments below.

-------- Original-Nachricht --------
> Datum: Mon, 18 Jan 2010 12:39:54 +0100
> Von: Andrew Lunn <andrew@lunn.ch>
>
> What do you see in /proc/net/batman-adv/originiators on 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 ...

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

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Re: [B.A.T.M.A.N.] batman-adv on different archs

[Marek Lindner]

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


>  so I went and  modified log.c directly to printk everything that is passed
>  to debug_log.

Actually, there is a debug level which you can modify to obtain the same 
result ...  ;)


> 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

Re: [B.A.T.M.A.N.] batman-adv on different archs

[Andrew Lunn]

> 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

Re: [B.A.T.M.A.N.] batman-adv on different archs

["Juha Ylönen"]

-------- Original-Nachricht --------
> Datum: Mon, 18 Jan 2010 21:38:32 +0800
> Von: Marek Lindner <lindner_marek@yahoo.de>
>
> 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?

> 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 

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

Re: [B.A.T.M.A.N.] batman-adv on different archs

["Juha Ylönen"]

-------- Original-Nachricht --------
> Datum: Mon, 18 Jan 2010 14:51:20 +0100
> Von: Andrew Lunn <andrew@lunn.ch>

> 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
-- 
Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.!
http://portal.gmx.net/de/go/dsl02

Re: [B.A.T.M.A.N.] batman-adv on different archs

[Marek Lindner]

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


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

Re: [B.A.T.M.A.N.] batman-adv on different archs

["Juha Ylönen"]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]


-------- Original-Nachricht --------
> Datum: Tue, 19 Jan 2010 20:07:38 +0800
> Von: Marek Lindner <lindner_marek@yahoo.de>
>
> 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
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

[-- Attachment #2: ARM-adhoc-batman --]
[-- Type: application/octet-stream, Size: 0 bytes --]

Re: [B.A.T.M.A.N.] batman-adv on different archs

["Juha Ylönen"]

[-- Attachment #1: Type: text/plain, Size: 242 bytes --]

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
-- 
Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.!
http://portal.gmx.net/de/go/dsl02

[-- Attachment #2: ARM-batman-wireshark.log --]
[-- Type: application/octet-stream, Size: 1982 bytes --]

Re: [B.A.T.M.A.N.] batman-adv on different archs

[Sven Eckelmann]

[-- Attachment #1: Type: Text/Plain, Size: 1486 bytes --]

Juha Ylönen wrote:
> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [B.A.T.M.A.N.] batman-adv on different archs

[Sven Eckelmann]

[-- Attachment #1: Type: Text/Plain, Size: 1392 bytes --]

Juha Ylönen wrote:
> > 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)).
> 
> 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 20100118132935.91200@gmx.net 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [B.A.T.M.A.N.] batman-adv on different archs

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 1783 bytes --]

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

On Tue, Jan 19, 2010 at 03:51:51PM +0100, "Juha Ylönen" wrote:
> 
> -------- Original-Nachricht --------
> > Datum: Tue, 19 Jan 2010 20:07:38 +0800
> > Von: Marek Lindner <lindner_marek@yahoo.de>
> >
> > 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
> -- 
> Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
> sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser



[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [B.A.T.M.A.N.] batman-adv on different archs

[Marek Lindner]

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

Re: [B.A.T.M.A.N.] batman-adv on different archs

["Juha Ylönen"]

-------- 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
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

Re: [B.A.T.M.A.N.] batman-adv on different archs

[Marek Lindner]

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

Re: [B.A.T.M.A.N.] batman-adv on different archs

[Andrew Lunn]

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

Re: [B.A.T.M.A.N.] batman-adv on different archs

[Sven Eckelmann]

[-- Attachment #1: Type: Text/Plain, Size: 1146 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [B.A.T.M.A.N.] batman-adv on different archs

["Juha Ylönen"]

-------- 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
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

Re: [B.A.T.M.A.N.] batman-adv on different archs

["Juha Ylönen"]

-------- Original-Nachricht --------
> Datum: Tue, 19 Jan 2010 20:37:01 +0100
> Von: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
>
> 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
-- 
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.

Re: [B.A.T.M.A.N.] batman-adv on different archs

[Marek Lindner]

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?

yap. If you want something more stable stay with the last release.


> 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

Re: [B.A.T.M.A.N.] batman-adv on different archs

[Marek Lindner]

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

Re: [B.A.T.M.A.N.] batman-adv on different archs

["Juha Ylönen"]

-------- 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
-- 
Haiti-Nothilfe! Helfen Sie per SMS: Sende UIHAITI an die Nummer 81190.
Von 5 Euro je SMS (zzgl. SMS-Gebühr) gehen 4,83 Euro an UNICEF.

Re: [B.A.T.M.A.N.] batman-adv on different archs

[Sven Eckelmann]

[-- Attachment #1.1: Type: Text/Plain, Size: 1009 bytes --]

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

[-- Attachment #1.2: rawsend.c --]
[-- Type: text/x-csrc, Size: 2692 bytes --]

#include <stdio.h>
#include <sys/ioctl.h>
#include <net/if.h> 
#include <sys/types.h>
#include <sys/socket.h>
#include <netpacket/packet.h>
#include <net/ethernet.h>
#include <stdint.h>
#include <string.h>
#include <arpa/inet.h>
#include <unistd.h>

int getmac(const char *src, unsigned char *dst)
{
	unsigned int n[6];
	int i;
	if (sscanf(src, "%x:%x:%x:%x:%x:%x",
	    &n[0], &n[1], &n[2], &n[3], &n[4], &n[5]) != 6) {
		if(sscanf(src, "%2x%2x.%2x%2x.%2x%2x",
		   &n[0], &n[1], &n[2], &n[3], &n[4], &n[5]) != 6) {
			return 1;
		}
	}

	for (i = 0; i < 6; i++) {
		if (n[i] <= 255)
			dst[i] = (unsigned char)n[i];
		else
			return 1;
	}

	return 0;
}

int main(int argc, char *argv[])
{
	int rawsock;
	uint16_t type = 0x1337;
	struct ifreq req;
	struct sockaddr_ll addr;
	struct iovec vector[2];
	char buf[256];
	size_t size = 256;
	struct ether_header header;

	if (argc != 2 && argc != 3) {
		fprintf(stderr, "Usage: %s DEVICE [DST-MAC]\n", argv[0]);
		return 1;
	}

	if ((rawsock = socket(PF_PACKET, SOCK_RAW, htons(type))) < 0 ) {
			fprintf(stderr, "Could not open raw socket\n");
			return 1;
	}

	strncpy(req.ifr_name, argv[1], IFNAMSIZ);
	if (ioctl(rawsock, SIOCGIFINDEX, &req) < 0) {
		fprintf(stderr, "Could not find device %s\n", argv[1]);
		return 1;
	}

	addr.sll_family = AF_PACKET;
	addr.sll_protocol = htons(type);
	addr.sll_ifindex  = req.ifr_ifindex;

	if (bind(rawsock, (struct sockaddr *)&addr, sizeof(addr)) < 0 ) {
		fprintf(stderr, "Could not bind to device %s\n", argv[1]);
		return 1;
	}

	strncpy(req.ifr_name, argv[1], IFNAMSIZ);
	if (ioctl(rawsock, SIOCGIFHWADDR, &req) < 0) {
		fprintf(stderr, "Could not get hwaddr of device %s\n", argv[1]);
		return 1;
	}

	if (argc == 2) {
		vector[0].iov_base = &header;
		vector[0].iov_len  = sizeof(struct ether_header);
		vector[1].iov_base = buf;
		vector[1].iov_len  = size;

		if (readv(rawsock, vector, 2) < 0) {
			close(rawsock);
			fprintf(stderr, "Could not receive message\n");
			return 1;
		}
		printf("Received message\n");
	} else if (argc == 3) {
		vector[0].iov_base = &header;
		vector[0].iov_len  = sizeof(struct ether_header);
		vector[1].iov_base = buf;
		vector[1].iov_len  = size;

		header.ether_type = htons(type);

		memcpy(header.ether_shost, req.ifr_hwaddr.sa_data, ETH_ALEN);

		if (getmac(argv[2], header.ether_dhost)) {
			close(rawsock);
			fprintf(stderr, "Could not parse mac address %s\n", argv[2]);
			return 1;
		}
		if (writev(rawsock, vector, 2) < 0) {
			close(rawsock);
			fprintf(stderr, "Could not send message\n");
			return 1;
		}
	}
	close(rawsock);
	return 0;
}

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [B.A.T.M.A.N.] batman-adv on different archs

[Gus Wirth]

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

Re: [B.A.T.M.A.N.] batman-adv on different archs

[Sven Eckelmann]

[-- Attachment #1.1: Type: text/plain, Size: 2138 bytes --]

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

[-- Attachment #1.2: eth1_blub.png --]
[-- Type: image/png, Size: 42017 bytes --]

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [B.A.T.M.A.N.] batman-adv on different archs

["Juha Ylönen"]

-------- Original-Nachricht --------
> Datum: Thu, 21 Jan 2010 18:57:52 +0100
> Von: Sven Eckelmann <sven.eckelmann@gmx.de>
> 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?

Hi,

This looks interesting, I've had problems with the wlan driver before but it has been quite stable for a while. Wlan chip in use is CSR UniFi 1050, with driver compiled from CSR supplied sources. 

I'll try your rawsend and ping capturing during the weekend. Sorry for the bother in advance if this turns out to be due the crappy wlan driver (as said, it has been giving problems earlier, though I haven't seen any packet mangling before).

-Juha

-- 
Haiti-Nothilfe! Helfen Sie per SMS: Sende UIHAITI an die Nummer 81190.
Von 5 Euro je SMS (zzgl. SMS-Gebühr) gehen 4,83 Euro an UNICEF.

Re: [B.A.T.M.A.N.] batman-adv on different archs

[Sven Eckelmann]

[-- Attachment #1: Type: Text/Plain, Size: 858 bytes --]

Juha Ylönen wrote:
> This looks interesting, I've had problems with the wlan driver before but
>  it has been quite stable for a while. Wlan chip in use is CSR UniFi 1050,
>  with driver compiled from CSR supplied sources.

Cannot find the driver at http://www.csr.com/products/UF1050_over.htm

> I'll try your rawsend and ping capturing during the weekend. Sorry for the
>  bother in advance if this turns out to be due the crappy wlan driver (as
>  said, it has been giving problems earlier, though I haven't seen any
>  packet mangling before).

So please test and capture 
 * rawsend from ARM
 * ping between laptop and arm 
 * a "ping -s 1" between laptop and arm

I hope that tests help to see were the problem really is. If the ping -s 1 
works, can you please also capture a some packets of batman-adv 0.2?

Best regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [B.A.T.M.A.N.] batman-adv on different archs

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 2612 bytes --]

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





[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [B.A.T.M.A.N.] batman-adv on different archs

["Juha Ylönen"]

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

-------- Original-Nachricht --------
> Datum: Fri, 22 Jan 2010 13:16:09 +0100
> Von: Sven Eckelmann <sven.eckelmann@gmx.de>
>
> Cannot find the driver at http://www.csr.com/products/UF1050_over.htm

They have files at csrsupport.com, but I can't actually find the driver sources there either. But the LICENSE file included says they're GPLv2. I'll check from the guy who I got the sources from, since this is a bit confusing.

> So please test and capture 
>  * rawsend from ARM
>  * ping between laptop and arm 
>  * a "ping -s 1" between laptop and arm
> 
> I hope that tests help to see were the problem really is. If the ping -s 1
> works, can you please also capture a some packets of batman-adv 0.2?

Logs for all cases attached. I pinged from arm to laptop, would you have liked it in the other direction too? 

Rawsend from arm->laptop didn't work, the packets end up in the laptop as llc packets, so apparently they were mangled by the driver. rawsend from laptop->arm worked fine, which is included in the rawsend.log file.

I'll try out with a later driver version (it has bad stability issues, which is why we use older version in the device).

-Juha

-- 
Haiti-Nothilfe! Helfen Sie per SMS: Sende UIHAITI an die Nummer 81190.
Von 5 Euro je SMS (zzgl. SMS-Gebühr) gehen 4,83 Euro an UNICEF.

[-- Attachment #2: rawsend2.log --]
[-- Type: application/octet-stream, Size: 1494 bytes --]

[-- Attachment #3: rawsend.log --]
[-- Type: application/octet-stream, Size: 604 bytes --]

[-- Attachment #4: ping-s1.log --]
[-- Type: application/octet-stream, Size: 3796 bytes --]

[-- Attachment #5: ping.log --]
[-- Type: application/octet-stream, Size: 3900 bytes --]

[-- Attachment #6: batman-lvl3-traffic.log --]
[-- Type: application/octet-stream, Size: 4356 bytes --]

Re: [B.A.T.M.A.N.] batman-adv on different archs

["Juha Ylönen"]

-------- 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
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

Re: [B.A.T.M.A.N.] batman-adv on different archs

[Sven Eckelmann]

[-- Attachment #1: Type: Text/Plain, Size: 1268 bytes --]

Juha Ylönen wrote:
> > So please test and capture
> >  * rawsend from ARM
> >  * ping between laptop and arm
> >  * a "ping -s 1" between laptop and arm
> >
> > I hope that tests help to see were the problem really is. If the ping -s
> > 1 works, can you please also capture a some packets of batman-adv 0.2?
> 
> Logs for all cases attached. I pinged from arm to laptop, would you have
>  liked it in the other direction too?

No, one direction is ok. What we can see here is that we have a < 50 bytes 
packet and it is seems to be send correctly. So maybe the problem is not 
related to "small" packets.

> Rawsend from arm->laptop didn't work, the packets end up in the laptop as
>  llc packets, so apparently they were mangled by the driver. rawsend from
>  laptop->arm worked fine, which is included in the rawsend.log file.

Ok, so we have a real simple example here. We see that we have a "large" 
ethernet frame (unlike batman-adv) and a "unnormal" ethernet type. So maybe 
you could forward rawsend.log and rawsend.c to the driver developers. They 
should be able to find and fix the problem with such a real small example. Or 
does anyone see a related problem in rawsend.c?

What is the batmand stuff for?

Best regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]