DaynaPORT: outbound EtherTalk (AppleTalk Phase 2) frames have a padded 802.3 length field → AppleTalk zones/servers never appear in Chooser (regression since v2024.12.08 / pico-sdk 2.0.0)

[deltro68]

Summary

On WiFi/DaynaPORT builds, every outbound AppleTalk-over-802.3 (EtherTalk Phase 2)
frame the Mac transmits leaves BlueSCSI with an 802.3/LLC length field that has been
rounded up to a multiple of 4, instead of the true length (8 + DDP length).

For IP/Ethernet-II traffic those two bytes are an EtherType and the padded value is
ignored, so AFP-over-AppleTalk to a known/stored address still works (disks mount on
boot). But for 802.3 AppleTalk the field is a real length: AppleTalk routers and
atalkd/netatalk validate it against the DDP datagram's own length field, find they
disagree, and reject the datagram. The rejected frames are exactly the broadcast
ZIP GetNetInfo and NBP BrRq requests used for discovery, so:

• Chooser zone list is empty (ZIP GetNetInfo reply never comes back)
• AppleShare server list is empty (NBP LkUp replies never come back)
• Network control panels are slow (blocking on discovery timeouts)

This is a regression: older firmware transmitted the correct length and works fine.

Affected / not affected

• Broken: current firmware (tested up to the latest release), both Pico 1W and
  Pico 2W (RP2040 and RP2350). So it is not board-specific.
• Works: v2024.10.26 and earlier.
• First broken: v2024.12.08.

Root cause (bisected)

Bisected to commit d3f3db2 "chore: update to pico-sdk 2.0.0" (the SDK 1.x → 2.0.0 /
framework e139b9c7 → v4.1.1-DaynaPORT bump). BlueSCSI's own network.c /
BlueSCSI_platform_network.cpp are byte-identical across the boundary; the behavior
change comes in with the new SDK/cyw43 TX path. The 802.3 length field ends up rounded up
to a 4‑byte boundary somewhere between platform_network_send() →
cyw43_send_ethernet() and the wire.

Evidence (on-the-wire captures)

Captured with tcpdump on the AppleTalk router (Raspberry Pi running tashrouter +
netatalk 4.4.2), filtering the BlueSCSI MAC. Comparing the exact same frames from the same
Mac, only the firmware changed:

Firmware	DDP length	correct 802.3 len (8+ddp)	actual 802.3 len field	delta
v2024.10.26 (OLD, works)	21	29	29	0
v2024.10.26 (OLD, works)	50	58	58	0
SDK-2 (current, broken)	21	29	32	+3
SDK-2 (current, broken)	37	45	48	+3
SDK-2 (current, broken)	50	58	60	+2

Formula: broken 802.3_len == round_up(8 + ddp_len, 4). Across a full session the OLD
firmware was correct on 15/15 AppleTalk frames; the SDK-2 firmware was padded on 36/36.

Same ATP request frame, first 16 bytes (note bytes 12–13, the 802.3 length):

OLD fw (correct): aa c7 61 cf ae e7 00 80 19 5f 00 5f 00 1d aa aa   <- 0x001d = 29
NEW fw (padded):  aa c7 61 cf ae e7 00 80 19 5f 00 5f 00 20 aa aa   <- 0x0020 = 32

The DDP header's own length field is unchanged/correct (21) in both; only the outer
802.3 length is wrong on the SDK-2 build.

What the router sees

• Broken: Mac sends nbp-brRq "=:AFPServer@EtherTalk Network" and repeated
  at-#6 (ZIP GetNetInfo); the router drops them (length mismatch) and never fans them
  out → 0 replies → Chooser stays empty; the Mac re-sends GetNetInfo indefinitely.
• Working (old fw or after workaround): the same requests are accepted, the router
  replies (atp-resp carrying zone info), and zones/servers appear.

Confirmation / workaround

Patching the router to tolerate the padding immediately makes zones appear, which
confirms the length field is the sole cause. In tashrouter's datagram.py
(from_long_header_bytes / from_short_header_bytes) I changed the strict check:

# was:
if length != len(data):
    raise ValueError(...)
# to (accept trailing padding, then trim to the declared length):
if length > len(data):
    raise ValueError(...)
