[cip-dev] B@D network setup

[cip-dev] B@D network setup

[Daniel Wagner]

Hi Robert,

Finally I found some time to test/setup the B at D VM. I struggle a bit
with the network setup. If I understand it correctly, the VM needs to be
bridged to the main network:

  # Forward port 8888 for the internal REST server
  config.vm.network :forwarded_port, guest: 8888, host: 8888
  # Forward port 8010 for the Storage Server
  config.vm.network :forwarded_port, guest: 8010, host: 8010
  # Forward port 5000 for the KernelCI Frontend Web Server
  config.vm.network :forwarded_port, guest: 5000, host: 5000
  # Forward port 80 for the http Lava Frontend Web Server
  config.vm.network :forwarded_port, guest: 8080, host: 8080
  # Forward port 443 for the https Lava Frontend Web Server
  config.vm.network :forwarded_port, guest: 443, host: 4443
  # Configure network accessibility for tftp server
  config.vm.network "public_network", use_dhcp_assigned_default_route: true


At least the documentation is pointing in this direction:

"""
Public Networks

Network identifier: public_network

Vagrant public networks are less private than private networks, and the
exact meaning actually varies from provider to provider, hence the
ambiguous definition. The idea is that while private networks should
never allow the general public access to your machine, public networks can.

Confused? We kind of are, too. It is likely that public networks will be
replaced by :bridged in a future release, since that is in general what
should be done with public networks, and providers that do not support
bridging generally do not have any other features that map to public
networks either.
"""

This is a problem in our corporate network. I am not allowed to attach
devices to our network without permission. That normally means I need a
certificate for Ethernet port authentication. This will not really work
with TFTP booting.

Furthermore, I wouldn't be surprised if your switches are filtering the
BOOTP/DHCP protocol out. Sysadmins usually are not too happy if a rouge
BOOTP/DHCP servers are active in the network.

So my question is, couldn't we add additional network interface, e.g.
USB Ethernet adapter, and attach the device under test to this
interface? I don't know if Vagrant is offering such an option. In the
past I've done this with Qemu.

Thanks,
Daniel

[cip-dev] B@D network setup

[Daniel Sangorrin]

Hi Daniel

> -----Original Message-----
> From: cip-dev-bounces at lists.cip-project.org [mailto:cip-dev-bounces at lists.cip-project.org] On Behalf Of Daniel Wagner
> Sent: Monday, November 06, 2017 6:50 PM
> To: Robert Marshall
> Cc: cip-dev at lists.cip-project.org
> Subject: [cip-dev] B at D network setup
> 
> Hi Robert,
> 
> Finally I found some time to test/setup the B at D VM. I struggle a bit
> with the network setup. If I understand it correctly, the VM needs to be
> bridged to the main network:
> 
>   # Forward port 8888 for the internal REST server
>   config.vm.network :forwarded_port, guest: 8888, host: 8888
>   # Forward port 8010 for the Storage Server
>   config.vm.network :forwarded_port, guest: 8010, host: 8010
>   # Forward port 5000 for the KernelCI Frontend Web Server
>   config.vm.network :forwarded_port, guest: 5000, host: 5000
>   # Forward port 80 for the http Lava Frontend Web Server
>   config.vm.network :forwarded_port, guest: 8080, host: 8080
>   # Forward port 443 for the https Lava Frontend Web Server
>   config.vm.network :forwarded_port, guest: 443, host: 4443
>   # Configure network accessibility for tftp server
>   config.vm.network "public_network", use_dhcp_assigned_default_route: true
> 
> 
> At least the documentation is pointing in this direction:
> 
> """
> Public Networks
> 
> Network identifier: public_network
> 
> Vagrant public networks are less private than private networks, and the
> exact meaning actually varies from provider to provider, hence the
> ambiguous definition. The idea is that while private networks should
> never allow the general public access to your machine, public networks can.
> 
> Confused? We kind of are, too. It is likely that public networks will be
> replaced by :bridged in a future release, since that is in general what
> should be done with public networks, and providers that do not support
> bridging generally do not have any other features that map to public
> networks either.
> """
> 
> This is a problem in our corporate network. I am not allowed to attach
> devices to our network without permission. That normally means I need a
> certificate for Ethernet port authentication. This will not really work
> with TFTP booting.
> 
> Furthermore, I wouldn't be surprised if your switches are filtering the
> BOOTP/DHCP protocol out. Sysadmins usually are not too happy if a rouge
> BOOTP/DHCP servers are active in the network.
> 
> So my question is, couldn't we add additional network interface, e.g.
> USB Ethernet adapter, and attach the device under test to this
> interface? I don't know if Vagrant is offering such an option. In the
> past I've done this with Qemu.

