From: daniel.wagner@siemens.com (Daniel Wagner)
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] B@D network setup
Date: Mon, 6 Nov 2017 10:49:39 +0100 [thread overview]
Message-ID: <0fa1ed54-2ab2-06fb-edb4-8db76d760d0c@siemens.com> (raw)
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
next reply other threads:[~2017-11-06 9:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-06 9:49 Daniel Wagner [this message]
2017-11-07 2:40 ` [cip-dev] B@D network setup Daniel Sangorrin
2017-11-07 8:47 ` Daniel Wagner
2017-11-07 10:54 ` Robert Marshall
2017-11-07 11:42 ` Daniel Wagner
2017-11-07 11:58 ` Agustin Benito Bethencourt
2017-11-07 12:09 ` Robert Marshall
2017-11-07 14:13 ` Daniel Wagner
2017-11-07 14:19 ` Robert Marshall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0fa1ed54-2ab2-06fb-edb4-8db76d760d0c@siemens.com \
--to=daniel.wagner@siemens.com \
--cc=cip-dev@lists.cip-project.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox