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?