Differences

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

--- b2f:start [2025/02/14 16:55] – [Binary compressed protocol version 0] f4hof
+++ b2f:start [2025/02/15 10:13] (current) – [Standard Forwarding protocol (MBL/RLI)] f4hof
@@ Line 57: / 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:
-<code>FS <response></code>
-^ Code ^ Action ^ Remarks ^
-|  ''+''  | Accept | Send the message and delete it from the queue |
-|  ''-''  | 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:
-^ Code ^ Action ^ Remarks ^
-|  ''+'' or ''Y''  | Accept | Send the message and delete it from the queue |
-|  ''-'' 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  |
-==== Calling Station ID ====
-The calling station identification command is to be sent **PRIOR** the calling station SID.
-<code>;FW CALLSIGN</code>
 ==== Ascii Basic Protocol =====
@@ Line 92: / Line 66: @@
 ==== Binary compressed protocol version 0 ====
-(i) Usage of this proposal implies the presence of both the ''F'' and ''B'' features in the SID.
+(i) Usage of this proposal implies the presence of both the ''B'' and ''F'' features in the SID.
 Details in the dedicated page on the [[b2f:bcf_v0|Binary Compressed Forward Version 0]].
 ==== Binary compressed protocol version 1 ====
-==== Binary compressed protocol version 2 ====
+(i) Usage of this proposal implies the presence of both the ''B1'' and ''F'' features in the SID.
+Details in the dedicated page on the [[b2f:bcf_v1|Binary Compressed Forward Version 1]].
+==== B2F ====
 B2F is a superset of BCFv1, 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 109: / 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 165: / 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 ====