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
533 stars 82 forks source link

DaynaPort w/ DHCP is broken on Mac OS #987

Closed rdmark closed 1 year ago

rdmark commented 1 year ago

In the latest develop:

The Mac OS Open Transport network layer is no longer able to get an IP address from DHCP with the emulated DaynaPort adapter. This used to work not too long ago. Tested in my Power Mac 8600 / Classic II environments.

When using manually assigned IPs it works (requires NAT setup, since my router doesn't allow manual IPs).

rdmark commented 1 year ago

@uweseimet Does DaynaPort + DHCP work in your Atari environment?

uweseimet commented 1 year ago

@rdmark I don't have a working Daynaport networking environment for my Atari. The setup with a Daynaport is complicated, and I did not even get it working with my regular VME network card. The latter works for Linux-68k and Atari's SVR4, though, but these have no Daynaport support. As mentioned some time ago, my Mac networking environment is not reliable. Anyway, can you recommend Mac software I can use to reproduce your issue, hopefully with a minor effort? 22.10.01 works for you? Any idea since which commit you are observing issues? Except for formal changes (using accessor method instead of directly accessing fields) there were not many changes in the Daynaport code. I guess there is a typo somewhere. It's strange, though, that only DHCP would be affected, because the Daynaport code only reads and writes data, but does not know anything about the nature of the data it is dealing with.

rdmark commented 1 year ago

@uweseimet Yes I thought it was odd too. That's why I spent half the day yesterday trying everything I could think of, with various Macs. It could still be something broken with my home network environment, which is why I was hoping someone else could cross check in their environments.

I have a long work day ahead of me today but I'll see if can take the time to do some binary search for the breaking point.

As for your Mac environment, can you please remind me what Mac model that you have and which version of Mac OS it's running? It has to be 68030 or better to use the Open Transport network stack, which is required for DHCP.

uweseimet commented 1 year ago

My Mac is a Performa630 with almost (but not quite) the latest MacOS for this machine. So the processor should not be an issue. I cannot check the OS version right now because some of the cables I need are currently in use for something else. Knowing whether v22.10.01 works for you would already help a lot. When I test networking with the Daynaport I run the Netscape Communicator and check whether I can access some of the potentially few pages that do not require SSL.

rdmark commented 1 year ago

I spent some time this evening trying to troubleshoot this, and I haven't found evidence that RaSCSI is to fault. It might be something wrong with my network environment. I went as far back as May 2022 and it still doesn't work, even with a fresh RPi image.

If you want to test in your environment, which would be much appreciated to get a second opinion, I suggest you make sure that Open Transport 1.3 is installed, and then use OTTool to get diagnostic info on the network interface. Some info on our wiki https://github.com/akuker/RASCSI/wiki/Dayna-Port-SCSI-Link#open-transport

uweseimet commented 1 year ago

I installed Open Transport 1.3 and OTTool, but OTTool cannot resolve any hostname. Neither with the develop branch, nor with 22.05.02, 22.02.01 or 21.10.01. 22.02.01 was tested extensively because it was the first release successfully working with an Atari, also see https://github.com/akuker/RASCSI/issues/619 and https://github.com/akuker/RASCSI/pull/665. With Netscape I noticed there are also DNS issues when I try to access a different site than the one I usually use for testing. Again it does not matter which release I use, all behave the same. Maybe Netscape has cached the IP for the URL I usually use, I have no idea. But as already mentioned, my networking setup does not seem to be reliable. When I use eth0 instead of wlan0 for the bridge my Pi freezes. I have no idea why.

uweseimet commented 1 year ago

@rdmark I assume you are using eth0 for the Daynaport bridge? I usually use wlan0, and today I tried eth0. I tried with both Raspberry Pi OS and Ubuntu, v22.05.02 and the develop branch., The Pi always freezes right after the Daynaport has been accessed for the first time, i.e. when MacOS assumes a hard disk drive and tries to read the root sector. This only happens with eth0, not with wlan0. This is the command sequence logged when setting up the bridge:

[2022-11-15 15:38:22.263] [info] Executing: operation=ATTACH, device id=6, unit=0, type=UNDEFINED, device params='file=daynaport', vendor='', product='', revision='', block size=0
[2022-11-15 15:38:22.264] [trace] Opening Tap device
[2022-11-15 15:38:22.281] [trace] Opened tap device 5
[2022-11-15 15:38:22.281] [trace] Going to open ras0
[2022-11-15 15:38:22.282] [trace] Return code from ioctl was 0
[2022-11-15 15:38:22.282] [info] rascsi_bridge is not yet available
[2022-11-15 15:38:22.282] [trace] Checking which interface is available for creating the bridge
[2022-11-15 15:38:22.282] [trace] Interface eth0 is up
[2022-11-15 15:38:22.282] [info] Creating rascsi_bridge for interface eth0
[2022-11-15 15:38:22.282] [trace] brctl addbr rascsi_bridge
[2022-11-15 15:38:22.317] [trace] brctl addif rascsi_bridge eth0
[2022-11-15 15:38:22.317] [trace] ip link set dev rascsi_bridge up
[2022-11-15 15:38:22.317] [trace] ip link set ras0 up
[2022-11-15 15:38:22.318] [trace] brctl addif rascsi_bridge ras0
[2022-11-15 15:38:22.318] [trace] Getting the MAC address
[2022-11-15 15:38:22.318] [trace] Got the MAC
[2022-11-15 15:38:22.318] [info] Tap device ras0 created
[2022-11-15 15:38:22.318] [debug] Tap interface created
[2022-11-15 15:38:22.319] [info] Attached SCDP device, ID 6, unit 0

I cannot see anything unusual. Have you ever had a similar problem?

uweseimet commented 1 year ago

@rdmark Any idea how to proceed? If this is not a new issue I cannot address it. As far as I can tell nobody active in this project is familiar with the Daynaport, i.e. one cannot do more than trying to preserve the existing functionality.

rdmark commented 1 year ago

@uweseimet Let me close this issue again until I can find hard evidence that something is broken in our code. Thanks for the help with troubleshooting.

uweseimet commented 1 year ago

@rdmark Yes, closing this ticket unitl new information is available is probably best.

I would appreciate a comment on my bridge issue, though. Can you please tell me whether you are using eth0 or wlan0? In case your rascsi bridge initialization output on trace level differs from mine above, can you add it to this ticket?

rdmark commented 1 year ago

@uweseimet Sure I will test this today. BTW one thing I've noticed, which is new, is that the action of enabling and disabling the rascsi bridge seem to trigger my router to assign a new IPv6 address record, which consistently causes my ssh sessions to time out, and Web UI to become unresponsive for a long time. I don't think this was happening with the code from several weeks ago.

Nov 19 06:20:43 rasp32 sshd[10816]: Accepted password for dmark from 10.0.0.94 port 64589 ssh2
Nov 19 06:20:43 rasp32 sshd[10816]: pam_unix(sshd:session): session opened for user dmark(uid=1001) by (uid=0)
Nov 19 06:20:43 rasp32 systemd-logind[385]: New session 62 of user dmark.
Nov 19 06:20:43 rasp32 systemd[1]: Started Session 62 of user dmark.
Nov 19 06:20:53 rasp32 avahi-daemon[354]: Withdrawing address record for 2601:602:8d00:5b50:7080:b6ff:fe0f:2774 on rascsi_bridge.
Nov 19 06:20:53 rasp32 avahi-daemon[354]: Leaving mDNS multicast group on interface rascsi_bridge.IPv6 with address 2601:602:8d00:5b50:7080:b6ff:fe0f:2774.
Nov 19 06:20:53 rasp32 avahi-daemon[354]: Joining mDNS multicast group on interface rascsi_bridge.IPv6 with address 2601:602:8d00:5b50:84c:cbff:fea8:5c06.
Nov 19 06:20:56 rasp32 RASCSI[671]: [2022-11-19 06:20:56.435] [debug] brctl delif rascsi_bridge ras0
Nov 19 06:20:56 rasp32 kernel: device ras0 left promiscuous mode
Nov 19 06:20:56 rasp32 kernel: rascsi_bridge: port 2(ras0) entered disabled state
Nov 19 06:20:56 rasp32 avahi-daemon[354]: Interface ras0.IPv6 no longer relevant for mDNS.
Nov 19 06:20:56 rasp32 avahi-daemon[354]: Leaving mDNS multicast group on interface ras0.IPv6 with address fe80::84c:cbff:fea8:5c06.
Nov 19 06:20:56 rasp32 avahi-daemon[354]: Withdrawing address record for fe80::84c:cbff:fea8:5c06 on ras0.
Nov 19 06:20:56 rasp32 RASCSI[671]: [2022-11-19 06:20:56.519] [info] Detached all devices
Nov 19 06:20:56 rasp32 dbus-daemon[356]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.346' (uid=0 pid=10841 comm="hostnamectl status --pretty ")
Nov 19 06:20:56 rasp32 systemd[1]: Starting Hostname Service...
Nov 19 06:20:57 rasp32 dbus-daemon[356]: [system] Successfully activated service 'org.freedesktop.hostname1'
Nov 19 06:20:57 rasp32 systemd[1]: Started Hostname Service.
Nov 19 06:20:59 rasp32 avahi-daemon[354]: Withdrawing address record for 2601:602:8d00:5b50:ba27:ebff:feb5:a315 on rascsi_bridge.
Nov 19 06:21:00 rasp32 avahi-daemon[354]: Registering new address record for 2601:602:8d00:5b50:ba27:ebff:feb5:a315 on rascsi_bridge.*.
Nov 19 06:21:27 rasp32 systemd[1]: systemd-hostnamed.service: Succeeded.
Nov 19 06:22:12 rasp32 RASCSI[671]: [2022-11-19 06:22:12.883] [info] Validating: operation=ATTACH, command params='locale=sv', 'token=???', device id=6, lun=0, type=SCDP, device params='interface=eth0', vendor='', product='', revision='', block size=0
Nov 19 06:22:12 rasp32 RASCSI[671]: [2022-11-19 06:22:12.890] [info] rascsi_bridge is already available
Nov 19 06:22:12 rasp32 RASCSI[671]: [2022-11-19 06:22:12.895] [info] Tap device ras0 created
Nov 19 06:22:12 rasp32 RASCSI[671]: [2022-11-19 06:22:12.896] [debug] brctl delif rascsi_bridge ras0
Nov 19 06:22:12 rasp32 kernel: rascsi_bridge: port 2(ras0) entered blocking state
Nov 19 06:22:12 rasp32 kernel: rascsi_bridge: port 2(ras0) entered disabled state
Nov 19 06:22:12 rasp32 kernel: device ras0 entered promiscuous mode
Nov 19 06:22:12 rasp32 kernel: rascsi_bridge: port 2(ras0) entered blocking state
Nov 19 06:22:12 rasp32 kernel: rascsi_bridge: port 2(ras0) entered forwarding state
Nov 19 06:22:12 rasp32 kernel: device ras0 left promiscuous mode
Nov 19 06:22:12 rasp32 kernel: rascsi_bridge: port 2(ras0) entered disabled state
Nov 19 06:22:12 rasp32 systemd-udevd[10850]: Using default interface naming scheme 'v247'.
Nov 19 06:22:12 rasp32 systemd-udevd[10850]: ras0: Failed to query device driver: No such device
Nov 19 06:22:12 rasp32 systemd-udevd[10850]: ras0: Failed to get link config: No such device
Nov 19 06:22:12 rasp32 RASCSI[671]: [2022-11-19 06:22:12.999] [info] Executing: operation=ATTACH, command params='locale=sv', 'token=???', device id=6, lun=0, type=SCDP, device params='interface=eth0', vendor='', product='', revision='', block size=0
Nov 19 06:22:13 rasp32 RASCSI[671]: [2022-11-19 06:22:13.000] [info] rascsi_bridge is already available
Nov 19 06:22:13 rasp32 RASCSI[671]: [2022-11-19 06:22:13.002] [info] Tap device ras0 created
Nov 19 06:22:13 rasp32 RASCSI[671]: [2022-11-19 06:22:13.002] [info] Attached SCDP device, ID 6, unit 0
Nov 19 06:22:13 rasp32 kernel: rascsi_bridge: port 2(ras0) entered blocking state
Nov 19 06:22:13 rasp32 kernel: rascsi_bridge: port 2(ras0) entered disabled state
Nov 19 06:22:13 rasp32 kernel: device ras0 entered promiscuous mode
Nov 19 06:22:13 rasp32 kernel: rascsi_bridge: port 2(ras0) entered blocking state
Nov 19 06:22:13 rasp32 kernel: rascsi_bridge: port 2(ras0) entered forwarding state
Nov 19 06:22:13 rasp32 dbus-daemon[356]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.348' (uid=0 pid=10865 comm="hostnamectl status --pretty ")
Nov 19 06:22:13 rasp32 systemd[1]: Starting Hostname Service...
Nov 19 06:22:13 rasp32 dbus-daemon[356]: [system] Successfully activated service 'org.freedesktop.hostname1'
Nov 19 06:22:13 rasp32 systemd[1]: Started Hostname Service.
Nov 19 06:22:14 rasp32 avahi-daemon[354]: Joining mDNS multicast group on interface ras0.IPv6 with address fe80::90b1:f7ff:fe7a:6aa2.
Nov 19 06:22:14 rasp32 avahi-daemon[354]: New relevant interface ras0.IPv6 for mDNS.
Nov 19 06:22:14 rasp32 avahi-daemon[354]: Registering new address record for fe80::90b1:f7ff:fe7a:6aa2 on ras0.*.
Nov 19 06:22:15 rasp32 avahi-daemon[354]: Registering new address record for 2601:602:8d00:5b50:90b1:f7ff:fe7a:6aa2 on rascsi_bridge.*.
uweseimet commented 1 year ago

@rdmark Your log data were created when the bridge had already been enabled. In order to compare our results the bridge should not have been enabled before. Your log shows a important detail, though, which I missed when checking my output: The dry-run ("Validating") initializes the device, which it should not. The idea is that the validation does not affect any state, so that a failed validation leaves the system completely unchanged. In this particular case, the bridge should not be created when validating, but only later when executing. This is an unintended difference compared to 21.10.01 in the develop branch. I am going to create a PR to change that, the respective branch is fix_dry_run.

rdmark commented 1 year ago

@uweseimet Interestingly, I never get the rascsi_bridge is not yet available message. For me, it goes directly to rascsi_bridge is already available. And this is on a fresh boot of the system, without having run rascsi before during the session. I'm using the rascsi code from fix_dry_run.

$ sudo ./bin/fullspec/rascsi -ID6 -t scdp daynaport -L trace:6 |tee log.txt
SCSI Target Emulator RaSCSI Reloaded version 22.11 --DEVELOPMENT BUILD--  (Nov 20 2022 13:54:30)
Powered by XM6 TypeG Technology / Copyright (C) 2016-2020 GIMONS
Copyright (C) 2020-2022 Contributors to the RaSCSI Reloaded project
Connect type: FULLSPEC
[2022-11-20 14:35:24.092] [info] Set log level for device ID 6 to 'trace'
[2022-11-20 14:35:24.109] [info] Validating: operation=ATTACH, device id=6, lun=0, type=SCDP, device params='file=daynaport', vendor='', product='', revision='', block size=0
[2022-11-20 14:35:24.111] [info] Executing: operation=ATTACH, device id=6, lun=0, type=SCDP, device params='file=daynaport', vendor='', product='', revision='', block size=0
[2022-11-20 14:35:24.111] [trace] Opening tap device
[2022-11-20 14:35:24.143] [trace] Opened tap device 5
[2022-11-20 14:35:24.143] [trace] Going to open ras0
[2022-11-20 14:35:24.144] [trace] Return code from ioctl was 0
[2022-11-20 14:35:24.145] [info] rascsi_bridge is already available
[2022-11-20 14:35:24.145] [trace] ip link set ras0 up
[2022-11-20 14:35:24.145] [trace] brctl addif rascsi_bridge ras0
[2022-11-20 14:35:24.147] [trace] Getting the MAC address
[2022-11-20 14:35:24.147] [trace] Got the MAC
[2022-11-20 14:35:24.147] [info] Tap device ras0 created
[2022-11-20 14:35:24.147] [info] Attached SCDP device, ID 6, unit 0
[2022-11-20 14:35:24.148] [info] +----+-----+------+-------------------------------------
[2022-11-20 14:35:24.148] [info] | ID | LUN | TYPE | IMAGE FILE
[2022-11-20 14:35:24.148] [info] +----+-----+------+-------------------------------------
[2022-11-20 14:35:24.148] [info] |  6 |   0 | SCDP | DaynaPort SCSI/Link
[2022-11-20 14:35:24.148] [info] +----+-----+------+-------------------------------------
+----+-----+------+-------------------------------------
| ID | LUN | TYPE | IMAGE FILE
+----+-----+------+-------------------------------------
|  6 |   0 | SCDP | DaynaPort SCSI/Link
+----+-----+------+-------------------------------------
[2022-11-20 14:36:12.793] [trace] (ID 6) - ++++ Starting processing for initiator ID 7
[2022-11-20 14:36:12.793] [trace] (ID 6) - Selection phase
[2022-11-20 14:36:12.793] [trace] (ID 6) - Message Out phase
[2022-11-20 14:36:12.793] [trace] (ID 6) - Receiving data, transfer length: 1 byte(s)
[2022-11-20 14:36:12.793] [trace] (ID 6) - Phase: msgout
[2022-11-20 14:36:12.793] [trace] (ID 6) - Received IDENTIFY message for LUN 0
[2022-11-20 14:36:12.793] [trace] (ID 6) - Command phase
[2022-11-20 14:36:12.793] [debug] (ID 6) - Controller is executing Read6/GetMessage10, CDB $080000000100
[2022-11-20 14:36:12.793] [debug] (ID:LUN 6:0) - Device is executing Read6/GetMessage10 ($08)
[2022-11-20 14:36:12.794] [trace] (ID:LUN 6:0) - Control value: 0
[2022-11-20 14:36:12.794] [debug] (ID 6) - Error status: Sense Key $5, ASC $24
[2022-11-20 14:36:12.794] [trace] (ID 6) - Error (to status phase)
[2022-11-20 14:36:12.794] [trace] (ID 6) - Status Phase, status is $02
[2022-11-20 14:36:12.794] [trace] (ID 6) - Sending data, offset: 0, length: 1
[2022-11-20 14:36:12.794] [trace] (ID 6) - Moving to next phase: status
[2022-11-20 14:36:12.794] [trace] (ID 6) - Message In phase
[2022-11-20 14:36:12.794] [trace] (ID 6) - Sending data, offset: 0, length: 1
[2022-11-20 14:36:12.794] [trace] (ID 6) - Moving to next phase: msgin
[2022-11-20 14:36:12.794] [trace] (ID 6) - Bus free phase
[2022-11-20 14:36:12.794] [trace] (ID 6) - ++++ Starting processing for initiator ID 7
[2022-11-20 14:36:12.795] [trace] (ID 6) - Selection phase
[2022-11-20 14:36:12.795] [trace] (ID 6) - Message Out phase
[2022-11-20 14:36:12.795] [trace] (ID 6) - Receiving data, transfer length: 1 byte(s)
[2022-11-20 14:36:12.795] [trace] (ID 6) - Phase: msgout
[2022-11-20 14:36:12.795] [trace] (ID 6) - Received IDENTIFY message for LUN 0
[2022-11-20 14:36:12.795] [trace] (ID 6) - Command phase
[2022-11-20 14:36:12.795] [debug] (ID 6) - Controller is executing Read6/GetMessage10, CDB $080000000100
[2022-11-20 14:36:12.795] [debug] (ID:LUN 6:0) - Device is executing Read6/GetMessage10 ($08)
[2022-11-20 14:36:12.795] [trace] (ID:LUN 6:0) - Control value: 0
[2022-11-20 14:36:12.795] [debug] (ID 6) - Error status: Sense Key $5, ASC $24
[2022-11-20 14:36:12.795] [trace] (ID 6) - Error (to status phase)
[2022-11-20 14:36:12.795] [trace] (ID 6) - Status Phase, status is $02
[2022-11-20 14:36:12.795] [trace] (ID 6) - Sending data, offset: 0, length: 1
[2022-11-20 14:36:12.795] [trace] (ID 6) - Moving to next phase: status
[2022-11-20 14:36:12.795] [trace] (ID 6) - Message In phase
[2022-11-20 14:36:12.795] [trace] (ID 6) - Sending data, offset: 0, length: 1
[2022-11-20 14:36:12.795] [trace] (ID 6) - Moving to next phase: msgin
[2022-11-20 14:36:12.795] [trace] (ID 6) - Bus free phase
rdmark commented 1 year ago

Full log from the session:

  1. Reboot system
  2. Launch rascsi
  3. Boot Macintosh
  4. Try to resolve DNS with OTTool
  5. Shut down Macintosh

log.txt

uweseimet commented 1 year ago

@rdmark Can you please also add the output of "ifconfig -a", right after a reboot without any changes to the network configuration?

rdmark commented 1 year ago

@uweseimet 

 $ ifconfig -a
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:9f:37:e1:5d  txqueuelen 0  (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

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether b8:27:eb:b5:a3:15  txqueuelen 1000  (Ethernet)
        RX packets 21857  bytes 5786253 (5.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 301  bytes 46477 (45.3 KiB)
        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 25637  bytes 2411294 (2.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 25637  bytes 2411294 (2.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ras0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::6071:40ff:fed1:c8aa  prefixlen 64  scopeid 0x20<link>
        ether 62:71:40:d1:c8:aa  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 19571 overruns 0  carrier 0  collisions 0

rascsi_bridge: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.241  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 2601:602:8d00:5b50:6071:40ff:fed1:c8aa  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::ba27:ebff:feb5:a315  prefixlen 64  scopeid 0x20<link>
        ether 62:71:40:d1:c8:aa  txqueuelen 1000  (Ethernet)
        RX packets 2524  bytes 344337 (336.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 301  bytes 43453 (42.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
rdmark commented 1 year ago

@uweseimet BTW just to confirm: did you add the denyinterfaces eth0 line to /etc/dhcpcd.conf ?

uweseimet commented 1 year ago

@rdmark No, I didn't. Do I have to? (I never did that in the past.)

Regarding your ifconfig output: It's clear now why our output when lauching rascsi differs: You are launching rascsi (or something that creates the bridge, a systemd service) when booting, but I usually don't. This is why I have a "clean" setup when I launch rascsi manually, but yours has already been modified.

rdmark commented 1 year ago

@uweseimet I don't know the technical reasons for the denyinterfaces configuration. This part was implemented and documented before I got involved with the project. https://github.com/akuker/RASCSI/wiki/Dayna-Port-SCSI-Link#wired-raspberry-pi-setup

Anyhow, you're right I forgot to disable the systemd services before giving you the ifconfig output. (I disabled them for the other testing yesterday.)

Here is the proper output for when rascsi has not been launched after a fresh boot. The ras0 interface hasn't been created.

 $ ps aux|grep rascsi
root       553  0.0  0.5  33700  4936 ?        Ssl  10:49   0:00 /sbin/dhclient -4 -v -i -pf /run/dhclient.rascsi_bridge.pid -lf /var/lib/dhcp/dhclient.rascsi_bridge.leases -I -df /var/lib/dhcp/dhclient6.rascsi_bridge.leases rascsi_bridge
dmark      965  0.0  0.0   7452   520 pts/0    S+   10:58   0:00 grep --color=auto rascsi
$ ifconfig -a
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:5c:4d:f7:c1  txqueuelen 0  (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

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether b8:27:eb:b5:a3:15  txqueuelen 1000  (Ethernet)
        RX packets 11777  bytes 3065104 (2.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 254  bytes 37094 (36.2 KiB)
        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 77  bytes 6984 (6.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 77  bytes 6984 (6.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

rascsi_bridge: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.241  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 fe80::ba27:ebff:feb5:a315  prefixlen 64  scopeid 0x20<link>
        inet6 2601:602:8d00:5b50:ba27:ebff:feb5:a315  prefixlen 64  scopeid 0x0<global>
        ether b8:27:eb:b5:a3:15  txqueuelen 1000  (Ethernet)
        RX packets 1273  bytes 210091 (205.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 254  bytes 34498 (33.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
uweseimet commented 1 year ago

@rdmark But there is a rascsi_bridge item, i.e. something must have been run during startup and created the bridge. Anyway, that's fine, I was just surprised that your log output looks different than mine, but that's just because your setup creates additional interfaces during startup and my setup does not.

rdmark commented 1 year ago

@uweseimet Did you put the rascsi_bridge config file in /etc/network/interfaces.d/ ? My assumption is that dhclient creates the rascsi_bridge interface on boot (but it could be a different process too).

uweseimet commented 1 year ago

@rdmark No, I did not change my standard Pi networking setup at all. rascsi creates the bridge automatically if it is not yet available, so I don't see any need to modify the default system configuration.

rdmark commented 1 year ago

@uweseimet The fact that rascsi creates the bridge dynamically has completely passed me by. Let me try this in my environment and see if I get different behavior.

uweseimet commented 1 year ago

@rdmark Well, we discussed this long ago: The commands executed by your initial scripts that created the bridge were integrated into rascsi. rascsi logs all the commands it executes in order to set up the bridge.

rdmark commented 1 year ago

@uweseimet That rings a bell. I'm not good at remembering all our interactions. ;)

BTW, to rule out my ISP's router as the root cause, I tried hooking the RPi through a different router and use its DHCP server instead. Unfortunately, still the same behavior. The computer using the emulated DaynaPort interface still doesn't get an IP assigned by the DHCP server, and even when assigning a manual IP there's no route to any external IP. I'm at a loss to what the issue may be.

rdmark commented 1 year ago

@uweseimet So I spent some time testing this today, and I think both system configuration modifications are still required to have a system that boots headless into a running rascsi systemd service:

Without the dhcpcd.conf modification, the RPi can't get a network route to other machines when rascsi brings up the rascsi_bridge interface.

And if you have the dhcpcd.conf modification but no rascsi_bridge config file in /etc/network/interfaces.d then rascsi will fail to to initialize the SCDP device.

Maybe there's a way to bypass the latter SCDP initialization error? Doesn't it like that dhcpcd is blocking the eth0 interface, and fail to create the ras0 interface?

uweseimet commented 1 year ago

@rdmark I cannot really comment, because I'm not very familiar with networking setups.

Anything that you can configure can also be automatically executed by rascsi when the bridge is created. This was the initial idea, and it was successfully tested more than a year ago, wasn't it? In case something is missing in the commands executed by rascsi (all these commands are logged on trace level) it should be added. Currently we have:

brctl addbr rascsi_bridge
brctl addif rascsi_bridge eth0
ip link set dev rascsi_bridge up
ip link set ras0 up
brctl addif rascsi_bridge ras0

This (as once tested) should result in the same setup as the one created by your scripts.

I'm not sure which error you are referring to. In my logs there was no error message, and it is not an error if the bridge is already available. It will be anyway if rascsi is restarted, this is why rascsi does not try to create a bridge if it already exists. From my pespective the main question is: Are the commands executed by rascsi correct or is something wrong or missing? I am almost 100% sure that these commands have never changed since I added them and since they were tested. The effect of each command (if sequentially executed manually on the command line) can be verified with ifconfig. In case the bridge has already been set up before rascsi is started rascsi does not/should not modify it because there is no need for any action.