On Sun, 2009-10-04 at 16:40 -0700, Guy Harris wrote: > (I'm assuming that I can just reply to the third of your three > messages.)
ok - I saw the copies in the archive, but dit not receive anything due a positive subscription result. Anyway: Sorry for spamming! Please keep me in CC. > On Oct 4, 2009, at 5:20 AM, Felix Obenhuber wrote: > > 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. ok. > 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? Yes, I agree with you. I searched arround for software that uses that DLT, but did not find anything... My intention was to avoid to request a new DLT identifier. > > 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". The vcan driver by default names the devices vcan0..x. Thats the reason for the %s. Thanks! Felix - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
