Feature Request: Wifi bridge without NAT using parprouted

[fdanapfel]

Info

• Which version of Pi are you using: Raspberry Pi Zero 2W
• Which github revision of software: v23.11.01
• Which board version: Fullspec 2.3a
• Which computer is the PiSCSI connected to: Atari TT
• Which OS you are using (output of 'lsb_release -a'):
  Distributor ID: Raspbian
  Description: Raspbian GNU/Linux 11 (bullseye)
  Release: 11
  Codename: bullseye

Describe the issue

The current setup described at https://github.com/PiSCSI/piscsi/wiki/Dayna-Port-SCSI-Link for the Wireless Raspberry Pi setup using NAT does not allow to to use DHCP on a system to which the DaynaPort adapter is attached, and it also makes it difficult to connect to the system from a computer other than the Pi on which piscsi is running.

Using the setup described in the section "Option 1 - Same Subnet" at https://www.willhaley.com/blog/raspberry-pi-wifi-ethernet-bridge/ would allow the computer connected to the PiSCSI to communicate directly with other systems on the WLAN and also enable it to use DHCP to get an IP address.

As far as I can see the setup described here does not have the issues of the solution described in #917 since it uses parprouted (https://www.hazard.maks.net/parprouted/).

I've now tested this setup on my PiSCSI and verified that it works. Here are the steps to get it to work manually.

First, install parprouted and dhcp-helper:
sudo apt install parprouted dhcp-helper

Attach the DaynaPort either via the web-interface or by running

scsictl -i 6 -c attach -t scdp -f wlan0

Then "down" the piscsi0 interface and remove the bridge that is automatically created by piscsi when the DaynaPort was attached:

sudo /sbin/ip link set dev piscsi0 down
sudo /sbin/ip link delete piscsi_bridge

On bullseye the piscsi_bridge can also be removed with the following commands:

sudo /sbin/ip link set dev piscsi_bridge down
sudo brctl delbr piscsi_bridge

Make sure that IP forwarding is enabled:
sudo sysctl -w net.ipv4.ip_forward=1
To make this change permanent:
sudo sed -i'' s/#net.ipv4.ip_forward=1/net.ipv4.ip_forward=1/ /etc/sysctl.conf
To verify that IPv4 forwarding is enabled you can run the following commands:

sysctl net.ipv4.ip_forward

This should return net.ipv4.ip_forward = 1 showing that IPv4 forwarding is enabled in the Linux kernel

On bullseye update /etc/dhcpcd.conf to disable dhcpcd controlling the piscsi0 interface:

sudo grep '^denyinterfaces eth0$' /etc/dhcpcd.conf || printf "denyinterfaces piscsi0\n" >> /etc/dhcpcd.conf

Since bookworm uses NetworkManger instead of dhcpcd for managing the network interfaces, to prevent NetworkManager from trying to manage the piscsi0 interface it is necessary to create an additional configuration file:

$ cat /etc/NetworkManager/conf.d/99-unmanaged-devices.conf 
[keyfile]
unmanaged-devices=interface-name:piscsi0
$ sudo systemctl reload NetworkManager

