-
> Is there any way to check what canN/vcanN devices exist, so that we can
> enumerate them in pcap_findalldevs(), as we already do for DAG, USB, and
> Bluetooth devices on Linux?
I looked around, but didn't find anything appropriate. The devices are listed in proc with any other network interfaces - but cannot be identified as CAN devices somehow.
The statistics of the CAN interfaces are...
2010-01-03 13:32:03 UTC in The libpcap project
-
> If the latter is true, would the existing Linux PF_PACKET socket code in
> ibpcap be able to capture on CAN devices?
Yes, it is - and does as sll header without this patch.
2010-01-03 13:25:02 UTC in The libpcap project
-
Yep, you're right. sys/socket.h is the better choice, cause it satisfies can.h's dependencies. Furthermore it's also needed for the SocketCAN patch anyway.
I removed the obsolete include directive of can.h.
2009-12-30 22:57:52 UTC in The libpcap project
-
Using autoconf2.59 did the trick.
I attached two patches to this ticket with:
1. Patch for configure.in to check for linux/can.h in order to enable CAN sniffing support
2. Patch for configure script: This is regenerated with autotools2.59
Two separate patches, cause maybe you'd like to regenerate configure with your favorite autoconf version..
2009-12-30 12:07:44 UTC in The libpcap project
-
Thanks Guy!
You're right, that configure should check for can.h.
I updated configure.in, but autoconf (2.64) produced a malformed script ( same behaviour with the checked in configure.in). :
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
./configure: line 2461: syntax error near...
2009-12-30 11:21:16 UTC in The libpcap project
-
1: ok.
2: No, in fact moving the data 3 bytes up doesn't make the processing simpler. Furthermore the struct can_frame type can't be used anymore.
3. Yes - changed that with one of the updates of the patch.
5. With some thought about: no - this doesn't make the processing simple. See item 2. Changing the format will introduce another can frame format. There's really no need for that.
2009-12-07 21:08:00 UTC in The libpcap project
-
Libpcap gets extended to capture CAN frames via the SocketCAN interface.
This patch enabled tcpdump to print that captured frames for testing purposes and convenience. The printing routine is taken from the can-utlis of SocketCAN.
2009-10-11 21:19:57 UTC in The tcpdump project
-
Some times ago I took a view on SocketCAN [1]. Due I'm using CAN all day
long with various protocols, I'd like to get some tool support for
debugging and analyzation.
I used ethereal for all ip based stuff and would like to do something
similiar for CAN. With SocketCAN this should be possible anyway, so I
took a look at the code to get an impression about the effort for adding
CAN...
2009-10-03 06:01:28 UTC in The libpcap project