if length < len(data):
    data = data[:length]

With this, both Pico 1W and Pico 2W on the latest firmware work. This is a router-side
workaround only; it is not appropriate upstream for tashrouter (its strict check is
spec-correct — the 802.3 length should equal the LLC payload length), and every other
AppleTalk router / real netatalk will still reject BlueSCSI's frames.

Suggested fix

BlueSCSI should transmit the true 802.3 length for outbound frames rather than a
4‑byte‑padded value — i.e. do not let the SDK/cyw43 TX byte-alignment leak into the
802.3 length field. (Ethernet minimum-frame padding is fine, but the 802.3 length field
must remain the real LLC payload length for AppleTalk to route.)

Environment

• Board: BlueSCSI Pico 1W and Pico 2W (DaynaPORT / WiFi)
• Firmware: current release (also reproduced on v2024.12.08); good on v2024.10.26
• Server: Raspberry Pi, netatalk 4.4.2 + tashrouter, EtherTalk Phase 2, zone "EtherTalk Network"
• Mac: System 6/7 via BlueSCSI DaynaPORT

[deltro68]

Update: exact root cause found, and a verified fix

I traced this to the exact line and confirmed the fix end-to-end (on the wire, with a stock/unpatched AppleTalk router).

Root cause: the cyw43-driver SPI send path (pico-sdk 2), not BlueSCSI's DaynaPORT code

The frame BlueSCSI hands to cyw43_send_ethernet() is correct — I dumped the outbound buffer for all 51 AppleTalk frames in a session and every one had the right 802.3 length (8 + DDP length) and the right len. So network.c / platform_network_send() are innocent.

The corruption happens inside the cyw43 driver's SPI transmit path:

cyw43_ll.c → cyw43_sdpcm_send_common() ends with:

// pico-sdk 2 (broken):
return cyw43_write_bytes(self, WLAN_FUNCTION, 0, CYW43_WRITE_BYTES_PAD(size), buf);
//                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = ALIGN_UINT(size, 4)

For the SPI bus this rounds size up to a multiple of 4 and passes the padded value as the transfer length. But cyw43_write_bytes() uses that length in make_cmd(write, inc, fn, addr, sz), which encodes the size the CYW43 chip uses as the frame length. So the transmitted 802.3 frame ends up 1–3 bytes too long, with the 802.3 length field = the padded size.

The pre-pico-sdk-2 driver did not pad here — for SPI it used #define SDPCM_PAD(A) A (identity):

// pre-sdk-2 (working):
return cyw43_write_bytes(self, WLAN_FUNCTION, 0, SDPCM_PAD(size), buf);   // SPI: no padding

Note the padding is redundant anyway: cyw43_write_bytes() already computes aligned_len = (len + 3) & ~3 and DMAs aligned_len bytes (the PIO/DMA requires word alignment), while passing the true len to make_cmd. So aligning at the caller only corrupts the logical frame length; it is not needed for the hardware.

For Ethernet II / IP frames those two bytes are an EtherType (the value is ignored) — which is why AFP-over-AppleTalk to a stored address still works. For 802.3 AppleTalk the field is a real length, so routers/netatalk reject the datagram and NBP/ZIP discovery is silently dropped → no zones.

Fix

Restore the pre-sdk-2 behaviour on the SPI send path only (firmware/NVRAM download paths keep ALIGN(..., 4)):

#if CYW43_USE_SPI
#define CYW43_SDPCM_SEND_PAD(len) (len)         // no padding: cyw43_write_bytes aligns the DMA itself
#else
#define CYW43_SDPCM_SEND_PAD(len) CYW43_WRITE_BYTES_PAD(len)
#endif
...
return cyw43_write_bytes(self, WLAN_FUNCTION, 0, CYW43_SDPCM_SEND_PAD(size), buf);

Verification (end-to-end, stock unpatched router)

Built this into the firmware and tested on both Pico 1W and Pico 2W:

• Machine code: the & ~3 alignment before cyw43_write_bytes is gone.
• On the wire: the Mac's outbound 802.3 length is now correct on 6/6 AppleTalk frames (29, 58 = 8 + DDP), identical to the last-known-good firmware. Broken firmware was 32/48/60 (padded).
• Functional: AppleTalk zones now appear in the Chooser with a completely unmodified router (previously they never did).

