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

DaynaPort networking no longer working after latest build of 'develop' #1306

Closed benjamink closed 1 year ago

benjamink commented 1 year ago

Info

Raspberry Pi 4

develop branch (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:

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.

uweseimet commented 1 year ago

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

benjamink commented 1 year ago

@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 easyinstall.sh?

I don't have specific logs for each version. I have a huge piscsi.log that goes back to August though so it includes logs from when things were working but not specific logs like you're asking for. I'm going to revert to v23.04.01 & see if I can get networking working again. Possibly with a bare-bones disk image & then re-build with current develop to see if it breaks again. If things are still broken when I go back to v23.04.01 then we know it's my setup & I'll need to get that working first.

I'll capture logs from both versions when I have things all setup.

uweseimet commented 1 year ago

@benjamink In the cpp folder run these commands to compile with debug information:

DEBUG=1
make clean; make piscsi

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. Please also see the build notes on https://github.com/PiSCSI/piscsi/wiki/Setup-Instructions. And please remember to configure logging to only log anything (on trace level) for the daynaport device.

benjamink commented 1 year ago

I was able to revert back to v23.04.01 & things worked again. I did have to force an old version of the Werkzeug library (due to the older version of Flask) & rebuild the web-ui but that should be unrelated to anything I think. I did this by adding the following to python/web/requirements.txt, deleting the venv & running sudo ./start.sh to rebuild the venv: 

Werkzeug==2.3.7

Attaching screenshot & relevant logs/configs from test run:

image

20231105-issue-1306.tar.gz

I'm re-compiling current develop now & will test that later when I have time.

uweseimet commented 1 year ago

@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. Please ensure that you build both binaries with debug code enabled, i.e. set DEBUG to 1 before compiling. Then ensure that before re-building with "make" you have "make clean". Just to be 100% sure, please verify than the "-g" option is displayed as part of the compiler invocations.

benjamink commented 1 year ago

I'm suspecting that my real problem is with my netatalk configuration. When I originally setup this PiSCSI I was using wlan0 but have since moved the PiSCSI externally & am using eth0. However it appears that regardless of my configurations AFP shares are only working over wlan0 still.

I didn't note your comment about compiling with the -g option until just now. I can do that & re-run my tests later if you'd like. DEBUG should be enabled in the builds I used below, however.

Again, with wlan0 enabled I have a networking config that looks like the following: 

$ 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 7199sec preferred_lft 6299sec
    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 dc:a6:32:1f:8c:8b 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 7022sec preferred_lft 7022sec
    inet6 fe80::dea6:32ff:fe1f:8c8b/64 scope link
       valid_lft forever preferred_lft forever

I took wlan0 offline with this command & confirmed wlan0 was marked DOWN afterwards: 

sudo ifconfig wlan0 down

I performed a number of different iterations of tests & attached the logs in a tarball. I ran my tests by running the piscsi command manually with the following command line (changed as appropriate for each iteration - trace device, disk image & daynaport all remaining the same): 

sudo fullspec-v23.04.01-debug/piscsi -L trace:6 -id1 /home/pi/images/HD0-Performa-7.5.3.hda -id6 daynaport| tee piscsi-v23.04.01-fixatalkd-wlan0up.log

scsiutil shows the following output: 

$ scsictl -i 6 -c show
  6:0  SCDP  Dayna:SCSI/Link:1.4a  inet=10.10.20.1/24:interface=eth0,wlan0

atalkd mis-configured for 'wlan0'

atalkd.conf:

wlan0 -phase 2 -net 0-65534 -addr 65280.76

atalkd reconfigured to use piscsi_bridge

atalkd.conf:

piscsi_bridge -phase 2 -net 0-65534 -addr 65280.76

piscsi-testing-logs-2023-11-06.tar.gz

uweseimet commented 1 year ago

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

benjamink commented 1 year ago

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

rdmark commented 1 year ago

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…

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 < 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, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

benjamink commented 1 year ago

@rdmark I have access to the Internet when I run the v23.04.01 build but not when I run the v23.10.01 build (with nothing else changed).

Works (v23.04.01): 

sudo fullspec-v23.04.01-debug/piscsi -L trace:6 -id1 /home/pi/images/HD0-Performa-7.5.3.hda -id6 daynaport

Does not work (v23.10.01): 

sudo fullspec/piscsi -L trace:6 -id1 /home/pi/images/HD0-Performa-7.5.3.hda -id6 daynaport

All I've changed is the piscsi binary being run. I was even able to switch from v23.10.01 not working to v23.04.01 working while the Mac was on & powered up. Chooser instantly populated when I switched the piscsi binaries under the covers.

benjamink commented 1 year ago

Internet continues to work even after doing the following:

Mac running the whole time booted into System 7.5.3

  1. Stop picsci daemon (ctrl-c from foreground process)
  2. Take down wlan0 w/ ifconfig wlan0 down
  3. Start piscsi daemon again w/ the same commands in the previous comment
  4. Navigate to a random URL I haven't been to before in iCab
uweseimet commented 1 year ago

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

Nov  5 14:26:15 piscsi-perf475 PISCSI[16835]: [2023-11-05 14:26:15.406] [error] Duplicate ID 6, unit 0

This cannot work.

benjamink commented 1 year ago

@uweseimet I don't understand where that duplicate came from. I'm not seeing that when I run the v23.10.01 binary right now with this command: 

sudo fullspec/piscsi -L trace:6 -id1 /home/pi/images/HD0-Performa-7.5.3.hda -id6 daynaport | grep -i duplicate

I ran each binary command independently & sent the output to a separate log file each time. I ran the piscsi binary with the -L trace:6 (daynaport device) as you requested. It spews A LOT of output constantly so I'm not sure how to limit it without editing the log file & I wasn't sure if you'd get everything you needed if I did that.

uweseimet commented 1 year ago

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

benjamink commented 1 year ago

More info... I find this very odd. When I run the v23.04.01 binary & run nmap against what I believe is it's virtual IP(?) the nmap completes in about 10s: 

$ nmap -Pn 192.168.15.141
Starting Nmap 7.94 ( https://nmap.org ) at 2023-11-06 18:30 EST
Nmap scan report for 192.168.15.141
Host is up (0.036s latency).
All 1000 scanned ports on 192.168.15.141 are in ignored states.
Not shown: 1000 closed tcp ports (conn-refused)

Nmap done: 1 IP address (1 host up) scanned in 10.05 seconds

If I run the v23.10.01 binary with the same command & run nmap again it takes 85s: 

$ nmap -Pn 192.168.15.141
Starting Nmap 7.94 ( https://nmap.org ) at 2023-11-06 18:31 EST
Nmap scan report for 192.168.15.141
Host is up (0.000031s latency).
All 1000 scanned ports on 192.168.15.141 are in ignored states.
Not shown: 1000 filtered tcp ports (no-response)

Nmap done: 1 IP address (1 host up) scanned in 85.30 seconds

I am watching tcpdump when I run the above nmaps & confirm the nmap is runnag against piscsi: 

tcpdump -i piscsi0 tcp

I'm not sure if that suggests anything but the difference seems odd to me.

benjamink commented 1 year ago

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

uweseimet commented 1 year ago

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:

  1. Ensure that piscsi is not automatically launched on your Pi, e.g. by systemd
  2. Reboot your Pi
  3. Launch the 23.04.01 binary with ID 6 daynaport and trace enabled, but do not do anything else, do not use your Mac in order to avoid any network traffic. Just disconnect the Pi from the Mac before running these steps maybe.
  4. Now run "ifconfig -a" to get the complete network information
  5. Save the piscsi log and the ifconfig output

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. If there is anything wrong with piscsi it can either be that the bridge is not set up correctly or that the daynaport emulation is broken. These are completely different things, and from the collected output one can see which part of piscsi may be affected.

benjamink commented 1 year ago

Disabled piscsi & piscsi-web services with:

systemctl disable piscsi
systemctl disable piscsi-web

Rebooted

v23.04.01 tests

Ran ps ax before running anything else:

v23.04.01-ps-output.txt

Ran ifconfig -a before running anything else:

v23.04.01-pre-ifconfig-a.txt

Started piscsi with this command (Mac is off): 

sudo fullspec-v23.04.01-debug/piscsi -L trace:6 -id1 /home/pi/images/HD0-Performa-7.5.3.hda -id6 daynaport | tee piscsi-v23.04.01.log

piscsi-v23.04.01.log

Ran ifconfig -a again from a different terminal while piscsi was running:

v23.04.01-post-ifconfig-a.txt

Rebooted

v23.10.01 tests

Ran ps ax before running anything else:

v23.10.01-ps-output.txt

Ran ifconfig -a before running anything else:

v23.10.01-pre-ifconfig-a.txt

Started piscsi with this command (Mac is off): 

sudo fullspec/piscsi -L trace:6 -id1 /home/pi/images/HD0-Performa-7.5.3.hda -id6 daynaport | tee piscsi-v23.10.01.log

piscsi-v23.10.01.log

Ran ifconfig -a again from a different terminal while piscsi was running:

v23.10.01-post-ifconfig-a.txt

uweseimet commented 1 year ago

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. As soon as you have ensure that there is no bridge at all after a reboot, please run steps 1.-5. again for each binary.

benjamink commented 1 year ago

It's being setup by the file in /etc/network/interfaces.d/piscsi_bridge that the installer creates: 

pi@piscsi-perf475:/etc $ cat network/interfaces.d/piscsi_bridge
#
# Defines the 'piscsi_bridge' bridge that connects the PiSCSI network
# interface (ex DaynaPort SCSI/Link) to the outside world.
#
# Depending upon your system configuration, you may need to update this
# file to change 'eth0' to your Ethernet interface
#
# This file should be place in /etc/network/interfaces.d

auto piscsi_bridge
iface piscsi_bridge inet dhcp
    bridge_ports eth0

I'll disable that & re-run the tests.

uweseimet commented 1 year ago

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

benjamink commented 1 year ago

I shouldn't be surprised but commenting out the piscsi_bridge file means eth0 never gets an IP from DHCP (it's never brought up).

root@piscsi-perf475:/etc# ifconfig -a
eth0: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether dc:a6:32:1f:8c:8b  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 64  bytes 5144 (5.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 64  bytes 5144 (5.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.3.11  netmask 255.255.0.0  broadcast 192.168.255.255
        inet6 fe80::3bfe:ab:8ed7:3cbc  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:1f:8c:8c  txqueuelen 1000  (Ethernet)
        RX packets 1209  bytes 300942 (293.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 244  bytes 31841 (31.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I've SSH'd in via wlan0 & will re-run the tests.

benjamink commented 1 year ago

Same exact process as above but with the piscsi_bridge file commented out so it doesn't get setup.

**v23.04.01 tests***

v23.04.01-ps-output.txt v23.04.01-pre-ifconfig-a.txt piscsi-v23.04.01.log

**v23.10.01 tests***

v23.10.01-ps-output.txt v23.10.01-pre-ifconfig-a.txt piscsi-v23.10.01.log v23.10.01-post-ifconfig-a.txt

benjamink commented 1 year ago

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?

rdmark commented 1 year ago

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 < 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, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

rdmark commented 1 year ago

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 < 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, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

benjamink commented 1 year ago

@rdmark I went through that page & confirmed the original setup was correct. I've also disabled wlan0 completely by setting dtoverlay=disable-wifi in /boot/config.txt. I re-enabled the bridge interface & restored things back to how the wiki describes. All networking inv23.04.01 works perfectly, v23.10.01 does not at all.

/etc/network/interfaces.d/piscsi_bridge:

auto piscsi_bridge
iface piscsi_bridge inet dhcp
    bridge_ports eth0

/etc/dhcpcd.conf (at the bottom):

#interface eth0
#fallback static_eth0
denyinterfaces eth0

/etc/sysctl.conf still has forwarding commented out as expected: 

#net.ipv4.ip_forward=1

Rebooted & ifconfig -a looks like this (remember, wlan0 is disabled in the /boot/config.txt): 

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether dc:a6:32:1f:8c:8b  txqueuelen 1000  (Ethernet)
        RX packets 22833  bytes 1943809 (1.8 MiB)
        RX errors 0  dropped 34  overruns 0  frame 0
        TX packets 19917  bytes 6797434 (6.4 MiB)
        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 102  bytes 9161 (8.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 102  bytes 9161 (8.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

piscsi0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::14a2:fcff:fecb:6bc  prefixlen 64  scopeid 0x20<link>
        ether 16:a2:fc:cb:06:bc  txqueuelen 1000  (Ethernet)
        RX packets 219  bytes 18295 (17.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2266  bytes 315931 (308.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

piscsi_bridge: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.3.14  netmask 255.255.0.0  broadcast 192.168.255.255
        inet6 fe80::dea6:32ff:fe1f:8c8b  prefixlen 64  scopeid 0x20<link>
        ether 16:a2:fc:cb:06:bc  txqueuelen 1000  (Ethernet)
        RX packets 22780  bytes 1610311 (1.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 19123  bytes 6751008 (6.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

At the top of the logs when running piscsi is this: 

[2023-11-07 01:16:51.879] [info] piscsi_bridge is already available
[2023-11-07 01:16:51.882] [info] Tap device piscsi0 created

Without the /etc/network/interfaces.d/piscsi_bridge in place eth0 will not get an IP address & thus nothing can work.

uweseimet commented 1 year ago

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

uweseimet commented 1 year ago

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

uweseimet commented 1 year ago

@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? @benjamink Are you using buster or bullseye?

uweseimet commented 1 year ago

@benjamink In order to proceed faster I added a new branch "testing_daynaport". The code in this branch is identical to 22.04.01, but I will step by step apply the daynaport changes (there are hardly any, and mostly related to logging) from the develop branch there. Sooner or later the piscsi binary built with this branch should fail, and then we know what's wrong From now on please use testing_daynaport instead of 22.04.01 for testing. There is already a first set of changes available in "testing_daynaport". Can you please check out this branch and test it? I don't need any logs (yet) from this branch, just your verdict whether it works or not and the last commit ID of this branch after you checked it out/updated it.

benjamink commented 1 year ago

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

eth0: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether dc:a6:32:1f:8c:8b  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 64  bytes 5144 (5.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 64  bytes 5144 (5.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

piscsi0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::c08e:6ff:fea9:8200  prefixlen 64  scopeid 0x20<link>
        ether c2:8e:06:a9:82:00  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

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::88ca:92ff:fe56:91cc  prefixlen 64  scopeid 0x20<link>
        ether c2:8e:06:a9:82:00  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 37  bytes 6296 (6.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.3.11  netmask 255.255.0.0  broadcast 192.168.255.255
        inet6 fe80::3bfe:ab:8ed7:3cbc  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:1f:8c:8c  txqueuelen 1000  (Ethernet)
        RX packets 2504  bytes 546446 (533.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 642  bytes 100335 (97.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
uweseimet commented 1 year ago

@benjamink Thank you for the missing log. @benjamink @rdmark Do we all agree that the bridge setup created by develop and 23.04.01 is identical?

benjamink commented 1 year ago

@benjamink Besides adding the missing logfile (see my previous comment), please also run this test:

* Disconnect your Mac

* Reboot the Pi and ensure that the bridge is not set up (no need to add logfiles for this)

* Launch the develop piscsi manually and stop it again. The bridge should now be available, please verify with ifconfig. No need for attaching a log.

* Without a reboot now launch the 23.04.01 piscsi

* Please add logs of this piscsi startup sequence and with the ifconfig output after launching the 23.04.01 piscsi

* Check whether accessing the network with your Mac works. Does this work?

This way we have the develop piscsi set up the bridge and have the 23.04.01piscsi use it.

I've re-enabled wlan0 so I can access the pi when eth0 isn't getting a DHCP IP.

I've commented out the contents of the /etc/network/interfaces.d/piscsi_bridge & reverted /etc/dhcpcd.conf so it has this at the bottom (as it is originally): 

# fallback to static profile on eth0
interface eth0
fallback static_eth0
#denyinterfaces eth0

When I rebooted I confirmed the piscsi_bridge IS NOT created. Then I started the v23.10.01 binary. This time when I look at ifconfig -a I noticed thet that picsci_bridge that gets created DOES NOT have a 10.10.20.1 IP address now. I tried to be very diligent with organizing my output files above but this is different: 

eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether dc:a6:32:1f:8c:8b  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 63  bytes 5080 (4.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 63  bytes 5080 (4.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

piscsi0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::b804:4cff:fe02:877d  prefixlen 64  scopeid 0x20<link>
        ether ba:04:4c:02:87:7d  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

piscsi_bridge: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::b804:4cff:fe02:877d  prefixlen 64  scopeid 0x20<link>
        ether ba:04:4c:02:87:7d  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 23  bytes 3438 (3.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4675<UP,BROADCAST,RUNNING,ALLMULTI,MULTICAST>  mtu 1500
        inet 192.168.3.11  netmask 255.255.0.0  broadcast 192.168.255.255
        inet6 fe80::3bfe:ab:8ed7:3cbc  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:1f:8c:8c  txqueuelen 1000  (Ethernet)
        RX packets 863  bytes 182358 (178.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 262  bytes 41508 (40.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I rebooted again & this time started the v23.04.01 binary. Now the piscsi_bridge is setup WITH the 10.10.20.1 IP again: 

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::b46b:8fff:feed:a9d8  prefixlen 64  scopeid 0x20<link>
        ether ca:ce:58:ec:3e:8c  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 27  bytes 4404 (4.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Rebooted again & ran the v23.10.01 binary & confirmed again the missing 10.10.20.1 IP address: 

piscsi_bridge: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::9454:91ff:fef0:4e82  prefixlen 64  scopeid 0x20<link>
        ether 96:54:91:f0:4e:82  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 14  bytes 1772 (1.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
benjamink commented 1 year ago

@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? @benjamink Are you using buster or bullseye?

pi@piscsi-perf475:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:    11
Codename:   bullseye
benjamink commented 1 year ago

@benjamink In order to proceed faster I added a new branch "testing_daynaport". The code in this branch is identical to 22.04.01,

There is already a first set of changes available in "testing_daynaport". Can you please check out this branch and test it?

I'll build the binary from this & test again.

uweseimet commented 1 year ago

@rdmark I have to admit I don't understand the network setup part. It's important to ensure that whatever setup there is, the result after launching piscsi (develop or 23.04.01) while there is no traffic (Mac disconnected) is exactly the same. @benjamink Maybe you can add two logs each (develop and 22.04.01) with all your dhcp stuff enabled, of launching piscsi after a reboot and (with the Mac disconnected) with the ifconfig output after lauching piscsi. We definitely have to ensure that as long as the Mac is disconnected everything is identical. Otherwise we will waste a lot of time.

benjamink commented 1 year ago

I just did my last test with the testing_daynaport branch build & it does setup the 10.10.20.1 IP address on the piscsi_bridge interface when it starts.

uweseimet commented 1 year ago

@benjamin Please note that testing_daynaport is not meant to test the setup, but to test everything else. But we first definitely need to know that 23.04.01 (or testing_daynaport) and develop result in the same setup after you have enabled all your dhcp setup scripts etc. This is why I was asking for the two sets of logfiles (piscsi startup and ifconfig) showing that. (Please see my previous comment.) As soon as we know that the final setup is always the same we do not have to consider the setup being broken in develop, but may assume that the problem is related to the actual network traffic transfer.

benjamink commented 1 year ago

@benjamin Please note that testing_daynaport is not meant to test the setup, but to test everything else. But we first definitely need to know that 23.04.01 (or testing_daynaport) and develop result in the same setup after you have enabled all your dhcp setup scripts etc. This is why I was asking for the two sets of logfiles showing that. (Please see my previous comment.) As soon as we know that the final setup is always the same we do not have to consider the setup being broken in develop.

When you say "all of my dhcp stuff setup" I assume you mean re-enabling the piscsi_bridge configs & changes to /etc/dhcpcd.conf that the easyinstall.sh currently does? With the easyinstall.sh changes I get an IP address (192.168.3.14) for my LAN on the piscsi_bridge interface that bridges eth0.

I'm re-enabling those changes now & will test all 3 binaries with the log & ifconfig -a outputs as I have time today.

uweseimet commented 1 year ago

@benjamink Yes, this is what I meant. We have to ensure that with your regular setup what piscsi does when it is launched is still the same for develop and 22.04.01. No need for this test to also test testing_daynaport. Just test develop and 22.04.01.

benjamink commented 1 year ago

piscsi_bridge network script, DHCP on eth0, Mac disconnected

v23.04.01

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether dc:a6:32:1f:8c:8b  txqueuelen 1000  (Ethernet)
        RX packets 1330  bytes 206119 (201.2 KiB)
        RX errors 0  dropped 6  overruns 0  frame 0
        TX packets 373  bytes 219183 (214.0 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 64  bytes 5157 (5.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 64  bytes 5157 (5.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

piscsi0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::a800:f3ff:fe40:6b86  prefixlen 64  scopeid 0x20<link>
        ether aa:00:f3:40:6b:86  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

piscsi_bridge: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.3.14  netmask 255.255.0.0  broadcast 192.168.255.255
        inet6 fe80::dea6:32ff:fe1f:8c8b  prefixlen 64  scopeid 0x20<link>
        ether aa:00:f3:40:6b:86  txqueuelen 1000  (Ethernet)
        RX packets 1324  bytes 187223 (182.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 285  bytes 213375 (208.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4675<UP,BROADCAST,RUNNING,ALLMULTI,MULTICAST>  mtu 1500
        inet 192.168.3.11  netmask 255.255.0.0  broadcast 192.168.255.255
        inet6 fe80::3bfe:ab:8ed7:3cbc  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:1f:8c:8c  txqueuelen 1000  (Ethernet)
        RX packets 409  bytes 86964 (84.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 79  bytes 8303 (8.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Reboot

v23.10.01

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether dc:a6:32:1f:8c:8b  txqueuelen 1000  (Ethernet)
        RX packets 746  bytes 129229 (126.2 KiB)
        RX errors 0  dropped 2  overruns 0  frame 0
        TX packets 217  bytes 81354 (79.4 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 63  bytes 5093 (4.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 63  bytes 5093 (4.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

piscsi0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::c4c1:26ff:feb4:808d  prefixlen 64  scopeid 0x20<link>
        ether c6:c1:26:b4:80:8d  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

piscsi_bridge: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.3.14  netmask 255.255.0.0  broadcast 192.168.255.255
        inet6 fe80::dea6:32ff:fe1f:8c8b  prefixlen 64  scopeid 0x20<link>
        ether c6:c1:26:b4:80:8d  txqueuelen 1000  (Ethernet)
        RX packets 744  bytes 118693 (115.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 194  bytes 79836 (77.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4675<UP,BROADCAST,RUNNING,ALLMULTI,MULTICAST>  mtu 1500
        inet 192.168.3.11  netmask 255.255.0.0  broadcast 192.168.255.255
        inet6 fe80::3bfe:ab:8ed7:3cbc  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:1f:8c:8c  txqueuelen 1000  (Ethernet)
        RX packets 381  bytes 83046 (81.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 81  bytes 8304 (8.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Only difference is that the MAC addresses change for the piscsi0 & piscsi_bridge interfaces (not sure if that's expected/normal).

benjamink commented 1 year ago

Forgot the piscsi logs... here they are:

v23.04.01:

SCSI Target Emulator PiSCSI (Backend Service)
Version 23.04.01  (Nov  5 2023 17:09:40)
Powered by XM6 TypeG Technology / Copyright (C) 2016-2020 GIMONS
Copyright (C) 2020-2023 Contributors to the PiSCSI project
Connection type: FULLSPEC
[2023-11-07 12:28:07.009] [info] Set log level for device ID 6 to 'trace'
[2023-11-07 12:28:07.009] [trace] static void SBC_Version::Init()
[2023-11-07 12:28:07.009] [info] Detected device Raspberry Pi 4
[2023-11-07 12:28:07.009] [trace] static bool SBC_Version::IsBananaPi()
[2023-11-07 12:28:07.009] [trace] static bool SBC_Version::IsRaspberryPi()
[2023-11-07 12:28:07.009] [trace] Creating GPIOBUS_Raspberry
[2023-11-07 12:28:07.016] [trace] static void SysTimer::Init()
[2023-11-07 12:28:07.016] [trace] static bool SBC_Version::IsRaspberryPi()
[2023-11-07 12:28:07.016] [trace] static uint32_t SBC_Version::GetPeripheralAddress()
[2023-11-07 12:28:07.016] [trace] static uint32_t SBC_Version::GetDeviceTreeRanges(const char*, uint32_t)
[2023-11-07 12:28:07.016] [trace] static uint32_t SBC_Version::GetDeviceTreeRanges(const char*, uint32_t)
[2023-11-07 12:28:07.016] [debug] Peripheral address : 0xfe000000

[2023-11-07 12:28:07.033] [info] Validating: operation=ATTACH, device id=1, lun=0, type=UNDEFINED, device params='file=/home/pi/images/HD0-Performa-7.5.3.hda', vendor='', product='', revision='', block size=0
[2023-11-07 12:28:07.037] [info] Validating: operation=ATTACH, device id=6, lun=0, type=UNDEFINED, device params='file=daynaport', vendor='', product='', revision='', block size=0
[2023-11-07 12:28:07.037] [info] Executing: operation=ATTACH, device id=1, lun=0, type=UNDEFINED, device params='file=/home/pi/images/HD0-Performa-7.5.3.hda', vendor='', product='', revision='', block size=0
[2023-11-07 12:28:07.037] [info] Attached SCHD device, ID 1, unit 0
[2023-11-07 12:28:07.038] [info] Executing: operation=ATTACH, device id=6, lun=0, type=UNDEFINED, device params='file=daynaport', vendor='', product='', revision='', block size=0
[2023-11-07 12:28:07.038] [trace] Opening tap device
[2023-11-07 12:28:07.068] [trace] Opened tap device 5
[2023-11-07 12:28:07.068] [trace] Going to open piscsi0
[2023-11-07 12:28:07.069] [trace] Return code from ioctl was 0
[2023-11-07 12:28:07.069] [info] piscsi_bridge is already available
[2023-11-07 12:28:07.069] [trace] ip link set piscsi0 up
[2023-11-07 12:28:07.069] [trace] brctl addif piscsi_bridge piscsi0
[2023-11-07 12:28:07.072] [trace] Getting the MAC address
[2023-11-07 12:28:07.072] [trace] Got the MAC
[2023-11-07 12:28:07.072] [info] Tap device piscsi0 created
[2023-11-07 12:28:07.072] [info] Attached SCDP device, ID 6, unit 0
[2023-11-07 12:28:07.073] [info] +----+-----+------+-------------------------------------
[2023-11-07 12:28:07.073] [info] | ID | LUN | TYPE | IMAGE FILE
[2023-11-07 12:28:07.073] [info] +----+-----+------+-------------------------------------
[2023-11-07 12:28:07.073] [info] |  1 |   0 | SCHD | /home/pi/images/HD0-Performa-7.5.3.hda
[2023-11-07 12:28:07.073] [info] |  6 |   0 | SCDP | DaynaPort SCSI/Link
[2023-11-07 12:28:07.073] [info] +----+-----+------+-------------------------------------
+----+-----+------+-------------------------------------
| ID | LUN | TYPE | IMAGE FILE
+----+-----+------+-------------------------------------
|  1 |   0 | SCHD | /home/pi/images/HD0-Performa-7.5.3.hda
|  6 |   0 | SCDP | DaynaPort SCSI/Link
+----+-----+------+-------------------------------------
[2023-11-07 12:28:07.074] [trace] virtual bool GPIOBUS::PollSelectEvent()
[2023-11-07 12:28:07.074] [trace] static bool SBC_Version::IsBananaPi()

v23.10.01:

SCSI Target Emulator PiSCSI (Backend Service)
Version 23.10 --DEVELOPMENT BUILD--  (Nov  6 2023 00:27:36)
Powered by XM6 TypeG Technology / Copyright (C) 2016-2020 GIMONS
Copyright (C) 2020-2023 Contributors to the PiSCSI project
Connection type: FULLSPEC
[2023-11-07 12:31:16.403] [info] Set log level for device 6 to 'trace'
[2023-11-07 12:31:16.403] [info] Detected Raspberry Pi 4
[2023-11-07 12:31:16.412] [info] Cleared reserved ID(s)
[2023-11-07 12:31:16.418] [info] Validating: operation=ATTACH, device=1:0, type=UNDEFINED, device params='file=/home/pi/images/HD0-Performa-7.5.3.hda', vendor='', product='', revision='', block size=0
[2023-11-07 12:31:16.421] [info] Validating: operation=ATTACH, device=6:0, type=UNDEFINED, device params='file=daynaport', vendor='', product='', revision='', block size=0
[2023-11-07 12:31:16.421] [info] Executing: operation=ATTACH, device=1:0, type=UNDEFINED, device params='file=/home/pi/images/HD0-Performa-7.5.3.hda', vendor='', product='', revision='', block size=0
[2023-11-07 12:31:16.421] [info] Attached SCHD 1:0
[2023-11-07 12:31:16.421] [info] Executing: operation=ATTACH, device=6:0, type=UNDEFINED, device params='file=daynaport', vendor='', product='', revision='', block size=0
[2023-11-07 12:31:16.422] [trace] Opening tap device
[2023-11-07 12:31:16.444] [trace] Going to open piscsi0
[2023-11-07 12:31:16.445] [trace] Return code from ioctl was 0
[2023-11-07 12:31:16.445] [info] piscsi_bridge is already available
[2023-11-07 12:31:16.445] [trace] >ip link set piscsi0 up
[2023-11-07 12:31:16.446] [trace] >brctl addif piscsi_bridge piscsi0
[2023-11-07 12:31:16.447] [trace] Getting the MAC address
[2023-11-07 12:31:16.447] [info] Tap device piscsi0 created
[2023-11-07 12:31:16.447] [info] Attached SCDP 6:0
[2023-11-07 12:31:16.448] [info] +----+-----+------+-------------------------------------
[2023-11-07 12:31:16.448] [info] | ID | LUN | TYPE | IMAGE FILE
[2023-11-07 12:31:16.448] [info] +----+-----+------+-------------------------------------
[2023-11-07 12:31:16.448] [info] |  1 |   0 | SCHD | /home/pi/images/HD0-Performa-7.5.3.hda
[2023-11-07 12:31:16.448] [info] |  6 |   0 | SCDP | DaynaPort SCSI/Link
[2023-11-07 12:31:16.448] [info] +----+-----+------+-------------------------------------
+----+-----+------+-------------------------------------
| ID | LUN | TYPE | IMAGE FILE
+----+-----+------+-------------------------------------
|  1 |   0 | SCHD | /home/pi/images/HD0-Performa-7.5.3.hda
|  6 |   0 | SCDP | DaynaPort SCSI/Link
+----+-----+------+-------------------------------------
[2023-11-07 12:31:16.449] [trace] virtual bool GPIOBUS::PollSelectEvent()
uweseimet commented 1 year ago

@benjamink I don't think the mac address change is relevant. Or is it @rdmark ?

Assuming this is not relevant as far as I can tell the final setup with the Mac disconnected is the same for develop and 23.04.01. Does everybody agree? @benjamink In case we all agree, now we can concentrate on testing with the Mac connected. We know that 23.04.01 works, and the question is when (after which of my changes) testing_daynaport stops to work. No need for further ifconfig logs at this time. Please connect your Mac, install the 22.04.01 binary and provide a log with -L trace:6 with the Mac accessing the network. Try to produce as litte network traffic as possible. Next please do the same with testing_daynaport.

rdmark commented 1 year ago

@benjamink I don't think the mac address change is relevant. Or is it @rdmark ?

I don't know enough about Linux networking to say for sure. It seems unusual, since a MAC address is theoretically tied to a physical interface?

As a side note and reminder, the emulated daynaport interface has a hard coded MAC address. If you have multiple computers using piscsi daynaport on the same LAN subnet you may run into issues.

benjamink commented 1 year ago

Scenario - I have an AppleShare that is set to auto-mount at boot.

Final lines of log from testing_daynaport branch before crash: 

[2023-11-07 13:09:35.571] [trace] (ID 6) - Entering Data In phase
[2023-11-07 13:09:35.571] [trace] (ID 6) - Sending data, offset: 0, length: 6
[2023-11-07 13:09:35.571] [trace] (ID 6) - Moving to next phase: datain
[2023-11-07 13:09:35.571] [trace] (ID 6) - Status Phase, status is $00
[2023-11-07 13:09:35.571] [trace] (ID 6) - Sending data, offset: 0, length: 1
[2023-11-07 13:09:35.572] [trace] (ID 6) - Moving to next phase: status
[2023-11-07 13:09:35.572] [trace] (ID 6) - Message In phase
[2023-11-07 13:09:35.572] [trace] (ID 6) - Sending data, offset: 0, length: 1
[2023-11-07 13:09:35.572] [trace] (ID 6) - Moving to next phase: msgin
[2023-11-07 13:09:35.572] [trace] (ID 6) - Bus free phase
[2023-11-07 13:09:35.572] [trace] virtual bool GPIOBUS::PollSelectEvent()
[2023-11-07 13:09:35.572] [trace] static bool SBC_Version::IsBananaPi()
[2023-11-07 13:09:35.577] [trace] static bool SBC_Version::IsBananaPi()
[2023-11-07 13:09:35.577] [trace] (ID 6) - ++++ Starting processing for initiator ID 7
[2023-11-07 13:09:35.577] [trace] (ID 6) - Selection phase
[2023-11-07 13:09:35.577] [trace] (ID 6) - Command phase
[2023-11-07 13:09:35.577] [debug] (ID 6) - Controller is executing Read6/GetMessage10, CDB $08000005f4c0
[2023-11-07 13:09:35.577] [debug] (ID:LUN 6:0) - Device is executing Read6/GetMessage10 ($08)
[2023-11-07 13:09:35.577] [trace] (ID:LUN 6:0) - READ(6) command, record: $00000005
[2023-11-07 13:09:35.577] [trace] (ID:LUN 6:0) - Read maximum length: 244
[2023-11-07 13:09:35.577] [trace] bool CTapDriver::HasPendingPackets() const 1 revents
[2023-11-07 13:09:35.577] [debug] int CTapDriver::Receive(uint8_t*) CRC is 5C8A4D62 - 62 4D 8A 5C

[2023-11-07 13:09:35.577] [trace] (ID:LUN 6:0) - Packet Size 64, read count: 1
[2023-11-07 13:09:35.577] [trace] bool CTapDriver::HasPendingPackets() const 1 revents
[2023-11-07 13:09:35.577] [trace] (ID:LUN 6:0) - Length is 70
[2023-11-07 13:09:35.577] [trace] (ID 6) - Entering Data In phase
[2023-11-07 13:09:35.577] [trace] (ID 6) - Sending data, offset: 0, length: 70

Logs:

piscsi-testing-daynaport-branch.log piscsi-v23.04.01.log piscsi-v23.10.01.log

uweseimet commented 1 year ago

@rdmark The bridge is not a physical interface, this is why I think the address may change. At least there is nobody setting it, right?

benjamink commented 1 year ago

@benjamink I don't think the mac address change is relevant. Or is it @rdmark ?

I don't know enough about Linux networking to say for sure. It seems unusual, since a MAC address is theoretically tied to a physical interface?

As a side note and reminder, the emulated daynaport interface has a hard coded MAC address. If you have multiple computers using piscsi daynaport on the same LAN subnet you may run into issues.

It might make a difference when the piscsi0 is a virtual interface? Note that the MAC address of piscsi_bridge is the same as piscsi0 for the v23.04.01 output but different for the v23.10.01 output. Maybe that's significant?

benjamink commented 1 year ago

MAC address is the same between piscsi0 & piscsi_bridge for the testing_daynaport branch build as well (after starting piscsi).

uweseimet commented 1 year ago

@benjamink Is the mac addres with 23.04 always the same after a reboot? What I mean is, if you reboot 2 or 3 times, will the address always be the same? Same question for develop and testing_daynaport. Is the address stable when using the same binary version?