Starting capture from a disconnected CAN interface (can0) results in a Error 100, network down

[oloftangrot]

I made a bug repport [Bug 13501] on this issue at the Wireshark tracker but has been routed here since it seams that it is a libpcap issue.

tcpdump -i can0 -w /tmp/can0.pcap

raises the problem that becomes blocking in the Wireshark user interface. I repeat what I said in the Wireshark bug report:

"The network should be down since there is no second CAN controller on the bus so it would be natural for the interface to go bus if there is no acknowledge. But maybe this should be handled differently in the user interface. More dynamically so the capture will start as soon as traffic comes in. Or to open the interface in listen mode only."

I guess the user interface is the command shell in this case but the problem is of the same nature.

[guyharris]

"Error 100", on Linux, is ENETDOWN. I'm not sure why it's getting reported as "Error 100" rather than "Network is down" or something such as that.

It looks as if the Linux kernel code that implements bind() on PF_PACKET sockets - which is the operation that's used if you're trying to capture packets on a particular network interface - fails if the interface isn't marked as "up". This is documented in the PACKET(7) man page.

That makes it impossible, on Linux, to capture on a not-up interface. I'm not sure what it means to "open the interface in listen mode only", but it can't involve opening a PF_PACKET socket and binding the interface to it, as that doesn't work on Linux, unless there's some way to bypass the "is it up?" check in packet_do_bind().

[infrastation]

See also #402 and the-tcpdump-group/tcpdump#465 (plus there was another related discussion thread, which I cannot find).

[oloftangrot]

sudo ip link set can0 up type can bitrate 250000

will activate the CAN interface. This issue can be closed my observation was not related to any fault in libpcap.

[mcr]

Guy Harris <[email protected]> wrote: It looks as if the Linux kernel code that implements bind() on PF_PACKET sockets - which is the operation that's used if you're trying to capture packets on a particular network interface - fails if the interface isn't marked as "up". This is documented in the PACKET (7) man page. It is something that I think should be fixed inside the kernel... I've often needed to listen on an interface before it is marked up, because of some events (RAs, ARPs, also 802.3ad packets, etc.) that occur very early on... That makes it impossible, on Linux, to capture on a not-up interface. I'm not sure what it means to "open the interface in listen mode only", but it can't involve opening a PF_PACKET socket and binding the interface to it, as that doesn't work on Linux, unless there's some way to bypass the "is it up?" check in packet_do_bind().

…

-- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [

[guyharris]

I've often needed to listen on an interface before it is marked up

Ideally, it should be possible to connect (a BPF device, a PF_PACKET socket, etc.) to any interface that the kernel knows about, even if it's not "up" or "running", and arrange that packets be delivered to that mechanism as soon as the interface is capable of receiving packets (and presumably attempts to turn promiscuous mode on would be deferred until the hardware's up, and done as part of initializing the hardware if the hardware wasn't up at the time the request was made).