Additional configuration options for DaynaPort emulation

[akuker]

Info

From Discord user "speakers#7740"

I've been messing with piscsi Daynaport ethernet to write a driver for NetBSD. In particular, this is to provide ethernet on my SE30. The driver is based on the age-old se driver for Cabletron EA41x. I run NetBSD 3.1 on my 68k macs since it's reliable and reasonably fast -- although (amazingly) the latest version (9) will install and run.

I have a functional driver, but I've also needed to modify the piscsi code in two respects. Firstly, the send delay workaround for MacOS needs to be disabled. Secondly, the minimum packet size needs to be raised from 64 to 128 so that small packets - particularly ARPs -- are exchanged correctly. The changes are dynamic and depend on the behavior of the client OS. I can provide a diff.

[akuker]

Note that this needs to be updated on the fly, since the Mac will boot into MacOS first, then switch over to BSD

[speakers-k64]

Here's diffs that enables both MacOS and NetBSD to use the DaynaPort emulation:
bsd.patch

[uweseimet]

@speakers-k64 It may now be possible to make progress on this ticket. For the upcoming bookworm release (also running on bullseye) I removed the strange delay work-around. Testing has shown that it is not needed for the Mac.
Whether the packet size change can be applied depends on how the DaynaPort driver for the Atari deals with it, i.e. whether this driver also works with this patch applied. We can try to find this out once the bookworm release is available.

@mzryz Would you be willing to test this with your Atari?

@benjamink I'm aware that you have already spent a lot of time on #1306, but it would be great if you could also help here. I would like to verify whether the Mac really needs a work-around for the packet size. Most work-arounds in the piscsi code have turned out not to be required and some have even made things worse, so we should verify this.
In case you agree I would modify the existing "testing_daynaport" branch accordingly and would ask you for an additional test with this branch.

[benjamink]

@benjamink I'm aware that you have already spent a lot of time on #1306, but it would be great if you could also help here. I would like to verify whether the Mac really needs a work-around for the packet size. Most work-arounds in the piscsi code have turned out not to be required and some have even made things worse, so we should verify this. In case you agree I would modify the existing "testing_daynaport" branch accordingly and would ask you for an additional test with this branch.

@uweseimet absolutely! Let me know what you need.

[uweseimet]

@benjamink Thank you! As far as I can tell two things have to be tested, and I created a new branch testing_daynaport_2 for this. This branch is identical to issue_1306, which you have tested earlier, except for a work-around I removed. I would like to know whether networking still works for you with this branch.

[benjamink]

@uweseimet commit 0e77ab3fbdad14871d6ff0f02ddc63c935fd6c49 failed.

The Mac boots quickly without getting stuck on the AFP share mount but once the desktop loads the share is not mounted & an error pops up on the screen (I'll attach screenshot in a moment).

piscsi-issue-1088.log

[benjamink]

[uweseimet]

@benjamink OK, thank you. I just reverted the change and now applied a different change in order to test the second work-around regarding the packet size. Please update your testing_daynaport_2 branch and test again. No "make clean" required, just "make".

[benjamink]

@uweseimet commit 5ab222acfe26fb9ab9f342f3ec0413c0d0cac8a3 works

[uweseimet]

@benjamink Once more, thank you for testing. This means that the Mac would be fine with unconditionally setting the packet size to a minumum of 128 bytes.
If this also works for the Atari this value can simply be changed and it will work with all platforms without any platform-specific code.

[benjamink]

No problem. Just let me know if you need me to run any more.

[uweseimet]

@benjamink Not currently, thank you for the offer.

[uweseimet]

@anodynesoftware Just a quick question: Before we spend time on a trial-and-error approach, maybe you know by heart or can check whether your driver is fine with a minimum packet siize of 128 instead of 64 bytes?