Can you provide specifics about what you saw when
running tcpdump ? What does
'never getting anything back' mean ? The ping goes one way without any pong
showing up ? Have you checked on the ping destination (via tcpdump) that the
ping ever made it there ?
I had two non-batman clients on the mesh, connected to two different
nodes separated by a third node (i.e. for the client on node 1 to
communicate to the client on node 3, the data has to go through node 2).
Each client can ping the node they are connected to (the br0
interface, which has the IP address), but when they try and ping another
node or the other client I see the ping requests go out in tcpdump, but
nothing received at the other end (again in tcpdump). I do see a lot of
ARP requests without replies on the originator if that helps.
Here is some sample output. Client 3b is trying to ping client 4a and
4a is trying to ping 3b at the same time. While all batman nodes can
ping other nodes, they can only ping their own clients (i.e. those
connected directly to them).
I'm guessing I'm missing some sort of routing information or bridge
configuration. If anyone can shed some light or let me know what sort
of output they'd like to see I'm happy to gather it and send it along.
One more update. I switched to use the program arping to just send ARP
packets. I found that I can use arping to get the MAC address for any
node, provided that MAC address is in the cache of the node I am
connected to.
For example, if I run 'arping -I eth0 192.168.1.102 -c 5 -b' on my
client at 192.168.1.141, I see replies coming from 192.168.1.104 (the
batman node which has the MAC cached). If I omit the '-b' on the arping
command (i.e. use broadcast once, then unicast after), I get the first
reply, but nothing thereafter, nor does the node see the unicast requests.
As another test, I run 'arping -I eth0 192.168.1.132 -c 5 -b' on my
client at 192.168.1.141, I see the requests propagate through the mesh
all the way to 192.168.1.132 and I see it reply via a unicast ARP reply.
However, this unicast ARP reply is not seen by node 192.168.1.103 at
all (on any interface).
So it seems to be that there is something up with unicasting from a
non-batman client. Thoughts?