Notes for maintainers

• The cyw43 driver is shipped prebuilt (framework-arduinopico/lib/rp2040/libipv4.a, member cyw43_ll.c.obj), so a source edit alone has no effect — the fix requires rebuilding that archive (and the RP2350 equivalent for Pico 2W).
• This is really a cyw43-driver / pico-sdk 2 bug affecting any SPI raw-ethernet TX (not lwIP, which sends its own correctly-sized frames), so it may be worth reporting upstream to the cyw43-driver project as well.
• Interim user workaround (no firmware change): a strict AppleTalk router will reject these frames; relaxing the DDP length check to accept trailing padding restores zones. That is a router-side band-aid — the firmware fix above is the real one.

[Oronzo-Mazzeo]

Independent reproduction on a Macintosh SE/30, with additional inbound AARP evidence

I can independently reproduce the failure of AppleTalk servers to appear in Chooser when using BlueSCSI v2 Wi-Fi DaynaPORT emulation.

This appears closely related to the problem described in this issue. The tests below may add evidence concerning the inbound AARP path.

AFP over TCP/IP works correctly in the same configuration: entering the server IP address manually in AppleShare Client reaches the server, returns the correct shared server name, and presents the authentication dialog. Only automatic AppleTalk/NBP discovery fails.

Test environment

Component	Configuration
Macintosh	Macintosh SE/30
ROM	2 MB PurpleROM, 32-bit clean
Memory	68 MB total: PurpleRAM 4 × 16 MB plus 4 MB system RAM
System software	System 7.6.1 with gusd_0005 patch
Open Transport	1.3 GM
AppleShare Client	3.8.3
AppleTalk interface	Alternate Ethernet
Network driver	DaynaPORT SCSI/Link 1.2.2
BlueSCSI network image	NE6.hda, SCSI ID 6
BlueSCSI firmware	2026.04.27-rel
BlueSCSI Wi-Fi MAC	02:80:19:53:30:01
Positive-control server	PowerBook G4, Mac OS X 10.4.11, Personal File Sharing enabled
Network topology	SE/30 through BlueSCSI v2 Wi-Fi; G4 and an independent packet-capture Mac on the same LAN

Important DaynaPORT driver constraint

DaynaPORT SCSI/Link 1.2.2 is the stable and usable driver in this exact SE/30 configuration.

I separately tested the later DaynaPORT 1.2.5f1 driver. It is not usable in this setup because it does not release the emulated network device correctly during shutdown or restart and causes unstable shutdown behaviour. Returning to version 1.2.2 restored correct network-device closure and stable operation.

Therefore, installing the later classic-Mac DaynaPORT driver is not a viable workaround in this configuration. There is no remaining equivalent Mac-side configuration change to apply.

Server-side positive control

On the PowerBook G4, the Apple file-server preferences include:

registerAppleTalk = 1
registerNSL = 1
useAppleTalk = 0

Running this locally on the G4:

atlookup -d "=:AFPServer"

returns one registered service:

<PowerBook-name>:AFPServer

The G4 is therefore actually registering an AFPServer service through NBP, rather than merely having AppleTalk enabled in System Preferences.

Nevertheless, the G4 does not appear in Chooser → AppleShare on the SE/30.

The same non-discovery result was obtained with the G4 connected through AirPort and, in a separate controlled test, through built-in Ethernet with AppleTalk active on that interface.

When the G4 IPv4 address is entered manually in AppleShare Client, the SE/30 reaches the server, receives the correct shared server name, and displays the authentication dialog. AFP/TCP, IP networking through BlueSCSI, and the Tiger file server are therefore operational.

Packet-capture results

Three captures were collected:

Capture	Duration	NBP requests from SE/30/BlueSCSI	AARP requests from G4	AARP responses from SE/30
G4-local capture	46.13 s	45	450	0
Independent Wi-Fi capture, baseline	63.04 s	55	539	0
Independent Wi-Fi capture, BlueSCSI Debug=1	64.76 s	55	537	0

When Chooser → AppleShare is opened:

