Currently s2p only logs the command block, but any parameters sent with a command are not logged. This makes it hard to analyze errors not causes by the actual command, but by the data sent with it, e.g. with a MODE SELECT.
s2p shall log data sent with non sector-related SCSI commands on trace level, in a similar format used by s2pexec when logging received data. It may be assumed that any transfer size < 256 bytes is not a sector.

When creating a new ticket please provide information on your environment.

• The Pi type:
  Zero 2 W

• The Pi OS version (output of 'lsb_release -a'):
  Distributor ID: Debian
  Description: Debian GNU/Linux 12 (bookworm)
  Release: 12
  Codename: bookworm

• The SCSI2Pi release or git revision:
  scsi2pi_1.2_devel_fb4e56b_arm64-1.deb

• The computer/sampler connected to the RaSCSI/PiSCSI board:
  N/A

Describe the issue

When trying to start s2p on a fresh installation of Raspberry PI OS 12 (bookworm) arm64 lite after installing the scsi2p .deb as documented on https://www.scsi2pi.net/en/downloads.html, starting s2p fails with the following error:

$ sudo /opt/scsi2pi/bin/s2p -id 6 daynaport
./s2p: error while loading shared libraries: libprotobuf.so.32: cannot open shared object file: No such file or directory

To fix this libprotobuf32 needs to be installed:
$ sudo apt install libprotobuf32

Afterwards s2p starts without error.

It would therefore be good if either a dependency to libprotobuf32 could be added to the .deb packages, or if it was mentioned somewhere on https://www.scsi2pi.net/en/downloads.html that this package must be installed when using a fresh install of Raspberry Pi OS.

It might also be good to mention that s2p needs to be started using sudo, since it requires root privileges. Trying to start s2p as a user with admin privileges fails because GPIO access isn't allowed.

In order to have more descriptive options in addition to the one-letter options, s2pdump shall use getopt_long() instead of getopt() for parsing command line options.
In addition, some of the options shall be changed/renamed to be more consistent.

When creating a new ticket please provide information on your environment.

• The Pi type:
  Zero 2 W

• The Pi OS version (output of 'lsb_release -a'):
  Distributor ID: Debian
  Description: Debian GNU/Linux 12 (bookworm)
  Release: 12
  Codename: bookworm

• The SCSI2Pi release or git revision:
  scsi2pi_1.2_devel_50d3589_arm64-1.deb

• The computer/sampler connected to the RaSCSI/PiSCSI board:
  N/A

Describe the issue

Here is a systemd service file to enable the automatic start of s2p during boot (adapted from the piscsi.service file):

[Unit]
Description=scsi2pi s2p service
After=network.target

[Service]
Type=simple
Restart=always
ExecStart=/opt/scsi2pi/bin/s2p -r 7
# Example 1: If you want to automatically attach a hard disk at startup, 
# say an image called harddisk.hds on SCSI ID 1, change the ExecStart line to:
#
# ExecStart=/opt/scsi2pi/bin/s2p -ID1 /home/pi/images/harddisk.hds
#
# Example 2: If you want to reserve SCSI IDs to prevent usage, add '-r' followed by
# comma-separated SCSI ID numbers; for instance IDs 0 and 7:
#
# ExecStart=/opt/scsi2pi/bin/s2p -r 0,7
#
ExecStop=/opt/scsi2pi/bin/s2pctl -X
SyslogIdentifier=scsi2pi

[Install]
WantedBy=multi-user.target

To enable it, copy the file to /etc/systemd/system/s2p.service and then run the following commands:

sudo chmod 644 /etc/systemd/system/s2p.service
sudo systemctl daemon-reload
sudo systemctl start s2p.service
sudo systemctl enable s2p.service

in_process_test shall be improved:

• Add long option support
• Add help text
• Report an error if s2p initialization fails
• Add s2pctl support including interactive mode

In case a peripheral reports an error s2pexec shall also display the ASCQ value.

When creating a new ticket please provide information on your environment.

• The Pi type:
  Zero 2 W

