packet integrity verification

690 views
Skip to first unread message

Tony Klein

unread,
Jun 29, 2015, 10:30:57 AM6/29/15
to osti...@googlegroups.com
Ostinato is great for generating a stream of packets, shooting them through the device under test, and observing the rates and counts.

But my device under test (a wireless link) does header compression (proprietary) and thus I'm not so much interested in the rates as much as I want to verify packet integrity.  I need to know that each egress packet is bit-for-bit the same as the ingress packet. 

Any suggestings about the best technique for this?  I'm pondering a strategy involving a capture on the recieving side and then a diff against the capture on the sending side, but wondering if there might be a better way.

Regards,
TK

Srivats P

unread,
Jun 30, 2015, 8:42:12 AM6/30/15
to Tony Klein, ostinato
Would TCP/UDP checksums be sufficient to verify integrity? At the
receive end, capture the packets and verify if the checksum is valid

Srivats
> --
> Get Ostinato News and Updates on Twitter - Follow @ostinato
> (http://twitter.com/ostinato)
> ---------
> You received this message because you are subscribed to the Google Groups
> "ostinato" group.
> To post to this group, send email to osti...@googlegroups.com
> To unsubscribe from this group, send email to
> ostinato+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/ostinato?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "ostinato" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ostinato+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
http://ostinato.org/
@ostinato

Tony Klein

unread,
Jun 30, 2015, 4:09:11 PM6/30/15
to osti...@googlegroups.com, tony....@gmail.com
On Tuesday, June 30, 2015 at 7:42:12 AM UTC-5, Srivats P wrote:
Would TCP/UDP checksums be sufficient to verify integrity? At the
receive end, capture the packets and verify if the checksum is valid

Srivats

Hmm, maybe. I would need some kinda tool that validates checksums.  
I'd be missing any possible corruption of the IP header (TOS bits and so on).

If I had a way to spin a 32-bit CRC over the whole ethernet frame that would also work, but again this would require some hook to compute and then validate at the Rx side.

i was just thinking that if ostinato was both the sender and the receiver of a given packet, it would essentially have one packet in its left hand, and the other packet in its right hand, and it could just compare the two and tell me if they agree.  (Not to anthropomorphise a packet cannon or anything.)

Srivats P

unread,
Jul 1, 2015, 9:27:21 AM7/1/15
to Tony Klein, ostinato
Tony,

Rx packet may not match Tx packet always - e.g. a router DUT would
decrement TTL, adjust IP checksum and change src/dst mac addresses.

You could use a userscript protocol to calculate a CRC32 over the entire frame.

It would be nice if someone wrote a python script to do the same and
diff the Rx/Tx packet - all the infra is in place! ;-)

Srivats

Tony Klein

unread,
Jul 1, 2015, 10:19:50 AM7/1/15
to osti...@googlegroups.com, tony....@gmail.com
Ah yes of course, it would not generally be the case that a DUT would leave packets unchanged. 

Our device is layer 2 ethernet bridge which is not supposed to change anything.  Again my particular interest is that we are doing magic compression* to strip portions of the frame, xmit over air link, and then restore on other side, and we want to make sure its all correct.

So ... a user script, (in python? or QtScript?) to generate a packet, compute the CRC,  send it, receive it on a second interface, re-do the CRC and pass/fail the packet.

Alternatively, send a flow (possibly hundreds or thousands of packets), save the capture on the Tx side, then also save the capture on the Rx side, and post-process the entire capture files to locate any differences.   The significant issue with directly diffing wireshark ascii capture files is the timestamps ... a pre-process would have to strip out timestamps and just compare the remaining bytes.

Need to ponder which would be superior solutiuon: packet-at-a-time integrity check (send-recv-verify, loop) or batch mode (send batch, recv batch, verify batch).  

Give my a clue as to where and how I can hook a user script to generate / verify a CRC for any arbitrary packet. 

My initial casual observation of the drone proxy (python) reveals how to go about using a capture. 

You apparently are suggesting a creating a user script (QtScript) to implement a new protocol?   Please if you may tell me slightly more about what this would entail. 

Regards,
Tony

* P.S. We've noticed that "1" carries information, its a one, it means something. However "0" is nothing, it mean nothing, there is no information.
So we just strip all the zeros because they don't carry any information anyway, and just send the ones. Its a great compression scheme, the data gets a lot smaller.  

Srivats P

unread,
Jul 1, 2015, 11:43:53 AM7/1/15
to Tony Klein, ostinato
Tony,

> So ... a user script, (in python? or QtScript?) to generate a packet,
> compute the CRC, send it, receive it on a second interface, re-do the CRC
> and pass/fail the packet.

Yes, a python script which configures a stream, one of whose protocols
is a userscript. However, looking at the current support in
userscript, I see that you can't do a CRC32 - only a IP checksum.
Ideally, the userscript protocol should be the last protocol of the
stream and contain cksum of *all* the previous protocols . However, a
limitation of protocolFrameHeaderCksum() userscript function is that
it calculates the cksum of only the adjacent protocol, whereas
protocolFramePayloadCksum() userscript function does it for *all*
subsequent protocols, so you'll have to put the userscript protocol as
at least the second protocol in the stream (if possible) and combine
that result with result of protocolFramePayloadCksum() to calculate
the final cksum to be able to do a checksum over the entire packet.

> Alternatively, send a flow (possibly hundreds or thousands of packets), save
> the capture on the Tx side, then also save the capture on the Rx side, and
> post-process the entire capture files to locate any differences. The
> significant issue with directly diffing wireshark ascii capture files is the
> timestamps ... a pre-process would have to strip out timestamps and just
> compare the remaining bytes.

See if this pcapdiff tool helps -
http://sourceforge.net/projects/pcapdif/ (more tools on the wireshark
wiki - https://wiki.wireshark.org/Tools)
Alternatively, Ostinato has some code to do a pcap diff when it
imports a pcap file using standard tools - tshark/awk/diff - ostinato
calls these tools through C++ code
(http://code.google.com/p/ostinato/source/browse/common/pcapfileformat.cpp#256)
but that can easily be converted to a shell script

If you want to go with the original idea of just using the TCP/UDP
checksum - you can look at some sample code in
http://code.google.com/p/ostinato/source/browse/test/vftest.py which
tests that the checksum is valid.

Srivats
Reply all
Reply to author
Forward
0 new messages