If your network is using the MAC address for authentication you could also 
put the MAC address of your USB ethernet adapter into the Virtualbox 
ethernet interface (adapter 2).

Thanks,
Daniel

[cip-dev] B@D network setup

[Daniel Wagner]

Hi Daniel,

On 11/07/2017 03:40 AM, Daniel Sangorrin wrote:
>> So my question is, couldn't we add additional network interface, e.g.
>> USB Ethernet adapter, and attach the device under test to this
>> interface? I don't know if Vagrant is offering such an option. In the
>> past I've done this with Qemu.
> 
> If your network is using the MAC address for authentication you could also 
> put the MAC address of your USB ethernet adapter into the Virtualbox 
> ethernet interface (adapter 2).

Unfortunately, we do have proper security in place :) The device needs
to do EAP and I don't think u-boot is able to this.

Having a dedicated network interface (maybe attached to a standalone
switch) has also the beauty that you have it complete under control what
is happening on the test network.

Thanks,
Daniel

[cip-dev] B@D network setup

[Robert Marshall]

Daniel,

Daniel Wagner <daniel.wagner@siemens.com> writes:

> Hi Daniel,
>
> On 11/07/2017 03:40 AM, Daniel Sangorrin wrote:
>>> So my question is, couldn't we add additional network interface, e.g.
>>> USB Ethernet adapter, and attach the device under test to this
>>> interface? I don't know if Vagrant is offering such an option. In the
>>> past I've done this with Qemu.
>> 
>> If your network is using the MAC address for authentication you could also 
>> put the MAC address of your USB ethernet adapter into the Virtualbox 
>> ethernet interface (adapter 2).
>
> Unfortunately, we do have proper security in place :) The device needs
> to do EAP and I don't think u-boot is able to this.
>
> Having a dedicated network interface (maybe attached to a standalone
> switch) has also the beauty that you have it complete under control what
> is happening on the test network.
>

We've opened a ticket for this
https://gitlab.com/cip-project/cip-testing/testing/issues/169 

so that we can investigate and you can keep track!

Robert

[cip-dev] B@D network setup

[Daniel Wagner]

> We've opened a ticket for this
> https://gitlab.com/cip-project/cip-testing/testing/issues/169 
> 
> so that we can investigate and you can keep track!

Excellent!

Thanks,
Daniel

[cip-dev] B@D network setup

[Agustin Benito Bethencourt]

Hi,

On 07/11/17 09:47, Daniel Wagner wrote:
> Hi Daniel,
>
> On 11/07/2017 03:40 AM, Daniel Sangorrin wrote:
>>> So my question is, couldn't we add additional network interface, e.g.
>>> USB Ethernet adapter, and attach the device under test to this
>>> interface? I don't know if Vagrant is offering such an option. In the
>>> past I've done this with Qemu.
>>
>> If your network is using the MAC address for authentication you could also
>> put the MAC address of your USB ethernet adapter into the Virtualbox
>> ethernet interface (adapter 2).
>
> Unfortunately, we do have proper security in place :) The device needs
> to do EAP and I don't think u-boot is able to this.
>
> Having a dedicated network interface (maybe attached to a standalone
> switch) has also the beauty that you have it complete under control what
> is happening on the test network.