• The Pi OS version (output of 'lsb_release -a'):
  Distributor ID: Debian
  Description: Debian GNU/Linux 12 (bookworm)
  Release: 12
  Codename: bookworm

• The SCSI2Pi release or git revision:
  scsi2pi_1.2_devel_50d3589_arm64-1.deb

• The computer/sampler connected to the RaSCSI/PiSCSI board:
  N/A

Describe the issue

After attaching the daynaport the piscsi0 device and the piscsi bridge are automatically created:

$ ip a
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 noprefixroute 
       valid_lft forever preferred_lft forever
2: wlan0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether e4:5f:01:78:10:a2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.23/24 brd 192.168.178.255 scope global dynamic noprefixroute wlan0
       valid_lft 863902sec preferred_lft 863902sec
    inet6 2003:c9:d701:1200:470a:d09a:e629:147e/64 scope global dynamic noprefixroute 
       valid_lft 7189sec preferred_lft 3589sec
    inet6 fe80::8d9b:2326:42e9:e441/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
$ /opt/scsi2pi/bin/s2pctl -i 6 -c a -t daynaport
$ /opt/scsi2pi/bin/s2pctl -l
+----+-----+------+-------------------------------------
| ID | LUN | TYPE | IMAGE FILE
+----+-----+------+-------------------------------------
|  6 |   0 | SCDP | DaynaPort SCSI/Link
+----+-----+------+-------------------------------------
$ ip a
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 noprefixroute 
       valid_lft forever preferred_lft forever
2: wlan0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether e4:5f:01:78:10:a2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.23/24 brd 192.168.178.255 scope global dynamic noprefixroute wlan0
       valid_lft 863892sec preferred_lft 863892sec
    inet6 2003:c9:d701:1200:470a:d09a:e629:147e/64 scope global dynamic noprefixroute 
       valid_lft 7179sec preferred_lft 3579sec
    inet6 fe80::8d9b:2326:42e9:e441/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
7: piscsi0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master piscsi_bridge state UNKNOWN group default qlen 1000
    link/ether 42:56:e1:91:a2:7d brd ff:ff:ff:ff:ff:ff
    inet6 fe80::4056:e1ff:fe91:a27d/64 scope link 
       valid_lft forever preferred_lft forever
8: piscsi_bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 42:56:e1:91:a2:7d brd ff:ff:ff:ff:ff:ff
    inet 10.10.20.1/24 brd 10.10.20.255 scope global piscsi_bridge
       valid_lft forever preferred_lft forever
    inet6 fe80::78c0:dfff:fe69:3170/64 scope link 
       valid_lft forever preferred_lft forever

But when detaching the daynaport only the piscsi0 device is removed, but not the piscsi_bridge:

frank@bookworm:~ $ /opt/scsi2pi/bin/s2pctl -i 6 -c d -t daynaport
frank@bookworm:~ $ /opt/scsi2pi/bin/s2pctl -l
No devices currently attached.
frank@bookworm:~ $ ip a
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 noprefixroute 
       valid_lft forever preferred_lft forever
2: wlan0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether e4:5f:01:78:10:a2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.23/24 brd 192.168.178.255 scope global dynamic noprefixroute wlan0
       valid_lft 863864sec preferred_lft 863864sec
    inet6 2003:c9:d701:1200:470a:d09a:e629:147e/64 scope global dynamic noprefixroute 
       valid_lft 7151sec preferred_lft 3551sec
    inet6 fe80::8d9b:2326:42e9:e441/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
8: piscsi_bridge: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 10.10.20.1/24 brd 10.10.20.255 scope global piscsi_bridge
       valid_lft forever preferred_lft forever
    inet6 fe80::78c0:dfff:fe69:3170/64 scope link 
       valid_lft forever preferred_lft forever

I would expect that the bridge should be removed as well.

BTW. as I've mentioned in on bookworm brctl is not needed to remove a bridge, it can also be done directly with ip:
$ sudo /sbin/ip link delete piscsi_bridge
(it is not necessary to "down" the piscsi_bridge first)

