On Dec 8, 2009, at 3:03 PM, Felix Obenhuber wrote:
> During capture from a can interface the relevant fields (here struct
> can_frame.can_id ) have to be passed to callback() in network byte
> order. This means to swap on le platforms - for short htonl.
>
> cf = (struct can_frame*)&handle->buffe
Thanks Guy.
> For non-cooked captures, libpcap just supplies the raw data you get
> from the socket. It doesn't do any byte-swapping when reading the
> file for most link-layer types; the only link-layer types for which it
> swaps to host byte order are DLT_USB_LINUX and DLT_USB_LINUX_MMAPP
On Dec 7, 2009, at 12:57 PM, Felix Obenhuber wrote:
On Mon, 2009-12-07 at 11:38 -0800, Guy Harris wrote:
I think that preserving the byte order makes sense in order to lean
against the behavior of the native netdev interface. This is also
the
way libpcap does with ETH_P_ALL devices. Is this
On Mon, 2009-12-07 at 11:38 -0800, Guy Harris wrote:
> > I think that preserving the byte order makes sense in order to lean
> > against the behavior of the native netdev interface. This is also the
> > way libpcap does with ETH_P_ALL devices. Is this correct?
>
> What does "preserving the byte or
On Oct 25, 2009, at 2:55 AM, Felix Obenhuber wrote:
On Sun, 2009-10-11 at 19:42 -0400, Alexander Dupuy wrote:
In the specific case of the SocketCAN, the fields in question
appear to
be transmitted on the wire (otherwise there would have been no need
for
an optional extension to the ID field
On Sun, 2009-10-11 at 19:42 -0400, Alexander Dupuy wrote:
> In the specific case of the SocketCAN, the fields in question appear to
> be transmitted on the wire (otherwise there would have been no need for
> an optional extension to the ID field - the size could just unilaterally
> have changed)
On Sun, 2009-10-11 at 10:35 -0700, Guy Harris wrote:
> >
> > DLT_CAN_SOCKETCAN
>
> OK, I've assigned 227 to DLT_CAN_SOCKETCAN, and checked into the main
> branch and pushed changes for that
Thank you Guy!
I've updated the patch in the SF tracker item to use the DLT and
improved the device ind
I wrote:
If you ever think that SocketCAN/libpcap will be used on big-endian
systems, you might want to "canonicalize" the layout in the big-endian
format
Guy Harris replied:
Linux USB leaves the pseudo-header in host byte order - and, in the
code that reads the savefile, libpcap byte-swaps t
On Oct 11, 2009, at 2:58 AM, Felix Obenhuber wrote:
On Fri, 2009-10-09 at 08:27 -0400, Alexander Dupuy wrote:
...
Summing up the discussion till now, I'd like to request a new DLT for
SocketCAN that is called
DLT_CAN_SOCKETCAN
OK, I've assigned 227 to DLT_CAN_SOCKETCAN, and check
On Fri, 2009-10-09 at 08:27 -0400, Alexander Dupuy wrote:
> Given these differences between the two frame formats I would suggest
> that you use a new DLT for SocketCAN, especially as there would be no
> way to know for sure whether the flags were present or just padding (a
> packet with all zero f
On Sun, 2009-10-04 at 16:40 -0700, Guy Harris wrote:
> > 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 tha
Felix Obenhuber wrote:
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.
> "Felix" == Felix Obenhuber writes:
Gianluca> The only software (that I know of) that uses that DLT is a
Gianluca> proprietary one from Condor Engineering/GE-Fanuc,
Gianluca> BusTools/AFDX.
>> Let's get a new DLT value then.
Felix> I'd suggest to use DLT_CAN_SOCKETCAN.
> Gianluca> The only software (that I know of) that uses that DLT is a
> Gianluca> proprietary one from Condor Engineering/GE-Fanuc,
> Gianluca> BusTools/AFDX.
>
> Let's get a new DLT value then.
I'd suggest to use DLT_CAN_SOCKETCAN. The B is misleading anyway cause
socketcan handle
> "Gianluca" == Gianluca Varenni writes:
>>> 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 softwa
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
arra
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 re
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
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,
(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 clear
Hi,
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
similar for CAN. With SocketCAN this should be possible
Hi,
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 possibl
Hi,
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 possibl
23 matches
Mail list logo
