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