Patrick McHardy <[EMAIL PROTECTED]> writes: > I was thinking about this, don't CAN frames include the identity > of the sender? That would be the easiest way to determine whether > the frame needs to be delivered.
No, CAN is quite a broken networking technology (at least in my view, coming from tcp/ip). There is no station addresses and therefore no sender or receiver addresses. Everything is broadcast. > Actually its not unused, it needs to be set on TX frames once the > packet leaves the protocol specific code. Oops, yes, this is something still missing in our code. Needs to be fixed. > I don't get why you can't directly check the socket option on the > TX path. We have several types of sockets in the PF_CAN family, two of which are GPL'ed and which are in the patch series. These are CAN_RAW and CAN_BCM. The protocol implementations use can_send() in af_can.c to send a CAN frame and indicate to can_send() in an int argument, whether this frame should be looped back. Only the raw protocol has a socket option (setsockopt(2)) in struct raw_sock for this, bcm always sets this to 1 to have the frame looped back. There is no option in struct bcm_sock for this. In can_send() and in the driver we don't know what type of socket skb->sk points to and can't check that option. Changing this would mean we have to add such an option in the same position in all CAN socket types and set it to fixed values in some of them (e.g. to 1 for bcm). While it's doable, I wouldn't like that very much. Is there anything that prevents can_send() from using skb->pkt_type to pass the loopback flag down to the driver? urs - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
