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
signature.asc
Description: Digital signature
