Commit Graph

13 Commits

Author SHA1 Message Date
Zeling Feng d492b21319 Fix a potential indefinite blocking in packetimpact testbench
1. setsockopt(SO_RCVTIMEO, 0) == never timeout
2. float64(time.Microsecond/time.Second) == 0
3. packetimpact tests use a lot of 1s timeouts

This becomes a more significant problem because of a recent change that binds
the sniffer only on the specific testNet interface so now the traffic on the
ctrlNet cannot wake up the blocking call anymore.

PiperOrigin-RevId: 344123465
2020-11-24 13:42:07 -08:00
Zeling Feng d4951e05a0 [1/3] Support isolated containers for parallel packetimpact tests
Summary of the approach: the test runner will set up a few DUTs according to
a flag and pass all the test networks to the testbench. The testbench will only
reside in a single container. The testbench will put all the test networks into
a buffered channel which served as a semaphore and now the user can freely use
t.Parallel() in (sub)tests and the true parallelism will be determined by how
many DUTs are configured. Creating DUTs on demand is not supported yet, the
test author should determine the number of DUTs to be used statically.

Specifically in this change:
- Don't export any global variables about the test network in testbench.
- Sniffer only binds on the local interface because it will be possible to have
  multiple interfaces to multiple DUTs in a single testbench container.
- Migrate existing tests to stop using global variables.

PiperOrigin-RevId: 343965962
2020-11-23 18:13:07 -08:00
Zeling Feng 64aae6bbd6 Cleanup device name confusion in packetimpact testbench
There are two device names on the test net.
- The sniffer/injector device which is always a linux device. Only the
testbench library is interested in this device.
- The device which is on the DUT. It happens to be the same device as
the former if DUT is linux. An individual test might be interested in
this device if the test cares about the device name.

PiperOrigin-RevId: 332112968
2020-09-16 16:26:10 -07:00
Jay Zhuang cf7141fb43 Ask for *testing.T instead of storing it
Storing *testing.T on test helper structs is problematic when
subtests are used, because it is possible for nested tests to call
Fatal on parent test, which incorrect terminates the parent test.

For example

  func TestOuter(t *testing.T) {
    dut := NewDUT(t)

    t.Run("first test", func(t *testing.T) {
      dut.FallibleCall()
    })

    t.Run("second test", func(t *testing.T) {
      dut.FallibleCall()
    }
  }

In the example above, assuming `FallibleCall` calls `t.Fatal` on the
`t` it holds, if `dut.FallibleCall` fails in "first test", it will
call `Fatal` on the parent `t`, quitting `TestOuter`. This is not a
behavior we want.

PiperOrigin-RevId: 323350241
2020-07-27 06:39:06 -07:00
gVisor bot 92bafd7929 Automated rollback of changelist 311424257
PiperOrigin-RevId: 313300554
2020-05-26 17:40:57 -07:00
Bhasker Hariharan 8605c97136 Automated rollback of changelist 311285868
PiperOrigin-RevId: 311424257
2020-05-13 16:13:37 -07:00
Ian Gudger e4058c0355 Replace test_runner.sh bash script with Go.
PiperOrigin-RevId: 311285868
2020-05-13 01:22:42 -07:00
gVisor bot 633e1b89bb Internal change.
PiperOrigin-RevId: 311011004
2020-05-11 15:54:08 -07:00
Bhasker Hariharan e4d2d21f6b Add UDP send/recv packetimpact tests.
Fixes #2654

PiperOrigin-RevId: 310642216
2020-05-08 15:40:27 -07:00
Eyal Soha 1bcc2bf17f Refactor connections.go to make it easier to add new connection types.
Rather than have a struct for the state of each type of connection, such as
TCP/IPv4, UDP/IPv4, TCP/IPv6, etc, have a state for each layer, such as UDP,
TCP, IPv4, IPv6.  Those states can be composed into connections.

Tested:
  Existing unit tests still pass/fail as expected.
PiperOrigin-RevId: 306703180
2020-04-15 13:01:11 -07:00
gVisor bot c230d12b5c Add Sniffer.Drain() draining socket receive buffer
Add Sniffer.Drain() which drains the socket's receive buffer by temporarily
setting the socket to non-blocking, and receiving in a loop until EINTR,
EWOULDBLOCK or EAGAIN. This method should be used when long periods of time
elapses without receiving on the socket, because uninteresting packets may have
piled up in the receive buffer, filling it up and causing packets critical to
test operation to be dropped.

PiperOrigin-RevId: 306380480
2020-04-13 23:05:08 -07:00
gVisor bot 47db097773 Internal change.
PiperOrigin-RevId: 305341059
2020-04-07 14:29:29 -07:00
Eyal Soha 3192e55ffe Packetimpact in Go with c++ stub
PiperOrigin-RevId: 301382690
2020-03-17 08:53:27 -07:00