http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1279
------- Comment #2 from trav.ethereal@xxxxxxxxxxxxxxx 2006-12-31 13:22 GMT -------
(In reply to comment #1)
> However, I've since realised that there is another underlying problem in the
> code, in that it can look at earlier frames as being subsequent reports to
> later ones (this can also cause -ve deltas to be calculated). The code does
> try to verify that the original frame and response match, by matching the first
> timestamp and the LSR of the supposed reply... It may be that this is what
> you're seeing in the trace you have, check the generated field that points at
> the original frame used in the calculation?
The LSR did match the NTP timestamp correctly in the file I was looking at, I
do remember confirming that. And, I confirmed that the calculations were
calculated correctly.
> Maybe minimum preference should just be a +ve number which set a magnitude,
> i.e. 10 would apply reporting of values between -10 and 10?
I like that idea. It allows you to set a reasonable threshold and yet still see
these negative values that may indicate an issue, like buggy reporters.
> I've assigned this bug to myself, and I'll investigate early next year if
> no-one else gets to it first (I don't currently have access to a build
> environment or the capture file that displayed this problem)
Thanks. I'll try to talk to the person that sent me the file (when he's back
after the holidays) to see if there's any way we could get something that I
could attach for you to see. I'm sure that would be pretty useful.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
