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
>>
>>https://staging.validation.linaro.org/scheduler/device/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.
>
>https://staging.validation.linaro.org/static/docs/v2/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



--