tcpdump time stamp error

[SecretSquirrel]

HI Everyone,

My pcap time stamp on the file using tdpdump on PS are incorrect. Also the time and date for each packet is wrong too.

Does PS have a way of setting it's own time by reaching a time server or is this something I need to do?

 

Cheers,

James

[dark_pyrro]

To what extent is it incorrect? Years? Months? Days? Hours?

Check if the ntp daemon is running:

ps | grep [n]tpd

 

[SecretSquirrel]

The service is running

1019 root      1232 S<   /usr/sbin/ntpd -n -N -S /usr/sbin/ntpd-hotplug -p 0.openwrt.pool.ntp.org -p 1.openwrt.pool.ntp.

'date' gives me the correct date and time in UTC from the Packet Squirrel so it is talking to the ntp.

I just did another dump and the date is the same as yesterday's tcpdump of 10-10-2019, the date is always the same.

 

 

[dark_pyrro]

My guess, without actually trying to recreate the problem, is that tcpdump is started before the Squirrel has gotten the chance to update the date and time. If the specific date is used that you refer to (Oct 2019), it corresponds to about when the latest firmware was released for the Squirrel. So, it might be a fact that the Squirrel could start at that date when it boots (since it doesn't have any RTC), and uses that up until a successful online update of the date and time has been conducted using ntpd. You could try different ways of being assured that the date has been updated by including such checks in your payload (checking that the Squirrel is online, that the ntpd process is running, that the date is something else than 2019, etc, etc).

[SecretSquirrel]

The payload is the original one from PS, I got my PS a few days ago.

I did some experimenting and wrote a line of code which waited until date year was greater than 2019 before the tcpdump command in order to give more time for the ntp to get the time but it just hung there and never went to the tcpdump command.

I also later put the ntp command just before the tcpdump command in the hope it would run and get the time but to no avail.

at the moment I've run out of ideas apart from to do a tcpdump on of the packet squirrel to see if its ntp process actually gets the time. In arm mode it does get the correct time and I don't understand why it doesn't work new out of the box.

[dark_pyrro]

Can't recreate that problem. I get the correct datestamps in file names that tcpdump creates in /mnt/loot/tcpdump (well, not really the correct time since it's UTC, but that's on my side to configure if I want something else).

Even the captured network traffic (frames) in the pcap has the correct date and time.

I added a function to the tcpdump payload that waits until the year is 2022 and it works (seems to work with the original payload script as well though).

So, can't say what your issue is really if you can't get the correct date. It should work.

[SecretSquirrel]

Thanks for your help.

Could I ask you for the function of code you wrote just so that I have one that is known to work.

How long do you wait for the correct date to be set once the payload starts?

[dark_pyrro]

It's more or less no wait at all.

I have to connect and start up the Squirrel to get the exact function since I edited the original tcpdump payload and didn't store the "mod" outside the Squirrel. It's not that much that is included in the function though so I can try to remember it (roughly) from memory.

I call the function on the line just before the "run" function is being called at the bottom of the payload script. The new function (lets call it "wait_for_ntp") can be anywhere in the script before/above where it is called.

The new function starts with getting date and time from an ntp server. That should be started/executed with a line that ends with the & char so that it starts in the "background" and doesn't pause the script. On the line after that, add a while loop that isn't "satisfied" until the year is 2022. Something like:

while ! date +%Y | grep "2022"; do sleep 1; done

It will iterate until the date command throws back 2022 at the while loop which then exits.

I added some echo commands as well that puts events to a simple log file just for troubleshooting purposes. It's easier to see where things get stuck that way.