Files

Mario Fetka f1e88ab88d docs: audit accounting endpoint stubs

2026-06-02 18:35:13 +02:00

74 KiB

Raw Blame History

TODO

This file collects follow-up work that is known but intentionally not part of the current patches. It is meant for project-level items that are too broad or too low-priority to keep as inline source TODO comments.

Server / NCP compatibility

Console privilege model

Current status:

NCP 23/200 Check Console Privileges is implemented as a protocol-compatible status check.
For now, console privileges are mapped to the existing supervisor-equivalence state computed for the connection.
Callers with supervisor equivalence get success; other callers get 0xc6 (No Console Rights).

Follow-up:

Add a real console-operator privilege model instead of treating console rights as identical to supervisor equivalence.
Decide where the console privilege map should live:
- a bindery property,
- a server configuration option,
- or a small explicit internal list similar to queue operator handling.
Check how NetWare 3.x tools such as PCONSOLE, SYSCON, and console utilities expect console operators to be represented.
Keep NCP 23/200 as a completion-code-only endpoint; only the privilege source should change.

Queue spool path case handling

Current status:

Queue job paths can still be rebuilt from DOS/bindery path spelling such as SYS:SYSTEM/EPSON.QDR.
On a case-sensitive Unix filesystem this can differ from the existing directory, for example system/epson.qdr.

Follow-up:

Resolve queue job file paths case-insensitively in the queue connection/path resolver, or use the queue object's already-resolved Unix spool directory instead of rebuilding it from the DOS path.
Avoid creating duplicate directories that differ only by case.

NCP 17/4C test coverage

Current status:

NCP 17/4C List Relations of an Object is implemented server-side.
Existing DOS and Linux tools do not reliably trigger it for all useful set properties such as GROUP_MEMBERS and GROUPS_I'M_IN.

Follow-up:

Add a small direct test utility to mars-dosutils / NWTESTS that sends NCP 17/4C directly.
Suggested test cases:
- TESTGRP1 type 0x0002, property GROUP_MEMBERS
- TESTGRP2 type 0x0002, property GROUP_MEMBERS
- MARIO type 0x0001, property GROUPS_I'M_IN
- NOPASSUSER type 0x0001, property GROUPS_I'M_IN
- GUEST type 0x0001, property GROUPS_I'M_IN

NCP endpoint SDK documentation / stub audit

Current status:

Several legacy NCP endpoints in src/nwconn.c are implemented only as disabled stubs, explicit 0xfb unsupported replies, or success/no-op dummies.
The known candidates now have inline SDK-context comments so future work can start from the documented wire semantics instead of from guesswork.

Follow-up:

Implement or deliberately reject remaining endpoint gaps after client evidence or direct protocol tests.
Keep SDK details close to the corresponding endpoint in nwconn.c, and keep broader prioritization/status here in TODO.md.

NCP endpoint audit tracking

Current status:

src/nwconn.c contains a mix of implemented, forwarded, partial, dummy, and intentionally unsupported NCP endpoints.
Endpoint comments should be aligned with the Novell SDK Web documentation, SDK headers, the Rust nwserver implementation, lwared, and the existing mars_nwe admin/Pascal code where those sources cover the same call.

Follow-up:

Keep inline TODO: comments only where endpoint behavior is incomplete, approximate, intentionally dummy/no-op, or still needs SDK layout verification.
Mirror every real incomplete endpoint in this file so follow-up work remains visible outside the source code.
Do not treat every return(-1) in nwconn.c as incomplete: many of those paths intentionally forward bindery/global-server work to nwbind.
When an endpoint returns to nwbind, keep the audit paired: the dispatcher comment in nwconn.c should name the handoff, and the concrete parser in nwbind.c should carry the request/reply layout. This was rechecked for the currently documented forwarded paths: message group 0x2222/21, quota prehandling in Directory Services 0x2222/22, File Server Environment 0x2222/23, End of Job 0x2222/24, Logout 0x2222/25, and Semaphore 0x2222/32.

NCP endpoint layout audit (version-bucketed compatibility)

Current status:

The default NCP endpoint audit is scoped to compatibility calls through NetWare 3.x. NetWare 1.x/2.x legacy calls are part of that compatibility target when they are documented, but they should be kept in their own buckets instead of being mixed into the 3.x/default list.
Bucket endpoints by the oldest generation that documents or requires them: 1.x/2.x legacy first, then remaining through-3.x compatibility calls, then a separate NetWare 4.x planning/stub bucket for later work.
Keep SDK request/reply details close to the corresponding endpoint in the source file that handles the call. If nwconn.c forwards a group to nwbind.c, document the handoff in nwconn.c and the concrete subfunctions in nwbind.c.
Documentation-only audit patches should not change parsing or reply behavior; record observed differences here for later implementation or compatibility testing. Compare against the local NDK/Core Protocols PDF, the WebSDK HTML, and the uploaded SDK include prototypes when those sources cover the call.
MARS_NWE_4 is hard-disabled in include/config.h.cmake. Do not move or wrap already implemented code just because it is 4.x-era; only new, unimplemented 4.x stubs should be guarded with #if MARS_NWE_4.

Version buckets for endpoints documented so far

NetWare 1.x/2.x legacy bucket:

Old direct file/logical/physical synchronization calls: 0x2222/01 through 0x2222/0e where documented by the legacy SDK/PDF.
Old direct utility/message handoff calls around 0x2222/12 through 0x2222/15, including the 1.x/2.x-compatible broadcast subfunctions handled in src/nwbind.c.
Older directory-handle compatibility calls that the local PDF marks as early NetWare compatibility, especially 0x2222/22/17 and 0x2222/22/18.

NetWare 3.x/default compatibility bucket:

Remaining documented 0x2222/22 Directory Services calls through the NetWare-3.x-compatible namespace/directory range ending at 22/48, unless a specific call is proven to belong to the older bucket above.
Salvage compatibility is part of this default bucket where the old 22/27, 22/28, 22/29 bridges map to the newer salvage backend.

NetWare 4.x planning/stub bucket:

0x2222/22/50 Get Object Effective Rights for Directory Entry and 0x2222/22/51 Get Extended Volume Information are documented by the local NDK/Core Protocols PDF as NetWare 4.x/5.x calls and are also visible through the uploaded WebSDK/include material (NWGetObjectEffectiveRights, NWGetExtendedVolumeInfo).
MARS-NWE already has active compatibility implementations for these two calls; leave that code in place. Track them in the 4.x bucket for future cleanup, tests, and field mapping rather than moving them into the default 3.x TODO list or hiding them behind MARS_NWE_4.
Any additional not-yet-implemented NetWare 4.x endpoint discovered later should be documented as a plan and, if a source stub is useful, guarded with #if MARS_NWE_4 while the macro remains 0. Do not add source stubs merely for NetWare 5.x/OES/MOAB/newer endpoints during the current audit.

SDK-listed 0x2222 blocks not yet endpoint-audited

Current status:

The local NDK/Core-Protocols PDF and uploaded WebSDK/includes list several 0x2222 endpoint families that are not yet covered by the detailed per-endpoint audit above. This section is an index only; do not treat an entry here as implemented, missing, or in-scope until the block is compared against the real dispatcher and bucketed by the oldest documented NetWare generation.
Use SDK/PDF decimal numbers plus wire hex when drilling into a block. For example, SDK group 0x2222/23 is the top-level wire case 0x17; SDK group 0x2222/89 would be top-level wire case 0x59.

Present in the code but not yet fully endpoint-audited:

SDK 0x2222/23 / wire 0x17 File Server Environment: the audit has started with file-information, login/connection, bindery-object, queue, management/admin, and accounting calls. Remaining property, set, and password subfunctions still need the same PDF/WebSDK/include comparison in src/nwbind.c and the related queue prehandlers.
SDK 0x2222/34 / wire 0x22 TTS calls are present in src/nwconn.c and have been endpoint-audited as an unsupported/no-rollback compatibility group.
SDK 0x2222/35 / wire 0x23 AFP calls are present in src/nwconn.c and have been endpoint-audited as the AFP/Mac namespace compatibility block. AFP has separate smoke coverage under tests/afp/; future fixes should be driven by those tests and client traces rather than a new parallel metadata store.
SDK 0x2222/65 through 77 / wire 0x41 through 0x4d are old direct file open/create/read/write/rename/time/copy calls present in src/nwconn.c; they have been endpoint-audited as the old direct file-I/O compatibility block. Follow-up fixes, if any, should be driven by client traces, especially around the old six-byte file-handle layout and the 65 Open File (old) access-rights compatibility note.
SDK 0x2222/86 / wire 0x56 Extended Attribute is endpoint-audited as a compatibility shim block in src/nwconn.c and src/namspace.c; see the Extended Attribute section below for the exact per-subfunction status.
SDK 0x2222/87 / wire 0x57 Name Space is endpoint-audited for the current 1.x/2.x/3.x plus planned-4.x scope. Later-generation high selectors 87/44 and 87/64..87/69 are documented as out of current source-stub scope.
SDK 0x2222/97 / wire 0x61 Get Big Packet NCP Max Packet Size and SDK 0x2222/101 / wire 0x65 Packet Burst Connection Request are present in src/nwconn.c and endpoint-audited as the 4.x-era packet-burst negotiation and setup paths. The follow-on 0x7777 packet-burst data-plane handler is also documented, but it is not a normal 0x2222 endpoint.
SDK 0x2222/104 / wire 0x68 NDS/NCP fragger is endpoint-audited as planned NetWare-4.x/NDS work. The top-level source case remains active as unsupported (0xfb), while the documented 104/01..104/08 selector slots are recorded behind #if MARS_NWE_4 in src/nwconn.c.
SDK 0x2222/111 / wire 0x6f Semaphore is source-stub-audited as the newer NetWare 3.x/4.x paired semaphore family. The old 32/xx semaphore calls remain the active compatibility implementation; patch 0223 records 111/00..111/04 as disabled #if 0 selector slots in src/nwconn.c so the future semaphore provider can bridge both families.
SDK 0x2222/90 / wire 0x5a Data Migration / tree metadata is source-stub-audited as planned 4.x filesystem/namespace work. Patch 0224 records the 4.x-era 90/00, 90/10, 90/11, 90/12, 90/128..90/136, and 90/150 selector slots behind MARS_NWE_4 in src/nwconn.c. There is no active data-migration support module, compression metadata backend, or parse-tree provider yet; future ownership belongs to the filesystem/namespace provider, not nwnds.
SDK 0x2222/17 / wire 0x11 direct Print/Spool is source-stub-audited as a NetWare 2.x/3.x/4.x compatibility family. There is no active top-level handler for these legacy direct spool NCPs, so patch 0218 records the documented selector slots 17/00, 17/01, 17/02, 17/03, 17/06, 17/09, and 17/10 as a disabled #if 0 stub in src/nwconn.c. This is not a statement that all printing is absent: queue-based printing already exists through print queues, Q_UNIX_PRINT, and queue-job close/service paths. Any future direct-spool implementation should reuse that queue printing machinery where possible, and it does not belong to nwnds.
SDK 0x2222/36 and 0x2222/37 / wire 0x24 and 0x25 NCP Extension are source-stub-audited as a NetWare 4.x extension-registration family. Patch 0221 records the documented 36/00..36/06 information selectors and direct 37 execute-extension call behind MARS_NWE_4 in src/nwconn.c. There is no active extension registry/provider yet, and nwserv must remain a control-plane registry/supervisor rather than a data-plane broker for extension payloads.
SDK 0x2222/79, 0x2222/84, and 0x2222/85 / wire 0x4f, 0x54, and 0x55 are source-stub-audited as old direct file-metadata/open-create and sparse-data compatibility calls. Patch 0222 records disabled #if 0 slots in src/nwconn.c; future implementation belongs to the filesystem/namespace provider and should not be confused with NDS directory-object attributes.
SDK 0x2222/23/150..23/153 / wire 0x96..0x99 Accounting is source-stub-audited as a NetWare 2.x/3.x/4.x-compatible accounting-server family. Patch 0226 records disabled #if 0 selector slots in src/nwbind.c for Get Current Account Status, Submit Account Charge, Submit Account Hold, and Submit Account Note. Future ownership belongs to an accounting provider, with possible bridge points to queue printing for charge/hold/note behavior.

SDK-listed blocks that do not currently show a top-level handler in src/nwconn.c:

SDK 0x2222/92 / wire 0x5c SecretStore is scope-audited as a later-generation SecretStore/eDirectory single-sign-on family. The local NDK PDF marks the family as NetWare Server 5.x and eDirectory 8.5 or later, with subverbs 0 Query Server through 9 Get Service Information. There is no active top-level handler in src/nwconn.c, no indirect provider path was found in the audited source, and no source stub should be added under the current 1.x/2.x/3.x plus planned-4.x rule. It remains prose-only/out of the current compatibility target.
SDK 0x2222/123 / wire 0x7b service-address enumeration and SDK 0x2222/131 / wire 0x83 RPC/NLM-control style calls appear in the PDF/WebSDK index but do not currently show top-level handlers in src/nwconn.c. These are likely later-generation buckets, but each must be confirmed against the includes/WebSDK before adding guarded stubs. Only endpoints bucketed as 1.x/2.x/3.x compatibility or planned 4.x work should receive disabled source stubs.

Follow-up:

When auditing one of these blocks, first check whether an existing handler is reached through nwconn.c, nwbind.c, or a queue/salvage/helper prehandler. Only add a missing-endpoint TODO or guarded stub after that handoff search.
Do not add every later SDK-listed endpoint to the active TODO list. Put NetWare 4.x items in the NetWare 4.x planning bucket, and only add a disabled #if MARS_NWE_4 stub when that 4.x planning marker is useful and no existing implementation is present. NetWare 5.x/OES/MOAB/newer items should remain prose-only/out-of-scope unless the target scope changes.

Old direct file/logical/physical synchronization calls

Current status:

The old direct synchronization family in src/nwconn.c is annotated with Novell SDK endpoint names and request-layout notes.
NCP 0x01 File Set Lock (old) and NCP 0x02 File Release Lock are documented in the SDK but are not implemented in MARS-NWE yet. Inline documentation and commented case/break stubs are present in src/nwconn.c.
NCP 0x03 Log File (old) is implemented, but still belongs on the audit list because the original source already marked this old log/lock area as not well tested.
NCP 0x04 Lock File Set (old) and NCP 0x6a Lock File Set share the current implementation. The SDK documents the old 0x04 timeout word as Lo-Hi and the newer 0x6a timeout word as Hi-Lo; MARS-NWE currently reads the shared field with GET_BE16(). This is documented inline but not changed yet.
NCP 0x05 Release File (old) and NCP 0x07 Clear File (old) have request parsing that matches the documented old header offsets.
NCP 0x06 Release File Set and NCP 0x08 Clear File Set are implemented, but the SDK request contains a LockFlag byte that the current code does not read. This parser difference is documented inline but not changed yet.
NCP 0x09 Log Logical Record (old), NCP 0x0a Lock Logical Record Set (old), NCP 0x0b Clear Logical Record, and NCP 0x0c Release Logical Record have inline SDK request-layout documentation. The direct old endpoints have been compared against the NDK/Core Protocols PDF request offsets.
NCP 0x0d Release Logical Record Set and NCP 0x0e Clear Logical Record Set are implemented, but the SDK request contains a LockFlag byte that the current code does not read. This parser difference is documented inline but not changed yet.
NCP 0x1a Log Physical Record (old), 0x1c Release Physical Record, and 0x1e Clear Physical Record are implemented and now have inline request layout documentation. The parser matches the documented 6-byte handle position by ignoring the high/reserved two bytes and using the low 4-byte handle; offsets, lengths, and the Log Physical Record timeout are read as Hi-Lo.
NCP 0x1b Lock Physical Record Set (old) and the newer 0x6e Lock Physical Record Set share one handler. The SDK/PDF documents old 0x1b LockTimeout as Lo-Hi and newer 0x6e as Hi-Lo, while MARS-NWE currently reads the shared field with GET_BE16(). The current LockFlag mapping also treats bit 1 as shareable/read-only and the unset case as exclusive/read-write, which is the inverse of the NDK/Core-Protocols text.
NCP 0x1d Release Physical Record Set and 0x1f Clear Physical Record Set are implemented, but both SDK requests contain a LockFlags byte that the current code does not read. The reply has no payload and completion reports the set-operation result.

Follow-up:

Decide whether NCP 0x01 and NCP 0x02 should be implemented for real old-client compatibility or should return a deliberate 0xfb unsupported completion with normalized endpoint logging.
Verify NCP 0x03 Log File (old) against a real DOS requester or direct test caller; the documented PDF/WebSDK request offsets already match the current parser.
Decide whether the shared 0x04/0x6a parser should keep the current big-endian timeout read for both functions or special-case old 0x04 as documented Lo-Hi after direct requester evidence is available.
Decide whether 0x06, 0x08, 0x0d, and 0x0e should consume or ignore the documented LockFlag byte after direct requester evidence is available.
Decide whether 0x0a should keep the current big-endian timeout read or special-case the documented old Lo-Hi byte order after direct requester evidence is available.
Continue direct requester or NWTESTS coverage for the file, logical-record, and physical-record synchronization calls that are now wired.
Decide whether the shared 0x1b/0x6e physical-record-set parser should special-case old 0x1b LockTimeout as documented Lo-Hi, and whether the LockFlag bit-1 mapping should follow the PDF text or preserve current compatibility behavior.
Decide whether 0x1d and 0x1f should consume or continue ignoring the documented LockFlags byte after direct requester evidence is available.

Legacy utility and message/broadcast calls

Current status:

