On Wed, 2011-12-28 at 16:58 +0200, Akos Vandra wrote:
> Yes, I have thought about it, but when I started writing the pcap
> driver, I didn't know about socketcan, and this user-space driver was
> already mostly ready (had to be ported a wee bit from c++), as I have
> used an own program to display
Hi,
On Sat, 2011-12-17 at 17:54 +0100, Akos Vandra wrote:
> I have just written support for one of my CAN->USB adapter gadgets, so
> that it would work with libpcap and thus with wireshark. I would love
> to see support for my device as an option in future releases.
Did you think about writing a
Hi,
I just noticed, that
http://www.tcpdump.org/release/libpcap-1.0.0.tar.gz
seems to be double packed - something like:
.tar.gz.gz
Cheers,
Felix
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
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 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 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
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
> 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
> 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 ).
>
>
t in the
Linux source and the tools distributed with socketcan, eg:
# modprobe vcan
# ip link add dev can0 type vcan
# cansend can0 123#affe
Thanks for comments, review and libpcap!
Cheers,
Felix
[1] http://developer.berlios.de/projects/socketcan
--
Felix Obenhuber
F696D48 | Pe
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
14 matches
Mail list logo
