piscsi_bridge should not be created by default when WiFi is used for network access for daynaport #64

fdanapfel · 2024-02-07T14:20:49Z

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' and 'uname -a'):

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 12 (bookworm)
Release:	12
Codename:	bookworm
$ uname -a
Linux bookworm 6.1.0-rpi8-rpi-v8 #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 (2024-01-25) aarch64 GNU/Linux

The SCSI2Pi release or git revision:
scsi2pi_2.1_devel_0b10191_bookworm_arm64-1.deb
The computer/sampler connected to the RaSCSI/PiSCSI board:
Atari TT030
Mac SE/30

Describe the issue

As mentioned at PiSCSI/piscsi#1331 (comment) the NAT setup for the daynaport interface works if the piscsi_bridge is removed and the IP address is configured directly on the piscsi0 interface.

Also others have now been able to verify that the setup I proposed in PiSCSI/piscsi#1387 which uses parprouted instead of the bridge or the NAT setups that were originally used by PiSCSI works for both WLAN and Ethernet to allow systems using the emulated daynaport adapter to communicate over the network.

Therefore the piscsi_bridge should not be created by default when the daynaport is attached.

The text was updated successfully, but these errors were encountered:

uweseimet · 2024-02-07T14:31:51Z

The issue_64 branch does not create the bridge anymore for any wlan interface. What about other interfaces like eth1, wlan1? Where excatly do we need the bridge, and where not? (I'm not a networking expert.)

When using wlan0 and launching s2p, this is the initial setup I get with the issue_64 branch:

piscsi0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::e8cb:b2ff:fefa:9386  prefixlen 64  scopeid 0x20<link>
        ether ea:cb:b2:fa:93: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

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.103  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::30cf:c63f:6981:b6c6  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:98:c9:d3  txqueuelen 1000  (Ethernet)
        RX packets 19883  bytes 25269302 (24.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7481  bytes 1654910 (1.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

>sudo iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  10.10.20.0/24        anywhere

Now I run:

sudo /sbin/ip addr add 10.10.20.1/24 brd + dev piscsi0

And see this:

piscsi0: 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::e8cb:b2ff:fefa:9386  prefixlen 64  scopeid 0x20<link>
        ether ea:cb:b2:fa:93: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

I assigned IP 10.10.20.2 to the TT, but STiNG cannot connect to ftp.uni-erlangen.de, for instance. Any idea what might be wrong?

uweseimet · 2024-02-07T14:41:37Z

@fdanapfel Without programmatically exeucting

sudo /sbin/ip addr add 10.10.20.1/24 brd + dev piscsi0

this setup is rather inconvenient, isn't it? The setting gets lost after shutting s2p down, because the bridge interface it refers to is gone.

fdanapfel · 2024-02-07T15:18:12Z

@uweseimet

The issue_64 branch does not create the bridge anymore for any wlan interface. What about other interfaces like eth1, wlan1? Where excatly do we need the bridge, and where not? (I'm not a networking expert.)

The bridge is only needed if a physical Ethernet interface (eth0, eth1, ...) is used for the connection of the piscsi0 interface to the real network. As documented at https://wiki.debian.org/BridgeNetworkConnections#Bridging_with_a_wireless_NIC using a bridge to connect a wlan interface and an Ethernet interface (real or virtual like the piscsi0) doesn't work.

And as mentioned in PiSCSI/piscsi#1387 with the setup using parprouted the bridge is not needed at all.

When using wlan0 and launching s2p, this is the initial setup I get with the issue_64 branch:

piscsi0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::e8cb:b2ff:fefa:9386  prefixlen 64  scopeid 0x20<link>
        ether ea:cb:b2:fa:93: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

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.103  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::30cf:c63f:6981:b6c6  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:98:c9:d3  txqueuelen 1000  (Ethernet)
        RX packets 19883  bytes 25269302 (24.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7481  bytes 1654910 (1.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

>sudo iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  10.10.20.0/24        anywhere

Now I run:

sudo /sbin/ip addr add 10.10.20.1/24 brd + dev piscsi0

And see this:

piscsi0: 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::e8cb:b2ff:fefa:9386  prefixlen 64  scopeid 0x20<link>
        ether ea:cb:b2:fa:93: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

This looks good.

I assigned IP 10.10.20.2 to the TT, but STiNG cannot connect to ftp.uni-erlangen.de, for instance. Any idea what might be wrong?

Did you also set up the ROUTE.TAB file for STING to send the Network traffic over the 10.10.20.0 Network? See https://www.atari-forum.com/viewtopic.php?p=438157#p438157

@fdanapfel Without programmatically exeucting
sudo /sbin/ip addr add 10.10.20.1/24 brd + dev piscsi0
this setup is rather inconvenient, isn't it? The setting gets lost after shutting s2p down, because the bridge interface it refers to is gone.

Sorry, I don't understand what you mean here. There is no reference to a brige in that ip addr add command, all it does is assign the IP address to the piscsi0 interface and sets the netmask (the brd + part in the command).

uweseimet · 2024-02-07T15:39:27Z

@fdanapfel Indeed, I forgot that I also had to edit ROUTE.TAB. Now it's working! (With bookworm.)

Regarding the ip command, what I mean is that if s2p removes the piscsi0 interface when you stop s2p, any setting (ip addr add) for this interface is lost. Even when s2p re-creates piscsi0 when you re-start s2p the setting is lost.
And even when s2p does not remove the piscsi0 interface you still have to run the ip addr add command once, after lauching s2p for the first time.

uweseimet · 2024-02-07T15:41:44Z

Regarding creating the bridge: My current approach is to not create it whenever the network interface name starts with "wlan", i.e. also wlan1 is covered. Correct me if I am wrong, but this approach should be fine, shouldn't it?

fdanapfel · 2024-02-07T16:29:24Z

@uweseimet

@fdanapfel Indeed, I forgot that I also had to edit ROUTE.TAB. Now it's working! (With bookworm.)

Great!

Regarding the ip command, what I mean is that if s2p removes the piscsi0 interface when you stop s2p, any setting (ip addr add) for this interface is lost. Even when s2p re-creates piscsi0 when you re-start s2p the setting is lost. And even when s2p does not remove the piscsi0 interface you still have to run the ip addr add command once, after lauching s2p for the first time.

OK, but this is the standard way how a network interface works even for Ethernet or WLAN interfaces. When a network interface is created (for Ethernet or WLAN interfaces this normally is done by the Linux kernel during boot based on the hardware it finds) it initially doesn't have an IP address assigned to it. This normally happens later via tools like NetworkManager or dhcpcd, or by configuring the IP address manually using the ip command.
But as long as the interface exists it should keep the same IP address unless it is changed either manually or by NetWorkManager or dhcpcd. If the piscsi0 interface is removed when s2p is stopped or the daynaport is stopped then yes, the IP will have to be set again when the piscsi0 interface is re-created again later on.

If s2p is not removing the piscsi0 interface when the daynaport is detached or when s2p itself is stopped then the piscsi interface should still keep the same ip address it was configured with before.

Please also keep in mind that the IP address that needs to be assigned to the piscsi0 interface will not necessarily be the same all the time. As you can see in PiSCSI/piscsi#1387 when using parprouted the IP adress of the piscsi interface is actually set to the same IP address as the real network interface

Regarding creating the bridge: My current approach is to not create it whenever the network interface name starts with "wlan", i.e. also wlan1 is covered. Correct me if I am wrong, but this approach should be fine, shouldn't it?

Yes, this should be fine, unless the approach to use parprouted is accepted as the new standard for connecting the piscsi0 interface to the real network for both Ethernet and WLAN. Then the brige is also not needed when Ethernet is used.

uweseimet · 2024-02-07T16:38:55Z

@fdanapfel Thank you for providing more details. Regarding manual configuration, this is IMO a blocker. One cannot expect the user to manually add the IP address after launching s2p (or piscsi).
How would the use case look like in your opinion? How would the IP address be set, without the user being bothered with this, at least for the default scenario with a default IP like 10.10.20.1?

uweseimet · 2024-02-07T17:29:49Z

@fdanapfel I experimented a bit and think that s2p (issue_64 branch) now does everything required automatically. Before lauching s2p there is no piscsi0 interface. After lauching s2p ifconfig says:

piscsi0: 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::14c1:e6ff:fe46:30ee  prefixlen 64  scopeid 0x20<link>
        ether 16:c1:e6:46:30:ee  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

After stopping s2p piscsi0 is gone, but it's there again when you re-start s2p.

My TT was also happy with this, and on bullseye I get the same result.

uweseimet · 2024-02-07T22:06:15Z

@fdanapfel https://www.scsi2pi.net/packages/develop/scsi2pi_2.1_devel_7c3df1b_bookworm_arm64-1.deb is a binary package of the current issue_62 branch. If possible, can you please verify whether it works as expected, i.e. as I have claimed it works?
If it does, the next step would be to use a similar setup for eth0 I guess? If it is possible to have a rather simple setup for both eth0 and wlan0 I will probably add network instructions to the SCSi2Pi website. Being compatible with PiSCSI in this case is not a very high priority for me. A simple setup that works for bookworm and also for bullseye is more important to me than compatibility. Who knows if and when the C++ network code of PiSCSI will be updated ...

uweseimet · 2024-02-08T11:45:21Z

After some more testing I have just merged the current changes into the develop branch. Any potential change related to eth0 should be a separate ticket.
The current behavior is:

If the interface name starts with "eth" (physical interface), "piscsi0" and "piscsi_bridge" are created.
If the name starts with anything else only "piscsi0" is created.
When terminating s2p all additional interfaces are removed.

This solution is still not the best, because the interfaces are created even though they might never be needed. A user might always attach a DaynaPort but might not always not use it.
In the ideal case the interfaces should only be created when s2p receives an ENABLE INTERFACE command from the DaynaPort driver. I might address this in the future, but not now.
On the other hand, learning immediately (when launching s2p) that the Daynaport emulation will not work may be better than learning about it later, in the middle of a session.

fdanapfel · 2024-02-08T18:29:15Z

@uweseimet Thanks, I've now tested this with scsi2pi_2.1_devel_7c3df1b_bookworm_arm64-1.deb and it works as expected when attaching the daynaport:

$ s2pctl -l
No devices currently attached.
$ 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,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 808224sec preferred_lft 808224sec
    inet6 2003:c9:d701:1200:470a:d09a:e629:147e/64 scope global dynamic noprefixroute 
       valid_lft 7101sec preferred_lft 3501sec
    inet6 fe80::8d9b:2326:42e9:e441/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
$ sudo apt install ./scsi2pi_2.1_devel_7c3df1b_bookworm_arm64-1.deb
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'scsi2pi' instead of './scsi2pi_2.1_devel_7c3df1b_bookworm_arm64-1.deb'
The following NEW packages will be installed:
  scsi2pi
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/734 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 /home/frank/scsi2pi_2.1_devel_7c3df1b_bookworm_arm64-1.deb scsi2pi arm64 2.1-devel [734 kB]
Selecting previously unselected package scsi2pi.
(Reading database ... 81714 files and directories currently installed.)
Preparing to unpack .../scsi2pi_2.1_devel_7c3df1b_bookworm_arm64-1.deb ...
Unpacking scsi2pi (2.1-devel) ...
Setting up scsi2pi (2.1-devel) ...
Starting SCSI2Pi service
Consider adding SCSI2Pi to your local environment with:
  export PATH=$PATH:/opt/scsi2pi/bin
  export MANPATH=$MANPATH:/opt/scsi2pi/man
N: Download is performed unsandboxed as root as file '/home/frank/scsi2pi_2.1_devel_7c3df1b_bookworm_arm64-1.deb' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
$ sudo systemctl status s2p.service 
● s2p.service - SCSI2Pi s2p service
     Loaded: loaded (/etc/systemd/system/s2p.service; disabled; preset: enabled)
     Active: active (running) since Thu 2024-02-08 19:04:54 CET; 13s ago
   Main PID: 9198 (s2p)
      Tasks: 2 (limit: 176)
        CPU: 24ms
     CGroup: /system.slice/s2p.service
             └─9198 /opt/scsi2pi/bin/s2p

Feb 08 19:04:54 bookworm s2p[9198]: SCSI Target Emulator and SCSI Tools SCSI2Pi (Device Emulation)
Feb 08 19:04:54 bookworm s2p[9198]: Version 2.1-devel
Feb 08 19:04:54 bookworm s2p[9198]: Copyright (C) 2016-2020 GIMONS
Feb 08 19:04:54 bookworm s2p[9198]: Copyright (C) 2020-2023 Contributors to the PiSCSI project
Feb 08 19:04:54 bookworm s2p[9198]: Copyright (C) 2021-2024 Uwe Seimet
Feb 08 19:04:54 bookworm s2p[9198]: [2024-02-08 19:04:54.622] [info] Set log level to 'info'
Feb 08 19:04:54 bookworm s2p[9198]: [2024-02-08 19:04:54.622] [info] Default image folder set to '/home/frank/images'
Feb 08 19:04:54 bookworm s2p[9198]: [2024-02-08 19:04:54.626] [info] Reserved ID(s) set to 7
Feb 08 19:04:54 bookworm s2p[9198]: [2024-02-08 19:04:54.626] [info] No devices currently attached.
Feb 08 19:04:54 bookworm s2p[9198]: No devices currently attached.
$ s2pctl -i 6 -c a -t daynaport
$ 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,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 807494sec preferred_lft 807494sec
    inet6 2003:c9:d701:1200:470a:d09a:e629:147e/64 scope global dynamic noprefixroute 
       valid_lft 6919sec preferred_lft 3319sec
    inet6 fe80::8d9b:2326:42e9:e441/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
5: piscsi0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 2a:19:e9:f8:31:06 brd ff:ff:ff:ff:ff:ff
    inet 10.10.20.1/24 brd 10.10.20.255 scope global piscsi0
       valid_lft forever preferred_lft forever
    inet6 fe80::2819:e9ff:fef8:3106/64 scope link 
       valid_lft forever preferred_lft forever

But when detaching the daynaport the piscsi0 interface isn't removed and also the IP address stays configured:

$ s2pctl -i 6 -c d
$ s2pctl -l
No devices currently attached.
$ 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,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 807469sec preferred_lft 807469sec
    inet6 2003:c9:d701:1200:470a:d09a:e629:147e/64 scope global dynamic noprefixroute 
       valid_lft 6895sec preferred_lft 3295sec
    inet6 fe80::8d9b:2326:42e9:e441/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
5: piscsi0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 2a:19:e9:f8:31:06 brd ff:ff:ff:ff:ff:ff
    inet 10.10.20.1/24 brd 10.10.20.255 scope global piscsi0
       valid_lft forever preferred_lft forever
    inet6 fe80::2819:e9ff:fef8:3106/64 scope link 
       valid_lft forever preferred_lft forever

I would have expected that this works like with a real network interface or the piscsi_bridge ( #45), meaning that the piscsi0 interface is removed when the daynaport is detached.

fdanapfel · 2024-02-08T18:42:44Z

@uweseimet

@fdanapfel Thank you for providing more details. Regarding manual configuration, this is IMO a blocker. One cannot expect the user to manually add the IP address after launching s2p (or piscsi). How would the use case look like in your opinion? How would the IP address be set, without the user being bothered with this, at least for the default scenario with a default IP like 10.10.20.1?

Sorry I'm not sure what the best way would be to automatically set the IP address, since right now there are three different possibilities how the connection between the emulated daynaport and the real network could be set up:

Using WLAN with NAT: in this case the IP can aways be set to 10.10.20.1
Using Ethernet with a bridge: in this case the piscsi0 interface doesn't need an IP address but the IP address needs to be set on the piscsi_bridge instead according to https://github.com/PiSCSI/piscsi/wiki/Dayna-Port-SCSI-Link
Using the parprouted setup described in Feature Request: Wifi bridge without NAT using parprouted PiSCSI/piscsi#1387 which works for both WLAN and Ethernet: in this case the piscsi0 interface always gets configured to the same IP address as the real network interface, but it also requires that the real interface is put in promiscuous mode before this is done (otherwise the network connection will no longer work) and parprouted needs to be started after the IP address has been set

uweseimet · 2024-02-08T18:49:27Z

@fdanapfel I cannot reproduce this, but this might be because in the meantime I have cleaned up the legacy networking code quite a bit, and this is the code I have just tested with.
With the next set of development binaries (available tomorrow), which is the same code I tested with, anything related to the bridge should be gone. Would be great if you could re-test with the latest package tomorrow.

Regarding 1. just a note: 10.10.20.1 is the default, but you can configure any IP, just like you can configure any interface. This way you can also use wlan0 even when eth0 (the default) is available, e.g.

>s2p -i 6 -t scdp inet=10.10.20.200:interface=wlan0
...
2024-02-08 19:48:21.585] [trace] Setting up TAP interface piscsi0
[2024-02-08 19:48:21.587] [trace] >ip link set piscsi0 up
[2024-02-08 19:48:21.588] [trace] >ip addr add 10.10.20.200 brd + dev piscsi0
[2024-02-08 19:48:21.588] [info] TAP interface piscsi0 created

Regarding 3. I will wait until PiSCSI/piscsi#1387 is done.

fdanapfel · 2024-02-10T13:39:31Z

@uweseimet I've now tested again with the latest development build from this morning, and now everything works as expected (the bridge is not created and the piscsi0 device is created/removed when the daynaport is attached/detached):

$ sudo apt install ./scsi2pi_2.1_devel_2fa8c30_bookworm_arm64-1.deb 
...
$ s2pctl -l
No devices currently attached.
$ 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,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 862469sec preferred_lft 862469sec
    inet6 2003:c9:d701:1200:470a:d09a:e629:147e/64 scope global dynamic noprefixroute 
       valid_lft 7153sec preferred_lft 3553sec
    inet6 fe80::8d9b:2326:42e9:e441/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
$ s2pctl -i 6 -c a -t daynaport
$ 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,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 862428sec preferred_lft 862428sec
    inet6 2003:c9:d701:1200:470a:d09a:e629:147e/64 scope global dynamic noprefixroute 
       valid_lft 7113sec preferred_lft 3513sec
    inet6 fe80::8d9b:2326:42e9:e441/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: piscsi0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 8a:27:84:98:a2:4e brd ff:ff:ff:ff:ff:ff
    inet 10.10.20.1/24 brd 10.10.20.255 scope global piscsi0
       valid_lft forever preferred_lft forever
    inet6 fe80::8827:84ff:fe98:a24e/64 scope link 
       valid_lft forever preferred_lft forever
$ s2pctl -i 6 -c d
$ s2pctl -l
No devices currently attached.
$ 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,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 862401sec preferred_lft 862401sec
    inet6 2003:c9:d701:1200:470a:d09a:e629:147e/64 scope global dynamic noprefixroute 
       valid_lft 7086sec preferred_lft 3486sec
    inet6 fe80::8d9b:2326:42e9:e441/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
$

Thanks for implementing those changes. And for the information about configuring the IP and interface when attaching the daynaport, wasn't aware of that.

So from my point of view this issue can be closed.

uweseimet · 2024-02-10T13:41:39Z

@fdanapfel Thank you for your feedback!

fdanapfel mentioned this issue Feb 7, 2024

piscsi_bridge on Bookworm PiSCSI/piscsi#1331

Open

uweseimet self-assigned this Feb 7, 2024

uweseimet added the enhancement New feature or request label Feb 7, 2024

uweseimet added this to SCSI2Pi release 3.0 Feb 7, 2024

uweseimet moved this to In progress in SCSI2Pi release 3.0 Feb 7, 2024

uweseimet added a commit that referenced this issue Feb 8, 2024

Do not create piscsi_bridge for wlan interfaces (#64)

062d499

uweseimet moved this from In progress to In review in SCSI2Pi release 3.0 Feb 8, 2024

uweseimet added a commit that referenced this issue Feb 8, 2024

Further clean up bridge code (#64)

1264fb9

uweseimet closed this as completed Feb 10, 2024

github-project-automation bot moved this from In review to Done in SCSI2Pi release 3.0 Feb 10, 2024

uweseimet mentioned this issue Feb 22, 2024

Log human-readable SCSI error code data instead of hexadecimal values #20

Closed

fdanapfel mentioned this issue Feb 25, 2024

Can't set IP address when attaching DaynaPort device #75

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

piscsi_bridge should not be created by default when WiFi is used for network access for daynaport #64

piscsi_bridge should not be created by default when WiFi is used for network access for daynaport #64

fdanapfel commented Feb 7, 2024

uweseimet commented Feb 7, 2024

uweseimet commented Feb 7, 2024

fdanapfel commented Feb 7, 2024

uweseimet commented Feb 7, 2024 •

edited

Loading

uweseimet commented Feb 7, 2024 •

edited

Loading

fdanapfel commented Feb 7, 2024

uweseimet commented Feb 7, 2024 •

edited

Loading

uweseimet commented Feb 7, 2024 •

edited

Loading

uweseimet commented Feb 7, 2024

uweseimet commented Feb 8, 2024 •

edited

Loading

fdanapfel commented Feb 8, 2024

fdanapfel commented Feb 8, 2024

uweseimet commented Feb 8, 2024 •

edited

Loading

fdanapfel commented Feb 10, 2024

uweseimet commented Feb 10, 2024

piscsi_bridge should not be created by default when WiFi is used for network access for daynaport #64

piscsi_bridge should not be created by default when WiFi is used for network access for daynaport #64

Comments

fdanapfel commented Feb 7, 2024

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

Describe the issue

uweseimet commented Feb 7, 2024

uweseimet commented Feb 7, 2024

fdanapfel commented Feb 7, 2024

uweseimet commented Feb 7, 2024 • edited Loading

uweseimet commented Feb 7, 2024 • edited Loading

fdanapfel commented Feb 7, 2024

uweseimet commented Feb 7, 2024 • edited Loading

uweseimet commented Feb 7, 2024 • edited Loading

uweseimet commented Feb 7, 2024

uweseimet commented Feb 8, 2024 • edited Loading

fdanapfel commented Feb 8, 2024

fdanapfel commented Feb 8, 2024

uweseimet commented Feb 8, 2024 • edited Loading

fdanapfel commented Feb 10, 2024

uweseimet commented Feb 10, 2024

uweseimet commented Feb 7, 2024 •

edited

Loading

uweseimet commented Feb 7, 2024 •

edited

Loading

uweseimet commented Feb 7, 2024 •

edited

Loading

uweseimet commented Feb 7, 2024 •

edited

Loading

uweseimet commented Feb 8, 2024 •

edited

Loading

uweseimet commented Feb 8, 2024 •

edited

Loading