Sometimes only a few bytes of data need be sent with a SCSI command in the DATA OUT phase. Being able to provide these data on the command line can be more convenient than passing a file with these data.
s2pexec shall provide an additional command line option "-d" that accepts these data, e.g.

>s2pexec -i 0 -c 15:10:00:00:0c:00 -d 00:00:00:08:00:00:00:00:00:00:02:00

In order to have more descriptive options in addition to the one-letter options, s2p shall use getopt_long() instead of getopt() for parsing command line options.
In addition, some of the options shall be changed/renamed to be more consistent.

Provide for types of installation binaries: bullseye 32/64 bit, bookworm 32/64 bit.

s2p shall support not just a single properties file but a comma-separated list of property files. The contents of these files shall be merged.
With this approach a more granular configuration is possible A user can, for instance, have different property files, each one for a separate device. When launching s2p the final set of devices can then be defined by providing a list of files with the properties for each device.

Currently s2pctl displays the s2p startup settings as properties with "s2pctl -P". This shall be the current settings instead. The output can then be used to conveniently to create a property file (e.g. /etc/s2p.conf) from a running s2p setup.
The scsi_level setting is ignored, because it is exotic and might result in users thinking you would usually need it.

Add mode page 37 (DEC), see https://manx-docs.org/collections/antonio/dec/dec-scsi.pdf.

Done as part of #18.

MODE SELECT is only supported for special cases of mode page 3, and only for SCHD and SCMO. In all other cases invalid_command_operation_code is reported.
In general scsi2pi cannot meaningfully support MODE SELECT because typically this would require changing a device's behavior. In order to do that, scsi2pi would at least have to persist the selected changes.
MODE SELECT is only supported for special cases of mode page 3, and only for SCHD and SCMO. In all other cases invalid_command_operation_code is reported. Reporting invalid_field_in_cdb instead of invalid_command_operation_code might at least improve the compatibility with some computers.

s2pexec shall be extended to send any SCSI/SASI command to any device. If there is a DATA IN phase the data to transfer shall be read from a file with the binary data. If there is a DATA OUT phase the device output shall be stored in a file. The hexadecimal CDB shall be passed to s2pexec as a parameter to the new "--command/-c" option. When no output file is specified the result shall be printed on the console in a human readable hexadecimal format in a similar format as the one used by 'od -x'.

In target mode the bus code for the initiator is not needed, and vice versa. It may make sense to re-organize the GpioBus and Bus classes and split them into a target and an initiator part.
With this approach the explicit target/initiator mode checks in GpioBus will become obsolete and the difference between initiator and target becomes more explicit.

When a standard mode page is replaced by a user-defined data s2p shall validate whether the size of the provided data is at least the mandatory size of the mode page. For the standardized mode pages the SCSI standard specifies this size.

There are some SCSI drives that send a DISCONNECT or SYNCHRONOUS DATA TRANSFER REQUEST message. s2pdump does not yet handle unknown messages. IT shall properly reject them. Not doing that may make s2pdump incompabile with some types of hard drives.
s2pexec also shall reject unknown messages.

This is a follow-up ticket to PiSCSI/piscsi#598, where the details are described.
The approach of this ticket is to take the last 3 bytes of the bridge interface's (piscsi_bridge) MAC address and use it for the last 3 bytes of the DaynaPort. The first 3 bytes (OUI) remain unchanged.

In cases where the controller raises a SCSI2Pi-specific error with sense key ABORTED COMMAND it is hard to locate where exactly this error occurred. A vendor-specific ASC (see SCSI specification) shall be added to these errors.

These changes are included in the commits of #18.

After re-adding SASI hard drive support this has so far only been tested with an Atari and a tweaked Atari SCSI driver version. Since the Atari usually speaks SCSI these tests only have a limited value.
Help with testing with a more realistic SASI setup is appreciated. Both the SASI hard drive emulation and the SASI support of s2pdump should be tested.

The in_process_bus test (test/in_process_bus.cpp) can only execute a single command with each test, and this command has to be provided on the command line. For s2pexec as an initiator client an interactive mode shall be added. This mode will make it more convenient to test SCSI commands without a Pi, because you can run subsequent commands against the same s2p process, and you can also run a script with command, like it is already supported for s2pctl.
A typical use case is checking the sector size of a drive with READ CAPACITY, then changing it with MODE SELECT, and then checking with another READ CAPACITY whether the size has actually been changed. https://github.com/uweseimet/scsi2pi/wiki/Advanced-Testing has more details.

For exotic platforms supporting more mode pages may improve compatibility. Add support for mode pages 2 (disconnect-reconnect), 7 (verify error recovery), 10 (control mode) and 12 (notch).

When creating a new ticket please provide information on your environment.

• The Pi type:
  Zero 2 W

• The Pi OS version (output of 'lsb_release -a'):
  Distributor ID: Debian
  Description: Debian GNU/Linux 12 (bookworm)
  Release: 12
  Codename: bookworm

• The SCSI2Pi release or git revision:
  scsi2pi_1.2_devel_a1a8ada_bookworm_arm64-1.deb

• The computer/sampler connected to the RaSCSI/PiSCSI board:
  N/A

Describe the issue

According to the man-page for s2p the default location for the image file folder should be ˜/images’:
The default folder is ’˜/images’
Since s2p is running as root the default location should therefore be /root/images.

But when checking the default settings of the running s2p process it shows /home/pi/images instead:
$ /opt/scsi2pi/bin/s2pctl -s|grep "image file folder"
Default image file folder: /home/pi/images

Since the pi user doesn't exist anymore by default on bookworm it would be better to not have /home/pi/images as the default location, but maybe use just /images instead.

Sometimes it is useful that you can dump/restore not a complete drive but just parts of it. s2pdump should support this.

As part of the INQUIRY data s2pdump shall display the SCSI level and response data format.

>s2pdump -I -i 5
----------------------------------------
Board ID is 7
----------------------------------------
Scanning target ID:LUN 5:0
Vendor:               'PLEXTOR '
Product:              'CD-ROM PX-40TS  '
Revision:             '1.11'
Device Type:          CD-ROM/DVD/BD/DVD-RAM
SCSI Level:           SCSI-2
Response Data Format: SCSI-2
Removable:            Yes

s2pexec currently supports two modes: Sending any SCSI command and sending custom SCSI2Pi SCSI commands (opcodes 0xc0 and 0xc1), using protobuf data, to the host services device.
The latter functionality shall be extracted into a separate "s2proto" tool.

In order to improve scripting support s2pexec shall return the error status of a command as exit status. The meaning of the exit status:

• 0: No error
• -1: General error, e.g. target does not exist
• Any other value: The lowest 16 bit of the exit status are the sense key (upper 8 bit) and the ASC (lower 8 bit)

Currently devices either support both MODE SENSE and MODE SELECT or none of these. This is because the ModePageDevice class does not support dealing with MODE SENSE only. This shall be changed, so that devices inheriting from this class can control whether they also support MODE SELECT.

When attaching/detaching a device an error is reported because s2p sends two protobuf responses instead of only the one with the current device list.

This bug can affect any client, in particular the SCSI Control app, which does not update its device overview after attaching a new device.

s2pctl shall support an interactive mode. This mode is entered when s2pctl is launched without parameters. In interactive mode commands can be entered on the command line. Ctrl-D exits this mode.

>s2pctl
SCSI Target Emulator and SCSI Tools SCSI2Pi (Server Controller Tool)
Version 1.2-devel
Copyright (C) 2016-2020 GIMONS
Copyright (C) 2020-2023 Contributors to the PiSCSI project
Copyright (C) 2021-2024 Uwe Seimet
Entering interactive mode, quit with Ctrl-D
s2pctl>-r 5
s2pctl>-I
Reserved device IDs: 5
s2pctl>-v
s2pctl version: 1.2-devel

The Pi does not support synchronous transfers, but there is code and a data structure (in scsi_controller.h) dealing with synchronous transfer settings.
This code/data structure shall be verified and removed if it does not have any use.

Besides dealing with binary files for sending/receiving data s2pexec shall also support a human readable format with hexadecimal values.

