diff --git a/AI.md b/AI.md index 9278a6b..dd8b5fc 100644 --- a/AI.md +++ b/AI.md @@ -27,6 +27,14 @@ use, the current project status that the user pasted into the chat. cleanup, and logging refactors unless the user asks for that. - If a patch is only documentation or test cleanup, keep it that way. +## Current protocol audit scope + +- The current endpoint documentation/audit pass is scoped to NetWare 3.x-compatible NCPs. Do not add NetWare 5.x / MOAB-only endpoints or TODOs unless the user explicitly asks for later-version coverage. +- When a `0x2222` group is forwarded out of `nwconn.c`, document both layers: `nwconn.c` should explain the group handoff/header, and the destination file (for example `nwbind.c`) should document concrete subfunction request/reply layouts. +- For documentation-only endpoint patches, do not change parser offsets, byte order, reply layout, or completion behavior. If the code differs from the SDK layout, document the difference inline and mirror it in `TODO.md` for later testing. +- Keep `TODO.md` endpoint audit notes grouped by logical endpoint family instead of as one long flat list. +- The rejected `0152-docs-note-message-control-subfunction.patch` must not be applied: it documented `0x2222/21/0x0c Connection Message Control`, which is outside the NetWare 3.x MARS-NWE target scope. + ## mars-nwe coding style rules - Prefer existing mars_nwe / NetWare functions over new helper code. diff --git a/TODO.md b/TODO.md index e134eb8..c9e0b32 100644 --- a/TODO.md +++ b/TODO.md @@ -90,16 +90,27 @@ Follow-up: paths intentionally forward bindery/global-server work to `nwbind`. -### NCP synchronization endpoint audit +### NCP endpoint layout audit (NetWare 3.x compatibility) Current status: -- The old NCP synchronization endpoint family in `src/nwconn.c` is now - annotated with Novell SDK endpoint names. -- The existing source already marked this area as not well tested, so the - comments intentionally keep that compatibility warning visible. -- `NCP 0x03`, `0x05`, `0x06`, `0x07`, `0x08`, `0x09`, `0x0a`, `0x0b`, - `0x0d`, `0x0e`, `0x1a`, and `0x1e` have local implementations. +- The NCP endpoint audit is scoped to NetWare 3.x-compatible calls unless the + user explicitly asks for later NetWare/OES additions. Do not add NetWare 5.x + / MOAB-only endpoints to the implementation TODO list. +- 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. + +#### 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`. @@ -118,21 +129,11 @@ Current status: 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 now. + Record` have inline SDK request-layout documentation. - `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 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 now have inline SDK request/reply layout documentation. -- The forwarded `NCP 0x15` message subfunctions in `src/nwbind.c` now have - inline SDK request/reply layout documentation for broadcast send/get, - enable/disable, and console broadcast calls. -- `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: @@ -144,27 +145,61 @@ Follow-up: - 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` and `0x08` should consume or ignore the documented - `LockFlag` byte 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. -- Decide whether `0x0d` and `0x0e` should consume or ignore the documented - `LockFlag` byte 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. + +#### 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 3.x `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. +- `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 whether `NCP 0x2222/21/10 Send Broadcast Message` must accept the SDK-documented long connection list and return long completion flags, or whether the current 16-bit connection list plus byte status reply is the requester-compatible format used by the clients MARS-NWE supports. -- Verify the implemented file/logical-record/physical-record calls against the - Novell SDK request/reply layouts and a real DOS requester or direct test - caller. -- Continue direct requester or NWTESTS coverage for the file, logical-record, - and physical-record synchronization calls that are now wired. -- Verify timeout and error-code behavior for set-oriented locking calls against - a real requester, especially where MARS-NWE currently relies on the existing - underlying share implementation. + +#### Directory Services group 0x2222/22 + +Current status: + +- `NCP 0x2222/22` is handled in `src/nwconn.c`, not forwarded to `nwbind.c`. +- The group header is documented inline as `SubFuncStrucLen` (Hi-Lo), + `SubFunctionCode`, and subfunction payload. +- The first NetWare 2.x/3.x directory services subfunctions now have inline SDK + request/reply layout documentation: `22/00` Set Directory Handle, `22/01` + Get Directory Path, `22/02` Scan Directory Information, `22/03` Get + Effective Directory Rights, `22/04` Modify Maximum Rights Mask, `22/05` Get + Volume Number, and `22/06` Get Volume Name. +- The old SDK PDF table for `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. + +Follow-up: + +- Continue the `0x2222/22` audit from `22/0a` Create Directory onward, keeping + each patch to a small logical endpoint block. +- Verify the documented `22/00` source-handle interpretation against an old + requester or direct test caller before changing behavior. ### Extended volume information field mapping diff --git a/src/nwconn.c b/src/nwconn.c index fc8a4f0..c59cf85 100644 --- a/src/nwconn.c +++ b/src/nwconn.c @@ -3220,8 +3220,7 @@ static int handle_ncp_serv(void) /* * NCP 0x2222/21 is the Message NCP function group. The SDK routes * individual message calls through a nested SubFunctionCode, for - * example old broadcast send/get calls and newer connection-message - * control calls. + * example the NetWare 3.x broadcast send/get and enable/disable calls. * * SDK group request header: * @@ -3241,6 +3240,28 @@ static int handle_ncp_serv(void) return(-1); /* nwbind must do this call */ case 0x16 : { + /* + * NCP 0x2222/22 is the old Directory Services function group. + * These calls use the classic nested NCP 22 group header: + * + * requestdata[0..1] SubFuncStrucLen (Hi-Lo) + * requestdata[2] SubFunctionCode + * requestdata[3..] subfunction-specific payload + * + * The first NetWare 2.x/3.x-compatible directory calls are + * documented by the SDK as: + * + * 22/00 Set Directory Handle + * 22/01 Get Directory Path + * 22/02 Scan Directory Information + * 22/03 Get Effective Directory Rights + * 22/04 Modify Maximum Rights Mask + * 22/05 Get Volume Number + * 22/06 Get Volume Name + * + * Layout notes below document the current parser; this patch does not + * change wire behavior. + */ /* uint8 len = *(requestdata+1); */ uint8 *p = requestdata +2; @@ -3248,6 +3269,22 @@ static int handle_ncp_serv(void) case 0 : { /******** SetDirektoryHandle *************/ + /* + * NCP 0x2222/22/00 Set Directory Handle. + * + * SDK request payload after the group header: + * byte TargetDirectoryHandle + * byte SourceDirectoryHandle + * byte DirectoryPathLen + * byte DirectoryPath[DirectoryPathLen] + * + * The old PDF table repeats TargetDirectoryHandle for the + * second byte, but the remarks and the mars_nwe parser use + * it as SourceDirectoryHandle. + * + * Reply: completion code only; the target handle is remapped + * to the requested source/path directory. + */ struct INPUT { uint8 header[7]; /* Requestheader */ uint8 div[3]; /* 0x0, dlen, ufunc */ @@ -3267,6 +3304,16 @@ static int handle_ncp_serv(void) case 0x1 : { /******** GetDirektoryPATH ***************/ + /* + * NCP 0x2222/22/01 Get Directory Path. + * + * SDK request payload: + * byte TargetDirectoryHandle + * + * SDK reply payload: + * byte DirectoryPathLen + * byte DirectoryPath[DirectoryPathLen] + */ struct INPUT { uint8 header[7]; /* Requestheader */ uint8 div[3]; /* 0x0, dlen, ufunc */ @@ -3289,6 +3336,26 @@ static int handle_ncp_serv(void) case 0x2 : { /* Scan Direktory Information */ /******** Scan Dir Info ****************/ + /* + * NCP 0x2222/22/02 Scan Directory Information. + * + * SDK request payload: + * byte DirectoryHandle + * word StartingSearchNumber (Hi-Lo) + * byte DirectoryPathLen + * byte DirectoryPath[DirectoryPathLen] + * + * SDK reply payload: + * byte DirectoryPath[16] + * word CreationDate (Hi-Lo) + * word CreationTime (Hi-Lo) + * long OwnerTrusteeID (Hi-Lo) + * byte AccessRightsMask + * byte Reserved + * word NextSearchNumber (Hi-Lo) + * + * The current INPUT struct matches this old layout. + */ struct INPUT { uint8 header[7]; /* Requestheader */ uint8 div[3]; /* 0x0, dlen, ufunc */ @@ -3322,6 +3389,17 @@ static int handle_ncp_serv(void) case 0x3 : { /* Get Direktory Rights */ /******** Get Eff Dir Rights ****************/ + /* + * NCP 0x2222/22/03 Get Effective Directory Rights. + * + * SDK request payload: + * byte DirectoryHandle + * byte DirectoryPathLen + * byte DirectoryPath[DirectoryPathLen] + * + * SDK reply payload: + * byte EffectiveRightsMask + */ struct XDATA { uint8 eff_right_mask; /* Effektive Right to Dir, old! */ } *xdata = (struct XDATA*) responsedata; @@ -3365,6 +3443,16 @@ static int handle_ncp_serv(void) case 0x5 : { /* Get Volume Number 0 .. 31 */ /******** GetVolume Number ***************/ + /* + * NCP 0x2222/22/05 Get Volume Number. + * + * SDK request payload: + * byte VolumeNameLen + * byte VolumeName[VolumeNameLen] + * + * SDK reply payload: + * byte VolumeNumber + */ /* p+1 = namelen */ /* p+2 = data z.b 'SYS' */ struct XDATA { @@ -3380,6 +3468,19 @@ static int handle_ncp_serv(void) case 0x6 : { /* Get Volume Name from 0 .. 31 */ /******** Get Volume Name ***************/ + /* + * NCP 0x2222/22/06 Get Volume Name. + * + * SDK request payload: + * byte VolumeNumber + * + * SDK reply payload: + * byte VolumeNameLen + * byte VolumeName[VolumeNameLen] + * + * The SDK allows a successful empty name for an unused but + * potential volume slot. + */ struct XDATA { uint8 namelen; uint8 name[16];