(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.
