panic on UDP frames where payload is less than 8B.

[ytti]

[1 ytti@lintukoto ~]% sudo hping -d 7 -0H 253 194.100.7.227

Causes this backtrace:

thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:363
stack backtrace:
   1:     0x7fbc471ba999 - sys::backtrace::write::h58560f48d5b719d9lvs
   2:     0x7fbc471c2c69 - panicking::on_panic::h7c79997343596b35Pxx
   3:     0x7fbc4718802e - rt::unwind::begin_unwind_inner::h56159f0d5aa797b8h0w
   4:     0x7fbc47188bd1 - rt::unwind::begin_unwind_fmt::h21db40757fae9a0dnZw
   5:     0x7fbc471c25c1 - rust_begin_unwind
   6:     0x7fbc47210aef - panicking::panic_fmt::h45b84e160969d0c8qgC
   7:     0x7fbc4720b268 - panicking::panic::h62fafe958ac8e785XeC
   8:     0x7fbc47914cc8 - option::Option<T>::unwrap::h2911093014629543058
                        at ../src/libcore/macros.rs:20
   9:     0x7fbc4791607d - transport::UdpTransportChannelIterator<'a>::next::h8479062227c3c6c9Ure
                        at /home/ytti/.cargo/git/checkouts/libpnet-fbe89e77b3a2f206/master/src/transport.rs:210
  10:     0x7fbc4790f35f - main::he6f75027b1d55d39taa
                        at src/annubar.rs:21
  11:     0x7fbc471c4b14 - rt::unwind::try::try_fn::h8862207228583653733
  12:     0x7fbc471c2568 - __rust_try
  13:     0x7fbc471c47cb - rt::lang_start::h74469c6250afc3c4Ttx
  14:     0x7fbc47912166 - main
  15:     0x7fbc46d58b44 - __libc_start_main
  16:     0x7fbc4790ed48 - <unknown>
  17:                0x0 - <unknown>

Changing -d to 8 and problem is gone.

Code is essentially:

fn main() {
  let protocol = Layer4(Ipv4(IpNextHeaderProtocols::Test1));
  let (_tx, mut rx) = match transport_channel(4096, protocol) {
    Ok((tx, rx)) => (tx, rx),
    Err(e) => panic!("An error occurred when creating the transport channel: {}", e)
  };

  let mut iter = udp_packet_iter(&mut rx);
  loop {
    println!("here0");
    match iter.next() {
      Ok((packet, _addr)) => {
        println!("here1");

here1 is never reached

[mrmonday]

Copy/pasting/tweaking what I said on IRC for longevity:

16:21 <+ladyfriday> the packet that's being received is smaller than the minimum size for a UDP packet, which is why it's panicking
16:21 <+ladyfriday> it shouldn't panic though - that should be fixed
16:28 <+ladyfriday> so UDP has a 4 byte header, source/destination/checksum
16:28 <+ladyfriday> if a packet is received with 3 bytes, for example, libpnet can't parse the header properly
16:29 <+ladyfriday> which is why this error is occuring - there were changes a few months back that introduced checks for minimum size