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

[Sven Eckelmann <sven.eckelmann@gmx.de>]

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