=============================================================================
* Forwarded by Vince Coen (2:250/1)
* Area : BINKD (The ubiquitous BinkD TCP/IP FTN mailer a)
* From : Michiel van der Vlist, 2:280/5555 (Sunday March 02 2014 10:48)
* To : Kees van Eeten
* Subj : Error 10054 ============================================================================= Hello Kees,
On Saturday March 01 2014 22:41, you wrote to mark lewis:
As far as I know, the version line in de system handshake said the version supports binkd v1.1.
While it actually didn't because it was forced into 1.0 mode.
I see no reason why that banner should change if program is forced to
v1.0 by an available option.
So that it does not put the other side on the wrong foot?
This is from the log with log level 10:
20 Feb 00:32:36 [7804] Read 43 bytes
20 Feb 00:32:36 [7804] got block: 43 (msg)
20 Feb 00:32:36 [7804] rcvd msg NUL VER mbcico/0.50.0/GNU/Linux-i386 binkp/1.1
- 20 Feb 00:32:36 [7804] VER mbcico/0.50.0/GNU/Linux-i386 binkp/1.1
20 Feb 00:32:36 [7804] remote uses binkp v.1.1
20 Feb 00:32:36 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:36 [7804] selected 1 (r=1, w=0)
As you can see, this side receives the string that contains the banner with the
version. From that it concludes that the remote is 1.1 capable. The version number in the banner is used to determine the actual capability of the remote.
Advertsing 1.1 while being forced in 1.0 mode puts the remote on the wrong foot.
Cheers, Michiel
-!- GoldED+/W32-MINGW 1.1.5-b20110320
! Origin:
http://www.vlist.eu (2:280/5555)
=============================================================================
Hello Vince!
Hopefully the last FYI on this subject ...
but I will not take any bets on it !
From the above this test was on an old copy of mbse (0.50.0).
so the test is not a good one as we need to see if it applies on v1.01.1
Vince
--- Linux/Mbse/GoldED+/LNX 1.1.5-b20120229
* Origin: Air Applewood, The Linux Gateway to the UK (2:250/1)