NCP 0x12 Get Volume Info with Number, NCP 0x13 Get Station Number, NCP 0x14 Get File Server Date And Time, and the NCP 0x15 message group handoff have inline SDK request/reply layout documentation.
The forwarded NetWare 1.x/2.x/3.x-compatible NCP 0x15 message subfunctions in src/nwbind.c have inline SDK request/reply layout documentation for broadcast send/get, enable/disable, and console broadcast calls. The missing-endpoint pass for this group found implemented SDK 21/00, 21/01, 21/02, 21/03, 21/09, 21/10, and 21/11; no default-compatibility server NCPs were found for 21/04..21/08.
SDK 21/12 Connection Message Control is documented as NetWare 5.x, so it remains outside the default through-3.x endpoint target. Do not add it unless the later-generation feature work is explicitly enabled.
NCP 0x13 Get Station Number is documented by the SDK as a three-byte StationNumber reply; MARS-NWE currently returns only the low one-byte connection number. This parser/reply difference is documented inline but not changed yet.

Follow-up:

Verify whether the current one-byte 0x13 reply is required by old clients or whether the SDK three-byte StationNumber reply should be implemented.
Verify NCP 0x2222/21/10 Send Broadcast Message with a real client before changing the parser: the NDK/Core Protocols PDF page documents long connection numbers and long completion flags, while the CLIB/WebSDK NWSendBroadcastMessage prototype exposes a 16-bit connection list and byte result list, matching the current compatibility parser.

Directory Services group 0x2222/22

Current status:

NCP 0x2222/22 is handled in src/nwconn.c, with selected quota-related subfunctions forwarded to src/nwbind.c for bindery/ObjectID prehandling.
The group header is documented inline as SubFuncStrucLen (Hi-Lo), SubFunctionCode, and subfunction payload.
Endpoint numbers in SDK/PDF/WebSDK prose are decimal unless the source explicitly prefixes them with 0x. The wire case byte is listed below whenever decimal and hex notation can be confused.
Already audited and inline-documented default-compatibility calls:
- SDK 22/00 / wire 0x00 Set Directory Handle
- SDK 22/01 / wire 0x01 Get Directory Path
- SDK 22/02 / wire 0x02 Scan Directory Information
- SDK 22/03 / wire 0x03 Get Effective Directory Rights
- SDK 22/04 / wire 0x04 Modify Maximum Rights Mask
- SDK 22/05 / wire 0x05 Get Volume Number
- SDK 22/06 / wire 0x06 Get Volume Name
- SDK 22/10 / wire 0x0a Create Directory
- SDK 22/11 / wire 0x0b Delete Directory
- SDK 22/13 / wire 0x0d Add Trustee to Directory
- SDK 22/14 / wire 0x0e Delete Trustee from Directory
- SDK 22/15 / wire 0x0f Rename Directory
- SDK 22/18 / wire 0x12 Allocate Permanent Directory Handle
- SDK 22/19 / wire 0x13 Allocate Temporary Directory Handle
- SDK 22/20 / wire 0x14 Deallocate Directory Handle
- SDK 22/21 / wire 0x15 Get Volume Info with Handle
- SDK 22/22 / wire 0x16 Allocate Special Temporary Directory Handle
- SDK 22/23 / wire 0x17 Extract a Base Handle
- SDK 22/24 / wire 0x18 Restore an Extracted Base Handle
- SDK 22/25 / wire 0x19 Set Directory Information
- SDK 22/26 / wire 0x1a Get Path Name of a Volume-Directory Number Pair
- SDK 22/27 / wire 0x1b Scan Salvageable Files (old)
- SDK 22/28 / wire 0x1c Recover Salvageable File (old)
- SDK 22/29 / wire 0x1d Purge Salvageable File (old)
- SDK 22/30 / wire 0x1e Scan a Directory
- SDK 22/31 / wire 0x1f Get Directory Entry
- SDK 22/32 / wire 0x20 Scan Volume's User Disk Restrictions
- SDK 22/33 / wire 0x21 Add User Disk Space Restriction
- SDK 22/34 / wire 0x22 Remove User Disk Space Restrictions
- SDK 22/37 / wire 0x25 Set Directory Entry Information
- SDK 22/38 / wire 0x26 Scan File or Directory for Extended Trustees
- SDK 22/39 / wire 0x27 Add Extended Trustee to Directory or File
- SDK 22/40 / wire 0x28 Scan Directory Disk Space
- SDK 22/41 / wire 0x29 Get Object Disk Usage and Restrictions
- SDK 22/42 / wire 0x2a Get Effective Rights for Directory Entry
- SDK 22/43 / wire 0x2b Remove Extended Trustee from Dir or File
- SDK 22/44 / wire 0x2c Get Volume and Purge Information
- SDK 22/45 / wire 0x2d Get Directory Information
- SDK 22/46 / wire 0x2e Rename Or Move (old)
- SDK 22/47 / wire 0x2f Get Name Space Information
- SDK 22/48 / wire 0x30 Get Name Space Directory Entry
Already audited NetWare 4.x planning-bucket calls with existing active MARS-NWE implementations:
- SDK 22/50 / wire 0x32 Get Object Effective Rights for Directory Entry
- SDK 22/51 / wire 0x33 Get Extended Volume Information These are not part of the default 1.x/2.x/3.x implementation TODO list, but existing compatibility code remains active.
The old SDK PDF table for SDK 22/00 repeats TargetDirectoryHandle for the second payload byte, but the remarks describe a source handle; MARS-NWE parses the byte as SourceDirectoryHandle. This is documented inline but not changed.
No NetWare 1.x/2.x/3.x SDK/PDF entries were found for direct SDK 22/07, 22/08, or 22/09 during this audit. The next documented direct directory calls continue at SDK 22/10 / wire 0x0a.
WebSDK/PDF recheck found SDK 22/12 / wire 0x0c Scan Directory for Trustees. Do not confuse this with the already implemented wire case 0x12 / SDK 22/18 Allocate Permanent Directory Handle. Scan Directory for Trustees has only a disabled inline stub for now.
WebSDK/PDF also documents SDK 22/35 / wire 0x23 Get Directory Disk Space Restriction and SDK 22/36 / wire 0x24 Set Directory Disk Space Restriction as NetWare 3.x-compatible directory quota calls. They are not active cases in this dispatcher yet; disabled inline stubs now sit at their numeric wire slots between SDK 22/34 / wire 0x22 and SDK 22/37 / wire 0x25.
SDK 22/13 / wire 0x0d and SDK 22/14 / wire 0x0e match the SDK/PDF payload layouts. SDK 22/15 / wire 0x0f matches the payload layout; the old PDF labels this call's SubFuncStrucLen as Lo-Hi, but MARS-NWE dispatches the group before using that length word and the surrounding NCP 22 group header is otherwise documented as Hi-Lo.
SDK 22/10 / wire 0x0a and SDK 22/11 / wire 0x0b preserve the documented offset of DirectoryAccessMask, but the current implementation does not use that field when creating or deleting the directory.
SDK 22/18, 22/19, 22/22, 22/20, and 22/21 request parsers match the documented NetWare 1.x/2.x/3.x payload offsets.
SDK 22/23 / wire 0x17 and SDK 22/24 / wire 0x18 now have inline request/reply layout documentation. The current parsers match the actual payload fields, but the local NDK/Core Protocols PDF tables for this older NetWare 2.x save/restore pair contain header/length wording that does not line up cleanly with the common 0x2222/22 group header. This is documented inline and no behavior was changed.
SDK 22/25, 22/26, 22/27, and 22/29 match the documented request payload offsets. SDK 22/26 uses the old 16-bit directory-entry-number form; the WebSDK table does not spell out byte order for that word, while MARS-NWE reads it as Hi-Lo.
SDK 22/28 validates the documented old/new filename fields, but the current backend call recovers by directory handle and sequence only and does not pass the old/new names to the salvage backend.
SDK 22/30 / wire 0x1e matches the documented offsets, but the SDK documents Sequence as Lo-Hi while the current parser reads it with GET_BE32().
SDK 22/31 / wire 0x1f consumes the documented DirectoryHandle; legacy source comments expected two extra unknown bytes after it, but the SDK request has no such fields and the helper ignores them.
SDK 22/32 / wire 0x20 reads VolumeNumber in the normal NCP 22 payload position, but the WebSDK/PDF table for this call shows VolumeNumber one byte later than the common group-header alignment. The code also reads Sequence with GET_BE32() although the SDK/PDF documents Lo-Hi; treat both as audit items until verified with a direct test caller.
SDK 22/33 and 22/34 are forwarded to nwbind.c for quota prehandling; both layers are documented. The shared nwbind prehandler reads ObjectID from the documented payload position. SDK 22/33 includes a documented DiskSpaceLimit field, but the current shared prehandler does not consume it before returning the uid/gid/permission tuple.
SDK 22/38, 22/39, and 22/41 match the documented request payload offsets.
SDK 22/37 matches the documented payload field order, but the current parser reads Sequence with GET_BE32() although the SDK/PDF documents Lo-Hi.
SDK 22/40 matches the documented payload offsets, but the current parser reads Sequence with GET_BE32() although the SDK/PDF documents Lo-Hi; it also returns the normal directory scan structure from nw_scan_a_directory() rather than the full documented Scan Directory Disk Space reply.
SDK 22/42, 22/43, 22/45, 22/46, and 22/47 match the NetWare 1.x/2.x/3.x SDK/PDF payload offsets used by the current parser.
SDK 22/44 / wire 0x2c matches the documented request offset, but the PDF marks TotalBlocks as Hi-Lo while the remaining 32-bit counters are Lo-Hi; current code uses U32_TO_32() for all counters.
SDK 22/48 / wire 0x30 matches the documented payload offsets; the PDF does not label the DOSSequence byte order, and current code reads it with GET_32().