When designing B at D, we assumed the most simple network configuration. 
Since the system is based on a VM, the network set up is something that 
can be adapted. Looking at this assumption now, we probably were 
optimistic. Yes it can be customised, but the complexity might be high 
to expect a user to do it on her own.

Let's see how we can help. Probably the first step is clearly 
documenting the network set up we currently have in B at D pointing at the 
scripts responsible for such configuration. We will take decision from 
that point.

Robert, what is your take on this approach?


>
> Thanks,
> Daniel
> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev
>


-- 
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito at codethink.co.uk

[cip-dev] B@D network setup

[Robert Marshall]

Agustin/Daniel

Agustin Benito Bethencourt <agustin.benito@codethink.co.uk> writes:

> Hi,
>
> On 07/11/17 09:47, Daniel Wagner wrote:
>> Hi Daniel,
>>
>> On 11/07/2017 03:40 AM, Daniel Sangorrin wrote:
>>>> So my question is, couldn't we add additional network interface, e.g.
>>>> USB Ethernet adapter, and attach the device under test to this
>>>> interface? I don't know if Vagrant is offering such an option. In the
>>>> past I've done this with Qemu.
>>>
>>> If your network is using the MAC address for authentication you could also
>>> put the MAC address of your USB ethernet adapter into the Virtualbox
>>> ethernet interface (adapter 2).
>>
>> Unfortunately, we do have proper security in place :) The device needs
>> to do EAP and I don't think u-boot is able to this.
>>
>> Having a dedicated network interface (maybe attached to a standalone
>> switch) has also the beauty that you have it complete under control what
>> is happening on the test network.
>
> When designing B at D, we assumed the most simple network
> configuration. Since the system is based on a VM, the network set up
> is something that can be adapted. Looking at this assumption now, we
> probably were optimistic. Yes it can be customised, but the complexity
> might be high to expect a user to do it on her own.
>
> Let's see how we can help. Probably the first step is clearly
> documenting the network set up we currently have in B at D pointing at
> the scripts responsible for such configuration. We will take decision
> from that point.
>
> Robert, what is your take on this approach?
>

I think that first step sounds reasonable - all the network config IIRC
happens in the Vagrantfile apart from the suggested workthrough on the
wiki.

Robert

[cip-dev] B@D network setup

[Daniel Wagner]

On 11/07/2017 01:09 PM, Robert Marshall wrote:
>> Robert, what is your take on this approach?
>>
> 
> I think that first step sounds reasonable - all the network config IIRC
> happens in the Vagrantfile apart from the suggested workthrough on the
> wiki.

When I tried to build my own VM from scratch I failed at the config part
inside the VM. Though this is a while ago. Maybe I should just retry to
build the VM, though I would prefer not to do it. I workaround could be
to asign the VM my USB Ethernet interface... Need to check the docs :)

Thanks,
Daniel

[cip-dev] B@D network setup

[Robert Marshall]

Daniel Wagner <daniel.wagner@siemens.com> writes:

> On 11/07/2017 01:09 PM, Robert Marshall wrote:
>>> Robert, what is your take on this approach?
>>>
>> 
>> I think that first step sounds reasonable - all the network config IIRC
>> happens in the Vagrantfile apart from the suggested workthrough on the
>> wiki.
>
> When I tried to build my own VM from scratch I failed at the config part
> inside the VM. Though this is a while ago. Maybe I should just retry to
> build the VM, though I would prefer not to do it. I workaround could be
> to asign the VM my USB Ethernet interface... Need to check the docs :)
>

>From my experience with network issues at ELCE I'd be inclined to just
comment out the

  config.vm.network "public_network", use_dhcp_assigned_default_route: true

line. And the VM should build without problems, it only needs that line
for running a test on the beaglebone black

Robert