how to make blackbox testing with packetdril client

[Heeyeol Yu]

Hi

I want to setup a packetdrill client and a blackbox server for TCPIP conformance in server

Can you guide me how to modify packetdrill package?

Thx

[Neal Cardwell]

My sense is that the sketch I posted in this packetdrill group thread from 2015 still holds:

  https://groups.google.com/d/msg/packetdrill/1JYSB5bBpsg/qvM8M7M6EAAJ

Quoting from my message in that thread:

"""

When it comes to the question of sending traffic from packetdrill to remote
hosts not running packetdrill, my sense is that most of what would be required
is already in the code base: parsing scripts, injecting packets, sniffing
packets. But currently the "wire" mode requires a client running
packetdrill (which makes system calls on the machine under test)
and the server running packetdrill (which injects packets on the LAN),
and the two machines must be on the same LAN.

My sense is that an interested party could write a new packetdrill mode that
was closely based on wire_server.c but removed the logic to handshake
with the client, and simply injected packets and waited for inbound packets,
according to the script.

"""

best,

neal

[Heeyeol Yu]

Hi Neal

Let me summarize wire client/server for blackbox testing.

wire client sends all info including .pkt script.

Once wire client/server declare readiness to each pear, client or server start run on .pkt script on each side

Usually .pkt script has socket operations and there is a direction in TCP packet sending ( to client or server)

BTW, in .pkt script who initiates TCP connection and who sends TCP packet to where?

Do you have syntax for .pkt script?

In tcp-info-sndbuf-limited.pkt I saw this sample, but I don't know who initially make TCP connection?

Is wire client is TCP client? and what does '<' symbol mean?

   +0 connect(3, ..., ...) = -1 EINPROGRESS (Operation now in progress)

   +0 > S 0:0(0) <mss 1460,sackOK,TS val 100 ecr 0,nop,wscale 8>

 +.01 < S. 0:0(0) ack 1 win 10000 <mss 1000,sackOK,nop,nop,nop,wscale 8>

   +0 > . 1:1(0) ack 1

   +0 getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0

Thx

On Saturday, February 29, 2020 at 5:53:30 AM UTC-8, Neal Cardwell wrote:

[Neal Cardwell]

On Mon, Mar 2, 2020, 7:35 PM Heeyeol Yu <heeye...@gmail.com> wrote:

Hi Neal

Let me summarize wire client/server for blackbox testing.

wire client sends all info including .pkt script.

Once wire client/server declare readiness to each pear, client or server start run on .pkt script on each side

Usually .pkt script has socket operations and there is a direction in TCP packet sending ( to client or server)

Yes, that's basically right.

BTW, in .pkt script who initiates TCP connection and who sends TCP packet to where?

Do you have syntax for .pkt script?

The reference grammar for packetdrill scripts is linked off of the packetdrill readme landing page:

https://github.com/google/packetdrill/blob/master/syntax.md

Also linked off if that page is the USENIX Login article for a "how-to" guide with info about the functionality and syntax of packetdrill: 

 http://research.google.com/pubs/pub41848.html

In tcp-info-sndbuf-limited.pkt I saw this sample, but I don't know who initially make TCP connection?

Is wire client is TCP client?

The wire client runs on the device under test, and thus executes the system calls.

and what does '<' symbol mean?

As mentioned in the Login article, the > means packetdrill should sniff and check an outgoing packet. The < means packetdrill should inject an incoming packet. Where "incoming" and "outgoing" are from the reference point of the device under test.

Best,

Neal

--
You received this message because you are subscribed to the Google Groups "packetdrill" group.
To unsubscribe from this group and stop receiving emails from it, send an email to packetdrill...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/packetdrill/5031a960-a80c-44c6-81bb-73279f98154b%40googlegroups.com.

[Heeyeol Yu]

Hi

I need more clarity on this as inline

Thx

On Monday, March 2, 2020 at 5:24:28 PM UTC-8, Neal Cardwell wrote:

On Mon, Mar 2, 2020, 7:35 PM Heeyeol Yu <heey...@gmail.com> wrote:

Hi Neal

Let me summarize wire client/server for blackbox testing.

wire client sends all info including .pkt script.

Once wire client/server declare readiness to each pear, client or server start run on .pkt script on each side

Usually .pkt script has socket operations and there is a direction in TCP packet sending ( to client or server)

Yes, that's basically right.

BTW, in .pkt script who initiates TCP connection and who sends TCP packet to where?

Do you have syntax for .pkt script?

The reference grammar for packetdrill scripts is linked off of the packetdrill readme landing page:

https://github.com/google/packetdrill/blob/master/syntax.md

Also linked off if that page is the USENIX Login article for a "how-to" guide with info about the functionality and syntax of packetdrill: 

 http://research.google.com/pubs/pub41848.html

In tcp-info-sndbuf-limited.pkt I saw this sample, but I don't know who initially make TCP connection?

Is wire client is TCP client?

The wire client runs on the device under test, and thus executes the system calls.

wire client/server have the same context of .pkt script via mgmt IF of each.

They don't execute any command in .pkt script for actual testing.

In running .pkt script, only wire client calls system functions based on .pkt script, and both wire client/server send packets according to '<' or '>' symbol in .pkt

Since wire client under test is our product, we don't support 'tc' and 'ip ns'. I don't know how to resolve these commands which wire client uses

 

 

To unsubscribe from this group and stop receiving emails from it, send an email to packe...@googlegroups.com.

[Neal Cardwell]

On Tue, Mar 10, 2020 at 2:20 PM Heeyeol Yu <heeye...@gmail.com> wrote:

Hi

I need more clarity on this as inline

Thx

On Monday, March 2, 2020 at 5:24:28 PM UTC-8, Neal Cardwell wrote:

On Mon, Mar 2, 2020, 7:35 PM Heeyeol Yu <heey...@gmail.com> wrote:

Hi Neal

Let me summarize wire client/server for blackbox testing.

wire client sends all info including .pkt script.

Once wire client/server declare readiness to each pear, client or server start run on .pkt script on each side

Usually .pkt script has socket operations and there is a direction in TCP packet sending ( to client or server)

Yes, that's basically right.

BTW, in .pkt script who initiates TCP connection and who sends TCP packet to where?

Do you have syntax for .pkt script?

The reference grammar for packetdrill scripts is linked off of the packetdrill readme landing page:

https://github.com/google/packetdrill/blob/master/syntax.md

Also linked off if that page is the USENIX Login article for a "how-to" guide with info about the functionality and syntax of packetdrill: 

 http://research.google.com/pubs/pub41848.html

In tcp-info-sndbuf-limited.pkt I saw this sample, but I don't know who initially make TCP connection?

Is wire client is TCP client?

The wire client runs on the device under test, and thus executes the system calls.

wire client/server have the same context of .pkt script via mgmt IF of each.

They don't execute any command in .pkt script for actual testing.

In running .pkt script, only wire client calls system functions based on .pkt script, and both wire client/server send packets according to '<' or '>' symbol in .pkt

Yes indeed, that's basically how it works.

 

Since wire client under test is our product, we don't support 'tc' and 'ip ns'. I don't know how to resolve these commands which wire client uses

Are you referring to the use of tc in defaults.sh  and 'ip netns' in gtests/net/packetdrill/in_netns.sh ?

I believe you can comment out that code for your tests. Those are "nice to have" but not strictly needed for most cases.

neal

 

To unsubscribe from this group and stop receiving emails from it, send an email to packetdrill...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/packetdrill/47a37d2a-abf7-48f5-a925-f8d3df3428fe%40googlegroups.com.