(see https://access.redhat.com/documentation/de-de/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/configuring-networkmanager-to-ignore-certain-devices_configuring-and-managing-networking for more information)

Configure dhcp-helper to use the right network interface (only necessary if using WLAN instead of the wired connection):

sudo systemctl stop dhcp-helper
sudo cat > /etc/default/dhcp-helper <<EOF
DHCPHELPER_OPTS="-b wlan0"
EOF

Start dhcp-helper and make sure it is enabled on boot:

sudo systemctl start dhcp-helper
sudo systemctl enable dhcp-helper

Verify that dhcp-helper is running with systemctl status dhcp-helper

Enable avahi reflector if it's not already enabled:

sudo sed -i'' 's/#enable-reflector=no/enable-reflector=yes/' /etc/avahi/avahi-daemon.conf
sudo systemctl restart avahi-daemon

Put wlan0 in promiscuos mode:
sudo /sbin/ip link set wlan0 promisc on

Clone the dhcp-allocated IP from wlan0 to piscsi0 so dhcp-helper will relay for the correct subnet:

sudo /bin/bash -c '/sbin/ip addr add $(/sbin/ip -4 -br addr show wlan0 | /bin/grep -Po "\\d+\\.\\d+\\.\\d+\\.\\d+")/32 dev piscsi0'
sudo /sbin/ip link set dev piscsi0 up

If you now run ip a it should show output similar to the following:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: wlan0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether e4:5f:01:78:10:a2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.23/24 brd 192.168.178.255 scope global dynamic noprefixroute wlan0
       valid_lft 844129sec preferred_lft 844129sec
    inet6 2003:c9:d701:1200:470a:d09a:e629:147e/64 scope global dynamic noprefixroute 
       valid_lft 6903sec preferred_lft 3303sec
    inet6 fe80::8d9b:2326:42e9:e441/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
5: piscsi0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 0e:f4:a6:9c:e6:d8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.23/32 scope global piscsi0
       valid_lft forever preferred_lft forever
    inet6 fe80::cf4:a6ff:fe9c:e6d8/64 scope link 
       valid_lft forever preferred_lft forever

The important things here are that both the piscsi0 and the wlan0 interface show the UP flag, that the PROMISC flag is also set on wlan0 and that both interfaces have the same IP address.

If that is the case you can start parprouted:

sudo /usr/sbin/parprouted piscsi0 wlan0

Running ps -ef| grep parprouted should show that parprouted is running and its connecting the piscsi0 interface to the interface used for forwarding the IP traffic:

root        3043       1  0 13:43 ?        00:00:01 /usr/sbin/parprouted piscsi0 wlan0

To find out if there is any issue with parprouted you can check its logs using journalctl|grep parprouted

If I now boot the Atari TT with EasyMiNT with the SCSILink driver enabled it wil automatically get an IP address via DHCP and I'm also able to ping other computers on the network directly.

[fdanapfel]

Did some further research over the weekend, and it looks like it should also be possible to use this setup for the wired Ethernet configuration. All that is needed is to replace wlan0 with eth0 in the instructions I've mentioned above.

Maybe somebody with a PiSCSI attached to a Raspberry Pi with Ethernet port can verify this.

If it also works for the wired Ethernet setup then it might be a good idea to alsp replace the Ethernet bridge setup with this and have a unified setup for both Ethernet and WiFi for the DaynaPort adapter.

[rdmark]

@fdanapfel I agree that if your solution is stable and portable with no hidden drawbacks, we should apply it to wired as well as wireless setups.

If I can find my RPi3B+ (has an Ethernet port) I will test this out during the coming weekend.

One remark: dhcpcd isn’t installed on Bookworm by default. Also, network interfaces are managed by nm by default in Bookwork. Do we have to change the nm configuration as well?

[fdanapfel]

@rdmark Sorry, I haven't had a chance to take a look at Bookworm so far, therefore I can't say what changes will be required to make this setup work on Bookworm.

The only changes in this setup regarding dhcpcd is to make sure the "ip-forwarding" option is set on DHCP requests and to disable mangement of the piscsi0 interface by dhcpcd. So it would be necessary to find out how this is done with the DHCP client that replaced dhcpcd in bookworm, but I'm not 100% sure if these two changes are actually really needed.

If the only way to manage network interfaces in Bookworm is by using nm, then yes the nm configuration would most likely have to be changed as well. But if it is still possible to use the "ip" command then I would try to use the commands I mentioned above first to see if they still work on Bookworm.

[rdmark]

Makes sense, thanks. Getting the bridge working (at all) on Bookworm is priority no.1 for me right now, so I'll try on the weekend to see if there are further complications.

Btw, I think it's fair to say that we should remove or rehash the piscsi code that creates piscsi_bridge dynamically, if we were to make this approach the default. It seems to only obstruct your procedure.

[fdanapfel]

Btw, I think it's fair to say that we should remove or rehash the piscsi code that creates piscsi_bridge dynamically, if we were to make this approach the default. It seems to only obstruct your procedure.

Yes, if the setup I describe in this issue is adopted as the default for giving network access to devices using the emulated DaynaPort device then the piscsi_pridge is no longer needed and the piscsi code to create it dynamically should be removed.

[rdmark]

@fdanapfel I finally got around to playing around with your steps. Sorry for the hold-up!

The good news is that I seem to be able to get an IP address from my DHCP router. The bad news is that no TCP/IP traffic is coming through. Saw once instance of this error in the syslogs:

Jan 15 23:46:06 rasp32 dhcpcd[669]: wlan0: authentication failed from fe80::7277:81ff:fe9c:d862: No such file or directory

This is on a Performa 6116CD running 8.1. I'll try other Macs and OS variants and see if it makes a difference!

[fdanapfel]

@rdmark Thanks for the feedback and giving this a try.

If the Mac is able to get an IP address via DHCP then the network connection should be working. Not sure why you are not getting any other TCP/IP traffic coming trough.

The error message seems to be related to authentication for the WiFi connection of the Rasberry Pi, but since DHCP seems to be working it should not be related to the issue you are seeing.

Which version of Raspberry Pi OS are you using on the PiSCSI, bullseye or bookworm?

If I have time until the weekend I'll try to get my RaSCSI hooked up to one of my old Macs to see if the network connection works with my existing PiSCSI setup on bullseye. If that works I'll can try to figure out what needs to be changed to make it work on bookworm as well.

[fdanapfel]

@rdmark I was now able to test my proposed setup with the RaSCSI (running bullseye) connected to a Macintosh SE 1/40 running System 7.5 with MacTCP and had no issues with TCP/IP communication. Ping, DNS lookup, etc all work (tested with MacTCP Ping and MacTCP Watcher).

[fdanapfel]

@rdmark I was now also able to test this setup on bookworm (using the scsi2pi binaries provided by @uweseimet at https://github.com/uweseimet/scsi2pi) and can confirm that it works there as well.

While testing the setup I noticed one important piece of information missing from my original instructions: to enable IPv4 forwarding on the Raspberry Pi immediately without rebooting the following command must be run before setting up the piscs0 interface and starting parprouted:
$ sudo sysctl -w net.ipv4.ip_forward=1

Also I found out that it is not necessary to use brctl to remove the piscsi_bridge, this can actually be done directly with ip (which should work on both bullseye and bookworm):
$ sudo /sbin/ip link delete piscsi_bridge
(it is not necessary to "down" the piscsi_bridge first)

Since bookworm uses Network Manger instead of dhcpcd for managing the network interfaces, to prevent Network Manager from trying to manage the piscsi0 interface it is necessary to create an additional configuration file:

$ cat /etc/NetworkManager/conf.d/99-unmanaged-devices.conf 
[keyfile]
unmanaged-devices=interface-name:piscsi0
$ sudo systemctl reload NetworkManager

(see https://access.redhat.com/documentation/de-de/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/configuring-networkmanager-to-ignore-certain-devices_configuring-and-managing-networking for more information)

[rdmark]

Thanks for all the detailed instructions! I didn't get around to looking at this today, but I think I can take some time tomorrow.

[rdmark]

@fdanapfel May I ask you to update the instructions in the original description, to make it easier to follow along your steps and avoid making mistakes?

I tried again this evening to get my Power Mac working with this setup but still no luck.

Do you have other network interfaces in your setup? I have a wired interface as well as the virtual docker interface (that I took down) that might be interfering perhaps?

My next step is to try to get back to a working "traditional" piscsi bridge to make sure that nothing else is malfunctioning...

FWIW I'm testing on Bullseye right now since that's what my main piscsi setup is using. The Bookworm instructions will come in handy later on for sure, though.