On 22.01.2011 19:42, Kurt Van Dijck wrote: > On Sat, Jan 22, 2011 at 07:07:22PM +0100, Oliver Hartkopp wrote: >> >> Independently from the fact that i do not have any general objections to add >> some infrastructure to af_can.c to redirect netlink messages, i wonder if >> your >> address concept is addressing the correct layer ?!? > ok, I'll try to address this question ... >> >> If you tweak your CAN protocol with addresses bound to a specific CAN >> interface this has a system-wide effect. So your Linux box can only act as a >> specific J1939 node as restricted by the given addresses above. > on a pure j1939 network, a box is intended to use only de addresses given > above. > I assume that a given box can use multiple addressess, each of them configured > with '$ ip addr add ...'
Yes. But the missing point is that you can ideally have multiple of these 'boxes' running on one single host to simulate a complete environment consisting of multiple nodes. E.g. having one 'real' J1939 ECU on the CAN bus an having four ECUs running on your host. >> >> The idea of SocketCAN is to have independent CAN applications on a single >> host >> that may communicate with each other - not knowing whether they are on the >> same host or on different hosts. >> >> IMHO the addresses for CAN protocols need to be specified on a per-socket >> basis - and not as a system-wide restriction bound to CAN interfaces. > I disagree here. The way I look at it, is that an CAN device will get > 1 (or more, but that a bit more complicated to expleain) SA. Whichever > application > that binds, will now use that SA. I can then build up my device by different > applications, cooperating to form a single entity on CAN (even within the > virtual > SocketCAN bus). As such, I can have 1 app just spitting out 1 second status > message, > 1 app sending DM1 msgs, 1 app sending regular IO updates, .... > > When adding addresses per socket, each app will need to know what > SA it is supposed to work with, which leads to malconfigurations ... This is really a configuration point. I'm pretty sure this can be solved in some way ... e.g. by introducing groups of sockets that use the space in sockaddr_can for the definition of group identifiers. Or just by ensuring a proper configuration of the applications (e.g. on the commandline). If you misconfigure your routing you also get cut from the network ... and no one provides configuration airbags to you :-) > > I rather compare the addressing of J1939 with IP, or at least I'd like > to deal with them in the same way. A node may use e.g. 0x80, but if I > want that to change to 0x81, I change it on 1 place and all traffic changes > with me. ... Do you know why people invented VLANs or multiple IPs bound to a single ethernet interface? So far you missed that step entirely. > I'm quite convinced my concept here is right. I'm pretty sure it is not, as it does not allow the use-case acting as multiple ECUs on one host as described above. Regards, Oliver _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
