There may be other issues involved besides the one I will mention here, but
the first thing I noticed is that the Wireshark output shows "(relative
sequence number)" after the sequence numbers. Often it is convenient when
looking at TCP packet captures in Wireshark if you can see what the
sequence numbers are, not the raw values from the packet, which can start
at an arbitrary 32-bit value, but the relative value, which is the value
from the packet minus the 32-bit value that was decided during the initial
3-way handshake.
Wireshark should have an option in the GUI somewhere to show the absolute
sequence number from the packet, not the relative number. Those absolute
numbers from the packet are what you should be comparing to the values in
your P4 program.
Here is a page I found by a quick Google search from Wireshark's
documentation describing this feature, and how to disable it. I haven't
tried it myself: https://wiki.wireshark.org/TCP_Relative_Sequence_Numbers
Andy
On Fri, Jan 22, 2021 at 10:42 AM Sahil Gupta sg5414@rit.edu wrote:
Hi all,
I was trying to convert some incoming msg from the host, into an RST
packet for my experiment.
I use curl as a client application hitting the target server.
Instead of terminating the connection on the client machine, it hung up
everytime.
Upon debugging, I found that following the issues:
- ACK number in TCP pkt is not matching with the number set in the P4
program.
- Seq. number in TCP is not matching with the number set in P4 program.
- Initially, I set checksum=0 but later use update_checksum_with_payload
to see if that may fix the issue. Program is not getting compiled even if I
use the same method mentioned in the error message.
Why ACK and seq. numbers are not matching with their assignments and why
they turn out to be so large in wireshark capture?
Looking for insight on how I can debug and fix the issues.
Attaching the snapshots for references:
A1. ACK and Seq number set in P4 code:
[image: RST.png]
A2. ACK and Seq number captured from wireshark:
[image: RST_wireshark.png]
B1. update_checksum control block
[image: Checksum_p4.png]
B2. Error in compilation after adding update_checksum_with_payload method:
[image: checksum.jpeg]
Regards
Sahil Gupta
P4-dev mailing list -- p4-dev@lists.p4.org
To unsubscribe send an email to p4-dev-leave@lists.p4.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
There may be other issues involved besides the one I will mention here, but
the first thing I noticed is that the Wireshark output shows "(relative
sequence number)" after the sequence numbers. Often it is convenient when
looking at TCP packet captures in Wireshark if you can see what the
sequence numbers are, not the raw values from the packet, which can start
at an arbitrary 32-bit value, but the relative value, which is the value
from the packet minus the 32-bit value that was decided during the initial
3-way handshake.
Wireshark should have an option in the GUI somewhere to show the absolute
sequence number from the packet, not the relative number. Those absolute
numbers from the packet are what you should be comparing to the values in
your P4 program.
Here is a page I found by a quick Google search from Wireshark's
documentation describing this feature, and how to disable it. I haven't
tried it myself: https://wiki.wireshark.org/TCP_Relative_Sequence_Numbers
Andy
On Fri, Jan 22, 2021 at 10:42 AM Sahil Gupta <sg5414@rit.edu> wrote:
> Hi all,
> I was trying to convert some incoming msg from the host, into an RST
> packet for my experiment.
> I use curl as a client application hitting the target server.
> Instead of terminating the connection on the client machine, it hung up
> everytime.
>
> *Upon debugging, I found that following the issues*:
> 1. ACK number in TCP pkt is not matching with the number set in the P4
> program.
> 2. Seq. number in TCP is not matching with the number set in P4 program.
> 3. Initially, I set checksum=0 but later use update_checksum_with_payload
> to see if that may fix the issue. Program is not getting compiled even if I
> use the same method mentioned in the error message.
>
> Why ACK and seq. numbers are not matching with their assignments and why
> they turn out to be so large in wireshark capture?
>
>
> *Looking for insight on how I can debug and fix the issues.*
> Attaching the snapshots for references:
> A1. ACK and Seq number set in P4 code:
> [image: RST.png]
> A2. ACK and Seq number captured from wireshark:
> [image: RST_wireshark.png]
> B1. update_checksum control block
> [image: Checksum_p4.png]
> B2. Error in compilation after adding update_checksum_with_payload method:
> [image: checksum.jpeg]
>
> Regards
> Sahil Gupta
>
> _______________________________________________
> P4-dev mailing list -- p4-dev@lists.p4.org
> To unsubscribe send an email to p4-dev-leave@lists.p4.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