1. the SE/30 repeatedly transmits an NBP lookup for =:AFPServer@*;
2. the G4 receives that lookup;
3. the G4 repeatedly transmits AARP requests for the SE/30 AppleTalk node;
4. no AARP response from the SE/30 is observed;
5. consequently, no NBP reply reaches Chooser.

The independent Wi-Fi capture receives both:

• the NBP broadcasts transmitted from the SE/30/BlueSCSI side;
• the AARP requests transmitted by the G4.

This makes a general access-point block affecting all AppleTalk multicast traffic unlikely. It does not, by itself, prove that every frame is presented to the emulated DaynaPORT interface in the expected format.

BlueSCSI Debug=1 comparison

The Debug=1 capture reproduced essentially the same network behaviour:

Frame type	Baseline	Debug=1
NBP requests	55	55
AARP requests	539	537
AARP responses	0	0

Enabling debug therefore did not materially alter the failure.

The BlueSCSI debug log confirms:

• firmware 2026.04.27-rel;
• Debug=1 was applied;
• NE6.hda was configured as a network device on SCSI ID 6;
• Wi-Fi initialized successfully;
• network transfers on SCSI ID 6 completed with STATUS: 0 GOOD.

During the Chooser test, the log contains repeated:

• 64-byte Write6 transfers from the SE/30 to BlueSCSI;
• 70-byte Read6 transfers from BlueSCSI to the SE/30.

No queue-overflow, oversized-packet, or explicit network-delivery error was found.

Because the debug log does not include packet payloads, I am not treating the transfer sizes and counts alone as definitive proof of packet identity. Their timing and frequency do, however, correlate closely with the NBP and AARP traffic in the simultaneous external capture.

Potentially relevant encapsulation difference

A potentially relevant difference appears between the G4-local capture and the independent Wi-Fi capture.

On the transmitting G4, the outgoing AARP request is captured as an IEEE 802.3 LLC/SNAP frame:

09 00 07 ff ff ff
00 03 93 ed 07 fd
00 24
aa aa 03 00 00 00 80 f3
...

On the independent Wi-Fi Mac, the corresponding traffic is presented as an Ethernet II frame:

09 00 07 ff ff ff
00 03 93 ed 07 fd
80 f3
...

The following IEEE 802.3/LLC/SNAP bytes visible in the G4-local capture are absent:

00 24 aa aa 03 00 00 00

and 80 f3 is exposed directly as the Ethernet type.

Working hypothesis — not a concluded root cause

One possible explanation is that the AARP frame is converted from EtherTalk Phase 2 IEEE 802.3 LLC/SNAP encapsulation to Ethernet II while crossing the Wi-Fi path.

BlueSCSI appears to receive network traffic and make data available through the DaynaPORT SCSI interface, but the classic Mac AppleTalk stack may not recognize the received representation as the AARP frame expected for EtherTalk Phase 2. It therefore sends no AARP response, preventing the remote server from returning its NBP lookup result.

I am presenting this only as a working hypothesis based on the captures, not as a confirmed firmware defect.

Questions for the maintainers

1. Is this likely to share the root cause described in this issue, or might it indicate a separate inbound AARP encapsulation problem?

2. When the CYW43 interface supplies an incoming Ethernet II frame with EtherType 0x80F3, should BlueSCSI reconstruct the EtherTalk Phase 2 IEEE 802.3 LLC/SNAP representation before presenting it through DaynaPORT emulation?

3. Is there a diagnostic build, patch, or additional trace that could confirm the exact frame bytes delivered to the classic Mac?

4. Would testing an earlier BlueSCSI firmware release be useful for this specific inbound-path observation? I have not changed firmware yet, in order to preserve the controlled configuration.

Evidence archive

The attached ZIP contains:

• the G4-local packet capture;
• the independent Wi-Fi baseline capture;
• the independent Wi-Fi Debug=1 capture;
• the complete BlueSCSI Debug=1 log, with the Wi-Fi SSID redacted;
• the normal Debug=0 startup log, with the SSID redacted;
• a README describing the files;
• SHA-256 checksums.

The PCAP files are unchanged because altering packet bytes would reduce their diagnostic value. They contain local MAC addresses and the G4 AppleTalk server name. No Wi-Fi password is included.

I can run a narrowly specified additional test or provide further traces if required.

BlueSCSI_issue_400_independent_reproduction_evidence.zip