Hi!
I setup 3 nodes on OpenWRT Kamikaze and B.A.T.M.A.N 0.3, using atheros chipset.
My gateway is started this way: batmand -g 5Mbit/1Mbit -a some_subnet... ath0 My nodes: batmand -r 2 -a other_subnets... ath0
Let's call them "gateway", "node1", "node2".
"gateway" is in my basement.
"node1" is upstairs.
"node2" is in the shed.
node1's connection to gateway is strong. node2's connection to gateway is very weak, about 50% packet loss. node2's connection to node1 is strong.
Knowing this: does anybody have a clue to why my node2 keeps switching from node1 to gateway? I connect to node2 and ping on the internet constantly, I see the node switching back and forth from node1 to gateway, sending some of my packets to one, or the other... basically the user experience is horrible.
I was missing FW masquerading rules until yesterday, things were not working at all when I was not going through the gateway directly, but that "seems" to be resolved, now packets go by "sometimes". If node2 could stick to using node1, it would be easier to troubleshoot.
I'm trying to move my nodes as far as I can so it can't connect to the gateway directly at all from node2 but the shed does not seem to be far enough :)
Thanks for any enlightenment...
Philippe April
Hello,
I too am stuck at a similar case would where in my remote node keeps jumping on and off the gateway even tho it has better signal strength form node1 . i have node running as -r 2 atm when i had them on -r 3 the batman gateway crashed (batmand exited ungracefully leaving routes in table 66). now with -r2 it does not crash but keeps jumping at time.
I am using batman (r 963) on kamikaze 7.09 with kernel 2.6.21 and tun on gateway .i only have batman as routing daemon and have masqueraded output interfaces (referring to a previous solution for the -r 3 crash) .
Regards, Vinay
On Mon, Apr 14, 2008 at 11:12 AM, Philippe April < isf_lists@philippeapril.com> wrote:
Hi!
I setup 3 nodes on OpenWRT Kamikaze and B.A.T.M.A.N 0.3, using atheros chipset.
My gateway is started this way: batmand -g 5Mbit/1Mbit -a some_subnet... ath0 My nodes: batmand -r 2 -a other_subnets... ath0
Let's call them "gateway", "node1", "node2".
"gateway" is in my basement.
"node1" is upstairs.
"node2" is in the shed.
node1's connection to gateway is strong. node2's connection to gateway is very weak, about 50% packet loss. node2's connection to node1 is strong.
Knowing this: does anybody have a clue to why my node2 keeps switching from node1 to gateway? I connect to node2 and ping on the internet constantly, I see the node switching back and forth from node1 to gateway, sending some of my packets to one, or the other... basically the user experience is horrible.
I was missing FW masquerading rules until yesterday, things were not working at all when I was not going through the gateway directly, but that "seems" to be resolved, now packets go by "sometimes". If node2 could stick to using node1, it would be easier to troubleshoot.
I'm trying to move my nodes as far as I can so it can't connect to the gateway directly at all from node2 but the shed does not seem to be far enough :)
Thanks for any enlightenment...
Philippe April _______________________________________________ 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
Seems like the gateway still crashes with clients connected as -r 2 but after a long time.I dont see a log message nither do i know when it crashed but the non gateway node have been running for almost 48+ hrs without any down time on lan.
Regards,
On Tue, Apr 15, 2008 at 4:04 AM, Vinay Menon vinaymenon@gmail.com wrote:
Hello,
I too am stuck at a similar case would where in my remote node keeps jumping on and off the gateway even tho it has better signal strength form node1 . i have node running as -r 2 atm when i had them on -r 3 the batman gateway crashed (batmand exited ungracefully leaving routes in table 66). now with -r2 it does not crash but keeps jumping at time.
I am using batman (r 963) on kamikaze 7.09 with kernel 2.6.21 and tun on gateway .i only have batman as routing daemon and have masqueraded output interfaces (referring to a previous solution for the -r 3 crash) .
Regards, Vinay
On Mon, Apr 14, 2008 at 11:12 AM, Philippe April < isf_lists@philippeapril.com> wrote:
Hi!
I setup 3 nodes on OpenWRT Kamikaze and B.A.T.M.A.N 0.3, using atheros chipset.
My gateway is started this way: batmand -g 5Mbit/1Mbit -a some_subnet... ath0 My nodes: batmand -r 2 -a other_subnets... ath0
Let's call them "gateway", "node1", "node2".
"gateway" is in my basement.
"node1" is upstairs.
"node2" is in the shed.
node1's connection to gateway is strong. node2's connection to gateway is very weak, about 50% packet loss. node2's connection to node1 is strong.
Knowing this: does anybody have a clue to why my node2 keeps switching from node1 to gateway? I connect to node2 and ping on the internet constantly, I see the node switching back and forth from node1 to gateway, sending some of my packets to one, or the other... basically the user experience is horrible.
I was missing FW masquerading rules until yesterday, things were not working at all when I was not going through the gateway directly, but that "seems" to be resolved, now packets go by "sometimes". If node2 could stick to using node1, it would be easier to troubleshoot.
I'm trying to move my nodes as far as I can so it can't connect to the gateway directly at all from node2 but the shed does not seem to be far enough :)
Thanks for any enlightenment...
Philippe April _______________________________________________ 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
-- Vinay Menon
I just found out why my node is switching! Now I need to know if there's a way to tell it not to :)
It switches because the quality (/ 255) varies from 230 to 255 in each direction.
As soon as signal from node2 to node1 goes down from let's say 250 to 240, if another connection to the gateway's quality is 241, it'll switch as soon as it hits 240... Then when quality comes back up to 242, it switches back to node1.
I don't think it's very good to switch as soon as the quality is higher somewhere else, it should at least "give it a chance" by either having a threshold, or switch only if it's been in a more degraded state for more than x minutes, etc.
Is there something I can do to influence that? Did I miss a command line argument?
Thank you!
On 15-Apr-08, at 4:04 AM, Vinay Menon wrote:
Hello,
I too am stuck at a similar case would where in my remote node keeps jumping on and off the gateway even tho it has better signal strength form node1 . i have node running as -r 2 atm when i had them on -r 3 the batman gateway crashed (batmand exited ungracefully leaving routes in table 66). now with -r2 it does not crash but keeps jumping at time.
I am using batman (r 963) on kamikaze 7.09 with kernel 2.6.21 and tun on gateway .i only have batman as routing daemon and have masqueraded output interfaces (referring to a previous solution for the -r 3 crash) .
Regards, Vinay
On Mon, Apr 14, 2008 at 11:12 AM, Philippe April <isf_lists@philippeapril.com
wrote:
Hi!
I setup 3 nodes on OpenWRT Kamikaze and B.A.T.M.A.N 0.3, using atheros chipset.
My gateway is started this way: batmand -g 5Mbit/1Mbit -a some_subnet... ath0 My nodes: batmand -r 2 -a other_subnets... ath0
Let's call them "gateway", "node1", "node2".
"gateway" is in my basement.
"node1" is upstairs.
"node2" is in the shed.
node1's connection to gateway is strong. node2's connection to gateway is very weak, about 50% packet loss. node2's connection to node1 is strong.
Knowing this: does anybody have a clue to why my node2 keeps switching from node1 to gateway? I connect to node2 and ping on the internet constantly, I see the node switching back and forth from node1 to gateway, sending some of my packets to one, or the other... basically the user experience is horrible.
I was missing FW masquerading rules until yesterday, things were not working at all when I was not going through the gateway directly, but that "seems" to be resolved, now packets go by "sometimes". If node2 could stick to using node1, it would be easier to troubleshoot.
I'm trying to move my nodes as far as I can so it can't connect to the gateway directly at all from node2 but the shed does not seem to be far enough :)
Thanks for any enlightenment...
Philippe April _______________________________________________ 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
-- Vinay Menon _______________________________________________ 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
As soon as signal from node2 to node1 goes down from let's say 250 to 240, if another connection to the gateway's quality is 241, it'll switch as soon as it hits 240... Then when quality comes back up to 242, it switches back to node1.
I don't think it's very good to switch as soon as the quality is higher somewhere else, it should at least "give it a chance" by either having a threshold, or switch only if it's been in a more degraded state for more than x minutes, etc.
Is there something I can do to influence that? Did I miss a command line argument?
You can use e.g. "-r 20" to switch the gateway as soon as the TQ difference is bigger than 20.
From "batmand -H":
-r routing class (only needed if gateway class = 0) default: 0 -> set no default route allowed values: 1 -> use fast internet connection (gw_flags * TQ) 2 -> use stable internet connection (TQ) 3 -> use fast-switch internet connection (TQ but switch as soon as a better gateway appears)
XX -> use late-switch internet connection (TQ but switch as soon as a gateway appears which is XX TQ better)
Greetings, Marek
I tried that but I think it's only for switching from a gateway to another gateway.
My problem is for switching from an intermediate node, to another...
For example, imagine a square where there's a node in each corner at almost equal distance/signal quality (to keep things simple) with some interference, and only one of them is the gateway, and the node opposite to the gateway can't reach the gateway directly.
That node (opposite to the gateway) has the choice between two nodes to get to the gateway.
In my/this case, it keeps switching from one to the other (since the quality is almost the same on each). I guess it doesn't help keeping things reliable for laptop connections behind... Playing with -r doesn't seem to help because I only have one gateway node.
Am I right?
On 15-Apr-08, at 2:02 PM, Marek Lindner wrote:
As soon as signal from node2 to node1 goes down from let's say 250 to 240, if another connection to the gateway's quality is 241, it'll switch as soon as it hits 240... Then when quality comes back up to 242, it switches back to node1.
I don't think it's very good to switch as soon as the quality is higher somewhere else, it should at least "give it a chance" by either having a threshold, or switch only if it's been in a more degraded state for more than x minutes, etc.
Is there something I can do to influence that? Did I miss a command line argument?
You can use e.g. "-r 20" to switch the gateway as soon as the TQ difference is bigger than 20.
From "batmand -H":
-r routing class (only needed if gateway class = 0) default: 0 -> set no default route allowed values: 1 -> use fast internet connection (gw_flags * TQ) 2 -> use stable internet connection (TQ) 3 -> use fast-switch internet connection (TQ but switch as soon as a better gateway appears)
XX -> use late-switch internet connection(TQ but switch as soon as a gateway appears which is XX TQ better)
Greetings, 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
In my/this case, it keeps switching from one to the other (since the quality is almost the same on each). I guess it doesn't help keeping things reliable for laptop connections behind... Playing with -r doesn't seem to help because I only have one gateway node.
Correct - I misunderstood you. What is switching then ? The route itself and not the tunnel to the internet ? Why is that a problem ? Can you draw a picture ?
Greetings, Marek
Hi Philippe -
fast switching of a route is a problem if does cause routing loops. I have verified in a 7x7 physical mesh grid that B.A.T.M.A.N. doesn't loop - ever. And - yes - particularly in my tests where I saturated the grid with several massive traffic streams that were colliding in the center of the grid, B.A.T.M.A.N. was switching routes quite often (every few seconds).
I see therefore no point in adding hysteresis. If someone can show that there is an issue we can add hysteresis to the protocol.
cu elektra
I tried that but I think it's only for switching from a gateway to another gateway.
My problem is for switching from an intermediate node, to another...
For example, imagine a square where there's a node in each corner at almost equal distance/signal quality (to keep things simple) with some interference, and only one of them is the gateway, and the node opposite to the gateway can't reach the gateway directly.
That node (opposite to the gateway) has the choice between two nodes to get to the gateway.
In my/this case, it keeps switching from one to the other (since the quality is almost the same on each). I guess it doesn't help keeping things reliable for laptop connections behind... Playing with -r doesn't seem to help because I only have one gateway node.
Am I right?
On 15-Apr-08, at 2:02 PM, Marek Lindner wrote:
As soon as signal from node2 to node1 goes down from let's say 250 to 240, if another connection to the gateway's quality is 241, it'll switch as soon as it hits 240... Then when quality comes back up to 242, it switches back to node1.
I don't think it's very good to switch as soon as the quality is higher somewhere else, it should at least "give it a chance" by either having a threshold, or switch only if it's been in a more degraded state for more than x minutes, etc.
Is there something I can do to influence that? Did I miss a command line argument?
You can use e.g. "-r 20" to switch the gateway as soon as the TQ difference is bigger than 20.
From "batmand -H":
-r routing class (only needed if gateway class = 0) default: 0 -> set no default route allowed values: 1 -> use fast internet connection (gw_flags * TQ) 2 -> use stable internet connection (TQ) 3 -> use fast-switch internet connection (TQ but switch as soon as a better gateway appears)
XX -> use late-switch internet connection(TQ but switch as soon as a gateway appears which is XX TQ better)
Greetings, 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 mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
:)
In my case, I'm not having loop problems, I'm just testing my setup to see if things are stable, and I was wondering why the path wouldn't stay the same.
With your tests with massive traffic streams, can you confirm that (for example) a user who's downloading something big (or an interactive ssh session) should not see a difference and the flow should stay constant, even though the traffic switches to another path several times during the session? That'd be great (and I'll test that tonight!)
On 15-Apr-08, at 3:04 PM, elektra wrote:
Hi Philippe -
fast switching of a route is a problem if does cause routing loops. I have verified in a 7x7 physical mesh grid that B.A.T.M.A.N. doesn't loop - ever. And - yes - particularly in my tests where I saturated the grid with several massive traffic streams that were colliding in the center of the grid, B.A.T.M.A.N. was switching routes quite often (every few seconds).
I see therefore no point in adding hysteresis. If someone can show that there is an issue we can add hysteresis to the protocol.
cu elektra
I tried that but I think it's only for switching from a gateway to another gateway.
My problem is for switching from an intermediate node, to another...
For example, imagine a square where there's a node in each corner at almost equal distance/signal quality (to keep things simple) with some interference, and only one of them is the gateway, and the node opposite to the gateway can't reach the gateway directly.
That node (opposite to the gateway) has the choice between two nodes to get to the gateway.
In my/this case, it keeps switching from one to the other (since the quality is almost the same on each). I guess it doesn't help keeping things reliable for laptop connections behind... Playing with -r doesn't seem to help because I only have one gateway node.
Am I right?
On 15-Apr-08, at 2:02 PM, Marek Lindner wrote:
As soon as signal from node2 to node1 goes down from let's say 250 to 240, if another connection to the gateway's quality is 241, it'll switch as soon as it hits 240... Then when quality comes back up to 242, it switches back to node1.
I don't think it's very good to switch as soon as the quality is higher somewhere else, it should at least "give it a chance" by either having a threshold, or switch only if it's been in a more degraded state for more than x minutes, etc.
Is there something I can do to influence that? Did I miss a command line argument?
You can use e.g. "-r 20" to switch the gateway as soon as the TQ difference is bigger than 20.
From "batmand -H":
-r routing class (only needed if gateway class = 0) default: 0 -> set no default route allowed values: 1 -> use fast internet connection (gw_flags * TQ) 2 -> use stable internet connection (TQ) 3 -> use fast-switch internet connection (TQ but switch as soon as a better gateway appears)
XX -> use late-switch internet connection(TQ but switch as soon as a gateway appears which is XX TQ better)
Greetings, 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 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 -
With your tests with massive traffic streams, can you confirm that (for example) a user who's downloading something big (or an interactive ssh session) should not see a difference and the flow should stay constant, even though the traffic switches to another path several times during the session?
If two routes have similar quality it is no wonder that the protocol may switch because self-inflicted interference from payload degrades the route metric. If the alternative route is 10 % worse, the protocol may occasionally use the latter for a short time if the best route is fully saturated. As soon as the superior route has no payload anymore the metric improves again, while the metric of the inferior route drops. So the protocol will switch back quickly.
In such a scenario the superior route may be used most of the time, while the inferior route may be chosen less often. This may have a minor affect on the throughput - if one route has 10% less throughput than the other, but is only used 20% of the time, the negative effect is very limited. I'd prefer this behavior over adding hysteresis, which may introduce new and more severe headaches.
What is important to me is that the protocol is responsive to changes, and while it changes often, doesn't produce any routing errors.
When I was working on OLSR in 2004 and 2005 for Freifunk, we had the problem that OLSR started producing routing loops under such conditions in our mesh. We saturated a route (transferring high speed data traffic at 200 kByte/sec for 10 seconds) and then the route would break down completely for 40 seconds and come back at a speed of something like 8 kByte/sec and 'stabilize' itself there... We solved the problem for OLSR (not entirely, but to about 95%) by making its responsiveness slower and slower and introducing Fisheye into OLSR (send topology information more redundant and more often without drowning the network with protocol overhead).
I have made some rough tests to see how much a fully saturated link degrades the metric value measured by Originator messages. I have found that a fully saturated link does reduce the metric values of Batman a bit, but in my tests it was less than 10%.
If the protocol would switch between a miserable route and a good route, and utilize each one half of the time this would have a significant effect on the throughput, and it was one of my worries in the early days of the protocol design. As far as I have seen in practice this is not the case.
That'd be great (and I'll test that tonight!)
Yes, please test it.
cu elektra
Philippe...seems your problem and mine are similar hence continuing posting in this thread,if you feel its different please tell me ill repost as a new thread.
My network setup is as shown
Gateway 10.24.249.96 ------------------------------------- | 50ft | | | | Node 1 (10.1.125.158) ------------------------------------- | 25ft | | Node 2 (10.1.52.)236 -------------------------------------
The wifi signal strength between Gateway and Node 1 is good and so is between Node 1 and Node 2 .In general the average signal strength between Node 2 and gateway is bad. But momentarily there seems to be an improvement in direct link between the Gateway and Node 2 and at this point of time the the tunnel formed from Node 2 to gateway via Node 1 is deleted and the a new direct tunnel is formed which again looses link as its average signal strength is bad.
This is what batmand -cd3 on the Node 2 shows
/ # batmand -cd3 WARNING: You are using the unstable batman branch. If you are interested in *using* batman get the latest stable release ! Gateway client - successfully refreshed IP lease: 10.24.249.96 Deleting route to 10.24.249.96 via 0.0.0.0 (table 66 - ath0) Adding route to 10.24.249.96/32 via 10.1.125.158 (table 66 - ath0) Deleting route to 10.24.249.96/32 via 10.1.125.158 (table 66 - ath0) Adding route to 10.24.249.96 via 0.0.0.0 (table 66 - ath0) Deleting route to 10.24.249.96 via 0.0.0.0 (table 66 - ath0) Adding route to 10.24.249.96/32 via 10.1.125.158 (table 66 - ath0) Gateway client - disconnecting from unresponsive gateway (10.24.249.96): could not refresh IP lease Deleting default route via gate0 (table 68) Adding default route to 10.24.249.96 (gw_flags: 41, tq: 178, gw_product: 0) Adding default route to 10.24.249.96 (gw_flags: 41, tq: 171, gw_product: 0) Gateway client - got IP (169.254.0.2) from gateway: 10.24.249.96 Adding default route via gate0 (table 68) Gateway client - gateway (10.24.249.96) says: IP (169.254.0.2) is expired Deleting default route via gate0 (table 68) Adding default route to 10.24.249.96 (gw_flags: 41, tq: 46, gw_product: 0) Gateway client - got IP (169.254.0.2) from gateway: 10.24.249.96 Adding default route via gate0 (table 68) Deleting route to 10.24.249.96/32 via 10.1.125.158 (table 66 - ath0) Adding route to 10.24.249.96 via 0.0.0.0 (table 66 - ath0) Deleting route to 10.24.249.96 via 0.0.0.0 (table 66 - ath0) Adding route to 10.24.249.96/32 via 10.1.125.158 (table 66 - ath0) Deleting route to 10.24.249.96/32 via 10.1.125.158 (table 66 - ath0) Adding route to 10.24.249.96 via 0.0.0.0 (table 66 - ath0) Deleting route to 10.24.249.96 via 0.0.0.0 (table 66 - ath0) Adding route to 10.24.249.96/32 via 10.1.125.158 (table 66 - ath0) Deleting route to 10.24.249.96/32 via 10.1.125.158 (table 66 - ath0) --CUT--
The above keeps happening very frequently (at times even every 5-10 secs) and in my case eventually the gateway crashed (which is my second problem i had posted separately yesterday).
I have noticed that while i am connected to Node 2 and am downloading or transfering data from internet the link keeps chopping up and in most cases times out....however as my wan ip is constant the downloads don't get disconnected.
Seems like on my node2 the TQ value keeps ramping up and down (120-230) along with my internet usage... Batman does consider and average TQ value rite?
On Wed, Apr 16, 2008 at 4:40 AM, Vinay Menon vinaymenon@gmail.com wrote:
Philippe...seems your problem and mine are similar hence continuing posting in this thread,if you feel its different please tell me ill repost as a new thread.
My network setup is as shown
Gateway 10.24.249.96 ------------------------------------- | 50ft | | | | Node 1 (10.1.125.158) ------------------------------------- | 25ft | | Node 2 (10.1.52.)236 -------------------------------------The wifi signal strength between Gateway and Node 1 is good and so is between Node 1 and Node 2 .In general the average signal strength between Node 2 and gateway is bad. But momentarily there seems to be an improvement in direct link between the Gateway and Node 2 and at this point of time the the tunnel formed from Node 2 to gateway via Node 1 is deleted and the a new direct tunnel is formed which again looses link as its average signal strength is bad.
This is what batmand -cd3 on the Node 2 shows
/ # batmand -cd3 WARNING: You are using the unstable batman branch. If you are interested in *using* batman get the latest stable release ! Gateway client - successfully refreshed IP lease: 10.24.249.96 Deleting route to 10.24.249.96 via 0.0.0.0 (table 66 - ath0) Adding route to 10.24.249.96/32 via 10.1.125.158 (table 66 - ath0) Deleting route to 10.24.249.96/32 via 10.1.125.158 (table 66 - ath0) Adding route to 10.24.249.96 via 0.0.0.0 (table 66 - ath0) Deleting route to 10.24.249.96 via 0.0.0.0 (table 66 - ath0) Adding route to 10.24.249.96/32 via 10.1.125.158 (table 66 - ath0) Gateway client - disconnecting from unresponsive gateway (10.24.249.96): could not refresh IP lease Deleting default route via gate0 (table 68) Adding default route to 10.24.249.96 (gw_flags: 41, tq: 178, gw_product: 0) Adding default route to 10.24.249.96 (gw_flags: 41, tq: 171, gw_product: 0) Gateway client - got IP (169.254.0.2) from gateway: 10.24.249.96 Adding default route via gate0 (table 68) Gateway client - gateway (10.24.249.96) says: IP (169.254.0.2) is expired Deleting default route via gate0 (table 68) Adding default route to 10.24.249.96 (gw_flags: 41, tq: 46, gw_product: 0) Gateway client - got IP (169.254.0.2) from gateway: 10.24.249.96 Adding default route via gate0 (table 68) Deleting route to 10.24.249.96/32 via 10.1.125.158 (table 66 - ath0) Adding route to 10.24.249.96 via 0.0.0.0 (table 66 - ath0) Deleting route to 10.24.249.96 via 0.0.0.0 (table 66 - ath0) Adding route to 10.24.249.96/32 via 10.1.125.158 (table 66 - ath0) Deleting route to 10.24.249.96/32 via 10.1.125.158 (table 66 - ath0) Adding route to 10.24.249.96 via 0.0.0.0 (table 66 - ath0) Deleting route to 10.24.249.96 via 0.0.0.0 (table 66 - ath0) Adding route to 10.24.249.96/32 via 10.1.125.158 (table 66 - ath0) Deleting route to 10.24.249.96/32 via 10.1.125.158 (table 66 - ath0) --CUT--
The above keeps happening very frequently (at times even every 5-10 secs) and in my case eventually the gateway crashed (which is my second problem i had posted separately yesterday).
I have noticed that while i am connected to Node 2 and am downloading or transfering data from internet the link keeps chopping up and in most cases times out....however as my wan ip is constant the downloads don't get disconnected.
-- Vinay Menon
Hi Vinay,
What kind of hardware are you running this on? I had a lot of problems when it switched route until I tweaked some radio settings and FW rules, it seems better now.
On 16-Apr-08, at 4:40 AM, Vinay Menon wrote:
Philippe...seems your problem and mine are similar hence continuing posting in this thread,if you feel its different please tell me ill repost as a new thread.
My network setup is as shown
Gateway 10.24.249.96 ------------------------------------- | 50ft | | | | Node 1 (10.1.125.158) ------------------------------------- | 25ft | | Node 2 (10.1.52.)236 -------------------------------------
Hi Philippe, My gateway is a old fonera and nodes are meraki. I am using kamikaze 7. 09 with 2.6.21 Kernel .
The tweaks you speak of are they related to madwifi drivers I had diversity and stuff ON on the nodes Which I changed on the nodes but they dont seem to help.
Would be great if you could tell me more about the radio settings and firewall rules (which I suspect is crashing my gateway )
Regards,
On Apr 16, 2008, at 21:11, Philippe April isf_lists@philippeapril.com wrote:
Hi Vinay,
What kind of hardware are you running this on? I had a lot of problems when it switched route until I tweaked some radio settings and FW rules, it seems better now.
On 16-Apr-08, at 4:40 AM, Vinay Menon wrote:
Philippe...seems your problem and mine are similar hence continuing posting in this thread,if you feel its different please tell me ill repost as a new thread.
My network setup is as shown
Gateway 10.24.249.96 ------------------------------------- | 50ft | | | | Node 1 (10.1.125.158) ------------------------------------- | 25ft | | Node 2 (10.1.52.)236 -------------------------------------
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
Yes, the settings were all related to the madwifi drivers but it looks like I was wrong, I'm back to square one, my nodes are not reliable at all even after the tweaks. Sometimes I think I have it and it's stable for hours, and then for some reason it stops working.
Most of the time the ad-hoc network (for the mesh) is reliable (the nodes themselves are fine) but laptop clients can't associate to the nodes or the connection is flaky!
On my mac, it keeps disassociating and associating every 2 seconds... But this only happens sometimes!
I tried the RO.B.IN firmware on 4 nodes and the symptoms are the same, it's basically unusable.
Does anybody have a great success story to tell me with this hardware (FON/Accton with Atheros) and mesh networks? B.A.T.M.A.N seems to be the only thing stable in my setup after all :)
On 16-Apr-08, at 12:29 PM, Vinay Menon wrote:
Hi Philippe, My gateway is a old fonera and nodes are meraki. I am using kamikaze 7. 09 with 2.6.21 Kernel .
The tweaks you speak of are they related to madwifi drivers I had diversity and stuff ON on the nodes Which I changed on the nodes but they dont seem to help.
Would be great if you could tell me more about the radio settings and firewall rules (which I suspect is crashing my gateway )
Regards,
On Apr 16, 2008, at 21:11, Philippe April isf_lists@philippeapril.com wrote:
Hi Vinay,
What kind of hardware are you running this on? I had a lot of problems when it switched route until I tweaked some radio settings and FW rules, it seems better now.
On 16-Apr-08, at 4:40 AM, Vinay Menon wrote:
Philippe...seems your problem and mine are similar hence continuing posting in this thread,if you feel its different please tell me ill repost as a new thread.
My network setup is as shown
Gateway 10.24.249.96 ------------------------------------- | 50ft | | | | Node 1 (10.1.125.158) ------------------------------------- | 25ft | | Node 2 (10.1.52.)236 -------------------------------------
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
On Thu, Apr 17, 2008 at 02:40:49PM -0400, Philippe April wrote:
Yes, the settings were all related to the madwifi drivers but it looks like I was wrong, I'm back to square one, my nodes are not reliable at all even after the tweaks. Sometimes I think I have it and it's stable for hours, and then for some reason it stops working.
that sounds familiar, i had *a*lot* of problems/ghost hunting, when i used kamikaze 7.09 on meraki mini. [...]
Does anybody have a great success story to tell me with this hardware (FON/Accton with Atheros) and mesh networks?
i have at the moment 5 meraki mini running with an about 2-3 months old kamikaze (r10223) and 2.6.23.1 ... and i don't see much difference in reliability in comparison to the good old wrt54g :-).
cheers
--Jan
Hi,
I tried the RO.B.IN firmware on 4 nodes and the symptoms are the same, it's basically unusable.
when did you try this ? I helped them to fix some of these problems, so I know it should be quite stable now.
Does anybody have a great success story to tell me with this hardware (FON/Accton with Atheros) and mesh networks? B.A.T.M.A.N seems to be the only thing stable in my setup after all :)
There are a bunch of thing you should pay attention to. the last item which made Robin much more stable was:
iwconfig ath0 rate 5.5M
Try this.
Greetings, Marek
Hi,
I tried the RO.B.IN firmware on 4 nodes and the symptoms are the same, it's basically unusable.
Can you tell me your hardware and what version are you using? Surely there are some problems in your configurations or hardware: many peoples run flawlessy robin beta-1.1.
Greetings, Antonio
Marek Lindner disse:
Hi,
I tried the RO.B.IN firmware on 4 nodes and the symptoms are the same, it's basically unusable.
when did you try this ? I helped them to fix some of these problems, so I know it should be quite stable now.
Does anybody have a great success story to tell me with this hardware (FON/Accton with Atheros) and mesh networks? B.A.T.M.A.N seems to be the only thing stable in my setup after all :)
There are a bunch of thing you should pay attention to. the last item which made Robin much more stable was:
iwconfig ath0 rate 5.5M
Try this.
Greetings, 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
:)
Sorry if this sentence sounded so bad... I obviously meant unusable in this situation where I couldn't make it work properly, I know there's a LOT of people who use it without any problem! There must be something in the air...
2 La Fonera, 2 Accton (from open-mesh.com). I had issues with antenna diversity at first, reflashed them all to c484 which got upgraded to beta-1.1.
Is there an image to flash straight to beta-1.1 and make sure I'm not missing upgrades in between or something weird like that?
I won't discuss this anymore on this list here and move the thread to the ROBIN forums, as it's no longer related to BATMAN which seems to work great except some firewall issues I'm having related to packets tagged as "INVALID".
Thanks to everyone for the great explanations... It'd be great to have the Wireless Community Weekend's ROBIN test filmed and put on the net, as I won't be able to be part of it :)
On 18-Apr-08, at 3:24 AM, a.anselmi@oltrelinux.com wrote:
Hi,
I tried the RO.B.IN firmware on 4 nodes and the symptoms are the same, it's basically unusable.
Can you tell me your hardware and what version are you using? Surely there are some problems in your configurations or hardware: many peoples run flawlessy robin beta-1.1.
Greetings, Antonio
Marek Lindner disse:
Hi,
I tried the RO.B.IN firmware on 4 nodes and the symptoms are the same, it's basically unusable.
when did you try this ? I helped them to fix some of these problems, so I know it should be quite stable now.
Does anybody have a great success story to tell me with this hardware (FON/Accton with Atheros) and mesh networks? B.A.T.M.A.N seems to be the only thing stable in my setup after all :)
There are a bunch of thing you should pay attention to. the last item which made Robin much more stable was:
iwconfig ath0 rate 5.5M
Try this.
Greetings, 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 mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
" as it's no longer related to BATMAN which seems to work great except some firewall issues I'm having related to packets tagged as "INVALID"."
I too had seen this (as well as had informed about it to Marek over irc) but later couldn't dint spend time replicating it. For some reason batman was not working with INVALID state detection in FORWARD chain.
So Philippe is your problem solved ? i am in the process of upgrading the firmware to latest openwrt trunk. as after rearranging nodes and fixing diversity my hopping problem is some what solved but batman on gateway still crashes after around 6-7 hrs of uptime on Kamikaze 7.09 (kernel 2.6.21)
b.a.t.m.a.n@lists.open-mesh.org
-
a.anselmi＠oltrelinux.com -
elektra -
Jan Hetges -
Marek Lindner -
Philippe April -
Vinay Menon