In order to improve the readability of the logfiles the hexadecimal error code values in the s2p logs shall be extended by a human-readable string representation, based on the respective names in the SCSI specification.

[2024-01-14 21:22:01.453] [trace] (ID:LUN 0:0) - Received unsupported command: $c3
[2024-01-14 21:22:01.454] [debug] (ID 0) - Error status: ILLEGAL REQUEST (Sense Key $05), INVALID COMMAND OPERATION CODE (ASC $20)

When creating a new ticket please provide information on your environment.

• The Pi type:
  Zero 2 W

• The Pi OS version (output of 'lsb_release -a'):
  Distributor ID: Debian
  Description: Debian GNU/Linux 12 (bookworm)
  Release: 12
  Codename: bookworm

• The SCSI2Pi release or git revision:
  scsi2pi_1.2_devel_50d3589_arm64-1.deb

• The computer/sampler connected to the RaSCSI/PiSCSI board:
  N/A

Describe the issue

When running s2pctl in interactive mode and just pressing enter without entering anything else it crashes with a "Segmentation fault":

$ /opt/scsi2pi/bin/s2pctl 
SCSI Target Emulator and SCSI Tools SCSI2Pi (Server Controller Tool)
Version 1.2-devel
Copyright (C) 2016-2020 GIMONS
Copyright (C) 2020-2023 Contributors to the PiSCSI project
Copyright (C) 2021-2024 Uwe Seimet
Entering interactive mode, Ctrl-D or "exit" to quit
s2pctl>
Segmentation fault

When entering commands it works without issues:

$ /opt/scsi2pi/bin/s2pctl 
SCSI Target Emulator and SCSI Tools SCSI2Pi (Server Controller Tool)
Version 1.2-devel
Copyright (C) 2016-2020 GIMONS
Copyright (C) 2020-2023 Contributors to the PiSCSI project
Copyright (C) 2021-2024 Uwe Seimet
Entering interactive mode, Ctrl-D or "exit" to quit
s2pctl>server-version
Device server version: SCSI2Pi 1.2-devel
s2pctl>

The .hd1 and .is1 extensions cover cases where a driver does not support SCSI-2 but only SCSI-1-CCS. This is usually sufficient, but there is a special case when the extension-based approach does not work: In case the device is attached without a medium, i.e. with an empty image filename. In such a scenario, when later inserting a medium the SCSI level will still be the default one, i.e. SCSI-2 for these device types. (The SCSI level must not change once it has been set.)
In order to support SCSI-1-CCS for removable media drives without a medium inserted at creation a new property "scsi-level" and a new s2p command line option "--scsi-level" shall be supported.
s2pctl shall support attaching a new SCSI-1-CCS device

The protobuf interface shall be extended in a backwards compatible way, so that the SCSI level is available for remote clients that know how to deal with this information.

Currently removable media devices support ejecting the current medium, but they cannot load a medium.
In order to work similarly to real devices with removal media support, when loading a medium s2p shall insert the last medium (image file) that was ejected. In order to do that, when ejecting a medium s2p has to rember the name of the respective image file. Load would effectively be the undo operation of eject.
This behavior would be similar to what happens when you eject a CD-ROM programmatically and then you load it again: If there is no human who has changed the CD, you will just work with the same CD as before.

For some computer platforms the SCSI2Pi default mode page data might not be suitable. They might not match the expectations of a driver, especially for exotic platforms, or a required mode page may be missing. In addition, mode page 0 is vendor-specific: it can have any content and format so that there cannot even be a meaningful default.
In order to address this, mode page data shall be made configurable. The current default data shall be kept, so that there is no change in behavior unless mode page data are explicitly overridden, additional mode pages are added or default mode pages are removed.

