Re: [PATCH] SocketCAN support for libpcap -

[Felix Obenhuber <felix () obenhuber de>]

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.