Differences

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

--- b2f:start [2025/02/15 10:03] – [Calling Station ID] f4hof
+++ b2f:start [2026/04/16 05:32] (current) – [Winlink specifics] f4hof
@@ Line 77: / Line 77: @@
 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 =====
-Apparently, clients and servers add the feature ''W'' in their SID string when establishing a WL2K connection. Some even complain if the remote peer doesn't expose it. The precise meaning and purpose of that flag is undocumented.
+From my observations, flag ''W'' is exposed by a CMS, or an RMS Relay in its SID string. Winlink clients actively check presence of this flag to confirm they're discussing with the Winlink network.
-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:
+Flag ''J'' is exposed by Central Messaging Servers. TODO: analyze an offline RMS Relay transaction to confirm presence of flag ''J'' when establishing a connection, in store and forward and Hybrid network operation scenarii.
-<code>;PR 99685857</code>
+W0RLI also documents ''T'' and ''U'' flags in their specification, but without any details on their real meaning, and those are *NOT* observed in transactions.
-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 143: / Line 102: @@
 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 ====