Follow-up:

Implement or intentionally reject SDK 22/12 / wire 0x0c Scan Directory for Trustees. Do not confuse the SDK decimal subfunction number 12 with the already implemented wire case 0x12 / SDK 22/18 directory-handle call.
Implement or intentionally reject SDK 22/35 / wire 0x23 Get Directory Disk Space Restriction and SDK 22/36 / wire 0x24 Set Directory Disk Space Restriction. Both are NetWare 3.x-compatible, not MARS_NWE_4 work.
Verify the documented SDK 22/00 source-handle interpretation against an old requester or direct test caller before changing behavior.
Decide whether SDK 22/10 / wire 0x0a and SDK 22/11 / wire 0x0b should apply or validate the documented DirectoryAccessMask byte, or whether ignoring it is required for old requester compatibility.
Verify SDK 22/23 / wire 0x17 and SDK 22/24 / wire 0x18 against an old requester or direct test caller before changing the conservative connection-local implementation; the SDK/PDF tables for those two NetWare 2.x calls are less internally consistent than the surrounding directory-handle calls.
Verify SDK 22/26 directory-entry-number byte order against an old requester or direct test caller before changing the current Hi-Lo interpretation.
Decide whether SDK 22/28 should pass the documented old/new filename fields to the salvage backend, or whether sequence-only recovery is sufficient for old requester compatibility.
Verify SDK 22/30 Sequence byte order; current code uses GET_BE32() although the SDK/WebSDK documents Lo-Hi.
Verify whether SDK 22/31 should continue accepting legacy callers that send the two extra bytes described by the old source comment, even though the SDK request only contains DirectoryHandle.
Verify SDK 22/32 VolumeNumber offset and Sequence byte order against a direct test caller; the WebSDK table appears shifted by one byte compared with the normal NCP 22 group header, and current code uses GET_BE32() although the SDK/PDF documents Lo-Hi.
Decide whether SDK 22/33 should pass the documented DiskSpaceLimit through the quota prehandling path or whether the current behavior is intentionally handled later in the quota backend.
Verify SDK 22/37 Sequence byte order; current code uses GET_BE32() although the SDK/PDF documents Lo-Hi.
Verify SDK 22/40 Sequence byte order and reply shape; current code uses GET_BE32() and delegates to the normal directory scan reply rather than the documented Scan Directory Disk Space reply.
Verify SDK 22/44 Volume and Purge Information reply byte order for TotalBlocks; the SDK/PDF marks only that field as Hi-Lo, while current code emits all 32-bit counters with U32_TO_32().
Verify SDK 22/48 DOSSequence byte order against an old requester or direct test caller; current code uses GET_32() and the PDF table does not spell out the order for that field.
The NetWare 1.x/2.x/3.x-compatible 0x2222/22 endpoint layout pass is covered through the documented SDK 22/48 namespace call, with the newly found SDK 22/12, 22/35, and 22/36 gaps tracked as disabled stubs/TODO items. Continue with the next compatibility group after this block; 5.x/OES-only groups are not current stub targets.

Semaphore group 0x2222/32

Current status:

Direct NCP 0x2222/32 / wire 0x20 is forwarded unchanged from src/nwconn.c to src/nwbind.c, which passes requestdata[0] as the semaphore subfunction and requestdata[1..] to handle_func_0x20() in src/sema.c.
The NetWare 2.x/3.x-compatible old semaphore subfunctions are now documented at their real parser/reply site in src/sema.c:
- SDK 32/00 / wire subfunction 0x00 Open Semaphore (old)
- SDK 32/01 / wire subfunction 0x01 Examine Semaphore (old)
- SDK 32/02 / wire subfunction 0x02 Wait On Semaphore (old)
- SDK 32/03 / wire subfunction 0x03 Signal Semaphore (old)
- SDK 32/04 / wire subfunction 0x04 Close Semaphore (old)
Request and response payloads were compared against the NDK/Core Protocols PDF, the extracted WebSDK semaphore pages, and nwsync.h. The old 32/00 through 32/04 operations line up with the currently implemented operation set.

Known differences / follow-up:

The PDF/WebSDK tables label SemaphoreHandle as long Lo-Hi. The current src/sema.c implementation parses and emits semaphore handles with GET_BE32() / U32_TO_BE32() while parsing SemaphoreTimeOut as Hi-Lo with GET_BE16(). Keep this documented as a compatibility detail until packet traces or client tests prove the expected wire order for MARS-NWE clients.
Wait On Semaphore currently does not sleep until SemaphoreTimeOut; the simple emulator returns timeout immediately when the semaphore value is not available.
Newer SDK 0x2222/111 semaphore calls are the modern paired variants. They are now source-stub-audited separately at the direct wire 0x6f dispatch slot; any future implementation should bridge to a shared semaphore provider rather than duplicating the old 32/xx implementation.

Direct semaphore group 0x2222/111

Current status:

Direct NCP 0x2222/111 / wire 0x6f is source-stub-audited in src/nwconn.c. There is no active top-level handler for this newer NetWare 3.x/4.x paired semaphore family.
The documented selector slots are recorded in a disabled #if 0 block:
- 111/00 Open/Create a Semaphore
- 111/01 Examine Semaphore
- 111/02 Wait On (P) Semaphore
- 111/03 Signal (V) Semaphore
- 111/04 Close Semaphore
The old 32/xx semaphore group remains the active compatibility path. Future implementation should decode the 111/xx wrapper and share the same semaphore provider/state rather than building a second semaphore table.

Known differences / follow-up:

The NDK documents SemaphoreHandle as long Lo-Hi for both old 32/xx and newer 111/xx families. The active old handler currently uses big-endian helpers for handles; verify client traces before bridging the new family.
This remains local semaphore/synchronization state. It does not belong to nwnds, nwdirectory, or the future directory store.

Direct connection lifecycle and buffer-size calls

Current status:

Direct NCP 0x2222/24 / wire function 0x18 End Of Job is implemented as a paired nwconn.c/nwbind.c handoff. The PDF/WebSDK request has no payload after FunctionCode 24 and the reply has no payload. nwconn.c releases task-local handles and jobs first; nwbind.c closes matching print jobs and sends the final empty success reply.
Direct NCP 0x2222/25 / wire function 0x19 Logout is implemented as a paired nwconn.c/nwbind.c handoff. The PDF/WebSDK request has no payload after FunctionCode 25 and the reply has no payload. nwconn.c releases local queue/file/user state; nwbind.c closes remaining print jobs, writes logout accounting state, clears bindery identity fields, and sends the final empty success reply.
Direct NCP 0x2222/33 / wire function 0x21 Negotiate Buffer Size is handled entirely in src/nwconn.c. The request is ProposedBufferSize as a Hi-Lo word and the reply is AcceptedBufferSize as a Hi-Lo word. The current parser/reply match the documented order. MARS-NWE clamps valid proposals to LOC_RW_BUFFERSIZE; proposals below 512 leave the existing/default negotiated size in force and return that value.

Missing-endpoint check:

These three are direct functions, not nested subfunction groups. No additional subfunctions are listed under SDK 24, SDK 25, or SDK 33 in the local NDK/Core-Protocols PDF/WebSDK material.

Retrospective endpoint coverage rule for audited blocks

Current status:

From this point on, each endpoint-family patch should first list the SDK/PDF/WebSDK endpoints in that family, then compare that list against the real dispatcher cases and any forwarded target handlers before documenting individual request/reply layouts.
Apply the same rule retroactively when touching an already-audited family: message 0x2222/21, directory/quota 0x2222/22, file-server environment 0x2222/23, direct lifecycle 0x2222/24 and 0x2222/25, semaphore 0x2222/32, and buffer negotiation 0x2222/33 should each state whether missing endpoints were checked, and whether the family has active code, disabled future stubs, or no top-level handler.
A disabled #if 0 stub is only a documentation/slot marker. Do not assign return(-1) forwarding semantics to such stubs in nwbind.c; that special forwarding meaning belongs to nwconn.c's handle_ncp_serv() path.

File Server Environment group 0x2222/23

Current status:

