Comment # 27
on bug 9586
from Emburey
(In reply to comment #26)
> (In reply to comment #25)
> > Now the 'TSF Timestamp' is representing the entire 64-bit get time as a
> > whole. I can understand that the new dissection is fetching it as an 8-byte
> > field in microseconds. But we actually process that field: first for a
> > 32-bit representation of 'seconds' and next 32-bit representation of
> > 'microseconds'.
>
> You do?
>
> How, then, do you explain that, as Joerg said in comment 4:
>
> > The decoding of the legacy header seems to be incorrect wrt timesec/timeusec.
> > My legacy trace spans ~180s but the seconds value remains at 4. My best guess
> > might be a 3 byte seconds and a 3 bytes useconds value - but even that didn't
> > fit too well.
>
The seconds/microseconds would not represent the time when the frame sniffed
hits the sniffing tool (here wireshark), but it is the AP uptime when the frame
was recieved at the AP.
So for the trace that had been taken for ~180seconds, the timestamp value would
not be in the order of starting from 1sec to 180sec. Rather, as said, it
possess the uptime when each frame was recieved at AP.
> and, as I said in comment 5:
>
> > ...and, in the capture you made available, the "microseconds" value is >
> > 1,000,000.
>
> so that I said in comment 12:
>
> > At least in the captures Joerg and I have seen, treating that field as a 4-byte
> > seconds field and a 4-byte microseconds field does *NOT* work - the 4-byte
> > "microseconds" field is more than 1 million in one capture, and Joerg saw a
> > trace that covered more than 180 seconds but the 4-byte "seconds" value did
> > not change.
Regd the microsecond(usec) value, I could observe that in all cases it is more
than a million.
Here I'm referring to the timestamps of the attached wireshark captures:
- The microsecond in 'Wireshark trace with legacy header'
starts from 2069988000usec (34.49mins), and
ends at 2082596000usec (34.7mins)
- Likewise in 'Wireshark trace with new header (2)' the microsecond field
starts from 2767159000usec (46.11mins), and
end at 2772486000usec (46.2mins)
>From both these captures, we can observe that timestamp is reported properly
when referred from the hex dump values.
Now the new dissection in 'TSF Timestamp' is also referring to the proper time
and there is no mismatch.
So, it is okay to have the new dissection as such, for differentiating each
frames.
It looks fine now.
You are receiving this mail because:
- You are watching all bug changes.
