I'd like to test out UDP broadcast on a very simple network: an old wifi router (WRT54GS) that's not connected to the internet at all, an android tablet, and my macbook:
[Tablet] <\/\/\/\/\/> [Wifi Router] <\/\/\/\/\/> [Macbook]
where the wavy lines indicate wireless connections.
The Macbook has IP address 192.168.1.101, the tablet has IP address 192.168.1.102. The router is 192.168.1.1.
To avoid too much low-level detail, I wanted to use netcat to do my testing. I decided to use port 11011 because it was easy to type.
As a first step, I thought I'd try just making this work from the macbook back to itself. In two terminal windows, I ran these programs
Window 1: % nc -ul 11011
which I started up first, and then:
Window 2: % echo 'foo' | nc -v -u 255.255.255.255 11011
Nothing showed up in Window 1. The result in Window 2 was this:
found 0 associations
found 1 connections:
1: flags=82<CONNECTED,PREFERRED>
outif (null)
src 192.168.1.2 port 61985
dst 255.255.255.255 port 11011
rank info not available
I'm fairly certain I'm missing something obvious here. Can someone familiar with nc spot my obvious error?
This is a multi-part answer, gleaned from other SO and SuperUser answers and a bit of guesswork.
Mac-to-mac communication via UDP broadcast over wifi
The first thing is that the mac version of netcat (nc) as of Oct 2018 doesn't support broadcast, so you have to switch to "socat", which is far more general and powerful in what it can send. As for the listening side, what worked for me, eventually, was
Terminal 1: % nc -l -u 11011
What about the sending side? Well, it turns out I needed more information. For instance, trying this with the localhost doesn't work at all, because that particular "interface" (gosh, I hate the overloading of words in CS; as a mathematician, I'd hope that CS people might have learned from our experience what a bad idea this is...) doesn't support broadcast. And how did I learn that? Via ifconfig, a tool that shows how your network is configured. In my case, the output was this:
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
nd6 options=201<PERFORMNUD,DAD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 98:01:a7:8a:6b:35
inet 192.168.1.101 netmask 0xffffff00 broadcast 192.168.1.255
media: autoselect
status: active
en1: flags=963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX> mtu 1500
options=60<TSO4,TSO6>
ether 4a:00:05:f3:ac:30
media: autoselect <full-duplex>
status: inactive
en2: flags=963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX> mtu 1500
options=60<TSO4,TSO6>
ether 4a:00:05:f3:ac:31
media: autoselect <full-duplex>
status: inactive
bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=63<RXCSUM,TXCSUM,TSO4,TSO6>
ether 4a:00:05:f3:ac:30
Configuration:
id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
ipfilter disabled flags 0x2
member: en1 flags=3<LEARNING,DISCOVER>
ifmaxaddr 0 port 5 priority 0 path cost 0
member: en2 flags=3<LEARNING,DISCOVER>
ifmaxaddr 0 port 6 priority 0 path cost 0
media: <unknown type>
status: inactive
p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304
ether 0a:01:a7:8a:6b:35
media: autoselect
status: inactive
awdl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1484
ether 7e:00:76:6d:5c:09
inet6 fe80::7c00:76ff:fe6d:5c09%awdl0 prefixlen 64 scopeid 0x9
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000
inet6 fe80::773a:6d9e:1d47:7502%utun0 prefixlen 64 scopeid 0xa
nd6 options=201<PERFORMNUD,DAD>
most of which means nothing to me. But look at "en0", the ethernet connection to the wireless network (192.168). The data there really tells you something. The flags tell you that it supports broadcast and multicast. Two lines late, the word broadcast appears again, followed by 192.168.1.255, which suggested to me that this might be the right address to which to send broadcast packets.
With that in mind, I tried this:
Terminal 2: % echo -n "TEST" | socat - udp-datagram:192.168.1.255:11011,broadcast
with the result that in Terminal 1, the word TEST appeared!
When I retyped the same command in Terminal 2, nothing more appeared in Terminal 1; it seems that the "listen" is listening for a single message, for reasons I do not understand. But hey, at least it's getting me somewhere!
Mac to tablet communication
First, on the tablet, I tried to mimic the listening side of the mac version above. The termux version of nc didn't support the -u flag, so I had to do something else. I decided to use socat. As a first step, I got it working mac-to-mac (via the wifi router of course). It turns out that to listen for UDP packets, you have to use udp-listen rather than udp-datagram, but otherwise it was pretty simple. In the end, it looked like this:
Terminal 1: % socat udp-listen:11011 -
meaning "listen for stuff on port 11011 and copy to standard output", and
Terminal 2: % echo -n "TEST" | socat - udp-datagram:192.168.1.255:11011,broadcast
Together, this got data from Terminal 2 to Terminal 1.
Then I tried it on the tablet. As I mentioned, nc on the tablet was feeble. But socat was missing entirely.
I tried it, found it wasn't installed, and installed it.
Once I'd done that, on the Tablet I typed
Tablet: % socat udp-listen:11011 -
and on the mac, in Terminal 2, I once again typed
Terminal 2: echo -n "TEST" | socat - udp-datagram:192.168.1.255:11011,broadcast
and sure enough, the word TEST appeared on the tablet!
Even better, by reading the docs I found I could use
socat udp:recv:11011 -
which not only listens, but continues to listen, and hence will report multiple UDP packets, one after another. (udp-listen, by contrast, seems to wait for one packet and then try to communicate back with the sender of that packet, which isn't what I wanted at all.)
I have Three Rasbperry Pi3 and I have configured 2 of them as dhcp enabled ad-hoc network server they are working fine and I can connect to them using Windows PC and Linux PC as well as from Mobile. The dhcp also assigns the 'Laptop, PC and Mobile' the dynamic IP within specified range but when I try to connect from other Raspberry Pi with wpa_supplicant it can't connect to Raspberry Pi hosting ad-hoc network. I am using WEP encryption. My Raspberry Pi are equiped with internal wifi card.
Network Model
#1 Raspberry Pi3 with dhcp enabled ad-hoc
#2 Raspberry Pi3 with dhcp enabled ad-hoc
#3 Raspberry Pi3 is a moving node with managed network mode wpa_supplicant configurations which will connect to the either of those Raspberry Pi's based on which one has good signal strength and quality.
#1 Raspberry Pi with dhcp enabled ad-hoc
I have the following
interface configuration
my /etc/network/interfaces file looks like this
auto wlan0
iface wlan0 inet static
address 192.168.1.1
netmask 255.255.255.0
wireless-channel 1
wireless-essid Node1
wireless-key 6172736869
wireless-mode ad-hoc
dhcp configuration
and my Configuration for /etc/dhcp/dhcpd.conf is
ddns-update-style interim;
default-lease-time 600;
max-lease-time 7200;
authoritative;
log-facility local7;
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.5 192.168.1.150;
}
#2 Raspberry Pi with dhcp enabled ad-hoc
I have the following
interface configuration
my /etc/network/interfaces file looks like this
auto wlan0
iface wlan0 inet static
address 192.168.2.1
netmask 255.255.255.0
wireless-channel 1
wireless-essid Node2
wireless-key 6172736869
wireless-mode ad-hoc
dhcp configuration
and my Configuration for /etc/dhcp/dhcpd.conf is
ddns-update-style interim;
default-lease-time 600;
max-lease-time 7200;
authoritative;
log-facility local7;
subnet 192.168.2.0 netmask 255.255.255.0 {
range 192.168.2.5 192.168.2.150;
}
It is working fine. I can connect anything other than raspberry Pi with wpa_supplicant configuration. I have been working on it from almost 12 days and I tried almost every solution regarding WEP connection with wpa_supplicant and still no chance of connection.
I have the following configuration for
#3 Raspberry Pi3 with wpa_supplicant configuration
wpa_supplicant configuration
my /etc/wpa_supplicant/wpa_supplicant.conf looks like this
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=GB
network={
ssid="IoT-Lab"
psk="12323233"
key_mgmt=WPA-PSK
}
network={
ssid="Node1"
wep_key0="6172736869"
#wep_key0=6172736869
key_mgmt=NONE
}
When I connect to the Node1 it doesn't establish connection but create the the entry in wpa_supplicant.
Then read about removing the wep_key0 quotes and I did that but didn't work
I also read about a lots of tweaks to play with but nothing worked and did each of them but nothing seems to be work.
interface configuration
# interfaces(5) file used by ifup(8) and ifdown(8)
# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
iface eth0 inet manual
allow-hotplug wlan0
iface wlan0 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
I also check with interface configuration for wlan0 from manual to dhcp and but it doesn't work. I'll be thankful if you help me out.
I have found a partial answer to this question, and it is successfully setting the machine at the desired IP address. But the network is unreachable from inside a docker-machine created with the Hyper-V driver.
The TLDR on the answer above is to create a script, /var/lib/boot2docker/bootsync.sh:
sudo cat /var/run/udhcpc.eth0.pid | xargs sudo kill
sudo ifconfig eth0 192.168.XXX.YYY netmask 255.255.255.0 broadcast 192.168.XXX.255 up
Once I make the script, I restart the machine.
When I restart the machine, the IP is set to my desired address (expected). I can remote in at the address, so it is at least available through the host. But when I test for connections, there is no connection to the internet (unexpected).
Boot2Docker version 17.05.0-ce, build HEAD : 5ed2840 - Fri May 5 21:04:09 UTC 2017
Docker version 17.05.0-ce, build 89658be
docker#machine:~$ docker pull ubuntu
Using default tag: latest
Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on [::1]:53: read udp [::1]:48331->[::1]:53: read: connection refused
docker#machine:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network is unreachable
If I remove the script and restart again, I am reassigned a new/random IP address (expected), remote in at that new IP address, and can do network connections (expected):
docker#pm:~$ docker pull ubuntu
Using default tag: latest
latest: Pulling from library/ubuntu
aafe6b5e13de: Pull complete
0a2b43a72660: Pull complete
18bdd1e546d2: Pull complete
8198342c3e05: Pull complete
f56970a44fd4: Pull complete
Digest: sha256:f3a61450ae43896c4332bda5e78b453f4a93179045f20c8181043b26b5e79028
Status: Downloaded newer image for ubuntu:latest
docker#pm:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=43 time=18.424 ms
64 bytes from 8.8.8.8: seq=1 ttl=43 time=27.638 ms
The accepted answer has several up votes, but it reads like this is a confirmed work around on VirtualBox. Not sure what about Hyper-V would be causing the IP assignment to cut off internet access.
I had the same problem, and I solved it by adding the following to the end of bootsync.sh:
route add default gw <address>
There was no default route to the gateway or the internet, so it must be set manually.
I have configured a net with one host ( my computer) and two virtual machines. I don't want to use libvirt now to connect vm to host, so i manually created bridge and two tap interfaces.
Here is the configuration:
vm1 /etc/network/interfaces:
auto lo
iface lo inet loopback
auto enp0s2
iface enp0s2 inet static
address 192.168.50.3
netmask 255.255.255.0
dns-nameservers 8.8.8.8
up ip route add default via 192.168.50.1 dev enp0s2
the same for another one vm2:
auto lo
iface lo inet loopback
auto enp0s2
iface enp0s2 inet static
address 192.168.50.2
netmask 255.255.255.0
dns-nameservers 8.8.8.8
up ip route add default via 192.168.50.1 dev enp0s2
this is host :
auto enp4s0
13 iface enp4s0 inet manual
12
11 auto br0
10 iface br0 inet static
9 address 192.168.50.1
8 netmask 255.255.255.0
7 network 192.168.50.0
6 broadcast 192.168.50.255
5 # gateway 192.168.50.1
4 bridge_ports enp4s0 tap0 tap1
3 bridge_stp off
2 bridge_fd 0
1 bridge_maxwait 0
45 dns-nameservers 8.8.8.8
Host can ping vm and vms can ping host now. But from 192.168.50.3 vm 192.168.50.2 is unreachable. What is the problem here? I have read in "mastering kvm virtualization", that this is enough for getting the connection (ip forwarding is enabled, but this does not matter for bridge, as I understood)
can you try assigning same vlan to both vms xml(config) file ?
VirtualBox Port Forwarding on Windows 7 not Working
Im trying to ssh onto my VirtualBox from my Windows 7 host via port forwarding, but VirtualBox wont open the port for listening. I can connect to it by turning on the VirtualBox GUI and navigating via that terminal, but I cannot connect via a standard ssh client from my host. I want to be able to ssh on port 2222 on my host to the guest.
Here's my setup:
Host: Window 7 SP1
Guest: Ubunto Ubuntu 12.04
VirutalBox: 4.3.26
Host Processor: Intel Core i7 920
The guest machine is configured as a NAT and port forwarding is enabled for 127.0.0.1 for host port 2222 to guest port 22.
The output from ifconfig on the guest:
eth0 inet addr:10.0.2.15 Bcast:10.0.2.255 Mask: 255.255.255.0
The output from ps -ef | grep sshd on the guest:
root 625 1 0 12:27 ? 00:00:00 /usr/sbin/sshd -D
The output from netstat -ant | grep 22 on the guest:
tcp 0 0 0.0.0.0:22 0.0.0.0:*
tcp6 0 0 :::22 :::*
But on the host, netstat -ant | grep 2222 doesnt show anything.
In the VBox.log however I have this:
00:00:03.413790 NAT: set redirect TCP host 127.0.0.1:2222 => guest 10.0.2.15:22
00:00:03.424301 supR3HardenedErrorV: supR3HardenedScreenImage/LdrLoadDll: rc=VERR_LDRVI_UNSUPPORTED_ARCH fImage=1 fProtect=0x0 fAccess=0x0 \Device\HarddiskVolume2\Windows\mfnspstd64.dll: WinVerifyTrust failed with hrc=Unknown Status 0x800B0101 on '\Device\HarddiskVolume2\Windows\mfnspstd64.dll'
00:00:03.424422 supR3HardenedErrorV: supR3HardenedMonitor_LdrLoadDll: rejecting 'C:\Windows\mfnspstd64.dll' (C:\Windows\mfnspstd64.dll): rcNt=0xc0000190
00:00:03.424476 NAT: failed to redirect TCP 127.0.0.1:2222 => 10.0.2.15:22
The last line looks like the suspect but there's no clue as to why it fails to redirect. I've tried all of the following from various other posts and forums but cant get it to listen on any port on the host:
Turned off the firewall
Changed the port
Enabled VT-X on BIOS
Disabled Hyper-V
Tried numerous different builds of VirtualBox
Any help would be much appreciated. Works fine on my Mac Book with OS-X.
Did you set forwarding in machine settings ?
To forward ports in VirtualBox, first open a virtual machine’s settings window by selecting the Settings option in the menu.
Select the Network pane in the virtual machine’s configuration window, expand the Advanced section, and click the Port Forwarding button. Note that this button is only active if you’re using a NAT network type – you only need to forward ports if you’re using a NAT.
Use VirtualBox’s Port Forwarding Rules window to forward ports. You don’t have to specify any IP addresses – those two fields are optional.
Also here: http://www.howtogeek.com/122641/how-to-forward-ports-to-a-virtual-machine-and-use-it-as-a-server/
I found the solution in a hypernode-vagrant issue: VirtualBox fails to establish the port forwarding for SSH on Vagrant's standard port 2222, but higher ports work. In that issue, ports >= 4000 worked, whereas ports <= 3500 would fail. On my machine running Windows 10, I found 2380 to be the first port for which the TCP redirect can be established.
The port on the host used for forwarding can be changed by adding the following lines to your Vagrantfile (where you may have to replace 4000 by a higher number):
config.vm.network :forwarded_port, guest: 22, host: 2222, disabled: true
config.vm.network :forwarded_port, guest: 22, host: 4000, id: "ssh"
I have no idea what the root cause for this behavior could look like, but the workaround has been working reliably so far.
I used this article to ssh into my Raspberry pi3 VM.
Using this command ssh -p 2222 pi#localhost.
Originally, I had kept trying to use ssh pi#10.0.2.x -p 2222, but it didn't work and kept returning a "Connection timed out." My port number is 2222, but yours could be different depending what you set in your VirtualBox.
I am using a Windows 10 into a Debian Raspberry Pi VM (VirtualBox).