Hello Oliver, Hello Wolfgang
>>> B) Is it possible to label CAN packets in the similar way as done by >>> "--set-mark" in iptables? >> >> ??? Need to look into the ideas there. Maybe i can go for that tommorow. > > done :-) > > AFAICS a control message for marking CAN frames can be added to the CAN stuff > also. > > E.g. A new SO_MARK control message for CAN could be handled in the same way as > described here: So the "marker" can be read in the similar way as timestamp? And how do I label the message (assign "marker" to some message)? > But just for curiosity ... > > Why do you think that you need to know whether a CAN frame was locally > originated? It's a broadcast medium and the received frames on userspace level > reflect the traffic on the bus. > > Isn't the (uniquely defined) CAN-ID enough to know whether it was originated > from the local machine? I thought, that mechanisms may be used for making the getting of timestamp of sent CAN messages secure against issues like message order and mixing up the messages. I have already mentioned the message order issue in previous mail. Here is an example of what I mean by mixing messages up: Imaging you want to request some CAN message by sending corresponding RTR message. In CANopen this is requesting PDO over RTR request. One PDO may have several consumer, so several CAN nodes may send CAN message with same ID and data length (by the way, this may happen also with LSS messages). So, now we are sending RTR request for some PDO and want to make timeout monitoring on it. But, if another node (just another PDO consumer) will send simultaneously exactly the same CAN message, we may get "alien" message before our own is looped back. This is why it is important to have per-message self reception flag. Or the possibility to "mark" the message on transmission and then look for this mark on reception to identify looped back messages exactly. Probably one of the both mechanisms is enough. Probably mark approach is better and more universal (because per-message self reception flag is a kind of special case of the marker; by marking with incrementing counter value you may also directly address message order problem too). Probably having both of them will give the developer more flexibility. Regards, Vladislav _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
