[CUWiN-Dev] ieee802 radiotap and clock synchronization

[David Young]

On Thu, Feb 22, 2007 at 09:09:19PM +0900, Jeongkeun Lee wrote:
> Thank you, Dave.
> The TSF timestamp is what I want. Using pcap library, I programmed my own
> sniffer application which peeks out TSFT, RSS from ieee80211_radiotap_header
> and also parses UDP payload data. 
> 
> But I have encountered two problems.
> 1. pcap does not recognize filter expressions when I set pcap's datalink
> type as ieee802_11_radio. Actually this also happens with tcpdump. When I
> try any filter expressions with '-y ieee802_11_radio' option, tcpdump
> captures no packets.
> For example, 'tcpdump -ne -y ieee802_11_radio -i ath0' itself works well,
> 'tcpdump port 9191' works well too. But using them together does not work
> properly as follows.

I was afraid that filters might not work with radiotap.  You will need
help from a more expert tcpdump developer than I to fix it.  Try the
tcpdump-workers mailing list, whose address is advertised at tcpdump.org.

> 2. My second problem is about tsft synchronization. From capture logs, I
> have realized that tsf timer of mesh nodes can exhibit asynchronous states
> time to time, even though they can hear each other's beacon transmissions.

By how many microseconds do the timers stray?

> (I have five nodes in operation.) Papers have reported that 802.11 ad hoc
> mode operation does not guarantee tsft synchronization because 1) stations
> send beacons on a contention basis

Hopefully that is not a serious problem, unless the time is very badly
synchronized, so that some stations always "win" the contention.

> 2) stations can only set their clock
> times forward and never backward. Slower clocks synchronize with faster
> clocks, but faster clocks do not synchronize themselves with slower clocks
> learned from neighbor's beacons.

That is my understanding, too.

>  Do we have any solution which includes driver modifications? 

Since synchronization is a real-time process under the hardware's control,
I don't think we can intervene through the driver.

> My current solution is to disable beacon TX of all stations. Then stations
> do not change their clocks but the clock time difference between two
> stations is almost linearly increasing or decreasing over time according to
> my observation. So we can measure the difference changing speed and use it
> to compensate the difference. 

That sounds neat.  Do you compensate "on line," or in a postprocessing
step?

Dave

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933