panic when network adapter not use. about synner

[JuxhinDB]

Hi! Apologies for the late reply.

That would make sense. Could you please try running this with RUST_BACKTRACE=1 preprended (i.e. RUST_BACKTRACE=1 cargo run foo bar so that I can take a closer look at the stacktrace.

Additionally, if you already have a branch with a fix, go ahead and push it as a new Pull Request and I'll gladly help you tune it to make sure it's working correctly. We can also have a test simulate an empty list of IPs to make sure that it works as intended. :-)

[yolo2h]

Thanks for your reply, this is the stack trace:

List of Available Interfaces

Interface name: "lo"
Interface MAC: 00:00:00:00:00:00
Interface IP: 127.0.0.1

thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', /checkout/src/libcore/slice/mod.rs:2085:10
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:475
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:390
   6: rust_begin_unwind
             at libstd/panicking.rs:325
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:77
   8: core::panicking::panic_bounds_check
             at libcore/panicking.rs:59
   9: <usize as core::slice::SliceIndex<[T]>>::index
             at /checkout/src/libcore/slice/mod.rs:2085
  10: core::slice::<impl core::ops::index::Index<I> for [T]>::index
             at /checkout/src/libcore/slice/mod.rs:1953
  11: <alloc::vec::Vec<T> as core::ops::index::Index<I>>::index
             at /checkout/src/liballoc/vec.rs:1714
  12: synner::tcp::packet::send_tcp_packets
             at src/tcp.rs:85
  13: synner::main
             at src/main.rs:39
  14: std::rt::lang_start::{{closure}}
             at /checkout/src/libstd/rt.rs:74
  15: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  16: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:105
  17: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  18: std::rt::lang_start
             at /checkout/src/libstd/rt.rs:74
  19: main
  20: __libc_start_main
  21: _start

And ip addr:

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: enp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether e8:40:f2:e7:66:fe brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:12:7b:71:92:d2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.123/24 brd 192.168.1.255 scope global noprefixroute wlp2s0
       valid_lft forever preferred_lft forever
    inet6 fe80::212:7bff:fe71:92d2/64 scope link 
       valid_lft forever preferred_lft forever

I want to test the server's handling of network-unstable clients, but libpnet doesn't have example of TCP sender, so I found your blog. Unfortunately, I overestimated my understanding of rust and TCP, and my test program did not run successfully. Finally I used Scapy to complete it.

[JuxhinDB]

@NC4C -- Thank you, quite an easy fix if so. Would you like to push a PR anyway and I'll help you set it up?