piscsi_bridge on Bookworm

[rdmark]

As per the discussion in #1321 , there are signs that the current solution for spinning up piscsi_bridge isn't working anymore on Debian 12 Bookworm.

This ticket is to further investigate.

The current setup is a network bridge configuration that says:

auto piscsi_bridge
iface piscsi_bridge inet dhcp
        bridge_ports eth0

And then using dhcpcd to denyinterfaces for the bridged interface to force traffic through the bridge.

https://github.com/PiSCSI/piscsi/wiki/Dayna-Port-SCSI-Link

[uweseimet]

With bullseye brctl shows the expected output, i.e. including eth0.

[fdanapfel]

Maybe using Proxy ARP instead of the current bridge setup would be an option: https://wiki.debian.org/BridgeNetworkConnectionsProxyArp
https://hackmd.io/@akiranet/H1gpqUAUO

This would also have the benefit that DHCP could be used when the WiFi interface on the Pi is used as the network interface for the Daynaport

[uweseimet]

@rdmark I am getting more and more confused. It looks as if the bridge is set up with the piscsi_bridge script even though piscsi sets up the bridge automatically when there is none. The primary idea was that piscsi sets up everything automatically (depending on the parameters passed for the daynaport device by default preferably for eth0, and when not available then for wlan0), so that no unecessary static/global re-configuration of the Pi was required. I may simply be missing something, but I don't know yet what it is ;-).

[rdmark]

@fdanapfel Doesn't Proxy ARP require the systemd.networkd network stack? Last time I researched this (a year ago) I found a few potential blockers and didn't proceed with a POC. But I'm an amateur and may have missed some obvious solution. :)

Notes in #917

[rdmark]

@uweseimet Maybe it has something to do with dhcpcd that requires the bridge to be created on boot time, hence depending on interfaces.d to configure it earlier than what piscsi can do? I'm just guessing though.

[uweseimet]

@rdmark This may indeed be the case. I noticed that when NOT configuring the bridge beforehand "brctl show" does not list eth0 (this time on bullseye). Maybe the solution for bookworm will provide more insight.
I'm slowly making progress with my setup for the Atari I think. What I do not understand right now is where the Atari's IP address comes from. When eth0 is used there is no 10.10.20.0 network. Can you tell me which IP is the one the Atari has to use, and what the gateway IP address is? Is the gateway IP address the address of the piscsi bridge? I don't think the Wiki addresses this because it assumes that the computer supports DHCP, which for the Atari driver is not the case.
As soon as this is working I will add an Atari network setup section to the Wiki :).

[fdanapfel]

@fdanapfel Doesn't Proxy ARP require the systemd.networkd network stack? Last time I researched this (a year ago) I found a few potential blockers and didn't proceed with a POC. But I'm an amateur and may have missed some obvious solution. :)

Notes in #917

@rdmark No, it doesn't if you look at the links I posted you'll see they use parprouted.

[fdanapfel]

@rdmark This may indeed be the case. I noticed that when NOT configuring the bridge beforehand "brctl show" does not list eth0 (this time on bullseye). Maybe the solution for bookworm will provide more insight. I'm slowly making progress with my setup for the Atari I think. What I do not understand right now is where the Atari's IP address comes from. When eth0 is used there is no 10.10.20.0 network. Can you tell me which IP is the one the Atari has to use, and what the gateway IP address is? Is the gateway IP address the address of the piscsi bridge? I don't think the Wiki addresses this because it assumes that the computer supports DHCP, which for the Atari driver is not the case. As soon as this is working I will add an Atari network setup section to the Wiki :).

@uweseimet If you use eth0 (the physical network interface on the Pi), then the Atari will need to get a static IP from the network the Pi is connected to, and the gateway IP address will be the same as for all other systems on that network.

So for example if the Network the Pi is connected to is 192.168.0. the gateway for this network will most likely be 192.168.0.1 (you can actually check on the Pi with route or netstat). And you can then assign a static IP address on the Atari that is outside of the range of the IP Adresses that your DHCP server assigns (for example, if the DHCP server uses 192.168.0.10 to 192.168.0.100 as the range of IP addresses it assigns for DHCP requests, you could use 192.168.0.101 as the static IP for the Atari.

[uweseimet]

@fdanapfel It works, thank you for helping with this! I can now successfully ping 8.8.8.8, and get correct traceroute information for this address. And I can ping the Atari from my PC.

[uweseimet]

@rdmark When using wlan0 instead of eth0 it did not work out of the box. When both eth0 and wlan0 are up it fails. This is because piscsi tries to configure eth0 by default when it is available. When you add "denyinterfaces eth0" it works. It also works by explicitly launching piscsi with the interface parameter, e.g.

>piscsi -id 6 -t scdp -f interface=wlan0

For scenarios where you do no want to or cannot use DHCP launching with the parameter is the best solution, because you would not want to enable DHCP when you do not need it, just in order to block eth0. This is also something useful for the Wiki.

[uweseimet]

My assumption was that bookworm with wlan0 instead of eth0 would work but it did not. As far as I can tell the bridge was set up correctly:

eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether dc:a6:32:98:c9:d2  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 10  bytes 1558 (1.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10  bytes 1558 (1.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

piscsi0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::b810:beff:fe3c:3a7e  prefixlen 64  scopeid 0x20<link>
        ether ba:10:be:3c:3a:7e  txqueuelen 1000  (Ethernet)
        RX packets 16  bytes 2142 (2.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 48  bytes 6350 (6.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

piscsi_bridge: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.20.1  netmask 255.255.255.0  broadcast 10.10.20.255
        inet6 fe80::d0f0:2eff:fea9:fc41  prefixlen 64  scopeid 0x20<link>
        ether ba:10:be:3c:3a:7e  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 32  bytes 4270 (4.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.103  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 2a02:8071:2284:5340::8d74  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::fe21:de36:d352:a82f  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:98:c9:d3  txqueuelen 1000  (Ethernet)
        RX packets 2197  bytes 194095 (189.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1265  bytes 202752 (198.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

The daynaport log looks normal, with regular polling. The Atari can ping the Pi, which which IMHO means that nothing is wrong on the client side. But IP forwarding did not appear to work. There were timeouts and 100% package loss with ping and traceroute just made it to the Pi, but not further. On the Atari the setup was identical with the one that worked fine with bullseye.

I tend to say the release should not be postponed if these issues cannot be resolved. I may be wrong, but it looks to me as if there is no problem with piscsi as such, but this is a question of configuring bookworm correctly.

[rdmark]

@uweseimet Some research suggests that RPiOS Bookworm deprecated dhcpcd in favor of nm (Network Manager).

https://forums.raspberrypi.com/viewtopic.php?t=357739
https://networkmanager.dev/docs/api/latest/

[rdmark]

@uweseimet Over at Discord we were suggested one workaround to try: Disable nm management of the relevant interface. This might theoretically allow dhcpcd to control them again.

https://wiki.debian.org/NetworkManager#Wired_Networks_are_Unmanaged

[uweseimet]

@rdmark I suggest that the Discord users who want to help with this just try this out. They do not even need piscsi for this because this is an external setup. If they have found a good solution they might add it to the Wiki.
In the ideal case there will be a solution that can be coded directly in piscsi, just like the existing bridge stuff. But such a solution might not exist.