Hi all
I'm experiencing a strange situation
[AP_n]--wifi--[client]--mesh--[gateway]--wifi--[AP_g] | [xDSL]---[world]
The two nodes (client and gateway) are running batman 0.3 (experimental rv636) in the right way with option --bmx-defaults.
A wifi laptop associated with AP_g (gateway' AP) can browse internet pretty well while associated with AP_n (client' AP) it can't! Please note that client itself can browse internet! (I tryed ssh into node and then wget something). I verified no nameserver problem neither firewall blocking rules (gateway and node are flashed and run the same firmware)
But what is puzzling me is that running batman 0.2 on nodes... laptop associated with AP_n (client' AP) can browse! (I've only changed the daemon, no others change into environment - procedures dinamically change batmand command string) . I noticed the parameter "--no-unreachable-rule" then tryed adding this parameter at the batman 0.3 command string but unfortunately with no results!
Maybe I'm boring you... bat have any ideas about?
-- Antonio
Hi,
But what is puzzling me is that running batman 0.2 on nodes... laptop associated with AP_n (client' AP) can browse! (I've only changed the daemon, no others change into environment - procedures dinamically change batmand command string)
I don't know exactely about the experimental branch but the alpha branch has changed ports. Now we are using port 4305 for OGMs and 4306 for the internet tunnel. May be you have to adjust your firewall settings. In any case the debug level 3 output should give us more information regarding your problems.
I noticed the parameter "--no-unreachable-rule" then tryed adding this parameter at the batman 0.3 command string but unfortunately with no results!
I would suggest that you don't touch the policy routing switches unless you know what you are doing. If you don't have any special use cases the defaults should work perfectly for you.
Regards, Marek
Hello,
On Montag 24 September 2007, a.anselmi@oltrelinux.com wrote:
Hi all
I'm experiencing a strange situation
[AP_n]--wifi--[client]--mesh--[gateway]--wifi--[AP_g]
[xDSL]---[world]The two nodes (client and gateway) are running batman 0.3 (experimental rv636) in the right way with option --bmx-defaults.
A wifi laptop associated with AP_g (gateway' AP) can browse internet pretty well while associated with AP_n (client' AP) it can't! Please note that client itself can browse internet! (I tryed ssh into node and then wget something). I verified no nameserver problem neither firewall blocking rules (gateway and node are flashed and run the same firmware)
Just to get you right. your laptop is not running batman, just a usual wifi-client in managed mode. and your APs are not running batman as well, just usual APs in managed mode. If that is the case the problems is actually only related to non-batman nodes!? If not, try to collect further information about your iproute configuration like: $ip rule $ip r ls t 254 $ip r ls t 65 $ip r ls t 66 $ip r ls t 67 And maybe your firewall or nat settings?
But what is puzzling me is that running batman 0.2 on nodes... laptop associated with AP_n (client' AP) can browse! (I've only changed the daemon, no others change into environment - procedures dinamically change batmand command string) . I noticed the parameter "--no-unreachable-rule" then tryed adding this parameter at the batman 0.3 command string but unfortunately with no results!
Batman-0.3 and beyond supports policy routing, thus uses 3 routing tables for configuring the routes. There is table 65 for HNA routes, 66 for host routes, and 67 for default routes (the command: ip route list table 66 # for example shows the host routes). Also batman usually adds an unreachable rule to the end of table 66 so that all hosts which IP netmask is falling into the netmask used for the batman mesh is immediately considered unreachable if not having a dedicated batman-host route to that IP. The --no-unreachable-rule simply does not set this roule. Using this switch is usully only necessary if you are doing very fancy stuff.
ciao, axel
Maybe I'm boring you... bat have any ideas about?
-- Antonio
B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
Hi
Is not a problem of ports or firewall (batman' stream flows well over the mesh... otherwise client node itself would not browse or would not find any other originator): iI believe problem stay "in front" of mesh and not inside the mesh. I've two roads to walk:
1) AP IP space is in HNA: maybe exists a different way of managing HNA routes in gateways and in clients ? (remember that users associated with gateway AP browse). It seems client node batmand daemon (the 0.3 release) doesn't how to manage/route packets coming from HNA - it desn't matter if coming from wifi conenctions or wired one but its source IP
2) Something of wrong in route table 65?
I'll do more tests looking deeper at routing tables...
Antonio
Just to get you right. your laptop is not running batman, just a usual wifi-client in managed mode. and your APs are not running batman as well, just usual APs in managed mode. If that is the case the problems is actually only related to non-batman nodes!? If not, try to collect further information about your iproute configuration like: $ip rule $ip r ls t 254 $ip r ls t 65 $ip r ls t 66 $ip r ls t 67 And maybe your firewall or nat settings?
But what is puzzling me is that running batman 0.2 on nodes... laptop associated with AP_n (client' AP) can browse! (I've only changed the daemon, no others change into environment - procedures dinamically change batmand command string) . I noticed the parameter "--no-unreachable-rule" then tryed adding this parameter at the batman 0.3 command string but unfortunately with no results!
Batman-0.3 and beyond supports policy routing, thus uses 3 routing tables for configuring the routes. There is table 65 for HNA routes, 66 for host routes, and 67 for default routes (the command: ip route list table 66 # for example shows the host routes). Also batman usually adds an unreachable rule to the end of table 66 so that all hosts which IP netmask is falling into the netmask used for the batman mesh is immediately considered unreachable if not having a dedicated batman-host route to that IP. The --no-unreachable-rule simply does not set this roule. Using this switch is usully only necessary if you are doing very fancy stuff.
ciao, axel
Maybe I'm boring you... bat have any ideas about?
-- Antonio
B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
Hi,
Is not a problem of ports or firewall (batman' stream flows well over the mesh... otherwise client node itself would not browse or would not find any other originator): iI believe problem stay "in front" of mesh and not inside the mesh. I've two roads to walk:
ok - seems logic. :-)
- AP IP space is in HNA: maybe exists a different way of managing HNA
routes in gateways and in clients ? (remember that users associated with gateway AP browse). It seems client node batmand daemon (the 0.3 release) doesn't how to manage/route packets coming from HNA - it desn't matter if coming from wifi conenctions or wired one but its source IP
- Something of wrong in route table 65?
At first: Could you check on the batman alpha branch ? I fxed the HNA settings which may be the cause of your trouble. AFAIK Axel did not merge this into experimental yet.
Normally the packet flow would be like this: AP -> client which routes the traffic into the tun device. Batman 0.3 has a "default route protection" which disallows other mesh users to access the tunnel. All other interfaces should be routed through the tunnel. Could you send us your routing tables (as Axel already suggested) ?
Regards, Marek
Ok Marek
At present I can't test neither send any logs or printouts :( tomorrow morning I'll try 0.3 alpha into same scenario and feedback to you. Thanks for tip!
ciao
Antonio
Is not a problem of ports or firewall (batman' stream flows well over the mesh... otherwise client node itself would not browse or would not find any other originator): iI believe problem stay "in front" of mesh and not inside the mesh. I've two roads to walk:
ok - seems logic. :-)
- AP IP space is in HNA: maybe exists a different way of managing HNA
routes in gateways and in clients ? (remember that users associated with gateway AP browse). It seems client node batmand daemon (the 0.3 release) doesn't how to manage/route packets coming from HNA - it desn't matter if coming from wifi conenctions or wired one but its source IP
- Something of wrong in route table 65?
At first: Could you check on the batman alpha branch ? I fxed the HNA settings which may be the cause of your trouble. AFAIK Axel did not merge this into experimental yet.
Normally the packet flow would be like this: AP -> client which routes the traffic into the tun device. Batman 0.3 has a "default route protection" which disallows other mesh users to access the tunnel. All other interfaces should be routed through the tunnel. Could you send us your routing tables (as Axel already suggested) ?
Regards, Marek _______________________________________________ B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
b.a.t.m.a.n@lists.open-mesh.org
-
a.anselmi＠oltrelinux.com -
Axel Neumann -
Marek Lindner