Re: [Madwifi-devel] ramping ping in ad-hoc mode (ticket 1154)
Status: Beta
Brought to you by:
otaku
From: bruno r. <br...@th...> - 2008-05-30 11:57:31
|
On Friday 30 May 2008 00:33:22 Derek Smithies wrote: > On my setup, ramping has been obliterated. > The two networks I have for testing are not exhibiting ramping, even after > many days of uptime, and numerous tests. hello derek! i am happy to hear that! > Use of a preset, fixed BSSID is unwise. With a fixed BSSID, how can the > beacons be adjusted to have the timestamp in sync? i don't agree here. preset BSSIDs work fine here in berlin in a very large city wide network. the timestamp of the beacons will be adjusted automatically by the hardware if the BSSID matches. it does not matter how the BSSID got set initially (by IBSS merge or fixed). > There is (my view) a logical inconsistancy in the driver for adhoc > operation. When we receive a data packet from a foreign node, with the > BSSID used in our network, (and the foreign node is not in the nbour > table), we add this node to our neighbour table. Even though we don't know > if the ESSID/capabilities are acceptable. Even though we don't know if the > foreign node has correctly synced to our network timestamp. Later, on > receiving a packet from the foreign node, we act on it as a part of our > network. This is too accepting. hmm, i'm not sure about this. on the one hand i think we would like to accept data packets also from nodes which we have not heard beacons from before, as for example we might have missed some of it's beacons or it might not have had a chance to send a beacon recently due to the random backoff algorithm. on the other hand i see the problem that we don't really know that node's capabilities, like supported rates if we only received data frames, so we will have problems answering anyways. i don't think it's our responsibility to check if the other nodes timestamp is in sync, however, how would you check that anyways? > Do not merge with a foreign node, just because I have received a data > packet from them. Merges only happen after a full check of the foreign > node's beacon. we don't merge to a node just because we put him in the neighbour table. please let's be clear with the terms here: "IBSS merge" means the adaption of the BSSID and timestamp of a beacon with the same ESSID and an older timestamp. > Limit the promiscuity of the merge process, so as to only merge when there > is full agreement on the timestamps to use. Thus, I only allow merges to > happen with nodes in my network. This condition is required. You see, > there are too many foreign nodes out there with broken timestamp handling > who will merge with my network - which leads to (in my view) ramping. that might indeed be the reason for ramping. we have a part of the dereks more stricter beacon checks in trunk now. i have not tested if it helps against ramping, though. also i want to forward port my ATIM patches for trunk soon. bruno > I am part of a trial program of the HAL discussed on the list a while ago. > Sadly, this HAL is not available for release. > I have a report from one other user of this HAL (who would have used it in > a driver without my modifications) and says it ramps. > > In my view, the prerelease HAL is not sufficient to stop ramping. To stop > ramping, you have to find a way to ensure that only good nodes (ones that > correctly manage the timestamp) merge to our network. > > I hope this helps, > > Derek. > > On Thu, 29 May 2008, Amy M. Lu wrote: > > Hello Bruno, Derek, and all, > > > > Any update for the problem of ramping pings? > > > > I just finish up some work, and have some time for helping out > > experiment. If you have some new patches needed to try out, I can do > > that. > > > > Amy > > > > -----Original Message----- > > From: bruno randolf [mailto:br...@th...] > > Sent: Monday, March 31, 2008 10:04 PM > > To: Benoit PAPILLAULT > > Cc: Amy Lu; 'Derek Smithies'; '????'; mad...@li... > > Subject: Re: [Madwifi-devel] ramping ping in ad-hoc mode (ticket 1154) > > > > On Tuesday 01 April 2008 04:47:58 Benoit PAPILLAULT wrote: > >> Exactly what I was going to do :-). I'll try to make it work on 5210 as > >> well... but that would probably wait next week end :-( > > > > yeah, its not hard to add, but pointless if we are not going to use it. > > as of now i don't see any benefit in using our "own" beacon config > > instead of > > the HALs because it doesn't help to solve the problem. > > > > bruno |