piscsi: DaynaPort networking no longer working after latest build of 'develop'

Info

  • Which version of Pi are you using:

Raspberry Pi 4

  • Which github revision of software:

develop branch (built 2023-11-04 @ ~12pm UTC)

  • Which board version:

Current

  • Which computer is the PiSCSI connected to:

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:

root@piscsi-perf475:~# ip addr
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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master piscsi_bridge state UP group default qlen 1000
    link/ether dc:a6:32:1f:8c:8b brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether dc:a6:32:1f:8c:8c brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.11/16 brd 192.168.255.255 scope global dynamic noprefixroute wlan0
       valid_lft 6257sec preferred_lft 5357sec
    inet6 fe80::3bfe:ab:8ed7:3cbc/64 scope link
       valid_lft forever preferred_lft forever
4: piscsi_bridge: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 7e:47:31:f0:27:b0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.14/16 brd 192.168.255.255 scope global dynamic piscsi_bridge
       valid_lft 6233sec preferred_lft 6233sec
    inet6 fe80::dea6:32ff:fe1f:8c8b/64 scope link
       valid_lft forever preferred_lft forever
6: piscsi0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master piscsi_bridge state DOWN group default qlen 1000
    link/ether 7e:47:31:f0:27:b0 brd ff:ff:ff:ff:ff:ff

Netatalk appears to be configured properly.

/etc/netatalk/atalkd.conf (tried in both configurations):

piscsi_bridge -phase 2 -net 0-65534 -addr 65280.76
eth0 -phase 2 -net 0-65534 -addr 65280.76
root@piscsi-perf475:~# systemctl status atalkd
● atalkd.service - Netatalk AppleTalk daemon
     Loaded: loaded (/lib/systemd/system/atalkd.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2023-11-04 11:57:17 GMT; 2h 1min ago
      Tasks: 1 (limit: 472)
        CPU: 105ms
     CGroup: /system.slice/atalkd.service
             └─1728 /usr/local/sbin/atalkd

Nov 04 11:56:45 piscsi-perf475 systemd[1]: Starting Netatalk AppleTalk daemon...
Nov 04 11:56:45 piscsi-perf475 atalkd[1728]: Set syslog logging to level: LOG_DEBUG
Nov 04 11:56:45 piscsi-perf475 atalkd[1728]: restart (2.230302)
Nov 04 11:56:46 piscsi-perf475 atalkd[1728]: zip_getnetinfo for piscsi_bridge
Nov 04 11:56:56 piscsi-perf475 atalkd[1728]: zip_getnetinfo for piscsi_bridge
Nov 04 11:57:06 piscsi-perf475 atalkd[1728]: zip_getnetinfo for piscsi_bridge
Nov 04 11:57:16 piscsi-perf475 atalkd[1728]: config for no router
Nov 04 11:57:17 piscsi-perf475 atalkd[1728]: ready 0/0/0
Nov 04 11:57:17 piscsi-perf475 systemd[1]: Started Netatalk AppleTalk daemon.

/etc/netatalk/afpd.conf:

- -transall -uamlist uams_guest.so,uams_clrtxt.so,uams_dhx2.so -icon -setuplog "default log_maxdebug /var/log/afpd.log"
root@piscsi-perf475:~# systemctl status afpd
● afpd.service - Netatalk AFP fileserver for Macintosh clients
     Loaded: loaded (/lib/systemd/system/afpd.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2023-11-04 11:57:22 GMT; 2h 2min ago
      Tasks: 2 (limit: 472)
        CPU: 450ms
     CGroup: /system.slice/afpd.service
             └─1761 /usr/local/sbin/afpd -c 20

Nov 04 11:57:22 piscsi-perf475 systemd[1]: Starting Netatalk AFP fileserver for Macintosh clients...
Nov 04 11:57:22 piscsi-perf475 systemd[1]: Started Netatalk AFP fileserver for Macintosh clients.
Nov 04 11:57:22 piscsi-perf475 afpd[1761]: Set syslog logging to level: LOG_INFO

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.

About this issue

  • Original URL
  • State: closed
  • Created 8 months ago
  • Comments: 99 (50 by maintainers)

Commits related to this issue

Most upvoted comments

@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 😉. I have already prepared a branch “issue_1306”, to be applied to the develop branch in order to fix this issue. Before creating a PR I would like to ask you for testing the issue_1306 branch. Please check it out, and this time run a “make clean” before building.

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

@benjamink Again I think I have just found something suspicous. Please update once again before testing.

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

@benjamink I Just fixed this, please try again For the latest change set it was required to switch to C+±20 (just like in develop), but the Banana Pi code does not compie with this C++ level. I fixed these issues for non-optimized buids, but with optimization it still did not work.

@rdmark By the way, we might be able to get rid of all this platform dependent system timer code, also for the Raspberry Pi. testing_issue_1295 currently does not need it.

@benjamink That error has to do with bananapi support, which was removed two weeks ago. You can look at https://github.com/PiSCSI/piscsi/commit/43088ab3bcfef07ea891437755a82a1e41c7a0e4 and comment out irrelevant code locally to get it building again (or wait for Uwe to do the same)

@benjamink OK. I just committed the next set of changes to testing_daynaport. Please update and test again.

@benjamink The first set of changes in testing_daynaport is available. Reminder: After you have tested this branch I only need to know whether it crashed, and if not whether networking with your Mac is still working. When providing your results please always also mention the last commit ID so that we know exactly the codebase that was tested.

@benjamink Isn’t it supposed to be very healthy to climb stairs? 😉

@benjamink Thank you! Regarding testing_daynaport we have a good point to start the step-by-step-change approach. I am going to get back to you when I have changes for this branch.

@benjamink Please update your testing_daynaport branch, recompile with ‘make piscsi’ (no ‘make clean’ required) and re-try. If there is no crash, please provide the logfile after accessing the network with your Mac.