On 2010-09-29 23:40, Marek Lindner wrote:
On Wednesday 29 September 2010 22:44:36 Magosányi Árpád wrote:
I am using OpenWrt Backfire.
Ok.
One sign that I am using nonstandard setting is that a non-batman node will end up in a throw route of the batman nodes. But if it should work without firewall, then I will be happy with my current setup.
A throw route is no problem by itself. It only means that the Linux kernel will leave the current table to check the next one for a suitable routing entry.
If you are interested in understanding the routing techniques used by batman: http://www.open-mesh.org/wiki/RoutingVodoo
What I am seeing is that traffic from local wifi net does not "go down" to the tunnels, but goes through the batman nodes untunneled. Maybe I have to set up some routes from the local wifi net? For your reference here is the network setup again (N is the node number, ip of the node/netmask len): backbone batman network: 10.42.0.N/24 (for batman nodes) local wifi net: 10.42.N.1/24 (for non-batman users, dhcp served from the node in force mode) local lan: 10.43.N.1/24 (for wired users, DHCP served from the node)
Does each node announce the "local wifi net" via HNA ? You will need these announcements to make the routing towards this addresses work. As soon as batmand knows that it is responsible for a certain IP address space it will add the appropriate routing entries for you. Again, we have a document describing the process: http://www.open-mesh.org/wiki/AnnouncingNetworks
I do announce local wifi net through HNA. In the meantime my config started to not work. I saw that the node in the middle does REJECT tunnel traffic from packet filter, so added a firewall rule to accept everything in the FORWARD chain in all nodes. Then as packets started to come out from the system with tunnel source IP, I have added a MASQUERADE on the node which is connected to the internet gateway.
Now it works, but uses the tunnel in an assymetric way: packets out go through the tunnel, packets in go in the plain route.
13:38:53.464186 00:22:fa:95:1d:c4 > 00:0b:6b:3c:74:86, ethertype IPv4 (0x0800), length 74: 10.42.3.178.51723 > 1.2.3.4.80: Flags [S], seq 2151644104, win 5840, options [mss 1460,sackOK,TS val 6321427 ecr 0,nop,wscale 6], length 0 13:38:53.468526 00:0b:6b:3c:74:86 > 00:0b:6b:3c:73:56, ethertype IPv4 (0x0800), length 103: 10.42.0.3.4306 > 10.42.0.4.4306: UDP, length 61 13:38:53.469091 00:0b:6b:3c:73:56 > 00:0b:6b:3c:74:8c, ethertype IPv4 (0x0800), length 103: 10.42.0.3.4306 > 10.42.0.4.4306: UDP, length 61 13:38:53.474019 00:0b:6b:3c:74:8c > 00:0b:6b:3c:73:56, ethertype IPv4 (0x0800), length 74: 1.2.3.4.80 > 10.42.3.178.51723: Flags [S.], seq 1125027318, ack 2151644105, win 5792, options [mss 1460,sackOK,TS val 19849628 ecr 6321427,nop,wscale 5], length 0 13:38:53.474497 00:0b:6b:3c:73:56 > 00:0b:6b:3c:74:86, ethertype IPv4 (0x0800), length 74: 1.2.3.4.80 > 10.42.3.178.51723: Flags [S.], seq 1125027318, ack 2151644105, win 5792, options [mss 1460,sackOK,TS val 19849628 ecr 6321427,nop,wscale 5], length 0 13:38:53.475385 00:0b:6b:3c:74:86 > 00:22:fa:95:1d:c4, ethertype IPv4 (0x0800), length 74: 1.2.3.4.80 > 10.42.3.178.51723: Flags [S.], seq 1125027318, ack 2151644105, win 5792, options [mss 1460,sackOK,TS val 19849628 ecr 6321427,nop,wscale 5], length 0
Páty, Hungary. We are experimenting with participatory democracy, and this is one of the side effects:)
Cool! Good luck with your experiments. :-)
Regards, Marek