My host computer is connected via WiFi.
192.168.123.0/24 via 192.168.12.1 dev wlp146s0 proto static metric 100
The Pi has two IP addresses:
Routes on the PI:
default via 192.168.123.1 dev eth0 src 192.168.123.161 metric 202
default via 192.168.12.1 dev wlan1 src 192.168.12.1 metric 305
192.168.12.0/24 dev wlan1 proto dhcp scope link src 192.168.12.1 metric 305
192.168.123.0/24 dev eth0 proto dhcp scope link src 192.168.123.161 metric 202
220.127.116.11/4 dev lo scope link
I ran the following commands on the Pi to enable the forwarding of IP packets:
sudo sysctl -p
sudo iptables -F
sudo iptables -t nat -F
sudo iptables -t nat -A POSTROUTING -o wlan1 -j MASQUERADE
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -i wlan1 -o eth0 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o wlan1 -j ACCEPT
And I uncommented the line
net.ipv4.ip_forward=1 in the file
Therefore I’m able to reach the following devices by running nmap on my host computer:
Nmap scan report for 192.168.123.10
Host is up (0.0039s latency).
Nmap scan report for 192.168.123.13
Host is up (0.0015s latency).
Nmap scan report for 192.168.123.14
Host is up (0.0018s latency).
Nmap scan report for 192.168.123.15
Host is up (0.0023s latency).
Nmap scan report for 192.168.123.161
Host is up (0.0017s latency).
Nmap done: 256 IP addresses (5 hosts up) scanned in 15.51 seconds
What I can and can’t do
I am further able to control the robot without changing the IP address in the program (set to
192.168.123.161). I just don’t get status messages.
When I change the IP in the program to
192.168.12.1, I can control the robot and I do get status messages.
I am also able to connect to the Nvidia computers via ssh over the WiFi connection without any problem, which means the forwarding through the PI is working in both directions.
What I don’t understand
Since both of the addresses I use in the program belong to the PI there should not be a difference, which one I’m using to connect to it.
And because every inbound package at
192.168.12.1 addressed to the
192.168.123.0/24 network gets forwarded into the internal network, they should also be able to reach the “other side of the PI” at
Why I don’t like the solution of changing the IP in the code
- It shouldn’t be necessary because I can connect to the internal network
- Changing the code every time I switch between a wired and wireless connection is a possible error source
- After changing the IP in the code I’d have to recompile it
- In the future we are going to have a laboratory where we will probably be developing in a wired configuration and then be testing with the wireless connection. Therefore the code should stay the same to achieve equal conditions and enable a quick change between the configurations.