On Tue, Apr 22, 2008 at 04:01:57PM +0200, Axel Neumann wrote:
Hi Jan,
On Montag 21 April 2008, Jan Hetges wrote:
On Mon, Apr 21, 2008 at 02:57:44PM +0200, Benjamin Henrion wrote:
On Mon, Apr 21, 2008 at 2:39 PM, Jan Hetges tran@ms20.net wrote:
what i recognized lately, on two nodes (the ones with more than one bmx interface), show alternativeNextHops, which are *NO* alternative. It seems there gets some 'information' lost between the two IFs. I suppose that's a known issue ;-),
It is NOT a known issue (at least not to me) and if its a bug it should be fixed.
so, let's fix it then ;-)
Can you describe a little more extensively your network configuration?
x.x.0.0/24---x.x.0.1/x.x.3.1---x.x.3.0/24---x.x.3.160/x.x.4.1---x.x.4.0/24
One general questions: do all your interfaces operate on the same frequency?
no
Then, I am unsure about the netmasks you are using. The above line I understand that you are using x.x.3.0/24 and x.x.4.0/24 netmasks.
sorry, the /24 only specifys the netrange for the ssid it belongs to
Generally, It is strongly recommended to always use the same netmask on ALL batman interfaces !
i know, you helped me fixing that :-) and if you look again into my previous mail, i also wrote: batman network x.x.0.0/20. so, ALL batman broadcasting to x.x.15.255,
But according to the debug output there is a direct link to x.x.4.165/24 (which I guess has broadcast address of x.x.4.255) and therefore the two interfaces should not see each other!!??
there are direct links always only in the according /24 netrange, because they are on different channels/ssids, so .3.160 and .4.1 cannot "see" each other. Note, NO .4.x node cannot see ANY .3.x node, even if they would be on the same channel/ssid!
Can you verify that (note that the "ifconfig dev ip/netmask" command is buggy and does not always produce corresponding netmask and broadcast addresses and that the interfaces MUST be configured appropriately before the daemon is started. !!!)
i recognized the buggy ifconfig and ALWAYS set netmask and broadcast addresses.
.0.1/.3.1 is one node with two radios, and .3.160/.4.1 the other one. and, .3.160/.4.1 lists .4.162 as alternativeNextHop to .3.128. where .3.1 and .3.137 can see .3.128, but .4.162 can not.
An alternativeNextHop to a specific node must not necessarily be a direct neighbor of that node. For example in the following scenario:
claro
A---B---D | | +---E---+
From As' point of view B and E may both be potential next hops towards D. But only E
can directly see D.
Is it possible to generate (almost simultaneously) -cbd8 logs from the involved nodes, especially 3.1, 3.160, 4.162, 3.128.
attached, note that .3.137 is down due to power issues, and the link between .3.140 and .3.160 is not usable, but you should see the issue.
So, there is a real alternativeNextHop to .3.128 ... .3.137, which is listed after .4.162 on .3.160/.4.1. I attach the output of bmxd -cbd8.
The attached debug log shows: 172.19.3.128 wlan0:bmx 172.19.3.1 80 ( 97 1:01:20:33 15813 0 100 1012 18 2 1 ) 172.19.4.162 67 172.19.3.140 2
right, but it SHOULD show .3.137, and NOT .4.162 at all. The ONLY link between .4.x and .3.x IS .4.1/.3.160 (that's the reason for having a repeater there :)
At least this line does not show 3.137 listed after .4.162 on .3.160/.4.1 Has it been truncated ??
i don't think so, i'll make some more logs when .3.137 is back up
Looking forward to solve this...
cheers
--Jan