mars_nwe/mars-nwe
1
0
Fork 0
Code Issues Pull Requests Actions Projects Releases 2 Wiki Activity

docs: document core NCP 22 directory layouts

Browse Source
This commit is contained in:
Mario Fetka
2026-06-01 19:19:26 +00:00
committed by Mario Fetka
parent fba1939610
commit dd64d83979
3 changed files with 176 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
AI.md
View File

@@ -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.

95
TODO.md
View File

@@ -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

105
src/nwconn.c
View File

@@ -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];