NCP 0x2222/23 is handled in src/nwconn.c for the locally parsed file-information subfunctions, while other login, bindery, queue, and management subfunctions are forwarded to src/nwbind.c or existing queue prehandlers.
The group header is documented inline as SubFuncStrucLen (Hi-Lo), SubFunctionCode, and subfunction payload.
Endpoint numbers in SDK/PDF/WebSDK prose are decimal unless explicitly prefixed. The local/forwarded subfunction cases audited so far are:
- SDK 23/00 / wire 0x00 Login User (old) -- disabled future stub
- SDK 23/01 / wire 0x01 Change User Password (old) -- hard failure stub
- SDK 23/02 / wire 0x02 Get User Connection List (old) -- disabled future stub
- SDK 23/05 / wire 0x05 Get Station's Logged Info (old) -- disabled future stub
- SDK 23/12 / wire 0x0c Verify Serialization -- hard failure stub
- SDK 23/15 / wire 0x0f Scan File Information
- SDK 23/16 / wire 0x10 Set File Information
- SDK 23/17 / wire 0x11 Get File Server Information
- SDK 23/18 / wire 0x12 Get Network Serial Number
- SDK 23/19 / wire 0x13 Get Internet Address (old)
- SDK 23/20 / wire 0x14 Login Object
- SDK 23/21 / wire 0x15 Get Object Connection List (old)
- SDK 23/22 / wire 0x16 Get Station's Logged Info (old)
- SDK 23/23 / wire 0x17 Get Login Key
- SDK 23/24 / wire 0x18 Keyed Object Login
- SDK 23/26 / wire 0x1a Get Internet Address
- SDK 23/27 / wire 0x1b Get Object Connection List
- SDK 23/28 / wire 0x1c Get Station's Logged Info
- SDK 23/50 / wire 0x32 Create Bindery Object
- SDK 23/51 / wire 0x33 Delete Bindery Object
- SDK 23/52 / wire 0x34 Rename Object
- SDK 23/53 / wire 0x35 Get Bindery Object ID
- SDK 23/54 / wire 0x36 Get Bindery Object Name
- SDK 23/55 / wire 0x37 Scan Bindery Object
- SDK 23/56 / wire 0x38 Change Bindery Object Security
- SDK 23/57 / wire 0x39 Create Property
- SDK 23/58 / wire 0x3a Delete Property
- SDK 23/59 / wire 0x3b Change Property Security
- SDK 23/60 / wire 0x3c Scan Property
- SDK 23/61 / wire 0x3d Read Property Value
- SDK 23/62 / wire 0x3e Write Property Value
- SDK 23/63 / wire 0x3f Verify Bindery Object Password -- disabled future stub
- SDK 23/64 / wire 0x40 Change Bindery Object Password
- SDK 23/65 / wire 0x41 Add Bindery Object To Set
- SDK 23/66 / wire 0x42 Delete Bindery Object From Set
- SDK 23/67 / wire 0x43 Is Bindery Object In Set
- SDK 23/68 / wire 0x44 Close Bindery
- SDK 23/69 / wire 0x45 Open Bindery
- SDK 23/70 / wire 0x46 Get Bindery Access Level
- SDK 23/71 / wire 0x47 Scan Bindery Object Trustee Paths
- SDK 23/72 / wire 0x48 Get Bindery Object Access Level
- SDK 23/73 / wire 0x49 Is Calling Station A Manager
- SDK 23/74 / wire 0x4a Keyed Verify Password
- SDK 23/75 / wire 0x4b Keyed Change Password
- SDK 23/76 / wire 0x4c List Relations Of An Object
- SDK 23/100 / wire 0x64 Create Queue
- SDK 23/101 / wire 0x65 Destroy Queue
- SDK 23/102 / wire 0x66 Read Queue Current Status (old)
- SDK 23/103 / wire 0x67 Set Queue Current Status (old)
- SDK 23/104 / wire 0x68 Create Queue Job And File (old)
- SDK 23/105 / wire 0x69 Close File And Start Queue Job (old)
- SDK 23/106 / wire 0x6a Remove Job From Queue (old)
- SDK 23/107 / wire 0x6b Get Queue Job List (old)
- SDK 23/108 / wire 0x6c Read Queue Job Entry (old)
- SDK 23/109 / wire 0x6d Change Queue Job Entry (old)
- SDK 23/110 / wire 0x6e Change Queue Job Position -- disabled future stub
- SDK 23/111 / wire 0x6f Attach Queue Server To Queue
- SDK 23/112 / wire 0x70 Detach Queue Server From Queue
- SDK 23/113 / wire 0x71 Service Queue Job (old)
- SDK 23/114 / wire 0x72 Finish Servicing Queue Job (old)
- SDK 23/115 / wire 0x73 Abort Servicing Queue Job (old)
- SDK 23/116 / wire 0x74 Change To Client Rights (old) -- disabled future stub
- SDK 23/117 / wire 0x75 Restore Queue Server Rights -- disabled future stub
- SDK 23/118 / wire 0x76 Read Queue Server Current Status (old) -- disabled future stub
- SDK 23/119 / wire 0x77 Set Queue Server Current Status -- disabled future stub
- SDK 23/120 / wire 0x78 Get Queue Job File Size (old)
- SDK 23/121 / wire 0x79 Create Queue Job And File
- SDK 23/122 / wire 0x7a Read Queue Job Entry
- SDK 23/126 / wire 0x7e Set Queue Current Status
- SDK 23/127 / wire 0x7f Close File And Start Queue Job
- SDK 23/128 / wire 0x80 Remove Job From Queue
- SDK 23/129 / wire 0x81 Get Queue Job List
- SDK 23/130 / wire 0x82 Change Job Priority -- disabled future stub
- SDK 23/131 / wire 0x83 Finish Servicing Queue Job
- SDK 23/132 / wire 0x84 Abort Servicing Queue Job
- SDK 23/133 / wire 0x85 Change To Client Rights -- disabled future stub
- SDK 23/134 / wire 0x86 Read Queue Server Current Status -- disabled future stub
- SDK 23/135 / wire 0x87 Get Queue Job File Size
- SDK 23/200 / wire 0xc8 Check Console Privileges
- SDK 23/201 / wire 0xc9 Get File Server Description Strings
- SDK 23/202 / wire 0xca Set File Server Date And Time -- disabled future stub
- SDK 23/203 / wire 0xcb Disable File Server Login -- disabled future stub
- SDK 23/204 / wire 0xcc Enable File Server Login -- disabled future stub
- SDK 23/205 / wire 0xcd Get File Server Login Status
- SDK 23/207 / wire 0xcf Disable Transaction Tracking -- disabled future stub
- SDK 23/208 / wire 0xd0 Enable Transaction Tracking -- disabled future stub
- SDK 23/209 / wire 0xd1 Send Console Broadcast (old)
- SDK 23/210 / wire 0xd2 Clear Connection Number (old)
- SDK 23/211 / wire 0xd3 Down File Server
- SDK 23/232 / wire 0xe8 Get File Server Misc Information -- disabled future stub
- SDK 23/235 / wire 0xeb Get Connection's Open Files -- disabled future stub
- SDK 23/253 / wire 0xfd Send Console Broadcast -- disabled future stub
- SDK 23/254 / wire 0xfe Clear Connection Number -- disabled future stub
SDK 23/15 request payload offsets match the current parser: LastSearchIndex, DirectoryHandle, SearchAttributes, FileNameLen, and FileName. The reply shape also matches the documented fixed file information block. The SDK/PDF/WebSDK documents LastSearchIndex and NextSearchIndex as Lo-Hi words, while the current code uses GET_BE16() and U16_TO_BE16().
SDK 23/16 request payload field order matches the current parser. The code copies the documented status fields into NW_FILE_INFO after its 14-byte DOS-name prefix and then passes the documented directory handle, search attributes, and filename to nw_set_file_information().
Include cross-checks: NWScanFileInformation()/NWIntScanFileInformation() and NWSetFileInformation() in nwfile.h refer to this same SDK-level file-information family. The server/connection calls cross-check against NWGetFileServerInformation(), NWGetNetworkSerialNumber(), NWGetInternetAddress(), NWGetConnectionInformation(), NWGetObjectConnectionNumbers(), and related connection/server headers.
Bindery object calls SDK 23/50 through SDK 23/56 were compared against the NDK/Core-Protocols PDF, WebSDK API names, and nwbindry.h prototypes. The current nwbind.c parsers match the documented request payload order and Hi-Lo object type/object ID fields. Replies for SDK 23/53, 23/54, and 23/55 match the documented fixed bindery object reply blocks.
Bindery property calls SDK 23/57 through SDK 23/62 were compared against the NDK/Core-Protocols PDF, WebSDK API names, and nwbindry.h prototypes. The current nwbind.c parsers match the documented request payload order, including Hi-Lo ObjectType and Hi-Lo LastInstance/SearchInstance for SDK 23/60. Replies for SDK 23/60 and SDK 23/61 match the documented fixed property reply blocks. SDK 23/62 names the byte after SegmentNumber MoreFlag; the current local variable is named erase_segment, but it consumes that same byte.
Bindery password/set/access calls SDK 23/63 through SDK 23/76 were compared against the NDK/Core-Protocols PDF, WebSDK API names, and nwbindry.h prototypes where available. SDK 23/65 through SDK 23/67 share the documented object/property/member tuple and match the current parsers. SDK 23/68 and SDK 23/69 have no payload and are implemented as successful no-ops. SDK 23/70, 23/72, 23/73, 23/74, 23/75, and 23/76 match their documented request/reply layouts. SDK 23/71 is handled locally in src/nwconn.c because it resolves directory trustee paths; the disabled nwbind.c case comment now points back to that handler. SDK 23/63 / wire 0x3f is documented but not implemented, so a disabled future stub was added next to the surrounding bindery password calls. For SDK 23/64, the local NDK/Core-Protocols PDF text appears to contain a transposed set-member table; the WebSDK/include API shape matches the existing ObjectName/OldPassword/NewPassword parser.
Queue calls SDK 23/100 through SDK 23/108, queue-server and service calls SDK 23/109 through SDK 23/115, the old job-size call SDK 23/120, and the paired newer variants SDK 23/121 through SDK 23/129, SDK 23/131, SDK 23/132, and SDK 23/135 were compared against the nwqms.h prototypes and extracted WebSDK queue pages. src/nwconn.c performs required prehandling for queue path rewriting, queue-job file creation, queue job entry file-handle insertion, and close/start file association before forwarding to src/nwbind.c. The target handlers in nwbind.c now carry the concrete request/reply layout notes. The newer queue job-control calls that document 32-bit job numbers are intentionally noted where the current compatibility parser still consumes or emits old 16-bit job-number fields.
Remaining queue rights/status/priority calls SDK 23/110, SDK 23/116 through SDK 23/119, SDK 23/130, SDK 23/133, and SDK 23/134 were compared against the NDK/Core-Protocols PDF and nwqms.h/nwqueue.h prototypes. They are not implemented in the current queue backend. nwbind.c now documents them as disabled future stubs rather than leaving the wire slots implicit: job-position reorder, queue-server identity switch/restore, the per-server 64-byte status record, and newer long-priority/client-rights forms.
Console/server-management calls SDK 23/200 through SDK 23/211, plus SDK 23/232, SDK 23/235, SDK 23/253, and SDK 23/254, were compared against the NDK/Core-Protocols PDF and server/connection/message include prototypes (nwserver.h, nwconnec.h, nwmsg.h, and NLM nwenvrn.h). Implemented calls now carry inline layout notes in src/nwbind.c: console privilege check, description strings, login status, old console broadcast, old clear connection, and down server. Missing or non-modelled management calls are documented as disabled future stubs: set server date/time, enable and disable logins, enable and disable TTS, misc server information, open-file enumeration, new 32-bit console broadcast, and new 32-bit clear connection.

