On 30 April 2018 at 15:32, Tim Jaacks tim.jaacks@garz-fricke.com wrote:
On 30 April 2018 at 14:50, Tim Jaacks tim.jaacks@garz-fricke.com wrote:
On 30 April 2018 at 13:47, Tim Jaacks tim.jaacks@garz-fricke.com
wrote:
Hello everybody,
I have some testcases which need a remote network connection to the DUT.
I already managed to implement this using an LXC container as part of a multinode job.
Example: Check whether a telnet server is running on the DUT. Implementation:
- DUT and LXC are deployed and booted as two roles in a multinode job
- DUT sends its IP address to LXC via the multinode API (lava-send) and
then waits for a signal (lava-wait)
- LXC reads the IP address (lava-wait, lava_multi_node_cache.txt), tries
a telnet connection to DUT (lava-test-case) and then sends a signal to DUT (lava-send)
- DUT and LXC are shut down
Now I read that LXC containers can be used in a singlenode job context
as well, using the "namespace" attribute. I tried this and got the LXC container running along with my DUT, without the need of a multinode job. However, the multinode API cannot be used in this case, obviously. Is there another possibility to submit the DUT's IP address to the LXC?
Modify the DHCP configuration so that the DUT always gets the same IP
address and then set that as device_ip - this will be available inside the test shell using https://git.linaro.org/lava/ lava.git/tree/lava_dispatcher/lava_test_shell/lava-target-ip
staging-hi6220-hikey-r2-01/devicedict
Devices which have device_ip set then have a suitable device tag added
(static_ip) and that allows test writers to get the right support.
Thanks for the hint, that should be possible.
But the general question would be of interest for me as well: Exchanging
data between the LXC and the DUT via LAVA is not possible then, right?
That depends on what can be done in the LXC to access the device - it's
device and OS specific. AOSP test jobs use dedicated tools like fastboot and ADB to exchange files and commands to the DUT - however, the LXC remains in charge. Typically that requires udev support to add the relevant USB device to the LXC and may also require switchable USB hubs which is where things get expensive/complex.
I see that. But as far as I understand that requires an additional physical connection between the LXC host and the DUT (which is USB in the Android case), doesn't it? If I want to use ADB over TCP, the device is still required to have a static IP address which has to be known to the LXC, right?
There is no implicit connection between the LXC and the DUT. *Anything* that happens inside the LXC must be explicitly configured. For USB that means udev. For ethernet, that means static IP.
To get files off the DUT, use the publishing artifacts support - that
requires that the device has raised a network interface.
publishing-artifacts.html
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
Mit freundlichen Grüßen / Best regards Tim Jaacks DEVELOPMENT ENGINEER Garz & Fricke GmbH Tempowerkring 2 21079 Hamburg Direct: +49 40 791 899 - 55 Fax: +49 40 791899 - 39 tim.jaacks@garz-fricke.com www.garz-fricke.com SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz
Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users