On 20 August 2018 at 16:51, Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> wrote: > Hi Christian, > > On 18.08.2018 16:27, Christian Gagneraud wrote: >> On 18 August 2018 at 05:24, Oliver Hartkopp <socketcan@xxxxxxxxxxxx> wrote: >>> Maybe this is something that can be added to docker, that you can create >>> vcan's and can-gw rules at startup without urging the docker instance to >>> have root capabilities. >> >> Yes and no, my goal is a bit different, I want something generic: >> - create CAN virtual busses, as many as you want. The same way you >> create docker networks >> - create docker containers, as many as you want >> - connect them together with whatever topology you fancy. >> >> See below for more details. >> I think i've achieved my goals (so far so good). >> My main "issue" was the usage of the cangw as a replacement for the >> lack of a "CAN Linux Bridge". >> According to your explanation, that is the only way to go, for now. >> >>> The problem is: >>> >>> can's and vcan's are available in ONE namespace only >>> vxcan's endpoints are visible in exactly TWO namespaces >>> >>> Currently having multiple can-gw rules (in the root namespace) >>> interconnecting vxcan instances pointing into different namespaces seems to >>> be the only solution. >>> >>> If you only have ONE CAN application in your namespace you might also let >>> your application use the vxcan directly (without a can-gw crossrouting the >>> traffic to another 'namespace local' vcan). >>> >>> The vxcan has no local echo. But if you only have one application nobody >>> cares about the missing echo, right? ;-) >>> >>> Does that fit you use-case? >> >> It fits the simple use cases, but i want to offer a completely generic solution. >> The way we do our automated test is by using BDD (eg. >> https://behave.readthedocs.io/en/latest/) >> It is up to the test writer to "instantiate" as many virtual devices >> as needed, as many virtual CANbusses as needed and then interconnect >> them the way they need. >> We have 'gateway' devices, that sit b/w J1939 (boat engines) and >> NMEA200, and 'console' devices that are connected to N2K only. >> The goal is that every single physical devices is represented, during >> automated tests, by a self-contained docker container. >> I would like to containerise our simulators too (devices that generate >> CAN messages, eg, engine, auto pilot, gps, ...) > > I'm just curious. Are you using kernel or user space j1939 implementation? I would have to dig quite a bit to be 100% sure, but i am highly confident that we do everything in user-space. I bet it will take us some time to catch up. We still have code that deal with legacy hardware that don't even use the Linux CAN layer. Chris.
