piscsi_bridge on Bookworm #1331
Comments
|
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 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. :) Notes in #917 |
|
@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. |
@rdmark No, it doesn't if you look at the links I posted you'll see they use parprouted. |
@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. 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: 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 https://forums.raspberrypi.com/viewtopic.php?t=357739 |
|
@uweseimet Over at Discord we were suggested one workaround to try: Disable 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. |
|
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 <<a href=)> 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](#1331 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAQCYM3DNNYF3F2MI46J5O3YD45JVAVCNFSM6AAAAAA7F77CYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBWG42TMNJYG4).
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. |
|
First problem on Bookworm resolved with manual bridge creation: The same result when changing the piscsi_bridge script to this (replacing dhcp by manual) and then rebooting 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. 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. |
@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 When the PiSSCSI is turned on and without having any SCSI devices enabled then there is no Only the Also only the default network config for the WLAN interface exists at this point: If I now enable the DaynaPort adapter in PiSCSI all of a sudden the Still nothing in So the instructions in the wiki are indeed wrong, and there is no need to manually create the piscsi_bridge in 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 |
|
@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. |
|
@uweseimet Ah, OK. As I've mentioned in #1331 (comment) 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. |
|
@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: #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: No NAT rules are set up in iptables at this point: I then manually removed the piscsi_bridge that was automatically created: The IP address previously assigned to the pscsi_bridge interface was then assigned to the piscsi0 interface: Then the iptables rules for enabling NAT were set up according to the wiki: 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? |
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:
And then using dhcpcd to
denyinterfacesfor the bridged interface to force traffic through the bridge.https://github.com/PiSCSI/piscsi/wiki/Dayna-Port-SCSI-Link
The text was updated successfully, but these errors were encountered: