[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 62 on bug 12687 from Guy Harris

(In reply to Oliver Hartkopp from comment #60)
> (In reply to Guy Harris from comment #58)
> > (In reply to Guy Harris from comment #57)
> > > (In reply to Oliver Hartkopp from comment #56)
> > > > > > > > 2. Up to now only the Packet type 1 (Broadcast) was displayed inside
> > > > > > > > Wireshark. With the use of PF_PACKET sockets we now see the type 1 and type
> > > > > > > > 4 (from me) packet types - so we see sent frames two times, which is not
> > > > > > > > usual.
> > > 
> > > So are you saying that, if a CANbus device sends a broadcast packet, the
> > > sending hardware receives the packet it's sending and provides it as an
> > > input packet, so that software reading from a PF_PACKET socket will see two
> > > copies - a copy looped back in the networking stack, and a copy received by
> > > the hardware?  That's not the case with regular LAN hardware, which doesn't
> > > see its own transmissions, so that's not an issue for Ethernet, 802.11, etc..
> 
> Right!
> 
> > No, it looks as if the CAN networking stack loops back transmitted packets.
> 
> Not always.
> 
> The idea is to present a PACKET_BROADCAST packet to all consumers on the
> local host when you receive a CAN frame from the outside OR a sent CAN frame
> really hit the CAN bus. When sending a CAN frame the transmission can be
> delayed by arbitration (due to CSMA/CA) or a CAN frame might never be sent
> out when there's no CAN node which acknowledges the CAN frame.
> 
> For that reason CAN network devices have an interface flag IFF_ECHO which
> must not be mixed with IFF_LOOPBACK. When a CAN netdevice has IFF_ECHO set,
> the 'echo' of sent CAN frames is done on *driver level* when the CAN frame
> is sent out (TX OK interrupt). A minority of CAN drivers (e.g. slcan.c) do
> not provide the functionality to 'echo' CAN frames as they have some kind of
> data stream which does not allow to detect the correct transmission on the
> CAN bus.
> Only for these CAN interfaces the CAN network layer stuff in
> linux/net/can/af_can.c provides a 'echo' CAN frame for the local consumers
> on the host.
> 
> http://lxr.linux.no/#linux+v4.7.2/net/can/af_can.c#L271
> 
> > So does dev_queue_xmit_nit(), so we get *two* loopback packets.
> > 
> > If the CAN layer is *guaranteed* to loop back all transmitted packets, that
> > means that all PACKET_OUTGOING CAN packets can be discarded, unless there's
> > a way to detect which PACKET_BROADCAST CAN packets are looped back and which
> > are received, in which case we should discard the looped-back
> > PACKET_BROADCAST packets so that the packet type reflects whether we sent
> > the packet or not.
> 
> Now it gets sticky.
> 
> Whether a PACKET_BROADCAST CAN packet was sent from the local host or not is
> distinguished by the reference to the originating socket. When there's no
> originating socket (sk == NULL) the CAN frame comes from the outside:
> 
> http://lxr.linux.no/#linux+v4.7.2/net/can/raw.c#L126
> http://lxr.linux.no/#linux+v4.7.2/net/can/raw.c#L172
> 
> But this detail is not visible on PF_PACKET sockets!
> 
> I did not take this detail into account so far.
> IMO displaying PACKET_BROADCAST CAN frames would fit the user needs -
> especially the outgoing CAN frames would have the correct TX timestamp then!!
> That's why I suggest to disable the display of PACKET_OUTGOING by default.
> 
> If we want to provide the correctly timestamped PACKET_BROADCAST packets
> *together* with the information about the CAN frames origin we would need to
> get back to PF_CAN RAW sockets - with some more functionality:
> 
> http://lxr.linux.no/#linux+v4.7.2/Documentation/networking/can.txt#L631

OK, so:

1) How do you make that work on an unbound PF_PACKET socket (the "any" device)?

Or can it simply not be made to work *at all* on a PF_PACKET socket, in which
case either 1a) users will have to live with duplicate CAN packets if they
capture with the "any" device on a system with CAN interfaces or 1b) we just
discard *all* CAN packets on the "any" device, so that you don't see CAN
interfaces with the "any" device?

2) Is the "CAN or CAN FD frame" information available if we get the packets
from a PF_CAN socket, so we don't have to guess whether it's a CAN or CAN FD
frame?

3) Would this be done by putting the PF_CAN code into pcap-linux.c and, if
we're capturing on a particular device (rather than the "any" device), and that
device has ARPHRD_CAN as its ARP hardware type, we close the PF_PACKET socket,
open a PF_CAN socket, and use *that* to capture, rather than trying to guess
whether it's a CAN device based on the device's name (which didn't work
completely in the old code - it expected devices to have names beginning with
"can" or "can" and thus didn't find "slcan" devices)?

---

      You are receiving this mail because:

• You are watching all bug changes.