Questions about contents of packets under remote mode

[Atlantic Bob]

Hi Neal, 

Recently I'm testing the connection between two virtual machines (I will call them client and server respectively) in the same L2 ethernet. The information related is as below:

Client: 

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo state UP group default qlen 1000
    link/ether 08:00:27:75:1d:8e brd ff:ff:ff:ff:ff:ff
    inet 192.168.38.100/24 brd 192.168.38.255 scope global dynamic noprefixroute enp0s3
       valid_lft 3188sec preferred_lft 3188sec
    inet6 fe80::3462:1645:8ea3:464d/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

Server:

$ ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:60:3e:c8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.38.120/24 brd 192.168.38.255 scope global dynamic noprefixroute enp0s3
       valid_lft 3427sec preferred_lft 3427sec
    inet6 fe80::c1a0:2a2d:53b5:65bb/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

(TL; DR: ip of client is 192.168.38.100, and ip of server is 192.168.38.120)

Then I run instructions to test the connection:

Server: 

$ sudo packetdrill --wire_server --wire_server_port=8081 --wire_server_dev=enp0s3 --wire_client_dev=enp0s3

Client: 

$ sudo packetdrill --wire_client --wire_server_at=192.168.38.120 --local_ip=192.168.38.100 --remote_ip=192.168.38.120 --wire_server_port=8081 --wire_client_dev=enp0s3 --wire_server_dev=enp0s3 connect.pkt

And the contents of connect.pkt:

--tolerance_usecs=50000
0   socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0  setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0  bind(3, ..., ...) = 0
+0  listen(3, 1) = 0

//TCP three-way handshake
+0  < S 0:0(0) win 4000 <mss 1000>
+0  > S. 0:0(0) ack 1 <...>

+.1 < . 1:1(0) ack 1 win 4000
+0  accept(3, ..., ...) = 4

// write one hundred bytes
+0 write(4, ..., 100)=100
+0 > P. 1:101(100) ack 1
+.1 < . 1:1(0) ack 101 win 4000

// read two bytes
+.1 < P. 1:3(2) ack 101 win 4000
+0 > . 101:101(0) ack 3
+.2 read(4,...,1000)=2

//Packetdrill closes connection gracefully
+0 < F. 3:3(0) ack 101 win 4000
+0 > . 101:101(0) ack 4

//Kernel closes connection gracefully
+.1 close(4) = 0
+0 > F. 101:101(0) ack 4
+0 < . 4:4(0) ack 102 win 4000

Also, I run tcpdump on the server and wrote the information to a pcap file:
$ sudo tcpdump -i enp0s3 port 8081 -n -w connect1.pcap

It seemed to run successfully under remote mode because there is no error output both on client and server. However, when I opened the pcap file using Wireshark, there was a severe problem I could not understand: while I have read 100 bytes / write 2 bytes in the connect.pkt, there was no any packet that indicated this process. There were only packets that sent the command and packet contents using SMPP and pushed some strange payload. The detailed information is attached.

In addition, I also tested this process under local mode. The differences are explicit:
1. number of packets transmitted are less and fixed under local mode, which is only 12, but that is about 45 under remote mode and changes between each trial.

2. there are packets that sent 100 packets and 2 packets.

So what the problem is? 

Thanks,

Bob

[Neal Cardwell]

Hi,

I've pushed to https://github.com/google/packetdrill some fixes for remote ("wire server") mode. Hopefully this will improve the behavior. Can you please pull the latest code (up through and including c0b9f43a289e320e05b20140eea144efbb2e3c8f), rebuild, and re-run your tests, and let us know what the symptoms are (output with --debug) if things are not working?

Thanks!
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/5eb00235-b3a4-4097-a0fd-96a79401d5e2n%40googlegroups.com.