Providing mode page data on the command line is possible but inconvenient. It is better to use a property file (see #15) that contains a mapping of custom mode page data to the vendor and product INQUIRY data of a device. The revision field shall not be taken into account.

mode_page.MODE_PAGE_NR.VENDOR:PRODUCT=MODE_PAGE_DATA_IN_HEX
mode_page.MODE_PAGE_NR.VENDOR=MODE_PAGE_DATA_IN_HEX

e.g.

mode_page.0.IBM:DDRS-39130=04020304ff

In this excample the data to be returned as mode page 0 for the specified device are 04020304ff. These data contain the page code, the page size and the mode page payload. s2p shall validate this format. (See the SCSI specification for details.) Mode page 0 uses a free format, i.e. there is not necessarily a length field.
The INQUIRY product name in the property key is optional, i.e.

mode_page.40.IBM=28040380beff

returns the specified data for mode page 40 for all IBM drives.

It shall also be possible to remove an existing (default) mode page from the list of supported mode pages. This is just in case there are platforms that do not work the default mode pages but work without them. Not specifying any mode page data shall remove the respective page, e.g.

mode_page.2.IBM:DDRS-39130=

BlueSCSI codes drive properties in the name of the image files. While the command line approach of SCSI2Pi/PiSCSI is more flexible it would be useful to have a compatibility mode with the same parsing rules as those used by BlueSCSI, see https://github.com/BlueSCSI/BlueSCSI-v2/wiki/Usage. In this mode you can directly use existing BlueSCSI image files for SCSI2Pi without having to provide a full set of SCSI2Pi command line options.
A new device-specific s2p option "-B" shall switch to the compatiblity mode when parsing the data for the respective device. With this option s2p takes the drive parameters from the filename.

Instead of

>s2p -i 0:2 -b 1024 -n vendor:product:revision test.hds

you can also use an image file with a filename in BlueSCSI format:

>s2p -B HD02_1024_vendor:product:revision.hds

Note that there is a separator "_" between the sector size and the product data. If this separator is missing the string after the block size is ignored, because BlueSCSI permits any string between the block size and the extension. Without the "_" marker s2p cannot know whether to parse this string as product data or not.
The existing s2p command line options shall override the settings taken from the filename:

>s2p -B -i 2 HD10_1024.hds

This command assigns the drive a SCSI ID of 2, because "-i" overrides the SCSI ID 1 coded in the filename.

>s2p -B -h 2 HD10_1024.hds

Same as above, but for a SASI instead of a SCSI drive.
While BlueSCSI does not make use of the LUN number in a filename, SCSI2Piuses it.

>s2p -B HD10.hds -B CD131.hds -B RE11.hds

This results in a SCSI hard drive with SCSI ID 1, LUN 0, a CD-ROM drive with SCSI ID 1, LUN 31 and a removable media drive with SCSI ID1, Lun1.

This is a follow-up ticket to #38. The initial idea of making s2p configurable with dpkg --configure has been discarded because of the overhead involved.
Nevertheless, the package installation shall install s2p as a system service and shut down the PiSCSI service if it is running.

Rules to apply:

• Always install the SCSI2Pi system service, but do not necessarily enable and start it
• If the PiSCSI system service is up, stop it and disable it
• If either the PiSCSI or the SCSI2Pi system service was running before the installation, enable and start/restart the SCSI2Pi service

s2pdump shall suport an optional fault tolerant mode, where it reports read errors but does not terminate on an error. Instead, it shall try to read as many readable sectors from a drive as possible. If in a sequence of sectors (s2pdump reads several sectors in a single read operation) a sector in the sequence is not readable, the other sectors of this sequence shall still be read.
With this feature s2pdump can be used as a tool to recover data from drives where not all sectors are accessable anymore.

The data received/sent by the DaynaPort emulation shall be logged on trace level.

s2pexec now quite conveniently supports sending any SCSI command, valid or invalid, with any CDB and any parameter list. This makes advanced testing of the s2p error handling possible.
In particular the error handling of s2p shall be verified against the error handling of real SCSI devices. If s2p's behavior differs from that of a real device, based on the SCSI specification the correct error handling shall be determined and s2p shall be updated accordingly.

In order to have more descriptive options in addition to the one-letter options, s2pctl shall use getopt_long() instead of getopt() for parsing command line options.
In addition, some of the options shall be changed/renamed to be more consistent.

According to https://www.macuser.de/threads/fragen-zu-images-toast-dmg-iso-cdr.822473/ it appears reasonable to treat .cdr and .toast like .iso.

In order to have more descriptive options in addition to the one-letter options, s2pexec shall use getopt_long() instead of getopt() for parsing command line options.
In addition, some of the options shall be changed/renamed to be more consistent.

With the -I option s2pdump shall print device property data than can directly be used for s2p property files.
Besides ID, LUN, INQUIRY data and the block size s2pdump should also generate mode page data properties by querying all mode pages. With this information the properties of an emulated device are very close to those of the real device the data were derived from.

This feature allows the advanced cloning of drives. In addition to cloning the drive's sector data you can also clone other drive properties.

>s2pdump -I -i 5
----------------------------------------
Board ID is 7
----------------------------------------
Scanning target ID:LUN 5:0
Vendor:               'PLEXTOR '
Product:              'CD-ROM PX-40TS  '
Revision:             '1.11'
Device Type:          CD-ROM/DVD/BD/DVD-RAM
SCSI Level:           SCSI-2
Response Data Format: SCSI-2
Removable:            Yes

Device properties for s2p properties file:
device.5.type=SCCD
device.5.product_name=PLEXTOR:CD-ROM PX-40TS:1.11
device.5.mode_page.1=01:06:00:0a:00:00:00:00
device.5.mode_page.2=02:0e:02:00:00:00:00:00:00:00:00:00:00:00:00:00
device.5.mode_page.13=0d:06:00:0b:00:3c:00:4b
device.5.mode_page.14=0e:0e:04:00:00:00:00:00:01:ff:02:ff:00:00:00:00
device.5.mode_page.49=31:02:06:00

s2pdump shall be extended to support dumping and restoring of SASI hard drives. A new command line option "-h" shall be used for specifying the SASI drive ID and LUN, similar to the "-i" option for SCSI drives.

Configuring s2p with command line options can sometimes result in having to specify a lot of options. Configuring s2p settings in a property file (default ~/.config/s2p.properties) can simplify a setup and avoids long command lines.
A single property shall be set with the new -c KEY=VALUE option.
Command line settings shall override the respective properties file settings.

The remote interface shall be extended to return the effective property settings at the time s2p was launched.

s2pctl shall display the startup properties with the new "-q" option and as part of the server settings ("-s").

>s2pctl -q
Property settings on s2p startup:
  image_folder=/home/us/hatari
  locale=en_US.UTF-8
  log_level=trace
  mode_page.0.SCSI2Pi=00:ff:04:02:03:04:ff
  mode_page.3.SCSI2Pi:SCSI HD 1011 MiB=
  mode_page.40.SCSI2Pi=28:06:ff:04:02:03:04:ff
  port=6868
  property_file=
  reserved_ids=
  scan_depth=1
  device.0.block_size=1024
  device.0.params=test.hds
  device.1.type=SCLP
  device.3.params=test.mos
  device.4.params=test.iso
  device.5.params=zip.hds
  device.5.product_data=IOMEGA:ZIP 100:D.13
  device.5.type=SCRM
  device.6.params=daynaport
  device.6:2.params=services
  token_file=

See https://www.scsi2pi.net/en/properties.html for an up to date list of supported properties and their respective command line options. Also see #14.

This ticket results from PiSCSI/piscsi#1098 in the PiSCSI project.

There are DaynaPort drivers for the Atari, MacOS and NetBSD on 68k Macs. The MacOS driver is broken and requires a delay when data (a network packet) are returned. Currently this delay is the default behavior, but the default should not be tailored to a broken drivers but to working drivers. The delay work-around actually breaks the NetBSD driver to work.
Due to another peculiarity of the MacOS driver it is possible to detect whether this driver is the one sending a SCSI command: The driver is the only known driver that requests 17 bytes of INQUIRY data during its initialization.
In order to make s2p work for all known drivers the delay work-around should only be applied when the MacOS driver is connected. In order to support multi-initiator systems s2p has to remember which initiator needs the work-around (MacOS) and which not (all others.)