Follow-up:

Verify SDK 23/15 search-index byte order against a real old requester or direct test caller before changing the current big-endian parser/reply.
SDK 23/12 / wire 0x0c Verify Serialization is currently a hard failure stub; the PDF/WebSDK endpoint title is decimal 23/12, while one table row prints SubFunctionCode (212), so do not add a wire 0xd4 case without a packet trace or include-level confirmation.
SDK 23/17 / wire 0x11 returns the legacy server-info block; later PDF revisions name additional fields inside the current reserved tail. Keep the current behaviour until a client requires those fields.
SDK 23/18 / wire 0x12 documents the serial/application reply as Lo-Hi, while the current code writes both fields with big-endian helpers.
SDK 23/23 / wire 0x17 documents a TargetConnection byte, but the current implementation ignores it and returns a login key for the active connection.
SDK 23/27 / wire 0x1b documents SearchConnNumber and returned connection numbers as Lo-Hi long values; the current code reads the search number with GET_BE32() and returns 16-bit connection numbers.
Implement or deliberately hard-fail SDK 23/63 / wire 0x3f Verify Bindery Object Password; it is a NetWare 2.x/3.x compatibility call and is currently only a disabled documented stub.
Verify the shared queue handlers for newer queue calls that currently consume old 16-bit fields: SDK 23/122 / wire 0x7a, SDK 23/127 / wire 0x7f, SDK 23/128 / wire 0x80, SDK 23/131 / wire 0x83, SDK 23/132 / wire 0x84, and SDK 23/135 / wire 0x87 document long or Lo-Hi job-number fields in the WebSDK/include material, while the current compatibility parser often reuses the old 16-bit layout. SDK 23/126 / wire 0x7e also documents a long queue-status field but the shared parser consumes only one byte.
Implement or deliberately hard-fail the disabled queue future stubs once the queue backend can support their semantics: SDK 23/110 / wire 0x6e Change Queue Job Position, SDK 23/116 / wire 0x74 and SDK 23/133 / wire 0x85 Change To Client Rights, SDK 23/117 / wire 0x75 Restore Queue Server Rights, SDK 23/118 / wire 0x76 and SDK 23/134 / wire 0x86 Read Queue Server Current Status, SDK 23/119 / wire 0x77 Set Queue Server Current Status, and SDK 23/130 / wire 0x82 Change Job Priority.
SDK 23/205 / wire 0xcd Get File Server Login Status currently returns a one-byte enabled flag. The PDF documents a long UserLoginAllowed reply, while the CLIB/WebSDK prototype exposes a byte flag; verify expected wire length with a real client before changing the compatibility reply.
SDK 23/209 / wire 0xd1 Send Console Broadcast (old) is parsed as the old byte station-list form. The PDF table labels StationList as long[], but its own SubFuncStrucLen = 3 + NumberOfStations + MessageLen formula matches the byte-list parser; keep the newer 32-bit list in SDK 23/253 / wire 0xfd separate.
SDK 23/211 / wire 0xd3 Down File Server currently ignores the documented ForceFlag and always calls the local server-down path after supervisor-rights validation. Verify whether a non-forced request should fail when active files are open before changing behavior.
Implement or deliberately hard-fail the disabled management future stubs once the corresponding server state exists: SDK 23/202, SDK 23/203, SDK 23/204, SDK 23/207, SDK 23/208, SDK 23/232, SDK 23/235, SDK 23/253, and SDK 23/254.
Audit the remaining forwarded 0x2222/23 management subfunctions in the files that actually handle them instead of treating the nwconn.c forwarding points as complete local implementations.

Extended volume information field mapping

Current status:

NCP 0x16/0x33 Get Extended Volume Information returns the documented NWVolExtendedInfo reply and fills the core fields that can be derived from generic Unix filesystem statistics.
NetWare-specific fields that MARS-NWE does not currently model are returned as zero for now instead of guessed values.

Follow-up:

Fill additional NWVolExtendedInfo fields when reliable data is available from the backing filesystem or from MARS-NWE metadata.
Candidate fields include suballocation, deleted-file/limbo accounting, compression counters, migration counters, EA counters, Directory Services object id, and last-modified timestamp data.
Treat compression-related fields as real follow-up work rather than permanent zeroes; populate them only when the backing filesystem exposes trustworthy compressed-file or compressed-block accounting.

Object disk restriction fallback coverage

Current status:

NCP 0x16/0x29 Get Object Disk Usage And Restrictions keeps the existing QUOTA_SUPPORT split.
With quota support enabled, the endpoint is routed through nwbind so the bindery Object ID can be mapped to a Unix uid before querying the quota backend.
Without quota support, the endpoint returns the SDK-compatible fallback: unrestricted (0x40000000) and no space in use.

Follow-up:

Add direct tests for both build modes.
Verify the quota-enabled path against a real Unix quota setup.
Verify that the quota-disabled fallback remains compatible with requesters and with the WebSDK rule for invalid object IDs.

Server logging schema

Current status:

Server logging is useful during protocol work, but output is still noisy and not formatted consistently across NCP, namespace/path mapping, AFP, bindery, file, queue, trustee, and salvage code.
During salvage endpoint development, verbose logs are preferred over missing diagnostic information, but the messages should become easier to grep and compare across subsystems.

Follow-up:

Normalize new server log lines toward this shape:
```
<LVL4> <AREA> <DEC-CODE> <EVENT> key=value ...
```
Use four-character levels so columns do not jump around:
- INFO
- DBUG
- WARN
- ERRR
Put the level first, then the subsystem/function area, for example NCP, SALVAGE, AFP, MAP, BIND, TRUST, AUTH, CONN, FILE, or QUEUE.
Use decimal/protocol-facing endpoint identifiers near the front when they are what the documentation uses, for example 87/16, 87/17, and 87/18.
Keep exact wire values as hex key/value fields later in the same line, for example fn=0x57 sub=0x10 ns=0x00 seq=0x00000000 vol=0x0000 base=0x00000004 result=0x89ff.

Mark missing or unimplemented endpoints with a stable UNKNOWN event, for example:

INFO NCP 87/18 UNKNOWN fn=0x57 sub=0x12 msg="not implemented"
INFO NCP 87/255 UNKNOWN fn=0x57 sub=0xff msg="unknown subfunction"
INFO NCP 136 UNKNOWN fn=0x88 msg="unknown function"

Prefer existing mars_nwe logging functions/macros. Do not introduce a second logging subsystem just to change the message format.
Convert noisy areas gradually, starting with NCP function/subfunction dispatch and the salvage endpoints.

Printing / Queue backend

Q_UNIX_PRINT backend status

Current status:

