Create a virtual network for communication of all LTSP client, server and dhcp server

[d78ui98]

When you test with a virtual client and a virtual DHCP server (and virtual LTSP server of course), and all three of them are on the same computer/laptop, I think that you may need to create a virtual network as well, and connect all three of them to this virtual network, so that they can communicate with each-other.

If you bridge all three of them to an ethernet (cable) network interface, this can work only if this interface is connected to a switch/hub (or to another computer) through a cable. If no cable is connected, then the status of the network interface will be NO-CARRIER (not connected), and the same status will be inherited to the virtual interfaces that are bridged over it (ltsp-client, dhcp-server, ltsp-server), and so all three of them will be disconnected from each-other.

However it is not very practical to connect the machine to a hub just to test the ltsp-client and ltsp-server, so it may be better to create and use a virtual network in this case. Maybe you can create a script test.sh start which creates the virtual interface and modifies settings.sh by setting which interface to use for bridging to LAN. Then you can start up the dhcp-server, ltsp-server, ltsp-client and perform the testing steps (make login on the client, etc.) When you are done, you call test.sh stop which shuts down the virtual machines, deletes the virtual interface, then modifies back settings.sh.

This shows that the interface (on the laptop) that will be used for bridging to LAN cannot be auto-detected, in general. In some special cases you may be able to auto-detect it, but not always. For example, in the mode non-standalone, you may look for the default route, find the interface, and that is the one that you should use for bridging to LAN. But this assumes that the laptop is already connected to the LAN and has received an IP from the DHCP server, and it is not connected to any wifi networks). So, it may not always work.

In standalone mode however, you can use this method to get the WAN interface and it will always work correctly

[d78ui98]

So in this task, we need to create a virtual network. So that all 3 can communicate. @akash0x53 suggested a very good solution. He suggested on using a host-only adapter. This ensures that a virtual network adapter is created when vagrant boxes are created. I have implemented it. Here is a video of it - https://www.youtube.com/watch?v=Da7mjzigwPM&t=65s also implemented automatic configuration of dhcp server in this setup and shown both the mode of operations. Will be pushing code soon. As soon as the current branch is merged.

[dashohoxha]

Whatever solution that works is Ok. Of course some solutions are better or more elegant than the others.

[dashohoxha]

Maybe you can also create and use a virtual interface: https://unix.stackexchange.com/questions/152331/how-can-i-create-a-virtual-ethernet-interface-on-a-machine-without-a-physical-ad

[d78ui98]

I have created test.sh that creates virtual interface and modifies settings.sh. Also when I do test.sh stop it destroys the virtual interface and removes line added in settings.sh.

When I tried to do a vagrant up. The virtual interface is not working image. I did google about it a little and found out dummy interface cannot be used for bridging the LAN. Tried finding the solution for hours and realized this cannot be done. So I solved the issue by using host-only adpater.

[dashohoxha]

I made a little test by creating a virtual interface like this: ip link add eth-test type dummy. Then the command ip addr shows this:

233: eth-test: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 0a:9c:f9:1f:ca:ef brd ff:ff:ff:ff:ff:ff

Notice the words state DOWN which means that it is disabled. If you try ip link set eth-test up, then ip addr will show something like this:

233: eth-test: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 0a:9c:f9:1f:ca:ef brd ff:ff:ff:ff:ff:ff
    inet6 fe80::89c:f9ff:fe1f:caef/64 scope link 
       valid_lft forever preferred_lft forever

Then I created a virtual box (with GUI) which uses eth-test in bridged mode. When it is down it does not work, when it is up it seems to work.

So, maybe you forgot to enable (set up) the virtual interface. Can you try it again? Because if this works the solution for testing will be better than using host network.

[d78ui98]

Yes, this solution works. Will close the last PR and create another for this.