Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix ICMP Destination Unreachable packet causing panic #46

Closed
wants to merge 2 commits into from

Conversation

podhrmic
Copy link
Contributor

@podhrmic podhrmic commented Oct 2, 2017

If an Icmpv4Repr::DstUnreachable was received it resulted into panic!. This PR fixes that.

@whitequark
Copy link
Contributor

I'm confused. What's the backtrace for the panic?

@podhrmic
Copy link
Contributor Author

podhrmic commented Oct 3, 2017

Here is the backtrace - it starts at: let _poll_at = iface.poll(&mut sockets, timestamp).expect("poll error");

The poll_at is at line 418, the thread is started at line 245.

thread '<unnamed>' panicked at 'poll error: Unrecognized', /checkout/src/libcore/result.rs:906:4
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}SocketReceiver received 436 data.

             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:397
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:577
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:538
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:522
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:498
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:71
   9: core::result::unwrap_failed
             at /checkout/src/libcore/macros.rs:31
  10: <core::result::Result<T, E>>::expect
             at /checkout/src/libcore/result.rs:799
  11: rustwall::thread_iface
             at src/main.rs:418
  12: rustwall::main::{{closure}}
             at src/main.rs:245

And the panic corresponds with a reception on ICMP Destination Unreachable packet.

@whitequark
Copy link
Contributor

It's normal for poll to return errors. It will do so to indicate various boundary conditions, e.g. transmit buffers being exhausted, malformed packets, or (as we have here) unknown packets. The TCP/IP RFCs indicate that such conditions should be logged for debugging, so I provide a facility for logging them. None of these errors are fatal so if you don't care about logging you should just ignore them.

@whitequark whitequark closed this Oct 3, 2017
@whitequark
Copy link
Contributor

Docs updated in b0fc1d9.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants