Differences

This shows you the differences between two versions of the page.

--- b2f:start [2025/02/11 19:55] – created f4hof
+++ b2f:start [2025/02/15 10:13] (current) – [Standard Forwarding protocol (MBL/RLI)] f4hof
@@ Line 1: / Line 1: @@
-====== B2 Forwarding protocol ======
+====== BBS Forwarding protocol ======
+**WARNING** At this stage, this page is the scratchpad of an attempt to summarize everything related to the BBS forwarding protocol (including Winlink extensions). Considering the poor redactional and lacunar nature of the reference documentation, DO NOT take the content of this page at face value until this message disappears. Here be dragons, don't come complaining.
 ===== SID =====
@@ Line 46: / Line 47: @@
 ==== Required extensions for Winlink ====
-TODO Actually challenge which extensions break the nominal operation of Winlink Express
+FIXME Fuzz Wl2k express to see which extensions break its nominal operation.
 Here are the strict minimum extensions required by Winlink to accept a remote party, according the selected mode of operation:
@@ Line 56: / Line 57: @@
 | P2P |  ''B2FHM$''  |
 ===== Commands (AKA proposals) =====
-==== Common subset ====
-The ''FS'' command is issued by the client, and used to tell the server, based on the list of message that have been reported, how to process the messages.
-Format:
+==== Ascii Basic Protocol =====
-<code>FS <response></code>
+(i) Usage of this proposal implies the presence of the ''F'' feature in the SID.
-^ Code ^ Action ^ Remarks ^
+Details in the dedicated page on the [[b2f:ascii|ASCII Basic Protocol]]
-|  ''+''  | Accept | Send the message and delete it from the queue |
+==== Binary compressed protocol version 0 ====
-|  ''-''  | Reject | Don't send the message and delete it from the queue |
-|  ''=''  | Defer | Keep in the queue to retrieve it later |
-Starting from Binary compressed format version 1, additional responses are possible:
+(i) Usage of this proposal implies the presence of both the ''B'' and ''F'' features in the SID.
-^ Code ^ Action ^ Remarks ^
+Details in the dedicated page on the [[b2f:bcf_v0|Binary Compressed Forward Version 0]].
-|  ''+'' or ''Y''  | Accept | Send the message and delete it from the queue |
+==== Binary compressed protocol version 1 ====
-|  ''-'' or ''N''  | Reject | Don't send the message and delete it from the queue |
-|  ''='' or ''L''  | Defer | Keep in the queue to retrieve it later |
-|  ''H''  | Message accepted, but held in queue |  |
-|  ''R''  | Message rejected |  |
-|  ''E''  | Error detected in the line |  |
-|  ''!offset''  | Resume transfer from ''offset'' bytes | Offset is expressed according to the compressed stream  |
+(i) Usage of this proposal implies the presence of both the ''B1'' and ''F'' features in the SID.
-==== Calling Station ID ====
+Details in the dedicated page on the [[b2f:bcf_v1|Binary Compressed Forward Version 1]].
-The calling station identification command is to be sent **PRIOR** the calling station SID.
+==== B2F ====
-<code>;FW CALLSIGN</code>
+B2F is a superset of BCFv1, so ''FA'' and ''FB'' commands work the same way.
-==== Ascii Basic Protocol =====
-(i) Usage of this proposal implies the presence of the ''F'' feature in the SID.
-==== Binary compressed protocol version 0 ====
-==== Binary compressed protocol version 1 ====
-==== Binary compressed protocol version 2 ====
-BCPv2 is a superset of BCPv1, so ''FA'' and ''FB'' commands work the same way.
-Additionally, it defines a new command ''FC'' as following:
+This protocol's specifics are described in [[b2f:b2f|Open B2F]].
 ==== GZIP Experiment ====
-The GZIP Experiment is a superset of BCPv2 which adds the ''FD'' command, following the ''FC'' format
+The GZIP Experiment is a superset of BCPv2 which adds the ''FD'' proposal while following the ''FC'' proposal specifics, except for the use of GZIP instead of the LZHUF version 1 format.
 ===== Winlink specifics =====
@@ Line 102: / Line 86: @@
 W0RLI also ties the features ''T'' and ''U'' in their specification, but without any details on their real meaning.
-==== Secure login ====
-The exchange happens after the SID has been transmitted.
-The server sends a '';PQ'' proposal with an authentication challenge, which is formatted as follow:
-<code>;PQ 99685857</code>
-The client computes the response using the following pseudocode:
-<code c>
-// Trailing salt
-uint8_t sl_salt[] = {
-, 197, 101, 206, 190, 249,  93, 200,
-, 243,  93, 237,  71,  94, 239, 138,
-, 108,  70, 185, 225, 137, 217,  16,
-, 122, 193,  48, 194, 195, 198, 175,
-, 169,  70,  84,  61,  62, 104, 186,
-,  52,  61, 168,  66, 129, 192, 208,
-, 249, 232, 193,  41, 113,  41,  45,
-,  16,  29, 228, 208, 228,  61,  20
-};
-// Concatenate the challenge, the password and the salt.
-payload = concat( challenge, password, sl_salt)
-// Compute the md5 of the last result
-md5sum = md5(payload)
-// Take the first 4 bytes of the hash, flip the byte-wise endianness, and cap the first byte to 0x3f
-response = ( (uint8_t)(md5sum[3]) & 0x3f ) << 24 | (uint8_t)(md5sum[2]) << 16 | (uint8_t)(md5sum[1]) << 8 | (uint8_t)(md5sum[0]) )
-// Keep the 8 least significant digits in base 10 of response.
-// If response is shorter than 8 digits, 0-pad from the left.
-resval = itoa( response % 100000000, base10)
-sprintf( result, "%08d", resval)
-</code>
-The result is then sent to the server using the following format:
-<code>;PR 99685857</code>
-Reference source code in [[https://github.com/nwdigitalradio/paclink-unix/blob/1df400712a985045f2fce0d582a70763c2b2ba7b/wl2k.c#L1249|paclink-unix, function compute_secure_login_response()]] and [[https://github.com/la5nta/wl2k-go/blob/master/fbb/secure.go|wl2k-go]]
 ==== Forward messages ====
 ==== Pending messages ====
@@ Line 158: / Line 100: @@
 Your software is supposed to fall back in this mode when the feature ''F'' is not proposed by the remote party.
-Best recommended stance, for now, is to reject connections with an error message, given the lack of available documentation.
+F4HOF's remark: //Best recommended stance, for now, is to reject connections with an error message, given the lack of available documentation.//
 ==== ASCII Basic Protocol ====
-==== Ascii Basic Protocol ====
 ==== Binary compressed protocol version 0 ====
-=== Header ===
-Format:
-<code>0x01 head_len(uint8) fname(c-string) offset(bytes in c-string)</code>
-  * ''fname'' is a null-terminated C-String which either contains the title of the message or the filename, respectively for an ASCII or a Binary transfer.
-  * ''offset'' is a null-terminated C-String which contains an ASCII printable representation of the offset in bytes of the following data fragments. Valid values for the offset span from 0 to 999999 bytes.
-  * ''head_len'' expresses the sum of the length of the two above C strings, including their null terminator
-=== Data ===
-Format:
-<code>0x02 payload_len(uint8) data(bytes)</code>
-  * ''payload_len'' represents the length in bytes of the following ''data'' byte stream. Valid values span from 1 to 256 bytes, 256 bytes being represented by the value ''0x00''.
-=== Checksum ===
-Format:
-<code>Csum: 0x04 csum(uint8)</code>
-The checksum is designed so that the bytewise sum of data bytes, plus the checksum modulo 256 equals to zero if no error occured.
-To generate the checksum, compute the two's complement of the bytewise sum of data bytes.
 ==== Binary compressed protocol version 1 ====
 ==== Binary compressed protocol version 2 ====