Skip to content

Better ASP Error handling. #5

Merged
pgodwin merged 1 commit into
mainfrom
fix-asp-reply
Apr 19, 2026
Merged

Better ASP Error handling. #5
pgodwin merged 1 commit into
mainfrom
fix-asp-reply

Conversation

@pgodwin
Copy link
Copy Markdown
Contributor

@pgodwin pgodwin commented Apr 19, 2026

  • Add comments to methods to make it more obvious which parts of the spec is implemented.

  • Checked the error codes against Inside Macintosh, handle invalid session ids gracefully. Previously clients would just get stuck in a loop and we'd just ignore them.

  • Return the correct error code if requests exceed quantum size. Previously we just silently truncated them.

  • double-check sizes and return correct error codes.

  • Get client attention when we stop the services so the client is informed of the shutdown.

Also this seems to have fixed MacTCP! Previously it would hang/crash if the server stopped and started again. It now seems able to establish a new ASP and continue on its way.

 * Add comments to methods to make it more obvious which parts of the spec is implemented.

 * Checked the error codes against Inside Macintosh, handle invalid session ids gracefully. Previously clients would just get stuck in a loop and we'd just ignore them.
  * Return the correct error code if requests exceed quantum size. Previously we just silently truncated them.
  * double-check sizes and return correct error codes.
  * Get client attention when we stop the services so the client is informed of the shutdown.
@pgodwin pgodwin merged commit 29ee373 into main Apr 19, 2026
4 checks passed
@pgodwin pgodwin deleted the fix-asp-reply branch April 19, 2026 03:22
pgodwin added a commit that referenced this pull request May 17, 2026
The spec-compliant handleReadMPX from a7fa7ee returned the requested
chunk in a single WCT=8 response (Offset, Count=DataLength,
Remaining=0xFFFF, valid Pad+Data) per [MS-CIFS] 2.2.4.23. On the wire
this looks correct, but Win9x over Direct IPX silently rejects each
reply and retransmits the same Read MPX request at file offset 0
forever — see captures/ipx.pcap frames 365-393 (FID 0x0003, MID 35457,
all at offset 0) and frames 415+ (FID 0x0004).

Exact reason Win9x refuses the response is unknown — possibly a
required multi-response streaming form or some MID/dialect quirk we
have not reverse-engineered. Samba's reply_readbmpx in
source3/smbd/reply.c has avoided the command for the same reason
since the 1990s by returning ERRSRV/ERRuseSTD, which prompts the
client to fall back to SMB_COM_READ (which we already serve
correctly). Costs one extra round-trip per chunk; in exchange the
transfer actually completes.

- handleReadMPX now returns smbStatusUseStandard unconditionally.
- TestHandleReadMPXReturnsData / TestHandleReadMPXInvalidFID replaced
  with TestHandleReadMPXReturnsUseStandard.
- spec/errata.md documents the deviation per CLAUDE.md #5.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant