Hi Axel thanks for being stubborn :-) On Wed, Apr 23, 2008 at 09:54:37AM +0200, Axel Neumann wrote:
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!
ok, .4.165 can see .3.160
Are you also specifying the bssid? Because in order to define different cells in an ad-hoc network the ssid is almost useless in most adhoc implementations. THe BSSID is much more important! (E.g. use kamikaze-etc/config/wireless style: option bssid 44:ca:ff:ee:ba:be or the command-line-style: iwconfig wlan0 ap 44:ca:ff:ee:ba:be )
thanks, did'nt know that ^^
Anyway, you mean a debug output on 3.16 like the following can not be correct? Neighbor outgoingIF bestNextHop brc (rcvd knownSince lseq lvld rid sid ) [ viaIF RTQ RQ TQ].. 172.19.4.165 wlan0:bmx 172.19.4.165 55 ( 84 0:00:28:03 9777 1 1 4 ) [ wlan0:bmx 46 76 60]
did'nt see that ^^^^^
Sorry for being stubborn: what makes you so sure that they cannot see each other or that the driver does not mix things up?
At least from the madwifi driver (in ad-hoc mode) I know that it tends to ignore its assigned *bssid* and channel and switches back and forth between the assigned one and others.
Sometimes the driver hangs on a wrong bssid and channel, forwards the wrong IP packets, and cannot receive any packets from its originally assigned bssid/channel.
One way to verify this would be to run a tcpdump on interface 3.160/wlan0 and see if it ever tracks a batman packet with a src address of e.g. 172.19.4.165
ok, what happend: .4.165 (i386/prism2.5/hostap(-pci)) switched for some unknown reason to .3.x/channel/essid (which explains the poor link from .4.165 to ".4.1"(actually .3.160), and i thought it was a fast growing Guahumo tree :). So i fixed the bssids on both, .4.1 and .4.165. And it seems to not switch anymore... thanks for being so stubborn :-) But that doesn't change the fact, that .4.1 still shows .4.162 as alternativeNextHop to .3.x, where, in fact, all alternative paths inside .4.x to .3.x lead back to .4.1 !
i'll make some more logs when .3.137 is back up
still down, anyways, i attach -cbd8 from .4.1, .4.160, .4.162 and .4.165
cheers
--Jan