Open rdmark opened 10 months ago
With bullseye brctl shows the expected output, i.e. including eth0.
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
@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 ;-).
@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. :)
@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.
@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 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.
@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.
@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.
@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.
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.
@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/
@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
@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.
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: @.***>
@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.
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.
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.
@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.
@rdmark Thank you for spending your time on the release process.
Of the remaining 146 C++ code smells 110 are caused by cfilesystem :-(.
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.
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.
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
.
@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.
@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.
@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?
@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.
@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,.
@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
@fdanapfel Is MiNT required for DHCP, or is this also possible with the STiNG driver without MiNT?
@uweseimet As far as I know STiNG only supports static IPs, but no DHCP.
@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.
@fdanapfel As far as SCSI2Pi is concerned, can you please create a respective ticket in the SCSI2Pi project?
@uweseimet Done: https://github.com/uweseimet/scsi2pi/issues/64
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:
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