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

Sven Eckelmann
2010-01-21T18:32:10Z

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