DaynaPort networking no longer working after latest build of 'develop' #1306
Comments
|
@benjamink Can you please provide logs from v23.04.01 and the develop branch? Please restrict the logs to the SCSI ID of the daynaport by launching piscsi with "-L trace:SCSI_ID" and please use debug builds, not optimized builds. Fixing daynaport issues can be quite an effort, so please ensure that this is definitely not a problem with your environment. Just replacing the respective piscsi binaries (v23.04.01 and develop) without changing anything else should be how you can switch between a working and non-working setup. |
|
@uweseimet how can I build piscsi with debugging? I assume you're asking for something different than what I get when I run option #1 from I don't have specific logs for each version. I have a huge I'll capture logs from both versions when I have things all setup. |
|
@benjamink In the cpp folder run these commands to compile with debug information: The resulting binary will be placed in cpp/fullspec/bin. The binaries built this way are the ones to use for any testing. Please run any tests on a regular Raspberry Pi OS, bullseye or bookworm. But I assume you are already doing this, because the develop branch does not compile anymore on buster. |
|
I was able to revert back to Attaching screenshot & relevant logs/configs from test run:
I'm re-compiling current |
|
@benjamink OK. For testing please backup your 23.04.01 piscsi binary, and then replace it by the piscsi binary from the develop build. Do not change anything else (!!!) If the develop binary fails, in order to double-check replace it by the 23.04.01 binary, and do not change anything else (!!!). If things start working again we can be sure that this is a regression issue with the binary. Anything related to the UI is not relevant for proceeding further. We have to concentrate on the binary only. |
|
I'm suspecting that my real problem is with my netatalk configuration. When I originally setup this PiSCSI I was using I didn't note your comment about compiling with the Again, with I took I performed a number of different iterations of tests & attached the logs in a tarball. I ran my tests by running the
atalkd mis-configured for 'wlan0'
atalkd reconfigured to use
|
|
@benjamink Please note that if there is an issue with your setup and not with the binaries there is no need for logs, and I cannot help you I am afraid. I don't use a Mac. The logs usually only help if there is a bug in the piscsi code. @rdmark Maybe you can assist with any setup issue? |
|
@uweseimet Understood. I included all of the above moreso because I found it interesting the |
|
Benjamin, didn’t you say that web browsing doesn’t work either when we talked about this initially?
Let’s take netatalk out of the equation for now and reconfirm that DaynaPort…
- TCP/IP networking functions (can you talk to the internet?)
- AppleTalk networking functions (can your two Macs talk to each other)
For the latter, you can turn on personal file sharing on one of the Macs and have the other Mac connect to it, for instance.
For the former, try to just load a web page in a browser.
Let’s start with this to get a baseline assessment of your situation.
…On Mon, Nov 6, 2023 at 10:50 PM, Benjamin Krein ***@***.***(mailto:On Mon, Nov 6, 2023 at 10:50 PM, Benjamin Krein <<a href=)> wrote:
***@***.***(https://github.com/uweseimet) Understood. I included all of the above moreso because I found it interesting the v23.04.01 seems to tolerate whatever my netatalk config issues are just fine but v23.10.01 does not. I'm not sure why that makes a difference but there is definitely something different about the two versions related to this.
—
Reply to this email directly, [view it on GitHub](#1306 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAQCYM47O672OAUSPDN5OZ3YDDTKLAVCNFSM6AAAAAA65TCZ42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJUHA3DSMRUGE).
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
@rdmark I have access to the Internet when I run the Works ( Does not work ( All I've changed is the |
|
Internet continues to work even after doing the following: Mac running the whole time booted into System 7.5.3
|
|
@benjamink Please provide separate logs for each piscsi binary. It is important that the logs are as short as possible and that logging is only enabled for ID 6. Limit the number of daynaport accesses to a minimum, so that the logs are as short as possible. Your previous logs show that you tried to create two daynaport devices: This cannot work. |
|
@uweseimet I don't understand where that duplicate came from. I'm not seeing that when I run the I ran each binary command independently & sent the output to a separate log file each time. I ran the |
|
@benjamink I suggest that you add the two logs to this ticket. I will have a look at them and then let's see what the next steps might be. Thank you for spending your time on this. |
|
More info... I find this very odd. When I run the If I run the I am watching I'm not sure if that suggests anything but the difference seems odd to me. |
|
@uweseimet I'm happy to run whatever commands you'd like or reconfigure things however. Whatever I can do to help determine if this is a problem with the new piscsi version of it is me. I'm in no rush & I'll keep digging as well. |
|
I cannot really comment on this, but it might be helpful to have an overview on the initial setup created by both binaries. Can you please do this:
Now do the same steps including the reboot with the develop binary. Please attach the resulting outputs to this ticket. This is just to ensure that when setting up the bridge both piscsi binaries do the same. The logs should reflect that they do the same, and the ifconfig output should also reflect this. |
|
Disabled Rebooted v23.04.01 tests Ran Ran Started Ran Rebooted v23.10.01 tests Ran Ran Started Ran |
|
The pre-ifconfig logs show that the piscsi_bridge is already present before you launch piscsi manually. Where does the bridge come from? Please ensure that nothing is running that creates the bridge before you manually launch piscsi. |
|
It's being setup by the file in I'll disable that & re-run the tests. |
|
@rdmark I don't think anything else than piscsi should deal with the bridge, because piscsi sets up the bridge automatically, depending on the interface parameter settings. |
|
I shouldn't be surprised but commenting out the I've SSH'd in via |
|
Same exact process as above but with the v23.04.01 tests* v23.04.01-ps-output.txt v23.10.01 tests* v23.10.01-ps-output.txt |
|
Should I configure |
|
What does your bridge configuration look like now?
Please see this wiki page and work your way backwards. https://github.com/PiSCSI/piscsi/wiki/Dayna-Port-SCSI-Link#manual-setup
https://github.com/PiSCSI/piscsi/wiki/Dayna-Port-SCSI-Link#manual-setupIn particular, the state of these two files:
/etc/network/interfaces.d/piscsi_bridge
/etc/dhcpcd.conf
…On Tue, Nov 7, 2023 at 9:41 AM, Benjamin Krein ***@***.***(mailto:On Tue, Nov 7, 2023 at 9:41 AM, Benjamin Krein <<a href=)> wrote:
Should I configure eth0 to get an IP address as a normal interface but leave the piscsi_bridge script commented out so that only the piscsi binary creates the bridge?
—
Reply to this email directly, [view it on GitHub](#1306 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAQCYM5MLJCEONF3EVTBWRTYDF7SNAVCNFSM6AAAAAA65TCZ42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJXGA4DSNJUHA).
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
I can’t test right now, but if I’m not mistaken piscsi_bridge is started by interfaces.d independently from piscsi… required since we configure `denyinterfaces` for the bridged interface.
…On Tue, Nov 7, 2023 at 9:28 AM, Uwe Seimet ***@***.***(mailto:On Tue, Nov 7, 2023 at 9:28 AM, Uwe Seimet <<a href=)> wrote:
***@***.***(https://github.com/rdmark) I don't think anything else than piscsi should deal with the bridge, because piscsi sets up the bridge automatically, depending on the interface parameter settings.
—
Reply to this email directly, [view it on GitHub](#1306 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAQCYM7IBBWTTHA7GLWPMTDYDF6B5AVCNFSM6AAAAAA65TCZ42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJXGA3TSMJUGQ).
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
@rdmark I went through that page & confirmed the original setup was correct. I've also disabled
Rebooted & At the top of the logs when running Without the |
|
@benjamink In the last set of logs the 23.04.01 post-ifconfig is missing. Can you please add it? No need for the ps output, by the way. @rdmark Would you agree (please double-check) that the commands for setting up the bridge (the log items starting with ">" in the develop logfile) are identical in both logs? These items reflect the respective command line actions (this is why there is a leading ">") executed programmatically by piscsi. |
|
@benjamink Besides adding the missing logfile (see my previous comment), please also run this test:
This way we have the develop piscsi set up the bridge and have the 23.04.01piscsi use it. |
|
@rdmark I just noticed that the template for new issues does not indicate to add the Raspberry Pi os version, e.g. bullseye or bookworm. Can you please add this? |
|
@uweseimet |
|
@benjamink Thanks. The next change set is available :). |
|
@uweseimet is there any benefit to me doing |
|
@benjamink No, there is no benefit, unless there are compile-time errors. With the latest change set instead of "make piscsi" it is sufficient to run "make". Only the piscsi binary will be compiled. |
|
@uweseimet |
|
@benjamink OK. There is a new change set, please test. |
|
@benjamink I think I just found somethingt that is wrong. I suggest you stop your current test, update your source, and then re-test. |
|
Ok, I already had the last commit built & ready so I tested it anyhow, commit |
|
@benjamink Thank you. After testing with the latest sources, if it still fails, this time please attach a logfile created with trace:6. It is sufficient if the logs contains some of the initial data when the Mac tries to acces the network, i.e. just limit its size to something reasonable. |
|
commit |
|
@benjamink The next change set is available. |
|
commit |
|
@benjamink OK. The next change set is already available. Please test. |
|
commit |
|
@benjamink OK. I just pushed the next set of changes. |
|
@benjamink Again I think I have just found something suspicous. Please update once again before testing. |
|
commit I tried to cut out a bunch of the log where it was sitting waiting for the mount to fail at boot. There's a bunch of lines up into it hanging trying to mount the AFP share then remove some lines off the end after it started the desktop. Let me know if you want the complete log file instead. piscsi-testing-daynaport-branch.log.gz NOTE: I rebooted between EVERY build/run including this one. |
|
@benjamink No need for a log. I'm quite sure I found what was wrong. Just pushed a new change set, which I guess will work again. Please test. |
|
SUCCESS! commit |
|
@benjamink Great! The bug was caused by a condition that was inverted with "!", but should not have been. After stumbling upon this when reviewing the code I also found proof of that in the logs. This gets easier when you know what you have to look for ;-). |
|
@uweseimet confirmed the |
|
@benjamink Very good news! Thank you for spending your time on this! Without your help it would have been impossible to find out what's wrong. I will create the final PR soon, and once it has been merged the develop branch should be fine. |
|
Very happy to help! Do you want me to go ahead & do an |
|
@benjamink No, it wouldn't. The changes only affect the C++ code which you have already tested. Everything else remains unchanged. |
Info
Raspberry Pi 4
developbranch (built 2023-11-04 @ ~12pm UTC)Current
Macintosh Performa 475 w/ System 7.5.3
Describe the issue
Raspberry Pi connected via wired ethernet (
eth0) but wireless interface (wlan0) is also active & gets an IP from DHCP.PiSCSI is configured to bridge
eth0:Netatalk appears to be configured properly.
/etc/netatalk/atalkd.conf(tried in both configurations):/etc/netatalk/afpd.conf:Dyanaport networking was working on the Performa prior to rebuilding PiSCSI today but it hasn't been used for a couple months. Only new change is the domain used for my LAN but this is provided by DHCP as expected.
I'll provide additional details including screenshots later when I'm able to get back on the Macintosh.
The text was updated successfully, but these errors were encountered: