search

PiSCSI / piscsi

PiSCSI allows a Raspberry Pi to function as emulated SCSI devices (hard disk, CD-ROM, and others) for vintage SCSI-based computers and devices. This is a fork of the RaSCSI project by GIMONS.
https://piscsi.org
BSD 3-Clause "New" or "Revised" License
545 stars 82 forks source link

piscsi_bridge on Bookworm #1331

Open rdmark opened 1 year ago

rdmark commented 1 year ago

As per the discussion in https://github.com/PiSCSI/piscsi/issues/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 commented 1 year ago

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

fdanapfel commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 https://github.com/PiSCSI/piscsi/issues/917

rdmark commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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.

rdmark commented 1 year ago

Don’t hesitate to drop by Discord every now and then to encourage more contributions. ;)

In any case, we should make a decision today. Either spend more time to try to figure out how to get the network bridge to work on Bookworm. Or, cut one last release for Bullseye.

Was there anything specific in your changes to C++ code or build system that interferes with building or operating on Bullseye?

On the Python side, there shouldn’t be any blocker.

On Sat, Nov 11, 2023 at 6:02 PM, Uwe Seimet @.***(mailto:On Sat, Nov 11, 2023 at 6:02 PM, Uwe Seimet < wrote:

@.***(https://github.com/rdmark) I suggest that the Discord users who want to help with this just try this out. They do not even need piscsi for that, do they, 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.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

uweseimet commented 1 year ago

@rdmark Yes, more support would definitely help, and in this case it is not about C++, python or SCSI. IMO based on what we know so far the network bridge issue is not related to anything that is part of the piscsi release. Anybody who would like to help should not just provide links to stackoverflow pages, for instance, but should actively test on bookworm if the result is a working bridge, e.g. based on the brctl output ...

So far I have not found any issues on bullseye, and with my daynaport setup I have even tested more features that I have tested before. @benjamink has also done a lot of testing. But note that my tests only cover the C++ part and the remote interface. I neither use easyinstall nor the web UI.

If it turns out later that a code change is required, well, then a minor bugfix or feature release is needed, based on the tag for the upcoming release (i.e. not on develop). That's just normal. Same if you find a solution for the corrupted file upload issue: A bugfix release with just this change would be the right approach.

benjamink commented 1 year ago

When I'm back from vacation I'll try to find some time to really understand the bridge setup & see if I can help find a solution for Bookworm. I have a good bit of Linux experience but am definitely not a networking guru by any means.

uweseimet commented 1 year ago

Looks to me as if there are two issues with bookworm, which are both not caused by PiSCSI. Please correct me if I am missing something.

  1. Setting up a bridge has changed compared to bullseye. This affects using the daynaport emulation with eth0, but not with wlan0.
  2. IP-forwarding with the iptables settings that were working for bullseye does not work anymore. This affects using the daynaport emulation in general.
rdmark commented 1 year ago

@uweseimet FYI the 23.11.01 version has been tagged. I'm drafting the release notes now. Tomorrow I will attempt to run the image gen scripts. After that I'll flag the release as "current" and announce it broadly.

uweseimet commented 1 year ago

@rdmark Thank you for spending your time on the release process.

Of the remaining 146 C++ code smells 110 are caused by cfilesystem :-(.

uweseimet commented 1 year ago

For the record: With minor tweaking everything in the 23.11.01 release compiles on FreeBSD 14.0 and NetBSD 10.0. I added instructions to https://github.com/PiSCSI/piscsi/wiki/Compilation-Instructions. Of course, the only binary that might be useful is scsictl, and piscsi for testing the protobuf interface. Essentially you have the same test environment as on a regular Linux PC. Branch testing_macos_compile compiles but does not link on macos. Fixing the linker call is not worth the effort, this branch is just to ensure the codebase stays BSD compatible.

uweseimet commented 1 year ago

First problem on Bookworm resolved with manual bridge creation:

>brctl addbr piscsi_bridge
>brctl addif piscsi_bridge eth0
>brctl show
bridge name     bridge id               STP enabled     interfaces
piscsi_bridge           8000.dca63298c9d2       no              eth0

The same result when changing the piscsi_bridge script to this (replacing dhcp by manual) and then rebooting

auto piscsi_bridge
iface piscsi_bridge inet manual
        bridge_ports eth0

Do we need 'dhcp' in this script? But this anyway only appears to work as long is eth0 is not used, i.e. not connected. But with the manual setup above the daynaport is working with my setup on Bookworm with eth0. At least some progress. When NOT creating the bridge beforehand and having piscsi do that, which is the current behavior, it still works for me, both on Bookworm and Bullseye. My conclusion: The instructions on the Wiki for eth0 are not correct/outdated, and there is no need for the piscsi_bridge script. piscsi does all that is required automatically if there is not yet any bridge. This is what until recently I thought was the case anyway. Am I missing something?

When uninstalling dhcpcd on Bookworm an existing /etc/dhcpcd.conf file is not removed, but on a fresh Bookworm installation without dhcpcd installed it is not there at all. I wonder whether this is the same with a fresh Bullseye installation. If it is, there would probably not be any difference regarding dhcpcd at all.

fdanapfel commented 1 year ago

My conclusion: The instructions on the Wiki for eth0 are not correct/outdated, and there is no need for the piscsi_bridge script. piscsi does all that is required automatically if there is not yet any bridge. This is what until recently I thought was the case anyway. Am I missing something?

@uweseimet I just did some tests on my RaSCSI board attached to a Raspberry Pi Zero 2W, which has only WLAN but no Ethernet, which I think confirm your conclusion.

I use the standard "bullseye" image with piscsi updated to the November 2023 Release and I've used the Configure network bridge for WiFi (static IP + NAT) option in easyinstall.sh to set up the network for the DaynaPort.

When the PiSSCSI is turned on and without having any SCSI devices enabled then there is no piscsi_bridge, since there is also no configuration script for it in /etc/network/interfaces.d/:

pi@rascsi:~ $ scsictl -l
No devices currently attached.
pi@rascsi:~ $ brctl show
pi@rascsi:~ $ ls -la /etc/network/interfaces.d/
total 8
drwxr-xr-x 2 root root 4096 Nov  4  2020 .
drwxr-xr-x 7 root root 4096 Feb  6  2022 ..

Only the iptables rules for the NAT setup are present:

pi@rascsi:~ $ sudo iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 104 packets, 16602 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 102 packets, 15450 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 3199 packets, 192K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 3199 packets, 192K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 MASQUERADE  all  --  *      wlan0   10.10.20.0/24        0.0.0.0/0

Also only the default network config for the WLAN interface exists at this point:

pi@rascsi:~ $ ip a
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 
       valid_lft forever preferred_lft forever
2: wlan0: <BROADCAST,MULTICAST,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 862290sec preferred_lft 754290sec
    inet6 2003:c9:d742:e100:e539:577:d97a:c1e5/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 7099sec preferred_lft 1002sec
    inet6 fe80::2395:4ece:5c50:5d10/64 scope link 
       valid_lft forever preferred_lft forever

If I now enable the DaynaPort adapter in PiSCSI all of a sudden the piscsi_pridge appears, but it only has the piscsi0 interface attached (since there is no eth0 on the Zero 2W):

pi@rascsi:~ $ scsictl -i 6 -c attach -t scdp -f wlan0:10.10.20.1/24
pi@rascsi:~ $ scsictl -l
+----+-----+------+-------------------------------------
| ID | LUN | TYPE | IMAGE FILE
+----+-----+------+-------------------------------------
|  6 |   0 | SCDP | DaynaPort SCSI/Link
+----+-----+------+-------------------------------------
pi@rascsi:~ $ brctl show
bridge name bridge id       STP enabled interfaces
piscsi_bridge       8000.f2bbaf3d1c2f   no      piscsi0
pi@rascsi:~ $ ip a
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 
       valid_lft forever preferred_lft forever
2: wlan0: <BROADCAST,MULTICAST,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 861955sec preferred_lft 753955sec
    inet6 2003:c9:d742:e100:e539:577:d97a:c1e5/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 7036sec preferred_lft 1567sec
    inet6 fe80::2395:4ece:5c50:5d10/64 scope link 
       valid_lft forever preferred_lft forever
3: piscsi0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master piscsi_bridge state UNKNOWN group default qlen 1000
    link/ether f2:bb:af:3d:1c:2f brd ff:ff:ff:ff:ff:ff
    inet6 fe80::f0bb:afff:fe3d:1c2f/64 scope link 
       valid_lft forever preferred_lft forever
4: piscsi_bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether f2:bb:af:3d:1c:2f brd ff:ff:ff:ff:ff:ff
    inet 10.10.20.1/24 brd 10.10.20.255 scope global piscsi_bridge
       valid_lft forever preferred_lft forever
    inet6 fe80::ecc3:e7ff:feb3:f5e7/64 scope link 
       valid_lft forever preferred_lft forever

Still nothing in /etc/network/interfaces.d/:

pi@rascsi:~ $ ls -la /etc/network/interfaces.d/
total 8
drwxr-xr-x 2 root root 4096 Nov  4  2020 .
drwxr-xr-x 7 root root 4096 Feb  6  2022 ..

So the instructions in the wiki are indeed wrong, and there is no need to manually create the piscsi_bridge in /etc/network/interfaces.d/ since piscsi always automatically seems to create it when the DaynaPort is attached.

But I think the piscsi code is also wrong, because based on the instructions in the Wiki the piscsi_bridge is only needed when using a pysical Ethernet port for the Daynaport, but not when using WLAN. So PiSCSI should only create the bridge if eth0 is specified when enabling the DaynaPort, but not when specifiyfying wlan0.

uweseimet commented 1 year ago

@fdanapfel The piscsi code currently programmatically does what old instructions said should be done. Before I extended piscsi in order to do that, you had to execute the network commands that PiSCSI is now logging on trace level (e.g ">brctl delif ...") manually. If this can be improved/fixed I will try to address this, thank you for pointing this out. This may take some time, though, because there are several other changes (PRs and tickets in progress) that I need to have been merged first.

fdanapfel commented 1 year ago

@uweseimet Ah, OK. As I've mentioned in https://github.com/PiSCSI/piscsi/issues/1331#issuecomment-1805620723 it would be great if the whole network setup for the DaynaPort adapter could be changed so that it uses parprouted instead of the current bridge/NAT configuration, which would have the benefit that DHCP could also be used if the DaynaPort connects to the network via WLAN.

uweseimet commented 1 year ago

@fdanapfel I am open for any kind of improvement, but due to my lack of networking knowledge it is sometimes hard for me to evaluate some suggestions. Any active work (code/script changes) from your side would be appreciated. By the way, we are in need of reviewers for C++ code changes. Do you volunteer?

fdanapfel commented 1 year ago

@uweseimet Sorry, wish I could help, but I have next to no knowledge of C++ (I only did a very small bit of C++ coding when I was at university 2 decades ago). I'm more a "sysadmin" type, so I can help with testing things at the OS level.

Is there a way to prevent the automatic creation of the piscsi_bridge when the DaynaPort adapter is enabled? If yes then I could try to figure out if I could get the parprouted setup working so that the DaynaPort can communicate over WLAN with the rest of the network without using the NAT setup.

uweseimet commented 1 year ago

@fdanapfel When there is already a bridge piscsi does not create it but uses it. At least that's the idea. If you need a change in piscsi to help you with testing, just tell me, and I can do that in a branch. But only very small changes for now, as long as there are still several open tickets,.

fdanapfel commented 1 year ago

@rdmark @uweseimet I've now managed to get the WLAN bridge setup using parprouted working on bullseye and created a new issue describing the required steps: https://github.com/PiSCSI/piscsi/issues/1387

uweseimet commented 1 year ago

@fdanapfel Is MiNT required for DHCP, or is this also possible with the STiNG driver without MiNT?

fdanapfel commented 1 year ago

@uweseimet As far as I know STiNG only supports static IPs, but no DHCP.

fdanapfel commented 9 months ago

@rdmark @uweseimet I was now able to verify that the piscsi_bridge is not needed when using the "Wireless Raspberry Pi Setup" mentioned at https://github.com/PiSCSI/piscsi/wiki/Dayna-Port-SCSI-Link.

This is how the setup of the network interfaces looks after activating the daynaport on bookworm:

$ ip a
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,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 840250sec preferred_lft 840250sec
    inet6 2003:c9:d701:1200:470a:d09a:e629:147e/64 scope global dynamic noprefixroute 
       valid_lft 6986sec preferred_lft 3386sec
    inet6 fe80::8d9b:2326:42e9:e441/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: piscsi0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master piscsi_bridge state UNKNOWN group default qlen 1000
    link/ether 4e:a1:a1:3b:c0:74 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::4ca1:a1ff:fe3b:c074/64 scope link 
       valid_lft forever preferred_lft forever
4: piscsi_bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 4e:a1:a1:3b:c0:74 brd ff:ff:ff:ff:ff:ff
    inet 10.10.20.1/24 brd 10.10.20.255 scope global piscsi_bridge
       valid_lft forever preferred_lft forever
    inet6 fe80::7cd4:98ff:fe16:c0db/64 scope link 
       valid_lft forever preferred_lft forever

No NAT rules are set up in iptables at this point:

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
frank@bookworm:~ $ sudo iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

I then manually removed the piscsi_bridge that was automatically created:

$ sudo /sbin/ip link delete piscsi_bridge
$ ip a
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,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 840209sec preferred_lft 840209sec
    inet6 2003:c9:d701:1200:470a:d09a:e629:147e/64 scope global dynamic noprefixroute 
       valid_lft 6946sec preferred_lft 3346sec
    inet6 fe80::8d9b:2326:42e9:e441/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: piscsi0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 4e:a1:a1:3b:c0:74 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::4ca1:a1ff:fe3b:c074/64 scope link 
       valid_lft forever preferred_lft forever

The IP address previously assigned to the pscsi_bridge interface was then assigned to the piscsi0 interface:

$ sudo /sbin/ip addr add 10.10.20.1/24 brd + dev piscsi0
$ ip a
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,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 840190sec preferred_lft 840190sec
    inet6 2003:c9:d701:1200:470a:d09a:e629:147e/64 scope global dynamic noprefixroute 
       valid_lft 6927sec preferred_lft 3327sec
    inet6 fe80::8d9b:2326:42e9:e441/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: piscsi0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 4e:a1:a1:3b:c0:74 brd ff:ff:ff:ff:ff:ff
    inet 10.10.20.1/24 brd 10.10.20.255 scope global piscsi0
       valid_lft forever preferred_lft forever
    inet6 fe80::4ca1:a1ff:fe3b:c074/64 scope link 
       valid_lft forever preferred_lft forever

Then the iptables rules for enabling NAT were set up according to the wiki:

$ sudo iptables --flush
$ sudo iptables -X
$ sudo iptables -Z
$ sudo iptables -P INPUT ACCEPT
$ sudo iptables -P OUTPUT ACCEPT
$ sudo iptables -P FORWARD ACCEPT
$ sudo iptables -t nat -A POSTROUTING -o wlan0 -s 10.10.20.0/24 -j MASQUERADE
$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
$ sudo iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  10.10.20.0/24        anywhere

Afterwards I was able to access the network from both an Atari TT030 (with both STiNG and MiNT) and a Mac SE/30 (with System 7.5.5 with MacTCP) using a static IP assigned on both systems.

Therefore I would suggest that at least when only wlan0 is available or in case wlan0 has been explicitly defined as the network interface when enabling the daynaport, the piscsi_bridge should not be automatically be created by piscsi on either bullseye or bookworm.

uweseimet commented 9 months ago

@fdanapfel As far as SCSI2Pi is concerned, can you please create a respective ticket in the SCSI2Pi project?

fdanapfel commented 9 months ago

@uweseimet Done: https://github.com/uweseimet/scsi2pi/issues/64