rmgl... looks like the first mail got lost... so _resend_ On Thursday 26 March 2009 16:15:24 Max Filippov wrote: > >> 3) Beaconing works, but not the way it should: like MPs don't hear each other. Timestamps never get in sync > >> and both MPs issue beacon during 0.1s beacon interval. > >> I've seen it before, with stlc45xx. It shows when LMAC is set up with LMAC_SETUP_IBSS | LMAC_SETUP_TRANSPARENT flags. > >> If there's no LMAC_SETUP_TRANSPARENT flag in LMAC setup then timestamps get in sync. > > > > FYI: The TSF will always reset when a new beacon is submitted to the firmware. > > The specs talks about that. > > I'd like to make it clear: there are timestamp field in the beacon and > timestamp associated with the received packet. These two do not > correlate. First gets reset at beacon submission (and why firmware > wouldn't pick up timestamp from the submitted beacon?). The second > only gets reset on firmware reset. And it seems to me that there's no > way to find out, what the current value of beacon timestamp is. TSF > reported in p54_rx_data is the second. because the hardware has at least 3 timers ;) - One for the _mactime_ (as in rx_status.mactime) (of course, we can always drop RX_FLAG_TSFT flag.) - the second one for beacon - (some firmware will fire a trap for every beacon they send P54_TRAP_BEACON_TX ) - and one is for the user. (which we don't need...) > And if so, how timestamp syncing is expected to work in the following case: > > <7>[ 353.579189] RX beacon SA=00:1d:6e:9b:ee:6d > BSSID=7e:2e:03:09:31:25 TSF=0x4aaa81 BCN=0x618f1f6 diff=-97404789 > @1513 > <7>[ 353.579250] wlan0: beacon TSF higher than local TSF - IBSS merge > with BSSID 7e:2e:03:09:31:25 > > After which stack submit new beacon which we send to LMAC, effectively > resetting timestamp in our beacon and not affecting TSF that we would > report on the next received frame. I know... p54 is does not really follow IBSS standard, but TSF sync is not a "MUST" for IBSS. http://wireless.kernel.org/en/developers/Documentation/mac80211/API > I see constant beacon resubmission cycle. How does it work on pci/usb p54? firmware does it... all we need is to submit a beacon template. The firmware knows how to extract everything it needs (e.g intervals/dtim etc.) out of the frame itself... > >> - when LMAC was set up with LMAC_SETUP_TRANSPARENT flag firmware seem to truncate last 2 bytes of the packet > >> that it reports. > > Heh, that's also a ISL3887 (USB 2nd gen) bug... But PCI devices are not affected. > > The reason "why" has probably to do with the firmware's frame alignment code. > > Unfortunately the firmware for (ISL3887 and SPI) is rounding "down" to 4 bytes instead of up... > > So the FCS will be clipped... But fortunately the firmware set a bit in the header that tells > > us whenever the frames was corrupted or not (P54_HDR_FLAG_DATA_IN_FCS_GOOD). > Thank you for the explanation, it made me feel much better (: > > > what happens if you change p54spi_rx the following way:? > Actually, I did this kind of thing. And it works this way. > But I considered it a major hack, as noone acknowledged that there's a > firmware problem: > > https://garage.maemo.org/pipermail/stlc45xx-devel/2009-January/000126.html > > But if there's real problem in firmware, I'd consider it mere > workaround and put it back. > yes please do... And don't worry the frame which we'll pass to mac80211 will always have the correct length, even when the extra padding wasn't used. Regards, Chr -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
