On Sat, Dec 30, 2000 at 06:33:31PM -0600, Henry, Brad ERM wrote:
> sensor_sktn# tcpdump -r Saskatoon.2000.12.21-13.45.dat
> 13:45:27.042462 123.456.789.012.3456 > 789.012.345.678.9012: . ack 571384368
> win 8739 (DF)
> 13:45:27.058060 456.789.012.345.6789 > 012.345.678.901.2345: P
> 820505438:820505707(269) ack 4273926 win 17520 (DF)
>
> idsroot# tcpdump -r Saskatoon.2000.12.21-13.45.dat
> 19:45:27.042462 123.456.789.012.3456 > 789.012.345.678.9012: . ack 571384368
> win 8739 (DF)
> 19:45:27.058060 456.789.012.345.6789 > 012.345.678.901.2345: P
> 820505438:820505707(269) ack 4273926 win 17520 (DF)
>
> If it would help, I can show a sample of the code used to gather these
> results. Any ideas?
My first idea:
type "date" at both the "sensor_sktn#" and "idsroot#" prompts.
If "sensor_sktn" reports the current time in Mountain Standard Time and
"idsroot" reports a time that's 6 hours later than Mountain Standard
Time (Saskatchewan is currently 6 hours before UTC...), the problem may
just be that "idsroot" doesn't have its time zone set to
"America/Regina", so that it reads the time stamps from the capture file
- which are UNIX timestamps, meaning they're in UTC (modulo leap seconds
and so on) - and reports them in the machine's native time zone, i.e.
UTC, whilst "sensor_sktn" has its time zone set to "America/Regina" and
reads the UTC timestamps and reports them in MST.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