Queue metadata handling and the Q_UNIX_PRINT backend are intentionally separate.
The backend can already call /usr/bin/lp, lpr, or a custom script.

Follow-up:

Improve logging around queue job submission to the Unix print command.
Capture and expose backend exit status where possible.
Consider direct CUPS integration only if MARS_NWE needs CUPS job IDs, cancellation, or status polling. Do not add a hard CUPS dependency for basic queue compatibility.

Transaction Tracking System (TTS)

Current status:

NCP 0x2222/34 / wire 0x22 is endpoint-audited in src/nwconn.c.
34/00 TTS Is Available reports the WebSDK/NDK-documented unavailable status by returning completion 0x00 and no reply payload.
The SDK-listed through-3.x TTS subfunctions are documented inline: 34/01 Begin Transaction, 34/02 End Transaction, 34/03 Abort Transaction, 34/04 Transaction Status, 34/05/34/06 application thresholds, 34/07/34/08 workstation thresholds, and 34/09/34/10 transaction bits.
MARS-NWE does not currently implement TTS rollback semantics, transaction files, transaction status tracking, threshold state, or begin/end/abort transaction state. The non-availability subfunctions intentionally return 0xfb instead of pretending to succeed.
No SDK-listed through-3.x TTS subfunctions beyond 34/10 were found in the NDK/Core-Protocols TTS table during this audit.

Follow-up:

Implement TTS only if a concrete client requires it.
Treat this as a real transaction subsystem, not as a completion-code shim: the SDK calls require transaction numbering/status, rollback/backout, threshold state, control flags, and interaction with logical/physical locks.
If TTS is ever implemented, add tests that prove 34/02 returns a real TransactionNumber and that 34/04 reports status for that number.

Old direct file commit/search calls

Current status:

NCP 0x2222/59 / wire 0x3b Commit File and 0x2222/61 / wire 0x3d Commit File are endpoint-audited in src/nwconn.c. They share the same old six-byte file-handle request layout and return no reply payload. MARS-NWE commits the low four-byte handle via GET_32() and ignores the reserved/extended high bytes, matching the existing host file-handle model.
NCP 0x2222/62 / wire 0x3e File Search Initialize is endpoint-audited. The request payload after FunctionCode is DirectoryHandle, DirectoryPathLen, and DirectoryPath; the response returns volume, directory id, search sequence, and directory rights.
NCP 0x2222/63 / wire 0x3f File Search Continue is endpoint-audited. The parser reads volume, directory id, search sequence, search attributes, search path length, and search path in the documented old order. The reply returns the new search sequence, directory id, and the project's NW_FILE_INFO/NW_DIR_INFO compatibility body.
NCP 0x2222/64 / wire 0x40 Search for a File is endpoint-audited as the old two-byte-sequence direct search variant. It is intentionally documented separately from the newer 22/30 and 87/03 namespace search families.

Follow-up:

Verify old direct search replies against a real requester or packet test, especially the exact NW_FILE_INFO/NW_DIR_INFO packing and directory body.
Decide later whether the ignored high/extended bytes in the old six-byte file handle should remain compatibility padding or participate in a future handle table expansion.

Extended Attribute group 0x2222/86

Current status:

NCP 0x2222/86 / wire 0x56 is endpoint-audited as the old Extended Attribute group. src/nwconn.c forwards requestdata starting at the EA SubFunction byte to handle_func_0x56() in src/namspace.c, and maps the handler's non-negative return value to data_len or its negative return value to the NCP Completion code.
The NDK/Core-Protocols EA table lists through-3.x subfunctions 86/01 through 86/05; all five source slots are present in src/namspace.c, so no additional disabled source stubs are needed for this block.
86/01 Close Extended Attribute Handle is a success shim: it ignores the handle and returns no reply payload.
86/02 Write Extended Attribute is a success shim: it does not persist EA data and currently returns no reply payload, although the NDK reply format includes ErrorCode, BytesWritten, and NewEAHandle.
86/03 Read Extended Attribute returns a fixed body with ErrorCode 0xc9 / ERR_EA_NOT_FOUND and zero lengths/handle fields, rather than reading real EA storage.
86/04 Enumerate Extended Attribute returns a fixed all-zero body and no enumerated EA structures.
86/05 Duplicate Extended Attributes has a source case but is intentionally unimplemented and returns unknown request via 0xfb.

Follow-up:

Keep this block as a compatibility shim unless a concrete client needs real Extended Attribute storage.
If real EA support is added, decide whether to use the existing Unix xattr layer, the future libdirectory store, or a filesystem-backed sidecar, and add packet tests for the Lo-Hi EA handle structs, flag information levels, and multi-action EA return values.

Name Space group 0x2222/87 core block

Current status:

NCP 0x2222/87 / wire 0x57 is endpoint-audited for the core namespace subfunctions 87/01 through 87/12. src/nwconn.c forwards requestdata starting at the Name Space SubFunction byte to handle_func_0x57() in src/namspace.c, and maps a non-negative handler return value to data_len or a negative value to the NCP Completion code.
The audited source slots are present for 87/01 Open/Create File or Subdirectory, 87/02 Initialize Search, 87/03 Search for File or Subdirectory, 87/04 Rename Or Move, 87/05 Scan for Trustees, 87/06 Obtain File/Subdirectory Information, 87/07 Modify DOS Information, 87/08 Delete, 87/09 Set Short Directory Handle, 87/10 Add Trustee Set, 87/11 Delete Trustee Set, and 87/12 Allocate Short Directory Handle.
No new disabled source stubs were needed for this core block: the local NDK/Core-Protocols table jumps from 87/12 to salvageable-file calls such as 87/16, and no default-compatibility 87/13..87/15 endpoints were found during this pass.
Current compatibility notes are documented inline per endpoint. Important differences include 87/03 returning at most one entry and treating the data stream as the same value as NameSpace, and 87/10/87/11 expecting trustee entries after fixed legacy path-structure areas.

Follow-up:

Continue the 0x2222/87 audit after the later salvage/metadata subset. Keep the comments per endpoint rather than adding a large pre-block checklist.

Name Space group 0x2222/87 salvage and metadata subset

Current status:

NCP 0x2222/87 / wire 0x57 is endpoint-audited for the later salvage/metadata/namespace subfunctions 87/16 through 87/29 that are present in the current source range.
Active source cases are documented inline for 87/16 Scan Salvageable Files, 87/17 Recover Salvageable File, 87/18 Purge Salvageable File, 87/20 Search for File or Subdirectory Set, 87/21 Get Path String from Short Directory Handle, 87/22 Generate Directory Base and Volume Number, 87/24 Get Name Spaces Loaded List from Volume Number, 87/26 Get Huge NS Information, 87/28 Get Full Path String, and 87/29 Get Effective Directory Rights.
Disabled source stubs were added for eligible 3.x/4.x metadata gaps that were not active in the source: 87/19 Get NS Information, 87/23 Query NS Information Format, 87/25 Set NS Information, and 87/27 Get Name Space Directory Entry. These stubs are documentation-only and do not change runtime behavior.
87/26 already had a source slot, but it is effectively unimplemented and still returns the default 0xfb unknown request completion.

Name Space group 0x2222/87 open/create callback subset

Current status:

NCP 0x2222/87 / wire 0x57 is source-stub-audited for the next documented namespace subfunctions 87/30 through 87/35.
The current source did not contain active handlers for this range, so disabled #if 0 stubs were added at the correct selector locations for: 87/30 Open/Create File or Subdirectory with DataStream, 87/31 Get File Information, 87/32 Open/Create File or Subdirectory with Callback, 87/33 Open/Create File or Subdirectory II with Callback, 87/34 Open CallBack Control, and 87/35 Modify DOS Attributes on a File or Subdirectory.
These endpoints are eligible under the stub rule because they are 3.x/4.x namespace/file-system compatibility calls, including planned 4.x callback and DataStream variants. The stubs are documentation-only and leave runtime behavior unchanged.

Follow-up:

Continue the namespace audit with the remaining 87 subfunction ranges such as 87/36..87/44, 87/64..87/69, or the matching 89 long-name-space family. Keep future missing 1.x/2.x/3.x and planned 4.x endpoints as disabled source stubs at the correct selector location, not as prose-only notes.

Name Space group 0x2222/87 lock/quota/search/salvage-rights subset

Current status:

NCP 0x2222/87 / wire 0x57 is source-stub-audited for the next documented namespace/file subfunctions 87/36 through 87/43.
The active source had no handlers for this range, so disabled #if 0 stubs were added at the correct selector locations for: 87/36 Log File, 87/37 Release File, 87/38 Clear File, 87/39 Get Directory Disk Space Restriction, 87/40 Search for File or Subdirectory Set (Extended Errors), 87/41 Scan Salvageable File List, 87/42 Purge Salvageable File List, and 87/43 Revoke File Handle Rights.
87/44 Update File Handle Rights is documented as NetWare 5.x in the NDK material, so it is intentionally not added as a source stub under the current 1.x/2.x/3.x plus planned-4.x scope.
These stubs are documentation-only and leave runtime behavior unchanged.

