Re: [PATCH] SocketCAN support for libpcap - draft implementation

[Guy Harris <guy () alum mit edu>]

(I'm assuming that I can just reply to the third of your three  
messages.)

On Oct 4, 2009, at 5:20 AM, Felix Obenhuber wrote:

> I've done some hacks in tcpdump and wireshark that react on  
> incomming packets
> with DLT_CAN2B to visualize the captured frames but I'd like to get  
> pcap lined
> up clearly first, before going on with that tools. Furthermore the  
> facts of
> the libpcap implementation affect the way how to implement the  
> support in
> tcpdump or wireshark anyway...
>
> The patch works quite well for me, but I've got a couple of questions:
>
> 1. Should pcap_t.buffsize reflect the maximum amount of data captured
> within one call of can_read_linux? This so. Should be 8 bytes for the
> time and 16 bytes for the can frame ( worst case alignment ).

pcap_t.bufsize is not used in any of the "common" libpcap code, so how  
it's used is up to your particular capture device implementation.

You're using it as the size of the buffer into which you're reading  
packets, so it should be the size of the largest amount of data you  
can read from the socket.

> 2. The can frame struct is defined like this (from linux/can.h):
> /**
> * struct can_frame - basic CAN frame structure
> * @can_id:  the CAN ID of the frame and CAN_*_FLAG flags, see above.
> * @can_dlc: the data length field of the CAN frame
> * @data:    the CAN frame payload.
> */
> struct can_frame {
>         canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
>         __u8    can_dlc; /* data length code: 0 .. 8 */
>         __u8    data[8] __attribute__((aligned(8)));
> };
>
>
> Thus on my x86 hardware 3 bytes are padded before the data array to
> fulfill the alignment. Should I move the data bytes 3 bytes up before
> passing the data to the user?

Presumably aligned(8) means "align on an 8-byte boundary"; if canid_t  
is a 32-bit quantity, then there should be 3 bytes of padding on *all*  
platforms.

However, if you're using DLT_CAN20B, what matters here is what  
*existing* software that uses DLT_CAN20B expects; you would have to  
arrange to make the frame look like that, regardless of whether it  
matches "struct can_frame" or not, or you would have to request a  
different DLT_ value, e.g. DLT_CAN20B_LINUX or DLT_CAN20B_SOCKETCAN or  
something such as that.

Gianluca, what does the header look like in a DLT_CAN20B packet?

> 3. The identification of the device index is quite a hack. I'm  
> "parsing"
> the device name for an int before $. Any Ideas how to improve?

That's what pcap-usb-linux.c does, so I'm not sure any improvement is  
needed, other than having having the format be "can%d" rather than "%s 
%d" - the string preceding the number will be "can".

> 4. Am I right, that bytesex conversions should be done in the code  
> that
> uses libpcap?

Possibly, possibly not.  When capturing, you don't need to do any byte- 
order conversions; however, if you don't do so when capturing, you  
need to do it when reading from a savefile - see, for example, what's  
done for USB captures in sf_next_packet() in savefile.c.

> 5. The extended/standard frame flag is coded into the id in struct
> can_frame. Shall I extract and store in a separate byte?

See previous comment about the alignment - it depends on what any  
existing software that uses DLT_CAN20B expects.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.