Ask Your Question
0

negative values in time

asked 2024-06-28 08:42:51 +0000

updated 2024-06-28 11:53:18 +0000

Chuckc gravatar image

What is meant by the negative values on the Time Additional records

  <Root>: type OPT
    [Request In: 7]
    [Time: -0.058367000 seconds]
edit retag flag offensive close merge delete

Comments

Are you looking at packets that match dns.resp.type == 41 and dns.time < 0 ?

        <Root>: type OPT
            Name: <Root>
            Type: OPT (41) 
            UDP payload size: 4096
            Higher bits in extended RCODE: 0x00
            EDNS0 version: 0
            Z: 0x0000
            Data length: 0
    [Request In: 2086]
    [Time: 0.003947000 seconds]
Chuckc gravatar imageChuckc ( 2024-06-28 11:50:27 +0000 )edit

No, actually i am checking the dns query response time between our firewall and the DNS server. There i am seeing this -ve values.

No Time      Source  Destination Protocol Length DNS Time  Info
30  8.36078  x.x.x.x x.x.x.x     DNS      148    0.011264  Standard query response 0x52db
12 -0.661732 x.x.x.x x.x.x.x     DNS      157    0.01024   Standard query response 0x52db
9  -0.37504  x.x.x.x x.x.x.x     DNS      195    0.008704  Standard query response 0x52db
18  0.343694 x.x.x.x x.x.x.x     DNS      195    0.008192  Standard query response 0x52db
21  0.360905 x.x.x.x x.x.x.x     DNS      195    0.00768   Standard query response 0x52db
27  0.321518 x.x.x.x x.x.x.x     DNS      251    -0.036092 Standard query response 0x52db
7  -0.381696 ...
(more)
Satheesh gravatar imageSatheesh ( 2024-06-28 13:23:58 +0000 )edit

Sorting by packet number - could this be a capture issue?
Can you include the request packet?

No      Time    Source  Destination     Protocol        Length  DNS Time        Info
7   -0.381696 x.x.x.x x.x.x.x DNS 195 -0.381696   Standard query response 0x52db
9  -0.37504  x.x.x.x x.x.x.x DNS 195 0.008704        Standard query response 0x52db
12 -0.661732  x.x.x.x x.x.x.x DNS 157 0.01024 Standard query response 0x52db
18 0.343694  x.x.x.x x.x.x.x DNS 195 0.008192        Standard query response 0x52db
21 0.360905 x.x.x.x x.x.x.x DNS 195 0.00768 Standard query response 0x52db
27 0.321518 x.x.x.x x.x.x.x DNS 251 -0.036092   Standard query response 0x52db
30 8.36078 x.x.x.x x.x.x.x ...
(more)
Chuckc gravatar imageChuckc ( 2024-06-28 13:33:08 +0000 )edit
No  Time    Source  Destination Protocol    Length  DNS Time    Info
1   0   x.x.x.x x.x.x.x DNS 111     Standard query 0x55ec A  OPT
2   -0.392704   x.x.x.x x.x.x.x DNS 111     Standard query 0x55ec A  OPT
3   -0.652032   x.x.x.x x.x.x.x DNS 111     Standard query 0x70a6 A  OPT
4   0.00384 x.x.x.x x.x.x.x DNS 111     Standard query 0x70a6 A  OPT
5   -0.383744   x.x.x.x x.x.x.x DNS 111     Standard query 0x2898 A OPT
6   -0.645376   x.x.x.x x.x.x.x DNS 111     Standard query 0x2898 A  OPT
7   -0.381696   x.x.x.x x.x.x.x DNS 195 -0.381696   Standard query response 0x55ec No such name A  OPT
8   -0.637696   x.x.x.x x.x.x ...
(more)
Satheesh gravatar imageSatheesh ( 2024-06-28 13:39:43 +0000 )edit

What is View -> Time Display Format set to?
Where is the capture being made?

No  Time    Source     Destination Protocol    Length  DNS Time    Info
1   0          x.x.x.x x.x.x.x     DNS 111     Standard query 0x55ec A  OPT
2   -0.392704  x.x.x.x x.x.x.x     DNS 111     Standard query 0x55ec A  OPT
7   -0.381696  x.x.x.x x.x.x.x     DNS 195 -0.381696   Standard query response 0x55ec No such name A  
Chuckc gravatar imageChuckc ( 2024-06-28 14:02:42 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2024-06-28 16:04:54 +0000

Jim Young gravatar image

Switch the Time Display Format to Time of Day and visually confirm that the packets are in chronological order.

This can also be confirmed by running Wireshark's cli utility capinfos and checking the value of the Strict time order: field.

True indicates packets timestamps are in chronological order, False indicates that they are not.

When packets are not written to the capture in strict chronological order, Wireshark's various elapsed time analysis can result in physics defying duration reported between a query and its subsequent reply.

There are various reasons why capturing mechanisms produce captures where Strict time order of False. In some cases the actual order of the packets in the file is correct but the timestamps are just wrong. In other cases the timestamps of the packet are correct but order within the file is wrong. In the former case the editcap utility can be used to rewrite the timestamps of individual packets to ultimately satisfy the 'Strict time order' test. In the latter case the reordercap utility can be used to change to sort the packets by the original timestamps to also satisfy the 'Strict time order' test.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2024-06-28 08:42:51 +0000

Seen: 241 times

Last updated: Jun 28