DaynaPort: MAC Address & Multicast filtering is not implemented

[akuker]

Info

• Which version of Pi are you using: All
• Which github revision of software: 21.12
• Which board version: All
• Which computer is the RaSCSI connected to: Any

Describe the issue

They DaynaPort SCSI/Link is able to filter out incoming messages so that only the needed messages are passed through to the host. However, this functionality has not been implemented in the RaSCSI DaynaPort simulation. Therefore, the host is doing additional processing that it shouldn't need to.

In the real DaynaPort SCSI/Link, the multicast messages are handled in hardware by the DP83902A Ethernet receiver. The documentation for that device help understand how multicast messages should be handled.

10.9 MULTICAST ADDRESS REGISTERS (MAR0 –MAR7)

The multicast address registers provide filtering of multicast 
addresses hashed by the CRC logic. All destination addresses 
are fed through the CRC logic and as the last bit of the 
destination address enters the CRC, the 6 most significant bits 
of the CRC generator are latched. These 6 bits are then decoded 
by a 1 of 64 decode to index a unique filter bit (FB0 –63) in 
the multicast address registers. If the filter bit selected is 
set, the multicast packet is accepted. The system designer 
would use a program to determine which filter bits to set in 
the multicast registers. All multicast filter bits that 
correspond to multicast address accepted by the node are then 
set to one. To accept all multicast packets all of the 
registers are set to all ones.

On a Macintosh, when the host starts up with AppleTalk enabled, it will send a SCSI command 0Dh with a payload of 00 09 00 07 FF FF FF, which is the multicast address for AppleTalk.

devices/scsi_daynaport.cpp should be updated to filter out messages that do not need to be passed to the host. An incoming message should only be passed to the host if it meets one of these criteria:

• Broadcast message
• Destination MAC address matches the Daynaport
• Multicast message is part of a group that has been joined by the host.

Note: A half-baked implemented is commented out in SCSIDaynaPort::Read(), but it is hard coded for which multicast messages to receive. The map of enabled multicast messages should be dynamically updated/maintained based upon the SCSI command 0Dh. The code was never successfully tested, so it may or may NOT work.

Additionally, when a 0Dh command is received from the host with a multicast join, the RaSCSI service should probably also "join" the multicast group through the connected interface. If the RaSCSI is connected to a managed network switch, the switch needs to be told which multicast message groups should be passed through.

The Daynaport SCSI/Link emulation should also filter out any IPv6 traffic. Odds are pretty good that the host doesn't understand IPv6, so this will reduce the amount of wasted processing. (If someone disagrees with this, feel free to comment)