Name Space group 0x2222/87 later-generation high selectors

Current status:

The remaining SDK-listed high selectors in the 0x2222/87 / wire 0x57 family are explicitly reviewed for scope rather than implemented or stubbed: 87/44 Update File Handle Rights, 87/64 Read File, 87/65 Write to a File, 87/66 Get Current Size of File, 87/67 Log Physical Record, 87/68 Release Physical Record, and 87/69 Clear Physical Record.
These selectors are later-generation NDK additions and are outside the current 1.x/2.x/3.x plus planned-4.x source-stub rule. Do not add #if 0 cases for them during the current endpoint audit unless the project scope is explicitly extended beyond NetWare 4.x.
The older direct file-I/O calls (65..77) and old/new physical-record calls already audited in nwconn.c remain the compatibility paths for the current scope.

Follow-up:

The 87 family is now closed for the current endpoint-audit scope. Continue with the matching 89 Enhanced Name Space family as out-of-current-scope documentation, AFP 35, or another unaudited endpoint family requested by the user.

Enhanced Name Space group 0x2222/89

Current status:

NCP 0x2222/89 / wire 0x59 Enhanced Name Space has been reviewed for generation scope. src/nwconn.c has no top-level case 0x59, and the local NDK/Core-Protocols Enhanced NCP chapter lists the 89/xx operations as a later-generation family, with request pages such as 89/04 and 89/17 marked for NetWare Servers 6.5 SP2.
The documented 89 selectors are enhanced variants of namespace, trustee, salvage, EA, and rights calls already represented for the current scope by the 86 EA and 87 namespace audits. Examples include 89/01 Open/Create, 89/02 Initialize Search, 89/03 Search, 89/04 Rename/Move, 89/05 Scan Trustees, 89/06 Obtain Information, 89/07 Modify DOS Information, 89/08 Delete, 89/09 Set Short Directory Handle, 89/10 Add Trustee Set, 89/11 Delete Trustee Set, 89/12 Allocate Short Directory Handle, salvage and metadata selectors 89/16, 89/17, 89/19, 89/20, 89/22, 89/25, 89/28, 89/29, 89/35, 89/39, 89/40, plus enhanced EA/rights selectors 89/50, 89/52, 89/53, 89/54, and 89/71.
Under the current target rule, this block is out of source-stub scope because it is later than the planned NetWare 4.x compatibility target. Do not add a disabled top-level case 0x59 or per-selector #if 0 stubs unless the project scope is explicitly extended beyond NetWare 4.x.

Follow-up:

If the target is extended later, treat 89 as a filesystem/namespace provider family, not NDS. Reuse the normalized selector-path audit style from 87, and map any real implementation onto the future filesystem/namespace provider rather than nwnds.

NDS/NCP Fragger group 0x2222/104

Current status:

NCP 0x2222/104 / wire 0x68 is planned NetWare-4.x/NDS work, not a default NetWare-3.x server feature. src/nwconn.c already had a top-level case 0x68 that returns 0xfb; patch 0217 keeps that runtime behavior and adds disabled MARS_NWE_4 source-stub selectors for the documented NDS subfunctions.
The documented selector slots are 104/01 Ping for NDS NCP, 104/02 Send NDS Fragmented Request/Reply, 104/03 Fragment Close, 104/04 Return Bindery Context, 104/05 Monitor NDS Connection, 104/06 Return NDS Statistics, 104/07 Clear Statistics, and 104/08 Reload NDS Software.
104/02 is a nested-selector endpoint: after the NDS SubFunctionCode it carries a 32-bit NDS Verb payload field. Document selector paths as 0x2222/104/02 verb=<Verb> when future nwnds work reaches this block; do not flatten the verb into a one-byte NCP case.
Future implementation belongs to nwnds and libdirectory, with nwserv used only for control-plane actions such as reload/supervision. Normal NDS request payloads must not be routed through nwserv as a data-plane broker.

Follow-up:

Keep the MARS_NWE_4 stubs disabled until a real nwnds/fragment-state design exists. The next endpoint audit can continue with deeper 23 bindery/property/admin coverage, 36/37 NCP Extension scope, print/spool 17, or another user-selected family.

Retrospective source-stub coverage for already audited blocks

Current status:

The endpoint-stub scope is source-level as well as documentation-level. When an already audited family has a documented 1.x/2.x/3.x compatibility gap or a planned 4.x gap, the dispatcher should contain a disabled #if 0 slot marker at the correct numeric case, unless that slot is already active.
Retro-check of the already touched families found the known eligible stubs already present in source:
- Directory Services 22/12 / wire 0x0c, 22/35 / wire 0x23, and 22/36 / wire 0x24 are disabled source stubs in src/nwconn.c.
- File Server Environment 23 queue/server-management gaps that were previously documented as disabled stubs are present in src/nwbind.c.
No source stubs are needed for message 21/04..21/08 because they were not default-compatibility server endpoints in the checked SDK/PDF/WebSDK material. 21/12 remains later-generation only and should stay out of source under the current through-4.x planning scope.
Physical-record 26..31 plus 110, TTS 34/00..34/10, and direct file commit/search/I/O 59, 61..77 did not expose additional eligible missing slots during the retro-check.

Follow-up:

For each next endpoint-family patch, record the source outcome inline: active case, already-present disabled stub, newly added disabled stub, no server endpoint, or later-generation/out-of-scope.
If a disabled stub already exists, do not churn its code merely to restyle it; add or adjust prose only unless the user explicitly asks for cleanup or the endpoint is being implemented.

AFP / Mac namespace backend

Current status:

The current AFP compatibility slice is implemented and covered by the smoke tests under tests/afp/. Endpoint inventory, WebSDK audit notes, and AFP implementation history live in that directory instead of this project-level TODO file.
AFP 0x13 Get Macintosh Info On Deleted File is implemented as a salvage/deleted-entry adapter and covered by the AFP smoke suite. It returns FinderInfo, ProDOSInfo, resource fork size, and deleted filename from the shared Salvage snapshot.
ProDOSInfo is persisted through the existing nwatalk AFP metadata xattr layer (org.mars-nwe.afp.prodos-info) and is captured/restored in Salvage as prodos_info_hex; no parallel AFP metadata store was added.
The verified AFP smoke suite covers live FinderInfo/ProDOSInfo xattrs, AFP 35/19 deleted-file metadata, and the readonly Modify-rights negative path.
Keep future AFP deleted-file work on the shared salvage backend; do not expose .recycle or .salvage through normal AFP/NCP path opens.
Keep AFP metadata restore/lookup paths tied to the existing mars_nwe AFP and nwatalk mechanisms, not a new side database.
Keep the detailed AFP inventory and audit notes in tests/afp/.
Patch 0214 also records the NCP-level AFP 35/01..35/19 coverage inline in src/nwconn.c: all documented NDK/Core-Protocols AFP subfunctions in that range are represented by the current dispatcher, so no new missing-endpoint source stubs are needed for the current 1.x/2.x/3.x plus planned-4.x scope.

Follow-up:

AFP endpoint coverage is now documented at the NCP dispatcher level. Continue any remaining WebSDK/client-trace cleanup only where tests/afp/ inventory files still mark a behavioral or metadata-layout issue.

Deferred / optional protocol work

Basic Packet Burst file transfer support is implemented and verified with a diagnostics-enabled DOS client test.
Packet Burst support is built by default, but runtime use remains controlled by nwserv.conf. Endpoint coverage for SDK 97 and 101 is now documented; remaining Packet Burst work is behavioral/client-trace driven.
Packet Burst/NDS fragmentation support remains out of scope unless a concrete client requires it.

74 KiB Raw Blame History

TODO

Server / NCP compatibility

Console privilege model

Queue spool path case handling

NCP 17/4C test coverage

NCP endpoint SDK documentation / stub audit

NCP endpoint audit tracking

NCP endpoint layout audit (version-bucketed compatibility)

Version buckets for endpoints documented so far

SDK-listed 0x2222 blocks not yet endpoint-audited

Old direct file/logical/physical synchronization calls

Legacy utility and message/broadcast calls

Directory Services group 0x2222/22

Semaphore group 0x2222/32

Direct semaphore group 0x2222/111

Direct connection lifecycle and buffer-size calls

Retrospective endpoint coverage rule for audited blocks

File Server Environment group 0x2222/23

Extended volume information field mapping

Object disk restriction fallback coverage

Server logging schema

Printing / Queue backend

Q_UNIX_PRINT backend status

Transaction Tracking System (TTS)

Old direct file commit/search calls

Extended Attribute group 0x2222/86

Name Space group 0x2222/87 core block

Name Space group 0x2222/87 salvage and metadata subset

Name Space group 0x2222/87 open/create callback subset

Name Space group 0x2222/87 lock/quota/search/salvage-rights subset

Name Space group 0x2222/87 later-generation high selectors

Enhanced Name Space group 0x2222/89

NDS/NCP Fragger group 0x2222/104

Retrospective source-stub coverage for already audited blocks

AFP / Mac namespace backend

Deferred / optional protocol work

74 KiB

Raw Blame History