Error 10054

[Michiel van der Vlist]

Hello Wilfred,

On Wednesday February 19 2014 21:53, you wrote to me:

WV> Could you repeat the test with 'loglevel 10' ?


=== Cut ===
20 Feb 00:32:33 [5616] BEGIN standalone, binkd/1.1a-49/Win32 -p -P1016
binkd.cfg
20 Feb 00:32:33 [5616] creating a poll for 2:280/***@fidonet (`d' flavour)
20 Feb 00:32:33 [5616] clientmgr started
20 Feb 00:32:33 [5616] started client #1, id=1920
20 Feb 00:32:33 [7804] perl_init_clone(): new clone 0
20 Feb 00:32:33 [7804] created d:\fido\outbound\011803f8.csy
+ 20 Feb 00:32:33 [7804] call to 2:280/***@fidonet
20 Feb 00:32:33 [7804] trying f1016.n280.z2.binkp.net [188.142.112.203]...
20 Feb 00:32:33 [7804] connected
20 Feb 00:32:34 [7804] binkp init done, socket # is 1808
+ 20 Feb 00:32:34 [7804] outgoing session with 188.142.112.203
20 Feb 00:32:34 [7804] send message NUL SYS Blijf Tonijn
20 Feb 00:32:34 [7804] send message NUL ZYZ Michiel van der Vlist
20 Feb 00:32:34 [7804] send message NUL LOC Driebergen, NL
20 Feb 00:32:34 [7804] send message NUL NDL
CM,MO,IBN:fido.vlist.eu,U,RPK,NPK,ENC,NC
20 Feb 00:32:34 [7804] send message NUL TIME Thu, 20 Feb 2014 00:32:34 +0100
20 Feb 00:32:34 [7804] send message NUL VER binkd/1.1a-49/Win32 binkp/1.1
20 Feb 00:32:34 [7804] send_ADR(): got 0 remote addresses
20 Feb 00:32:34 [7804] send message ADR 2:280/***@fidonet 2:2/***@fifonet
2:28/***@fidonet
20 Feb 00:32:34 [7804] send message NUL OPT NDA EXTCMD CRYPT
20 Feb 00:32:34 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:34 [7804] selected 2 (r=1, w=1)
20 Feb 00:32:34 [7804] touched d:\fido\outbound\011803f8.csy
20 Feb 00:32:34 [7804] Read 2 bytes
20 Feb 00:32:34 [7804] recvd hdr: 50 (msg)
20 Feb 00:32:34 [7804] put next msg to obuf, 19
20 Feb 00:32:34 [7804] put next msg to obuf, 28
20 Feb 00:32:34 [7804] put next msg to obuf, 21
20 Feb 00:32:34 [7804] put next msg to obuf, 47
20 Feb 00:32:34 [7804] put next msg to obuf, 39
20 Feb 00:32:34 [7804] put next msg to obuf, 36
20 Feb 00:32:34 [7804] put next msg to obuf, 52
20 Feb 00:32:34 [7804] put next msg to obuf, 23
20 Feb 00:32:34 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:34 [7804] selected 2 (r=1, w=1)
20 Feb 00:32:34 [7804] Read 50 bytes
20 Feb 00:32:34 [7804] got block: 50 (msg)
20 Feb 00:32:34 [7804] rcvd msg NUL OPT PLZ
CRAM-MD5-e3ec110e690d9a544eed374535c856ea
- 20 Feb 00:32:34 [7804] OPT PLZ CRAM-MD5-e3ec110e690d9a544eed374535c856ea
+ 20 Feb 00:32:34 [7804] Remote requests MD mode
20 Feb 00:32:34 [7804] sending 265 byte(s)
20 Feb 00:32:34 [7804] send() done, rc=265
20 Feb 00:32:35 [7804] data sent
20 Feb 00:32:35 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:35 [7804] selected 1 (r=1, w=0)
20 Feb 00:32:35 [7804] Read 2 bytes
20 Feb 00:32:35 [7804] recvd hdr: 23 (msg)
20 Feb 00:32:35 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:35 [7804] selected 1 (r=1, w=0)
20 Feb 00:32:35 [7804] Read 23 bytes
20 Feb 00:32:35 [7804] got block: 23 (msg)
20 Feb 00:32:35 [7804] rcvd msg NUL SYS bbs.bredenbeek.net
- 20 Feb 00:32:35 [7804] SYS bbs.bredenbeek.net
20 Feb 00:32:35 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:35 [7804] selected 1 (r=1, w=0)
20 Feb 00:32:35 [7804] Read 2 bytes
20 Feb 00:32:35 [7804] recvd hdr: 19 (msg)
20 Feb 00:32:35 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:35 [7804] selected 1 (r=1, w=0)
20 Feb 00:32:35 [7804] Read 19 bytes
20 Feb 00:32:35 [7804] got block: 19 (msg)
20 Feb 00:32:35 [7804] rcvd msg NUL ZYZ Jan Bredenbeek
- 20 Feb 00:32:35 [7804] ZYZ Jan Bredenbeek
20 Feb 00:32:35 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:35 [7804] selected 1 (r=1, w=0)
20 Feb 00:32:35 [7804] Read 2 bytes
20 Feb 00:32:35 [7804] recvd hdr: 18 (msg)
20 Feb 00:32:35 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:35 [7804] selected 1 (r=1, w=0)
20 Feb 00:32:35 [7804] Read 18 bytes
20 Feb 00:32:35 [7804] got block: 18 (msg)
20 Feb 00:32:35 [7804] rcvd msg NUL LOC Hilversum, NL
- 20 Feb 00:32:35 [7804] LOC Hilversum, NL
20 Feb 00:32:35 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:35 [7804] selected 1 (r=1, w=0)
20 Feb 00:32:36 [7804] Read 2 bytes
20 Feb 00:32:36 [7804] recvd hdr: 25 (msg)
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)
20 Feb 00:32:36 [7804] Read 25 bytes
20 Feb 00:32:36 [7804] got block: 25 (msg)
20 Feb 00:32:36 [7804] rcvd msg NUL NDL MO,CM,XA,IBN,IFC,ITN
- 20 Feb 00:32:36 [7804] NDL MO,CM,XA,IBN,IFC,ITN
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)
20 Feb 00:32:36 [7804] Read 2 bytes
20 Feb 00:32:36 [7804] recvd hdr: 37 (msg)
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)
20 Feb 00:32:36 [7804] Read 37 bytes
20 Feb 00:32:36 [7804] got block: 37 (msg)
20 Feb 00:32:36 [7804] rcvd msg NUL TIME Thu, 20 Feb 2014 00:32:15 +0100
- 20 Feb 00:32:36 [7804] TIME Thu, 20 Feb 2014 00:32:15 +0100
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)
20 Feb 00:32:36 [7804] Read 2 bytes
20 Feb 00:32:36 [7804] recvd hdr: 43 (msg)
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)
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)
20 Feb 00:32:36 [7804] Read 2 bytes
20 Feb 00:32:36 [7804] recvd hdr: 18 (msg)
20 Feb 00:32:37 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:37 [7804] selected 1 (r=1, w=0)
20 Feb 00:32:37 [7804] Read 18 bytes
20 Feb 00:32:37 [7804] got block: 18 (msg)
20 Feb 00:32:37 [7804] rcvd msg NUL PHN -unpublished-
- 20 Feb 00:32:37 [7804] PHN -unpublished-
20 Feb 00:32:37 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:37 [7804] selected 1 (r=1, w=0)
20 Feb 00:32:37 [7804] Read 2 bytes
20 Feb 00:32:37 [7804] recvd hdr: 16 (msg)
20 Feb 00:32:37 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:37 [7804] selected 1 (r=1, w=0)
20 Feb 00:32:37 [7804] Read 16 bytes
20 Feb 00:32:37 [7804] got block: 16 (msg)
20 Feb 00:32:37 [7804] rcvd msg NUL OPM SYNCNET BBS
- 20 Feb 00:32:37 [7804] OPM SYNCNET BBS
20 Feb 00:32:37 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:37 [7804] selected 1 (r=1, w=0)
20 Feb 00:32:37 [7804] Read 2 bytes
20 Feb 00:32:37 [7804] recvd hdr: 20 (msg)
20 Feb 00:32:37 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:37 [7804] selected 1 (r=1, w=0)
20 Feb 00:32:37 [7804] Read 20 bytes
20 Feb 00:32:37 [7804] got block: 20 (msg)
20 Feb 00:32:37 [7804] rcvd msg ADR 2:280/***@fidonet
20 Feb 00:32:37 [7804] created d:\fido\outbound\011803f8.bsy
+ 20 Feb 00:32:37 [7804] addr: 2:280/***@fidonet
20 Feb 00:32:37 [7804] send message PWD
CRAM-MD5-9313c9bed099c6c96f0f73ede6a28cd5
20 Feb 00:32:37 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:37 [7804] selected 1 (r=0, w=1)
20 Feb 00:32:37 [7804] put next msg to obuf, 44
20 Feb 00:32:37 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:37 [7804] selected 1 (r=0, w=1)
20 Feb 00:32:38 [7804] sending 44 byte(s)
20 Feb 00:32:38 [7804] send() done, rc=44
20 Feb 00:32:38 [7804] data sent
20 Feb 00:32:38 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:38 [7804] selected 1 (r=1, w=0)
20 Feb 00:32:38 [7804] Read 1 bytes
20 Feb 00:32:38 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:38 [7804] selected 1 (r=1, w=0)
20 Feb 00:32:38 [7804] Read 1 bytes
20 Feb 00:32:38 [7804] recvd hdr: 11 (msg)
20 Feb 00:32:38 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:38 [7804] selected 1 (r=1, w=0)
20 Feb 00:32:38 [7804] Read 11 bytes
20 Feb 00:32:38 [7804] got block: 11 (msg)
20 Feb 00:32:38 [7804] rcvd msg OK non-secure
20 Feb 00:32:38 [7804] cur remote addr is 2:280/1016.0
20 Feb 00:32:38 [7804] removing flo: d:\fido\outbound\011803f8.dlo
20 Feb 00:32:38 [7804] unlinked `d:\fido\outbound\011803f8.dlo'
20 Feb 00:32:38 [7804] send message EOB
20 Feb 00:32:38 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:38 [7804] selected 2 (r=1, w=1)
20 Feb 00:32:38 [7804] Read 2 bytes
20 Feb 00:32:38 [7804] recvd hdr: 8 (msg)
20 Feb 00:32:38 [7804] put next msg to obuf, 3
20 Feb 00:32:38 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:38 [7804] selected 2 (r=1, w=1)
20 Feb 00:32:38 [7804] Read 8 bytes
20 Feb 00:32:38 [7804] got block: 8 (msg)
20 Feb 00:32:38 [7804] rcvd msg NUL TRF 0 0
- 20 Feb 00:32:38 [7804] TRF 0 0
+ 20 Feb 00:32:38 [7804] Remote has 0b of mail and 0b of files for us
20 Feb 00:32:38 [7804] sending 3 byte(s)
20 Feb 00:32:38 [7804] send() done, rc=3
20 Feb 00:32:39 [7804] data sent
20 Feb 00:32:39 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:39 [7804] selected 1 (r=1, w=0)
20 Feb 00:32:39 [7804] Read 2 bytes
20 Feb 00:32:39 [7804] recvd hdr: 1 (msg)
20 Feb 00:32:39 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:39 [7804] selected 1 (r=1, w=0)
20 Feb 00:32:39 [7804] Read 1 bytes
20 Feb 00:32:39 [7804] got block: 1 (msg)
20 Feb 00:32:39 [7804] rcvd msg EOB
20 Feb 00:32:39 [7804] there were 3 msgs in this batch
20 Feb 00:32:39 [7804] send message EOB
20 Feb 00:32:39 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:39 [7804] selected 1 (r=0, w=1)
20 Feb 00:32:39 [7804] put next msg to obuf, 3
20 Feb 00:32:39 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:39 [7804] selected 1 (r=0, w=1)
20 Feb 00:32:39 [7804] sending 3 byte(s)
20 Feb 00:32:39 [7804] send() done, rc=3
20 Feb 00:32:39 [7804] data sent
20 Feb 00:32:39 [7804] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:32:41 [7804] selected 1 (r=1, w=0)
20 Feb 00:32:41 [7804] Read -1 bytes
? 20 Feb 00:32:41 [7804] recv: {W32 API error 183} Eine Datei kann nicht
erstellt werden, wenn sie bereits vorhanden ist.
+ 20 Feb 00:32:41 [7804] done (to 2:280/***@fidonet, failed, S/R: 0/0 (0/0
bytes))
20 Feb 00:32:41 [7804] processing kill list
20 Feb 00:32:41 [7804] restoring poll with `d' flavour
20 Feb 00:32:41 [7804] unlinked `d:\fido\outbound\011803f8.bsy'
20 Feb 00:32:41 [7804] binkp deinit done...
20 Feb 00:32:41 [7804] session closed, quitting...
20 Feb 00:32:41 [7804] unlinked `d:\fido\outbound\011803f8.csy'
20 Feb 00:32:41 [7804] perl_done_clone(): destructing clone 0
20 Feb 00:32:41 [5616] the queue is empty, quitting...
20 Feb 00:32:41 [5616] downing clientmgr...
20 Feb 00:32:41 [5616] exitfunc()
20 Feb 00:32:41 [5616] exitfunc(): all threads finished
20 Feb 00:32:41 [5616] bsy_remove_all: done

20 Feb 00:38:02 [3196] started client #1, id=1648
20 Feb 00:38:02 [6576] perl_init_clone(): new clone 0
20 Feb 00:38:02 [6576] created d:\fido\outbound\01180013.csy
+ 20 Feb 00:38:02 [6576] call to 2:280/***@fidonet
20 Feb 00:38:02 [6576] trying binkp.dreamlandbbs.com [213.126.141.188]...
20 Feb 00:38:02 [6576] connected
20 Feb 00:38:02 [6576] binkp init done, socket # is 1360
+ 20 Feb 00:38:02 [6576] outgoing session with 213.126.141.188
20 Feb 00:38:03 [6576] send message NUL SYS Blijf Tonijn
20 Feb 00:38:03 [6576] send message NUL ZYZ Michiel van der Vlist
20 Feb 00:38:03 [6576] send message NUL LOC Driebergen, NL
20 Feb 00:38:03 [6576] send message NUL NDL
CM,MO,IBN:fido.vlist.eu,U,RPK,NPK,ENC,NC
20 Feb 00:38:03 [6576] send message NUL TIME Thu, 20 Feb 2014 00:38:03 +0100
20 Feb 00:38:03 [6576] send message NUL VER binkd/1.1a-49/Win32 binkp/1.1
20 Feb 00:38:03 [6576] send_ADR(): got 0 remote addresses
20 Feb 00:38:03 [6576] send message ADR 2:280/***@fidonet 2:2/***@fifonet
2:28/***@fidonet
20 Feb 00:38:03 [6576] send message NUL OPT NDA EXTCMD CRYPT
20 Feb 00:38:03 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:03 [6576] selected 2 (r=1, w=1)
20 Feb 00:38:03 [6576] Read 2 bytes
20 Feb 00:38:03 [6576] recvd hdr: 46 (msg)
20 Feb 00:38:03 [6576] put next msg to obuf, 19
20 Feb 00:38:03 [6576] put next msg to obuf, 28
20 Feb 00:38:03 [6576] put next msg to obuf, 21
20 Feb 00:38:03 [6576] put next msg to obuf, 47
20 Feb 00:38:03 [6576] put next msg to obuf, 39
20 Feb 00:38:03 [6576] put next msg to obuf, 36
20 Feb 00:38:03 [6576] put next msg to obuf, 52
20 Feb 00:38:03 [6576] put next msg to obuf, 23
20 Feb 00:38:03 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:03 [6576] selected 2 (r=1, w=1)
20 Feb 00:38:03 [6576] Read 46 bytes
20 Feb 00:38:03 [6576] got block: 46 (msg)
20 Feb 00:38:03 [6576] rcvd msg NUL OPT
CRAM-MD5-b29b1b81af1c249c425bc001ee5103d7
- 20 Feb 00:38:03 [6576] OPT CRAM-MD5-b29b1b81af1c249c425bc001ee5103d7
+ 20 Feb 00:38:03 [6576] Remote requests MD mode
20 Feb 00:38:03 [6576] sending 265 byte(s)
20 Feb 00:38:03 [6576] send() done, rc=265
20 Feb 00:38:03 [6576] data sent
20 Feb 00:38:03 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:03 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:03 [6576] Read 2 bytes
20 Feb 00:38:03 [6576] recvd hdr: 18 (msg)
20 Feb 00:38:03 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:03 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:04 [6576] touched d:\fido\outbound\01180013.csy
20 Feb 00:38:04 [6576] Read 18 bytes
20 Feb 00:38:04 [6576] got block: 18 (msg)
20 Feb 00:38:04 [6576] rcvd msg NUL SYS Dreamland BBS
- 20 Feb 00:38:04 [6576] SYS Dreamland BBS
20 Feb 00:38:04 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:04 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:04 [6576] Read 2 bytes
20 Feb 00:38:04 [6576] recvd hdr: 19 (msg)
20 Feb 00:38:04 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:04 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:04 [6576] Read 19 bytes
20 Feb 00:38:04 [6576] got block: 19 (msg)
20 Feb 00:38:04 [6576] rcvd msg NUL ZYZ Lukas de Groen
- 20 Feb 00:38:04 [6576] ZYZ Lukas de Groen
20 Feb 00:38:04 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:04 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:04 [6576] Read 2 bytes
20 Feb 00:38:04 [6576] recvd hdr: 29 (msg)
20 Feb 00:38:04 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:04 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:04 [6576] Read 29 bytes
20 Feb 00:38:04 [6576] got block: 29 (msg)
20 Feb 00:38:04 [6576] rcvd msg NUL LOC Houten - The Netherlands
- 20 Feb 00:38:04 [6576] LOC Houten - The Netherlands
20 Feb 00:38:04 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:04 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:04 [6576] Read 2 bytes
20 Feb 00:38:04 [6576] recvd hdr: 26 (msg)
20 Feb 00:38:04 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:04 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:04 [6576] Read 26 bytes
20 Feb 00:38:04 [6576] got block: 26 (msg)
20 Feb 00:38:04 [6576] rcvd msg NUL NDL CM,XX,IBN,IFC,IFT,ITN
- 20 Feb 00:38:04 [6576] NDL CM,XX,IBN,IFC,IFT,ITN
20 Feb 00:38:04 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:04 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:04 [6576] Read 2 bytes
20 Feb 00:38:04 [6576] recvd hdr: 37 (msg)
20 Feb 00:38:04 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:04 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:04 [6576] Read 37 bytes
20 Feb 00:38:04 [6576] got block: 37 (msg)
20 Feb 00:38:04 [6576] rcvd msg NUL TIME Thu, 20 Feb 2014 00:37:42 +0100
- 20 Feb 00:38:04 [6576] TIME Thu, 20 Feb 2014 00:37:42 +0100
20 Feb 00:38:04 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:04 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:04 [6576] Read 2 bytes
20 Feb 00:38:04 [6576] recvd hdr: 46 (msg)
20 Feb 00:38:05 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:05 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:05 [6576] Read 46 bytes
20 Feb 00:38:05 [6576] got block: 46 (msg)
20 Feb 00:38:05 [6576] rcvd msg NUL VER mbcico/0.95.13/GNU/Linux-x86_64
binkp/1.1
- 20 Feb 00:38:05 [6576] VER mbcico/0.95.13/GNU/Linux-x86_64 binkp/1.1
20 Feb 00:38:05 [6576] remote uses binkp v.1.1
20 Feb 00:38:05 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:05 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:05 [6576] Read 2 bytes
20 Feb 00:38:05 [6576] recvd hdr: 20 (msg)
20 Feb 00:38:05 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:05 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:05 [6576] Read 20 bytes
20 Feb 00:38:05 [6576] got block: 20 (msg)
20 Feb 00:38:05 [6576] rcvd msg NUL PHN 213.126.141.188
- 20 Feb 00:38:05 [6576] PHN 213.126.141.188
20 Feb 00:38:05 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:05 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:05 [6576] Read 2 bytes
20 Feb 00:38:05 [6576] recvd hdr: 48 (msg)
20 Feb 00:38:05 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:05 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:05 [6576] Read 48 bytes
20 Feb 00:38:05 [6576] got block: 48 (msg)
20 Feb 00:38:05 [6576] rcvd msg NUL OPM Dreamland BBS, your great source for
files!
- 20 Feb 00:38:05 [6576] OPM Dreamland BBS, your great source for files!
20 Feb 00:38:05 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:05 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:05 [6576] Read 2 bytes
20 Feb 00:38:05 [6576] recvd hdr: 135 (msg)
20 Feb 00:38:05 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:05 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:05 [6576] Read 135 bytes
20 Feb 00:38:05 [6576] got block: 135 (msg)
20 Feb 00:38:05 [6576] rcvd msg ADR 2:280/***@fidonet 2:280/***@fidonet
110:30/***@linuxnet 115:31/***@pascalnet 115:31/***@pascalnet 115:3100/***@pascalnet
115:3100/***@pascalnet
20 Feb 00:38:05 [6576] created d:\fido\outbound\01180013.bsy
+ 20 Feb 00:38:05 [6576] addr: 2:280/***@fidonet
20 Feb 00:38:05 [6576] created d:\fido\outbound\01180403.bsy
+ 20 Feb 00:38:06 [6576] addr: 2:280/***@fidonet
+ 20 Feb 00:38:06 [6576] addr: 110:30/***@linuxnet (n/a or busy)
+ 20 Feb 00:38:06 [6576] addr: 115:31/***@pascalnet (n/a or busy)
+ 20 Feb 00:38:06 [6576] addr: 115:31/***@pascalnet (n/a or busy)
+ 20 Feb 00:38:06 [6576] addr: 115:3100/***@pascalnet (n/a or busy)
+ 20 Feb 00:38:06 [6576] addr: 115:3100/***@pascalnet (n/a or busy)
20 Feb 00:38:06 [6576] Session send rate limit is - cps or 100%
20 Feb 00:38:06 [6576] Session recv rate limit is - cps or 100%
20 Feb 00:38:06 [6576] send message PWD
CRAM-MD5-46e8f56610dd1821251864deb2b33d12
20 Feb 00:38:06 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:06 [6576] selected 1 (r=0, w=1)
20 Feb 00:38:06 [6576] put next msg to obuf, 44
20 Feb 00:38:06 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:06 [6576] selected 1 (r=0, w=1)
20 Feb 00:38:06 [6576] sending 44 byte(s)
20 Feb 00:38:06 [6576] send() done, rc=44
20 Feb 00:38:06 [6576] data sent
20 Feb 00:38:06 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:06 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:06 [6576] Read 1 bytes
20 Feb 00:38:06 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:06 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:06 [6576] Read 1 bytes
20 Feb 00:38:06 [6576] recvd hdr: 7 (msg)
20 Feb 00:38:06 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:06 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:06 [6576] Read 7 bytes
20 Feb 00:38:06 [6576] got block: 7 (msg)
20 Feb 00:38:06 [6576] rcvd msg OK secure
+ 20 Feb 00:38:07 [6576] pwd protected session (MD5)
20 Feb 00:38:07 [6576] cur remote addr is 2:280/19.0
20 Feb 00:38:07 [6576] removing flo: d:\fido\outbound\01180013.clo
20 Feb 00:38:07 [6576] unlinked `d:\fido\outbound\01180013.clo'
20 Feb 00:38:07 [6576] send message EOB
20 Feb 00:38:07 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:07 [6576] selected 2 (r=1, w=1)
20 Feb 00:38:07 [6576] Read 2 bytes
20 Feb 00:38:07 [6576] recvd hdr: 22 (msg)
20 Feb 00:38:07 [6576] put next msg to obuf, 3
20 Feb 00:38:07 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:07 [6576] selected 2 (r=1, w=1)
20 Feb 00:38:07 [6576] Read 22 bytes
20 Feb 00:38:07 [6576] got block: 22 (msg)
20 Feb 00:38:07 [6576] rcvd msg NUL OPT EXTCMD GZ BZ2 PLZ
- 20 Feb 00:38:07 [6576] OPT EXTCMD GZ BZ2 PLZ
+ 20 Feb 00:38:07 [6576] Remote supports EXTCMD mode
20 Feb 00:38:07 [6576] sending 3 byte(s)
20 Feb 00:38:07 [6576] send() done, rc=3
20 Feb 00:38:07 [6576] data sent
20 Feb 00:38:07 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:07 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:07 [6576] Read 2 bytes
20 Feb 00:38:07 [6576] recvd hdr: 8 (msg)
20 Feb 00:38:07 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:07 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:07 [6576] Read 8 bytes
20 Feb 00:38:07 [6576] got block: 8 (msg)
20 Feb 00:38:07 [6576] rcvd msg NUL TRF 0 0
- 20 Feb 00:38:07 [6576] TRF 0 0
+ 20 Feb 00:38:07 [6576] Remote has 0b of mail and 0b of files for us
20 Feb 00:38:07 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:07 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:07 [6576] Read 2 bytes
20 Feb 00:38:07 [6576] recvd hdr: 1 (msg)
20 Feb 00:38:07 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:07 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:07 [6576] Read 1 bytes
20 Feb 00:38:07 [6576] got block: 1 (msg)
20 Feb 00:38:07 [6576] rcvd msg EOB
20 Feb 00:38:07 [6576] there were 4 msgs in this batch
20 Feb 00:38:07 [6576] send message EOB
20 Feb 00:38:07 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:07 [6576] selected 1 (r=0, w=1)
20 Feb 00:38:07 [6576] put next msg to obuf, 3
20 Feb 00:38:07 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:07 [6576] selected 1 (r=0, w=1)
20 Feb 00:38:07 [6576] sending 3 byte(s)
20 Feb 00:38:07 [6576] send() done, rc=3
20 Feb 00:38:07 [6576] data sent
20 Feb 00:38:08 [6576] tv.tv_sec=60, tv.tv_usec=0
20 Feb 00:38:09 [6576] selected 1 (r=1, w=0)
20 Feb 00:38:09 [6576] Read -1 bytes
? 20 Feb 00:38:09 [6576] recv: {W32 API error 183} Eine Datei kann nicht
erstellt werden, wenn sie bereits vorhanden ist.
+ 20 Feb 00:38:09 [6576] done (to 2:280/***@fidonet, failed, S/R: 0/0 (0/0
bytes))
20 Feb 00:38:09 [6576] processing kill list
20 Feb 00:38:09 [6576] restoring poll with `c' flavour
20 Feb 00:38:09 [6576] unlinked `d:\fido\outbound\01180013.bsy'
20 Feb 00:38:09 [6576] unlinked `d:\fido\outbound\01180403.bsy'
20 Feb 00:38:09 [6576] binkp deinit done...
20 Feb 00:38:09 [6576] session closed, quitting...
20 Feb 00:38:09 [6576] unlinked `d:\fido\outbound\01180013.csy'
20 Feb 00:38:09 [6576] perl_done_clone(): destructing clone 0



=== Cut ===

Cheers, Michiel

[mark lewis]

On Thu, 20 Feb 2014, Michiel van der Vlist wrote to Wilfred van Velzen:

MvdV> 20 Feb 00:32:39 [7804] data sent
MvdV> 20 Feb 00:32:39 [7804] tv.tv_sec=60, tv.tv_usec=0
MvdV> 20 Feb 00:32:41 [7804] selected 1 (r=1, w=0)
MvdV> 20 Feb 00:32:41 [7804] Read -1 bytes
MvdV> ? 20 Feb 00:32:41 [7804] recv: {W32 API error 183} Eine Datei
MvdV> kann nicht erstellt werden, wenn sie bereits vorhanden ist.

"A file can not be created if it already exists." ???

what file is it talking about? it appears to be a problem with the other end of
the link not being able to create some file... the other end of the link
definitely needs to be consulted with their logs...

)\/(ark

One of the great tragedies of life is the murder of a beautiful theory by a
gang of brutal facts. --Benjamin Franklin

[Michiel van der Vlist]

Hello mark,

On Wednesday February 19 2014 21:02, you wrote to me:

MvdV>> 20 Feb 00:32:41 [7804] selected 1 (r=1, w=0)
MvdV>> 20 Feb 00:32:41 [7804] Read -1 bytes
MvdV>> ? 20 Feb 00:32:41 [7804] recv: {W32 API error 183} Eine Datei
MvdV>> kann nicht erstellt werden, wenn sie bereits vorhanden ist.

ml> "A file can not be created if it already exists." ???

ml> what file is it talking about?

I have no idea... The negative number of bytes read also puzzles me.


Cheers, Michiel

[mark lewis]

On Fri, 21 Feb 2014, Michiel van der Vlist wrote to mark lewis:

MvdV>> 20 Feb 00:32:41 [7804] selected 1 (r=1, w=0)
MvdV>> 20 Feb 00:32:41 [7804] Read -1 bytes
MvdV>> ? 20 Feb 00:32:41 [7804] recv: {W32 API error 183} Eine Datei
MvdV>> kann nicht erstellt werden, wenn sie bereits vorhanden ist.

ml> "A file can not be created if it already exists." ???

ml> what file is it talking about?

MvdV> I have no idea... The negative number of bytes read also puzzles
MvdV> me.

agreed... since it is a received error, apparently from the remote telling you
about the problem, it would appear to point, yet again, to a remote side
situation...

)\/(ark

One of the great tragedies of life is the murder of a beautiful theory by a
gang of brutal facts. --Benjamin Franklin

[Michiel van der Vlist]

Hello mark,

On Friday February 21 2014 14:36, you wrote to me:

MvdV>> I have no idea... The negative number of bytes read also
MvdV>> puzzles me.

ml> agreed... since it is a received error, apparently from the remote
ml> telling you about the problem, it would appear to point, yet again, to
ml> a remote side situation...

Yes, so it seems...

Cheers, Michiel

[Markus Reschke]

Hello Michiel!

Feb 21 15:53 2014, Michiel van der Vlist wrote to mark lewis:


MvdV>>> 20 Feb 00:32:41 [7804] selected 1 (r=1, w=0)
MvdV>>> 20 Feb 00:32:41 [7804] Read -1 bytes
MvdV>>> ? 20 Feb 00:32:41 [7804] recv: {W32 API error 183} Eine Datei
MvdV>>> kann nicht erstellt werden, wenn sie bereits vorhanden ist.

ml>> "A file can not be created if it already exists." ???

ml>> what file is it talking about?

MvdV> I have no idea... The negative number of bytes read also puzzles
MvdV> me.

There's a simple explanation. The read() function returns the bytes read or -1
in the case of an error (the exact problem can then be gathered via errno).

Regards,
Markus

[Michiel van der Vlist]

Hello Markus,

On Friday February 21 2014 21:29, you wrote to me:

MvdV>> I have no idea... The negative number of bytes read also
MvdV>> puzzles me.

MR> There's a simple explanation. The read() function returns the bytes
MR> read or -1 in the case of an error (the exact problem can then be
MR> gathered via errno).

Yes of course. Now that you mention it, I knew that. I have allowed my
programming skills to become rusty....

Cheers, Michiel

[Wilfred van Velzen]

Hi Michiel,

On 20 Feb 14 00:49, Michiel van der Vlist wrote to Wilfred van Velzen:
about: "Error 10054":

WV>> Could you repeat the test with 'loglevel 10' ?

MvdV> + 20 Feb 00:38:07 [6576] Remote has 0b of mail and 0b of files for
MvdV> us
MvdV> 20 Feb 00:38:07 [6576] tv.tv_sec=60, tv.tv_usec=0
MvdV> 20 Feb 00:38:07 [6576] selected 1 (r=1, w=0)
MvdV> 20 Feb 00:38:07 [6576] Read 2 bytes
MvdV> 20 Feb 00:38:07 [6576] recvd hdr: 1 (msg)
MvdV> 20 Feb 00:38:07 [6576] tv.tv_sec=60, tv.tv_usec=0
MvdV> 20 Feb 00:38:07 [6576] selected 1 (r=1, w=0)
MvdV> 20 Feb 00:38:07 [6576] Read 1 bytes
MvdV> 20 Feb 00:38:07 [6576] got block: 1 (msg)
MvdV> 20 Feb 00:38:07 [6576] rcvd msg EOB
MvdV> 20 Feb 00:38:07 [6576] there were 4 msgs in this batch
MvdV> 20 Feb 00:38:07 [6576] send message EOB
MvdV> 20 Feb 00:38:07 [6576] tv.tv_sec=60, tv.tv_usec=0
MvdV> 20 Feb 00:38:07 [6576] selected 1 (r=0, w=1)
MvdV> 20 Feb 00:38:07 [6576] put next msg to obuf, 3
MvdV> 20 Feb 00:38:07 [6576] tv.tv_sec=60, tv.tv_usec=0
MvdV> 20 Feb 00:38:07 [6576] selected 1 (r=0, w=1)
MvdV> 20 Feb 00:38:07 [6576] sending 3 byte(s)
MvdV> 20 Feb 00:38:07 [6576] send() done, rc=3
MvdV> 20 Feb 00:38:07 [6576] data sent
MvdV> 20 Feb 00:38:08 [6576] tv.tv_sec=60, tv.tv_usec=0
MvdV> 20 Feb 00:38:09 [6576] selected 1 (r=1, w=0)
MvdV> 20 Feb 00:38:09 [6576] Read -1 bytes
MvdV> ? 20 Feb 00:38:09 [6576] recv: {W32 API error 183} Eine Datei kann nicht
MvdV> erstellt werden, wenn sie bereits vorhanden ist.
MvdV> + 20 Feb 00:38:09 [6576] done (to 2:280/***@fidonet, failed, S/R: 0/0
MvdV> (0/0 bytes))
MvdV> 20 Feb 00:38:09 [6576] processing kill list 20 Feb 00:38:09 [6576]
MvdV> restoring poll with `c' flavour
MvdV> 20 Feb 00:38:09 [6576] unlinked `d:\fido\outbound\01180013.bsy'
MvdV> 20 Feb 00:38:09 [6576] unlinked `d:\fido\outbound\01180403.bsy'
MvdV> 20 Feb 00:38:09 [6576] binkp deinit done...
MvdV> 20 Feb 00:38:09 [6576] session closed, quitting...
MvdV> 20 Feb 00:38:09 [6576] unlinked `d:\fido\outbound\01180013.csy'
MvdV> 20 Feb 00:38:09 [6576] perl_done_clone(): destructing clone 0

Interesting. There still is a 1 or 2 second gap before the Read -1 bytes (which
probably notifies an error). It might help if binkd, could log miliseconds when
in a higher loglevel!
And now the 'W32 API error' is different and in German!?

It would be interesting to compare this with logs from Kees at the same
loglevel, so we could tell if this is the same error.


Wilfred.

[Michiel van der Vlist]

Hello Wilfred,

On Thursday February 20 2014 09:02, you wrote to me:

MvdV>> ? 20 Feb 00:38:09 [6576] recv: {W32 API error 183} Eine Datei
MvdV>> kann nicht erstellt werden, wenn sie bereits vorhanden ist. +
MvdV>> 20 Feb 00:38:09 [6576] done (to 2:280/***@fidonet, failed, S/R:

WV> Interesting. There still is a 1 or 2 second gap before the Read -1
WV> bytes (which probably notifies an error).

Probably. I can't imagine how the number of bytes read can be negative.

WV> It might help if binkd, could log miliseconds when in a higher
WV> loglevel! And now the 'W32 API error' is different and in German!?

I have e German version of Windows. So the text asscociated with the error
number is generated locally.

What puzzles me is why the error is different from the one reported with
loglevel 4. I would not expect a different error, just more detailed
information.


Cheers, Michiel

[Wilfred van Velzen]

Hi,

On 2014-02-21 15:55:25, Michiel van der Vlist wrote to Wilfred van Velzen:
about: "Error 10054":

WV>> Interesting. There still is a 1 or 2 second gap before the Read -1
WV>> bytes (which probably notifies an error).

MvdV> Probably. I can't imagine how the number of bytes read can be negative.

Indeed. Functions like that return a negative number to signal an error.
Because zero and positive values are all valid return values.

WV>> It might help if binkd, could log miliseconds when in a higher
WV>> loglevel! And now the 'W32 API error' is different and in German!?

MvdV> I have e German version of Windows. So the text asscociated with the
MvdV> error
MvdV> number is generated locally.

But the previous error wasn't in German?

MvdV> What puzzles me is why the error is different from the one reported with
MvdV> loglevel 4. I would not expect a different error, just more detailed
MvdV> information.

Indeed. But maybe this is a clue to what's going on...

Bye, Wilfred.

[Michiel van der Vlist]

Hello Wilfred,

On Friday February 21 2014 17:20, you wrote to me:

WV>>> And now the 'W32 API error' is different and in German!?

MvdV>> I have e German version of Windows. So the text asscociated
MvdV>> with the error number is generated locally.

WV> But the previous error wasn't in German?

It was in English. So the text of that one was not generated by the local OS.

MvdV>> What puzzles me is why the error is different from the one
MvdV>> reported with loglevel 4. I would not expect a different error,
MvdV>> just more detailed information.

WV> Indeed. But maybe this is a clue to what's going on...

If it is, I haven't got it yet...

Cheers, Michiel

[Wilfred van Velzen]

Hi Michiel,

On 2014-02-25 00:44:00, you wrote to me:

MvdV>>> I have e German version of Windows. So the text asscociated
MvdV>>> with the error number is generated locally.

WV>> But the previous error wasn't in German?

MvdV> It was in English. So the text of that one was not generated by the
MvdV> local
MvdV> OS.

... Assuming that all error texts are translated in the local OS.

MvdV>>> What puzzles me is why the error is different from the one
MvdV>>> reported with loglevel 4. I would not expect a different error,
MvdV>>> just more detailed information.

WV>> Indeed. But maybe this is a clue to what's going on...

MvdV> If it is, I haven't got it yet...

Someone has to dive into the source... But I think the logs from the other side
would be the most helpfull at this stage.

Bye, Wilfred.

[Michiel van der Vlist]

Hello Wilfred,

On Tuesday February 25 2014 08:43, you wrote to me:

MvdV>>>> I have a German version of Windows. So the text asscociated
MvdV>>>> with the error number is generated locally.

WV>>> But the previous error wasn't in German?

MvdV>> It was in English. So the text of that one was not generated by
MvdV>> the local OS.

WV> ... Assuming that all error texts are translated in the local OS.

Apparently not. The English error texts presumably are genarate dby the
application.

MvdV>>>> What puzzles me is why the error is different from the one
MvdV>>>> reported with loglevel 4. I would not expect a different
MvdV>>>> error, just more detailed information.

WV>>> Indeed. But maybe this is a clue to what's going on...

MvdV>> If it is, I haven't got it yet...

WV> Someone has to dive into the source... But I think the logs from the
WV> other side would be the most helpfull at this stage.

Maybe. I wish Michiel Broek was still around...

Cheers, Michiel

[Wilfred van Velzen]

Hi Michiel,

On 25 Feb 14 10:57, Michiel van der Vlist wrote to Wilfred van Velzen:
about: "Error 10054":

WV>> ... Assuming that all error texts are translated in the local OS.

MvdV> Apparently not. The English error texts presumably are genarate dby the
MvdV> application.

I don't think so. It's a windows winsock error:

http://msdn.microsoft.com/en-us/library/aa924071.aspx

Just not translated.

The error 183 is from a different api:

http://tinyurl.com/cdofzvo or:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681382%28v=vs.85%29.a
spx

That apparantly is translated.

WV>> Someone has to dive into the source... But I think the logs from the
WV>> other side would be the most helpfull at this stage.

MvdV> Maybe. I wish Michiel Broek was still around...

He is arround, just not in fidonet. ;)

Wilfred.

[Michiel van der Vlist]

Hello All,

The plot thickens. Again...

It turns out, I actually can receive from- and send mail to the offending
system. But after the transfer is completed the other system forcebly closes
the session and although the mail transfer was completed, my side marks the
session as failed and just keeps on trying...

+ 25 Feb 12:25:45 [4696] call to 2:280/***@fidonet
25 Feb 12:25:45 [4696] trying binkp.dreamlandbbs.com [213.126.141.188]...
25 Feb 12:25:45 [4696] connected
+ 25 Feb 12:25:45 [4696] outgoing session with 213.126.141.188
- 25 Feb 12:25:45 [4696] OPT CRAM-MD5-78557b49511d9a1cabee73394744d474
+ 25 Feb 12:25:45 [4696] Remote requests MD mode
- 25 Feb 12:25:45 [4696] SYS Dreamland BBS
- 25 Feb 12:25:45 [4696] ZYZ Lukas de Groen
- 25 Feb 12:25:45 [4696] LOC Houten - The Netherlands
- 25 Feb 12:25:45 [4696] NDL CM,XX,IBN,IFC,IFT,ITN
- 25 Feb 12:25:45 [4696] TIME Tue, 25 Feb 2014 12:25:26 +0100
- 25 Feb 12:25:45 [4696] VER mbcico/0.95.13/GNU/Linux-x86_64 binkp/1.1
- 25 Feb 12:25:45 [4696] PHN 213.126.141.188
- 25 Feb 12:25:45 [4696] OPM Dreamland BBS, your great source for files!
+ 25 Feb 12:25:45 [4696] addr: 2:280/***@fidonet
+ 25 Feb 12:25:45 [4696] addr: 2:280/***@fidonet
+ 25 Feb 12:25:45 [4696] addr: 110:30/***@linuxnet (n/a or busy)
+ 25 Feb 12:25:45 [4696] addr: 115:31/***@pascalnet (n/a or busy)
+ 25 Feb 12:25:45 [4696] addr: 115:31/***@pascalnet (n/a or busy)
+ 25 Feb 12:25:45 [4696] addr: 115:3100/***@pascalnet (n/a or busy)
+ 25 Feb 12:25:45 [4696] addr: 115:3100/***@pascalnet (n/a or busy)
+ 25 Feb 12:25:46 [4696] pwd protected session (MD5)
- 25 Feb 12:25:46 [4696] OPT EXTCMD GZ BZ2 PLZ
+ 25 Feb 12:25:46 [4696] Remote supports EXTCMD mode
- 25 Feb 12:25:46 [4696] TRF 0 505
+ 25 Feb 12:25:46 [4696] Remote has 0b of mail and 505b of files for us
- 25 Feb 12:25:46 [4696] receiving 0000ea60.tu0 (505 byte(s), off 0)
+ 25 Feb 12:25:46 [4696] 0000ea60.tu0 -> d:\fido\secure\0000ea60.tu0
25 Feb 12:25:46 [4696] got *.TU?, creating d:\fido\sema\toss.now
25 Feb 12:25:46 [4696] got *, delayed starting d:\fido\mailrcvd.bat
+ 25 Feb 12:25:46 [4696] rcvd: 0000ea60.tu0 (505, 505.00 CPS, 2:280/***@fidonet)
? 25 Feb 12:25:48 [4696] recv: connection closed by foreign host
+ 25 Feb 12:25:48 [4696] done (to 2:280/***@fidonet, failed, S/R: 0/1 (0/505
bytes))
25 Feb 12:25:48 [4696] restoring poll with `c' flavour
25 Feb 12:25:48 [4696] Running d:\fido\mailrcvd.bat
- 25 Feb 12:25:48 [4696] executing `d:\fido\mailrcvd.bat'
- 25 Feb 12:25:48 [4696] rc=0
25 Feb 12:25:48 [4696] session closed, quitting...

So it gets the mail, but marks the session als failed and restores the poll
with 'c' flavour...

The same happens when sending mail:

+ 25 Feb 21:36:45 [6820] call to 2:280/***@fidonet
25 Feb 21:36:45 [6820] trying binkp.dreamlandbbs.com [213.126.141.188]...
25 Feb 21:36:45 [6820] connected
+ 25 Feb 21:36:45 [6820] outgoing session with 213.126.141.188
- 25 Feb 21:36:45 [6820] OPT CRAM-MD5-256c1d1f007a25f7d12025c4646522f3
+ 25 Feb 21:36:45 [6820] Remote requests MD mode
- 25 Feb 21:36:45 [6820] SYS Dreamland BBS
- 25 Feb 21:36:46 [6820] ZYZ Lukas de Groen
- 25 Feb 21:36:46 [6820] LOC Houten - The Netherlands
- 25 Feb 21:36:46 [6820] NDL CM,XX,IBN,IFC,IFT,ITN
- 25 Feb 21:36:46 [6820] TIME Tue, 25 Feb 2014 21:36:25 +0100
- 25 Feb 21:36:46 [6820] VER mbcico/0.95.13/GNU/Linux-x86_64 binkp/1.1
- 25 Feb 21:36:46 [6820] PHN 213.126.141.188
- 25 Feb 21:36:46 [6820] OPM Dreamland BBS, your great source for files!
+ 25 Feb 21:36:46 [6820] addr: 2:280/***@fidonet
+ 25 Feb 21:36:46 [6820] addr: 2:280/***@fidonet
+ 25 Feb 21:36:46 [6820] addr: 110:30/***@linuxnet (n/a or busy)
+ 25 Feb 21:36:46 [6820] addr: 115:31/***@pascalnet (n/a or busy)
+ 25 Feb 21:36:46 [6820] addr: 115:31/***@pascalnet (n/a or busy)
+ 25 Feb 21:36:46 [6820] addr: 115:3100/***@pascalnet (n/a or busy)
+ 25 Feb 21:36:46 [6820] addr: 115:3100/***@pascalnet (n/a or busy)
+ 25 Feb 21:36:46 [6820] pwd protected session (MD5)
+ 25 Feb 21:36:46 [6820] sending \FIDO\OUTBOUND\000011B0.TU0 as 000011B0.TU0
(1822)
- 25 Feb 21:36:46 [6820] OPT EXTCMD GZ BZ2 PLZ
+ 25 Feb 21:36:46 [6820] Remote supports EXTCMD mode
- 25 Feb 21:36:46 [6820] TRF 0 0
+ 25 Feb 21:36:46 [6820] Remote has 0b of mail and 0b of files for us
+ 25 Feb 21:36:46 [6820] sent: \FIDO\OUTBOUND\000011B0.TU0 (1822, 1822.00 CPS,
2:280/***@fidonet)
25 Feb 21:36:46 [6820] truncated \FIDO\OUTBOUND\000011B0.TU0
? 25 Feb 21:36:48 [6820] recv: connection closed by foreign host
+ 25 Feb 21:36:49 [6820] done (to 2:280/***@fidonet, failed, S/R: 1/0 (1822/0
bytes))
25 Feb 21:36:49 [6820] restoring poll with `c' flavour
25 Feb 21:36:49 [6820] session closed, quitting...

So... ?

I have asked Lukas for his logs. Waiting for his answer...

Groeten, Michiel


-+- GoldED+/W32-MINGW 1.1.5-b20110320

[Wilfred van Velzen]

Hi Michiel,

On 2014-02-26 11:27:57, you wrote to All:

MvdV> The plot thickens. Again...

MvdV> It turns out, I actually can receive from- and send mail to the
MvdV> offending
MvdV> system. But after the transfer is completed the other system forcebly
MvdV> closes the session and although the mail transfer was completed, my side
MvdV> marks the session as failed and just keeps on trying...

[...]

MvdV> So it gets the mail, but marks the session als failed and restores
MvdV> the poll with 'c' flavour...

MvdV> The same happens when sending mail:

MvdV> - 25 Feb 21:36:46 [6820] VER mbcico/0.95.13/GNU/Linux-x86_64
MvdV> binkp/1.1

The latest version of mbcico btw is 0.95.14, afaik... And of mbse as whole it
is 1.01. So maybe an update would be enough to fix it?

MvdV> + 25 Feb 21:36:46 [6820] sent: \FIDO\OUTBOUND\000011B0.TU0 (1822,
MvdV> 1822.00 CPS, 2:280/***@fidonet)
MvdV> 25 Feb 21:36:46 [6820] truncated \FIDO\OUTBOUND\000011B0.TU0
MvdV> ? 25 Feb 21:36:48 [6820] recv: connection closed by foreign host
MvdV> + 25 Feb 21:36:49 [6820] done (to 2:280/***@fidonet, failed, S/R:
MvdV> 1/0 (1822/0 bytes))
MvdV> 25 Feb 21:36:49 [6820] restoring poll with `c' flavour
MvdV> 25 Feb 21:36:49 [6820] session closed, quitting...

MvdV> So... ?

I don't see the "Win error" anymore? Or have you set the loglevel too low?

MvdV> I have asked Lukas for his logs. Waiting for his answer...

I'll stay tuned...

Bye, Wilfred.

[Michiel van der Vlist]

Hello All,

Problem solved! (Or maybe worked around)

I previously used Irex and Lukas had configured his MBSE to force binkp 1.0
connects with me. That worked for him then.

Apparently such a switch is useful for MBSE users....

But now that I switch to binkd and binkp v1.1 that setting does not work any
more,

He removed the force 1.0 on his side, and now all is hunky dory... ;-)

- 15:29 [9388] SYS Dreamland BBS
- 15:29 [9388] ZYZ Lukas de Groen
- 15:29 [9388] LOC Houten - The Netherlands
- 15:29 [9388] NDL CM,XX,IBN,IFC,IFT,ITN
- 15:29 [9388] TIME Wed, 26 Feb 2014 15:28:52 +0100
- 15:29 [9388] VER mbcico/0.95.13/GNU/Linux-x86_64 binkp/1.1
- 15:29 [9388] PHN 213.126.141.188
- 15:29 [9388] OPM Dreamland BBS, your great source for files!
+ 15:29 [9388] addr: 2:280/***@fidonet
+ 15:29 [9388] addr: 2:280/***@fidonet
+ 15:29 [9388] addr: 110:30/***@linuxnet (n/a or busy)
+ 15:29 [9388] addr: 115:31/***@pascalnet (n/a or busy)
+ 15:29 [9388] addr: 115:31/***@pascalnet (n/a or busy)
+ 15:29 [9388] addr: 115:3100/***@pascalnet (n/a or busy)
+ 15:29 [9388] addr: 115:3100/***@pascalnet (n/a or busy)
+ 15:29 [9388] pwd protected session (MD5)
- 15:29 [9388] OPT EXTCMD GZ BZ2 PLZ
+ 15:29 [9388] Remote supports EXTCMD mode
- 15:29 [9388] TRF 0 0
+ 15:29 [9388] Remote has 0b of mail and 0b of files for us
+ 15:29 [9388] done (to 2:280/***@fidonet, OK, S/R: 0/0 (0/0 bytes))
15:29 [9388] session closed, quitting...
15:29 [2908] the queue is empty, quitting...

Cheers, Michiel

[Wilfred van Velzen]

Hi,

On 2014-02-26 15:35:07, Michiel van der Vlist wrote to All:
about: "Error 10054":

MvdV> Problem solved! (Or maybe worked around)

MvdV> I previously used Irex and Lukas had configured his MBSE to force binkp
MvdV> 1.0
MvdV> connects with me. That worked for him then.

But it still annouced itself as binkp/1.1 capable...

From your previous log:

- 25 Feb 21:36:46 [6820] VER mbcico/0.95.13/GNU/Linux-x86_64 binkp/1.1

MvdV> Apparently such a switch is useful for MBSE users....

Are you withdrawing your request for binkd now, for such a switch?

MvdV> He removed the force 1.0 on his side, and now all is hunky dory...
MvdV> ;-)

But Kees never used irex and still has this problem. Or Lukas set is mistakenly
for Kees?

Bye, Wilfred.

[Michiel van der Vlist]

Hello Wilfred,

On Wednesday February 26 2014 17:57, you wrote to me:

MvdV>> Problem solved! (Or maybe worked around)

MvdV>> I previously used Irex and Lukas had configured his MBSE to
MvdV>> force binkp 1.0 connects with me. That worked for him then.

WV> But it still annouced itself as binkp/1.1 capable...

WV> From your previous log:

WV> - 25 Feb 21:36:46 [6820] VER mbcico/0.95.13/GNU/Linux-x86_64 binkp/1.1

I noticed that too. I may be more logical to announce 1.0 when in force 1.0
mode. At least it might have given us a clue.

MvdV>> Apparently such a switch is useful for MBSE users....

WV> Are you withdrawing your request for binkd now, for such a switch?

No! Om the contrary. The fact that the maker of MBSE found the option useful,
strenghtens my idea that it might be useful for other ninkp implemtations as
well.

MvdV>> He removed the force 1.0 on his side, and now all is hunky
MvdV>> dory... ;-)

WV> But Kees never used irex and still has this problem. Or Lukas set is
WV> mistakenly for Kees?

Kees does not have a problem with lukas. He has a problem with 280/1016.


Cheers, Michiel

[Wilfred van Velzen]

Hi,

On 2014-02-26 20:29:46, Michiel van der Vlist wrote to Wilfred van Velzen:
about: "Error 10054":

WV>> - 25 Feb 21:36:46 [6820] VER mbcico/0.95.13/GNU/Linux-x86_64
WV>> binkp/1.1

MvdV> I noticed that too. I may be more logical to announce 1.0 when in force
MvdV> 1.0
MvdV> mode. At least it might have given us a clue.

When I look in the loglevel 10 logs you posted before, I notice:

20 Feb 00:38:05 [6576] rcvd msg NUL VER mbcico/0.95.13/GNU/Linux-x86_64
binkp/1.1
- 20 Feb 00:38:05 [6576] VER mbcico/0.95.13/GNU/Linux-x86_64 binkp/1.1
20 Feb 00:38:05 [6576] remote uses binkp v.1.1

So your binkd thinks it's talking to a v1.1 binkp enabled system, while mbcico
is set to v1.0. That might be the cause of the bug then!

WV>> Are you withdrawing your request for binkd now, for such a switch?

MvdV> No! Om the contrary. The fact that the maker of MBSE found the option
MvdV> useful, strenghtens my idea that it might be useful for other ninkp
MvdV> implemtations as well.

But it might be a mistake to offer it. ;)

Or maybe the implementation in mbcico is wrong...

MvdV>>> He removed the force 1.0 on his side, and now all is hunky
MvdV>>> dory... ;-)

WV>> But Kees never used irex and still has this problem. Or Lukas set is
WV>> mistakenly for Kees?

MvdV> Kees does not have a problem with lukas. He has a problem with 280/1016.

Ok, my mistake...

Bye, Wilfred.

[Michiel van der Vlist]

Hello Wilfred,

On Wednesday February 26 2014 21:27, you wrote to me:

WV> When I look in the loglevel 10 logs you posted before, I notice:
[..]
WV> 20 Feb 00:38:05 [6576] remote uses binkp v.1.1

Aha!

WV> So your binkd thinks it's talking to a v1.1 binkp enabled system,
WV> while mbcico is set to v1.0. That might be the cause of the bug then!

Falsely announcing 1.1 sure is asking for problems...

WV>>> Are you withdrawing your request for binkd now, for such a switch?

MvdV>> No! Om the contrary. The fact that the maker of MBSE found the
MvdV>> option useful, strenghtens my idea that it might be useful for
MvdV>> other ninkp implementations as well.

WV> But it might be a mistake to offer it. ;)

It certainly should be used with caution.

But in this case it may have offered a work around if the sysop on the other
side had not responded.

WV> Or maybe the implementation in mbcico is wrong...

Obviously there is a misunderstanding between binkd and mbcico about which
version, 1.0 or 1.1, is in effect. It could be attributed to either one or
both...


Cheers, Michiel

[Michiel van der Vlist]

Hello Wilfred,

On Wednesday February 26 2014 11:45, you wrote to me:

WV> The latest version of mbcico btw is 0.95.14, afaik... And of mbse as
WV> whole it is 1.01. So maybe an update would be enough to fix it?

Perhaps. But as you can see, we sort of found the problem.

MvdV>> failed, S/R: 1/0 (1822/0 bytes))
MvdV>> 25 Feb 21:36:49 [6820] restoring poll with `c' flavour
MvdV>> 25 Feb 21:36:49 [6820] session closed, quitting...

MvdV>> So... ?

WV> I don't see the "Win error" anymore? Or have you set the loglevel too
WV> low?

The WIN error occured a minute later when my system performs an empty poll
after the "restoring poll with `c' flavour". And it kept on doing that...

MvdV>> I have asked Lukas for his logs. Waiting for his answer...

WV> I'll stay tuned...

Lukas did not see anything but normal connections on his side, but he noticed I
changed from 1.0 (Irex) to 1.1 (binkd.


Cheers, Michiel

[Vince Coen]

Hello Wilfred!

Wednesday February 26 2014 11:45, you wrote to Michiel van der Vlist:

MvdV>> - 25 Feb 21:36:46 [6820] VER mbcico/0.95.13/GNU/Linux-x86_64
MvdV>> binkp/1.1

Post by Wilfred van Velzen
The latest version of mbcico btw is 0.95.14, afaik... And of mbse as
whole it is 1.01. So maybe an update would be enough to fix it?

Latest version of mbcico is 1.0.1 along with the whole mbse system and all
tools.

However the problem is I suspect not with mbse but with your software so can I
suggest that you consider changing it to a version that does not have the
problem :)


I should point out that no one has reported such a problem with mbse within
the
mbse echo so I have to 'assume' it relates directly with binkd and the test
release that you are using.


Vince

[Wilfred van Velzen]

Hi,

On 2014-02-26 15:42:09, Vince Coen wrote to Wilfred van Velzen:
about: "Error 10054":

MvdV>>> - 25 Feb 21:36:46 [6820] VER mbcico/0.95.13/GNU/Linux-x86_64
MvdV>>> binkp/1.1

Post by Wilfred van Velzen
The latest version of mbcico btw is 0.95.14, afaik... And of mbse as
whole it is 1.01. So maybe an update would be enough to fix it?

VC> Latest version of mbcico is 1.0.1 along with the whole mbse system and
VC> all tools.

I looked at the code that is commited into the sourceforge code repository.
Latest changes for mbcico coincide with 0.95.14 ...

VC> However the problem is I suspect not with mbse but with your software
VC> so can I suggest that you consider changing it to a version that does
VC> not have the problem :)

VC> I should point out that no one has reported such a problem with mbse
VC> within the mbse echo so I have to 'assume' it relates directly with
VC> binkd and the test release that you are using.

Your assumption is wrong and you are addressing this to the wrong person, I'm
not the one having the problem... ;)

Look at Michiels message, for the solution.


Bye, Wilfred.

[Michiel van der Vlist]

Hello Vince,

On Wednesday February 26 2014 15:42, you wrote to Wilfred van Velzen:

VC> However the problem is I suspect not with mbse but with your software

I think you are going too fast. First: it is not Wilfred who has the problem.It
is I and some others. And I and those others ONLY have the problem with some
nodes using mbcico. That at least would suggest that part of the problem lies
with mbcico.

VC> so can I suggest that you consider changing it to a version that does
VC> not have the problem :)

Does such a version exist?

VC> I should point out that no one has reported such a problem with mbse
VC> within the mbse echo so I have to 'assume' it relates directly with
VC> binkd and the test release that you are using.

Again: that is to fast. The mbcico node I had a problem with had not noticed
anything wrong other than that my system just kept on makeinb polls. The only
thing that one can conclude is that mbcico does not report a problem and binkd
does. In and by itself that does not tell us who the cause of the problem is.
Just who reports it.




Cheers, Michiel

[Vince Coen]

Hello Michiel!

Post by Michiel van der Vlist
Again: that is to fast. The mbcico node I had a problem with had not
noticed anything wrong other than that my system just kept on makeinb
polls. The only thing that one can conclude is that mbcico does not
report a problem and binkd does. In and by itself that does not tell
us who the cause of the problem is. Just who reports it.

Thanks for your previous response with the answer. I noticed that I had one
downlink with this set. Now that I have cleared it it will be interesting to
see
of there is an issue for this node.

My apologies for 'assuming' it has been many years since I have had a need to
look at this setting that I totally forgot about it.

It what happens when the system just works (well, normally).

Vince

[Michiel van der Vlist]

Hello Vince,

On Thursday February 27 2014 23:33, you wrote to me:

VC> My apologies for 'assuming' it has been many years since I have had a
VC> need to look at this setting that I totally forgot about it.

VC> It what happens when the system just works (well, normally).

Yeah, that sounds familiar. ;-)

Ok, so we have found a work around. So far so good. What remains is the
question why binkd thinks mbicico is in 1.1 mode when the sysop has forced it
in 1.0 mode.

Is mbcico sending the wrong signal or is binkd misreading mbcico's signal?

It is my understanding that you are the present maintainer of MBSE. Could you
have a look at it?


Cheers, Michiel

[Vince Coen]

Hello Michiel!

Post by Michiel van der Vlist
Ok, so we have found a work around. So far so good. What remains is
the question why binkd thinks mbicico is in 1.1 mode when the sysop
has forced it in 1.0 mode.
Is mbcico sending the wrong signal or is binkd misreading mbcico's signal?
It is my understanding that you are the present maintainer of MBSE.
Could you have a look at it?

Can you verify that mbse was set for the specific sysop/node address to force
binkd protocol to v1.1 as it is possible that it was set to v1.0 only.

The standard default is v1.1.

Vince

[Michiel van der Vlist]

Hello Vince,

Post by Michiel van der Vlist
It is my understanding that you are the present maintainer of MBSE.
Could you have a look at it?

VC> Can you verify that mbse was set for the specific sysop/node address
VC> to force binkd protocol to v1.1 as it is possible that it was set to
VC> v1.0 only.

It WAS set to v1.0 only for my node and then I got the error. When that setting
was removed, the error disappeared.


Cheers, Michiel

[Vince Coen]

Hello Michiel!

Post by Michiel van der Vlist

Post by Michiel van der Vlist
It is my understanding that you are the present maintainer of
MBSE. Could you have a look at it?

VC>> Can you verify that mbse was set for the specific sysop/node
VC>> address to force binkd protocol to v1.1 as it is possible that it
VC>> was set to v1.0 only.

Post by Michiel van der Vlist
It WAS set to v1.0 only for my node and then I got the error. When
that setting was removed, the error disappeared.

In that case, it seems to be working correctly.


Vince

[mark lewis]

On Sat, 01 Mar 2014, Vince Coen wrote to Michiel van der Vlist:

VC>> Can you verify that mbse was set for the specific sysop/node
VC>> address to force binkd protocol to v1.1 as it is possible that it
VC>> was set to v1.0 only.

Post by Michiel van der Vlist
It WAS set to v1.0 only for my node and then I got the error. When
that setting was removed, the error disappeared.

VC> In that case, it seems to be working correctly.

IIUC, mbse showed that it was in binkp 1.1 mode even though it was forced to
binkp 1.0 mode... this doesn't seem correct...

)\/(ark

One of the great tragedies of life is the murder of a beautiful theory by a
gang of brutal facts. --Benjamin Franklin

[Kees van Eeten]

Hello mark!

01 Mar 14 15:57, you wrote to Vince Coen:

VC>> In that case, it seems to be working correctly.

ml> IIUC, mbse showed that it was in binkp 1.1 mode even though it was forced
ml> to binkp 1.0 mode... this doesn't seem correct...

As far as I know, the version line in de system handshake said the version
supports binkd v1.1.

I see no reason why that banner should change if program is forced to
v1.0 by an available option.

Kees

[mark lewis]

On Sat, 01 Mar 2014, Kees van Eeten wrote to mark lewis:

VC>> In that case, it seems to be working correctly.

ml> IIUC, mbse showed that it was in binkp 1.1 mode even though it
ml> was forced
ml> to binkp 1.0 mode... this doesn't seem correct...

KvE> As far as I know, the version line in de system handshake said
KvE> the version supports binkd v1.1.

right...

KvE> I see no reason why that banner should change if program is
KvE> forced to v1.0 by an available option.

why? so that the remote end will know that it is dealing with a 1.0 system and
not attempt to use 1.1 options... seems a reasonable expectation to me...

)\/(ark

One of the great tragedies of life is the murder of a beautiful theory by a
gang of brutal facts. --Benjamin Franklin

[Michiel van der Vlist]

Hello Kees,

On Saturday March 01 2014 22:41, you wrote to mark lewis:

KE> As far as I know, the version line in de system handshake said the
KE> version supports binkd v1.1.

While it actually didn't because it was forced into 1.0 mode.

KE> I see no reason why that banner should change if program is forced to
KE> 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

[Michiel van der Vlist]

Hello mark,

Post by Michiel van der Vlist
It WAS set to v1.0 only for my node and then I got the error. When
that setting was removed, the error disappeared.

VC>> In that case, it seems to be working correctly.

ml> IIUC, mbse showed that it was in binkp 1.1 mode even though it was
ml> forced to binkp 1.0 mode... this doesn't seem correct...

Indeed. So either MBSE incorrectly signals it is in 1.1 mode or binkd
incorrectly interprets the signal. Or a bit of both.

Add to that that binkd does not have problems with other binkp implemenations
such as Radius 4.009 and Argus 3.210, that are 1.0, I would suggest MBSE as the
prime suspect.


Cheers, Michiel

[mark lewis]

On Sat, 01 Mar 2014, Michiel van der Vlist wrote to mark lewis:

VC>> In that case, it seems to be working correctly.

ml> IIUC, mbse showed that it was in binkp 1.1 mode even though it was
ml> forced to binkp 1.0 mode... this doesn't seem correct...

MvdV> Indeed. So either MBSE incorrectly signals it is in 1.1 mode or
MvdV> binkd incorrectly interprets the signal. Or a bit of both.

maybe both but that depends on how binkd determines what the other end's
capabilities are... at least as far as what binkp version the other end
speaks...

MvdV> Add to that that binkd does not have problems with other binkp
MvdV> implemenations such as Radius 4.009 and Argus 3.210, that are
MvdV> 1.0, I would suggest MBSE as the prime suspect.

if you would like, we can also test the above with Taurus... the last available
beta that i'm aware of, anyway... IIRC, i even have the sources for it around
here somewhere...

)\/(ark

One of the great tragedies of life is the murder of a beautiful theory by a
gang of brutal facts. --Benjamin Franklin

[Vince Coen]

* Originally in BINKD
* Crossposted in MBSE

Hello mark!
VC>>> Can you verify that mbse was set for the specific sysop/node
VC>>> address to force binkd protocol to v1.1 as it is possible that
VC>>> it was set to v1.0 only.

Post by mark lewis

Post by Michiel van der Vlist
It WAS set to v1.0 only for my node and then I got the error. When
that setting was removed, the error disappeared.

VC>> In that case, it seems to be working correctly.

Post by mark lewis
IIUC, mbse showed that it was in binkp 1.1 mode even though it was
forced to binkp 1.0 mode... this doesn't seem correct...

Sound like ypu are saying that the report is only showing the mbse mode as
designed and not the 'Actual' mode it is currently in for the 'current'
connection?

If that is correct then yes it is a bug (cosmetic).
Confirm the above and I will pass to the mbse echo for reference and
discussion
before looking at the code by myself or one of the other support team.

A test shown in a later msg appears to uses mbcico v0.50.0 and mbse is at
v1.01.0 so a very old version.

If someone (who has had/has this problem) can get in touch direct I can set up
test for that sysop by setting him as a binkd v1.0 user and see what happens
when polled and likewise when I do so.

This can only be via IBN (all modems now discontinued due lack of usage - ok,
none in 4-5 years).


Vince

[Michiel van der Vlist]

Hello Vince,

Post by mark lewis
IIUC, mbse showed that it was in binkp 1.1 mode even though it was
forced to binkp 1.0 mode... this doesn't seem correct...

VC> Sound like ypu are saying that the report is only showing the mbse
VC> mode as designed and not the 'Actual' mode it is currently in for the
VC> 'current' connection?

Yes.

VC> If that is correct then yes it is a bug (cosmetic).

I think it is more than cosmetic because it causes a premature disconnect.

VC> If someone (who has had/has this problem) can get in touch direct I
VC> can set up test for that sysop by setting him as a binkd v1.0 user and
VC> see what happens when polled and likewise when I do so.

I had the problem. Here is what happened when I just called you:

03 Mar 21:54:26 [5592] BEGIN standalone, binkd/1.1a-49/Win32 -p -P250/1
binkd.cfg
03 Mar 21:54:26 [5592] creating a poll for 2:250/***@fidonet (`d' flavour)
03 Mar 21:54:26 [5592] clientmgr started
+ 03 Mar 21:54:26 [1368] call to 2:250/***@fidonet
03 Mar 21:54:27 [1368] trying f1.n250.z2.binkp.net [81.179.6.57]...
03 Mar 21:54:27 [1368] connected
+ 03 Mar 21:54:27 [1368] outgoing session with 81.179.6.57
- 03 Mar 21:54:27 [1368] OPT CRAM-MD5-22d8c31cc04608597fcaffb155d829c9
+ 03 Mar 21:54:27 [1368] Remote requests MD mode
- 03 Mar 21:54:27 [1368] SYS Air Applewood BBS
- 03 Mar 21:54:27 [1368] ZYZ Vince Coen
- 03 Mar 21:54:27 [1368] LOC Roydon, Essex, UK
- 03 Mar 21:54:27 [1368] NDL CM,XA,IBN
- 03 Mar 21:54:27 [1368] TIME Mon, 03 Mar 2014 20:54:35 +0000
- 03 Mar 21:54:27 [1368] VER mbcico/1.0.1/GNU/Linux-x86_64 binkp/1.1
- 03 Mar 21:54:27 [1368] PHN applewood.dtdns.net
- 03 Mar 21:54:27 [1368] OPM Air Applewood BBS Linux System
+ 03 Mar 21:54:27 [1368] addr: 2:250/***@fidonet
+ 03 Mar 21:54:27 [1368] addr: 2:25/***@fidonet
+ 03 Mar 21:54:27 [1368] addr: 2:250/***@fidonet
+ 03 Mar 21:54:27 [1368] addr: 2:263/***@fidonet
- 03 Mar 21:54:27 [1368] OPT EXTCMD GZ BZ2 PLZ
+ 03 Mar 21:54:27 [1368] Remote supports EXTCMD mode
- 03 Mar 21:54:28 [1368] TRF 0 0
+ 03 Mar 21:54:28 [1368] Remote has 0b of mail and 0b of files for us
+ 03 Mar 21:54:28 [1368] done (to 2:250/***@fidonet, OK, S/R: 0/0 (0/0 bytes))
03 Mar 21:54:28 [1368] session closed, quitting...

So now please set me up as a 1.0 users and I will poll you again.

VC> This can only be via IBN (all modems now discontinued due lack of
VC> usage - ok, none in 4-5 years).

Same here. Dropped POTS support last Friday. No calls in over five years, other
than the occasional test just to see if it still worked.


Cheers, Michiel

[mark lewis]

On Mon, 03 Mar 2014, Vince Coen wrote to mark lewis:

VC>>> Can you verify that mbse was set for the specific sysop/node
VC>>> address to force binkd protocol to v1.1 as it is possible that
VC>>> it was set to v1.0 only.

Post by mark lewis

Post by Michiel van der Vlist
It WAS set to v1.0 only for my node and then I got the error. When
that setting was removed, the error disappeared.

VC>> In that case, it seems to be working correctly.

Post by mark lewis
IIUC, mbse showed that it was in binkp 1.1 mode even though it was
forced to binkp 1.0 mode... this doesn't seem correct...

VC> Sound like ypu are saying that the report is only showing the mbse
VC> mode as designed and not the 'Actual' mode it is currently in for
VC> the 'current' connection?

all i know is what i read in the messages posted here... the logs showed binkp
1.1 on both ends but we know that one end (mbcico) was forced to binkp 1.0...

VC> If that is correct then yes it is a bug (cosmetic).

sound like it may be a bug but i don't know about it being only cosmetic... i
would have to study the binkp protocols details to see how it communicates the
level/version of binkp being support and/or offered...

VC> Confirm the above and I will pass to the mbse echo for reference
VC> and discussion before looking at the code by myself or one of the
VC> other support team.

i'll let those involved with the problem do the confirming... i'm only a
bystander watching the proceedings and pointing out things that may be being
missed O:)

)\/(ark

One of the great tragedies of life is the murder of a beautiful theory by a
gang of brutal facts. --Benjamin Franklin

[Michiel van der Vlist]

Hello mark,

On Tuesday March 04 2014 14:06, you wrote to Vince Coen:


ml> sound like it may be a bug but i don't know about it being only
ml> cosmetic... i would have to study the binkp protocols details to see
ml> how it communicates the level/version of binkp being support and/or
ml> offered...

This is a log snippet (loglevel 10) from my connect with Vince earlier today.
His system was set to force 1.0 mode with my system:

04 Mar 20:58:57 [6768] Read 44 bytes
04 Mar 20:58:57 [6768] got block: 44 (msg)
04 Mar 20:58:57 [6768] rcvd msg NUL VER mbcico/1.0.1/GNU/Linux-x86_64
binkp/1.1
- 04 Mar 20:58:57 [6768] VER mbcico/1.0.1/GNU/Linux-x86_64 binkp/1.1
04 Mar 20:58:57 [6768] remote uses binkp v.1.1

My system reports "remote uses binkp v1.1" immidiately after receiving the
other side's banner. I conclude that it derives the protocol version from the
banner.


VC>> Confirm the above and I will pass to the mbse echo for reference
VC>> and discussion before looking at the code by myself or one of
VC>> the other support team.

ml> i'll let those involved with the problem do the confirming... i'm only
ml> a bystander watching the proceedings and pointing out things that may
ml> be being missed O:)

I get the same results with Vince's system as with 280/19 before. An error
10054 when mbcico is forced to 1.0 mode.

This, BTW, is what happens when I connect to a true binkp 1.0 system:

05 Mar 00:32:10 [6620] Read 59 bytes
05 Mar 00:32:10 [6620] got block: 59 (msg)
05 Mar 00:32:10 [6620] rcvd msg NUL VER Radius/4.009-02.01.2003 (New Year
Release)/ binkp/1.0
- 05 Mar 00:32:10 [6620] VER Radius/4.009-02.01.2003 (New Year Release)/
binkp/1.0
05 Mar 00:32:10 [6620] remote uses binkp v.1.0

Again, my binkd reads the banner string and gleens the protocol version from
that.



Cheers, Michiel

[mark lewis]

On Wed, 05 Mar 2014, Michiel van der Vlist wrote to mark lewis:

ml> sound like it may be a bug but i don't know about it being only
ml> cosmetic... i would have to study the binkp protocols details to see
ml> how it communicates the level/version of binkp being support and/or
ml> offered...

MvdV> This is a log snippet (loglevel 10) from my connect with Vince
MvdV> earlier today. His system was set to force 1.0 mode with my
MvdV> system:

MvdV> 04 Mar 20:58:57 [6768] Read 44 bytes
MvdV> 04 Mar 20:58:57 [6768] got block: 44 (msg)
====
MvdV> 04 Mar 20:58:57 [6768] rcvd msg NUL VER
MvdV> mbcico/1.0.1/GNU/Linux-x86_64 binkp/1.1
====
MvdV> - 04 Mar 20:58:57 [6768] VER mbcico/1.0.1/GNU/Linux-x86_64
MvdV> binkp/1.1 04 Mar 20:58:57 [6768] remote uses binkp v.1.1

MvdV> My system reports "remote uses binkp v1.1" immidiately after
MvdV> receiving the other side's banner. I conclude that it derives the
MvdV> protocol version from the banner.

actually, the line i hilited above is the protocol's version exchange...
according to FSP-1024 (proposal for binkp 1.1), this exchange must be done so
that both ends know what they are talking to on the other end so they can
decide if they can do multiple batches and session turn-arounds which is one of
the features of binkp 1.1 ;)

[quote FSP-1024]
4.1 Protocol identification string
----------------------------------

In session setup stage both sides sends M_NUL frame like this:

M_NUL "VER mailer version binkp/1.1"

where "mailer version" is mailer identification string, usually
mailer name and version, in free form, and "binkp/1.1" is the
protocol identification string, case-incencitive.
Mailer identification string MAY have and SHOULD consist only
characters in the ASCII codes range 32-126 (" ".."~").

Example:

M_NUL "VER binkd/0.9.5a/FreeBSD binkp/1.1"

Version identification frame MUST be send and may be received
before autentification ends (before sending of M_PWD frame by
originating side and M_OK by answering side). Otherwise mailer
MUST fallback to binkp 1.0.
[/quote]

this VER protocol frame is also done in binkp 1.0 /but/ the standards document
for binkp 1.0 notes that not all binkp 1.0 mailers present the VER frame...

based on both binkp 1.0 and 1.1 sending the VER frame, i would have to say that
a system that can force binkp 1.0 for another link should advertise 1.0 in
their VER frame when they transmit it... i do believe that vince can definitely
consider this a bug in mbcico ;)

)\/(ark

[Michiel van der Vlist]

Hello mark,

On Wednesday March 05 2014 11:57, you wrote to me:

MvdV>> My system reports "remote uses binkp v1.1" immidiately after
MvdV>> receiving the other side's banner. I conclude that it derives
MvdV>> the protocol version from the banner.

ml> actually, the line i hilited above is the protocol's version
ml> exchange... according to FSP-1024 (proposal for binkp 1.1), this
ml> exchange must be done so that both ends know what they are talking to
ml> on the other end so they can decide if they can do multiple batches
ml> and session turn-arounds which is one of the features of binkp 1.1 ;)

That is what I suspected right from the beginning, but I did not get around to
check against the docs. Thankls for doing the leg work.

ml> based on both binkp 1.0 and 1.1 sending the VER frame, i would have to
ml> say that a system that can force binkp 1.0 for another link should
ml> advertise 1.0 in their VER frame when they transmit it... i do believe
ml> that vince can definitely consider this a bug in mbcico ;)

Agreed. But there is more... Look at Vince's log and you will see that his
system forceably downgrades itself to 1.0 a few steps AFTER the protocol
version exchange that you mention. Without notifying the other side..

So this is more than mbcico just misinforming the other side about the version
in effect, it is a case of unilaterally changing the version in effect AFTER
having reached an agreement on what version to use...

This is asking for problems. Forcing a downgrade to 1.0 should only be done on
outgoing calls...


Cheers, Michiel

[mark lewis]

On Thu, 06 Mar 2014, Michiel van der Vlist wrote to mark lewis:

MvdV>> My system reports "remote uses binkp v1.1" immidiately after
MvdV>> receiving the other side's banner. I conclude that it derives
MvdV>> the protocol version from the banner.

ml> actually, the line i hilited above is the protocol's version
ml> exchange... according to FSP-1024 (proposal for binkp 1.1), this
ml> exchange must be done so that both ends know what they are talking
ml> to on the other end so they can decide if they can do multiple
ml> batches and session turn-arounds which is one of the features of
ml> binkp 1.1 ;)

MvdV> That is what I suspected right from the beginning, but I did not
MvdV> get around to check against the docs. Thankls for doing the leg
MvdV> work.

you are welcome... i didn't know if it was part of the protocol or just
something in a banner being transmitted... that's why i looked it up...

ml> based on both binkp 1.0 and 1.1 sending the VER frame, i would
ml> have to say that a system that can force binkp 1.0 for another
ml> link should advertise 1.0 in their VER frame when they transmit
ml> it... i do believe that vince can definitely consider this a bug
ml> in mbcico ;)

MvdV> Agreed. But there is more... Look at Vince's log and you will
MvdV> see that his system forceably downgrades itself to 1.0 a few
MvdV> steps AFTER the protocol version exchange that you mention.
MvdV> Without notifying the other side..

i haven't seen that post yet (personal mail first, then all other mail)... i'll
keep an eye out for it... but i don't know if there's a way, in the protocol,
to signal the change... i don't know if one can send another M_NUL VER frame
and it be accepted by the other side...

MvdV> So this is more than mbcico just misinforming the other side
MvdV> about the version in effect, it is a case of unilaterally
MvdV> changing the version in effect AFTER having reached an agreement
MvdV> on what version to use...

i don't know that the protocol allows the machines to negotiate, actually...
the VER frame tells the other side what this side can support but we'll have to
dig deeper into the documents to see what is supposed to happen when one side
alters its support level...

MvdV> This is asking for problems. Forcing a downgrade to 1.0 should
MvdV> only be done on outgoing calls...

in this case, i think yes... especially since the one side is telling the other
that it is only 1.0 capable... or... oh wait... does IREX advertise 1.1 and is
only 1.0? that's where this started... with IREX not being able to work and so
the mbcico link set the option to force 1.0 mode for the IREX node... i've
never run IREX and i forget what gets logged on the main machine when they
connect...

with all of this, i sure hope that the binkp proposal gets completed soon...
with all the binkd systems out there, it is definitely in widespread use...
however, i think the mess in ukraine may have some side effects outside the
parties involved... i hope they are doing ok over there...

)\/(ark

One of the great tragedies of life is the murder of a beautiful theory by a
gang of brutal facts. --Benjamin Franklin

[Michiel van der Vlist]

Hello mark,

On Thursday March 06 2014 09:48, you wrote to me:

ml>> based on both binkp 1.0 and 1.1 sending the VER frame, i would
ml>> have to say that a system that can force binkp 1.0 for another
ml>> link should advertise 1.0 in their VER frame when they transmit
ml>> it... i do believe that vince can definitely consider this a bug
ml>> in mbcico ;)

It seems we have not convinced him yet...

MvdV>> Agreed. But there is more... Look at Vince's log and you will
MvdV>> see that his system forceably downgrades itself to 1.0 a few
MvdV>> steps AFTER the protocol version exchange that you mention.
MvdV>> Without notifying the other side..

ml> i haven't seen that post yet (personal mail first, then all other
ml> mail)... i'll keep an eye out for it... but i don't know if there's a
ml> way, in the protocol, to signal the change...

There is not.

ml> i don't know if one can send another M_NUL VER frame and it be
ml> accepted by the other side...

Since there is no mention of it in the docs, one must assume that there is no
provision in the protocol for it.

MvdV>> So this is more than mbcico just misinforming the other side
MvdV>> about the version in effect, it is a case of unilaterally
MvdV>> changing the version in effect AFTER having reached an
MvdV>> agreement on what version to use...

ml> i don't know that the protocol allows the machines to negotiate,
ml> actually... the VER frame tells the other side what this side can
ml> support

Well the negotiation is very basic. They both send a version string to the
other side, informing them what they support. Obviously they settle for the
common denominator. That being 1.1 only when both advertise 1.1.

ml> but we'll have to dig deeper into the documents to see what is
ml> supposed to happen when one side alters its support level...

They are not supposed to change the support level once the version string is
sent. Period.

MvdV>> This is asking for problems. Forcing a downgrade to 1.0 should
MvdV>> only be done on outgoing calls...

ml> in this case, i think yes...

On second thoughts it need not be. The receiving side need not send its version
string right after receiving it from the sending party. It can wait (and in
fact does in the case under discussion) for the ADR and then decide what
protocol to use. Like this:

A: Hallo, I can do binkp v 1.1 and my node number is 1:2/3.4

B: Ho there, yes I know you and with you I can only do 1.0.

or:

B: Hi there, I can also do 1.1.

ml> especially since the one side is telling the other that it is only
ml> 1.0 capable... or... oh wait... does IREX advertise 1.1 and is only
ml> 1.0? that's where this started...

Yes there is a problem with Irex. It advertises 1.1, but ithas its own
implementation which is not quite compatible with binkd.

So they have to gear down to 1.0

ml> with IREX not being able to work and so the mbcico link set the option
ml> to force 1.0 mode for the IREX node...

Yes.

ml> i've never run IREX and i forget what gets logged on the main machine
ml> when they connect...

1.1

ml> with all of this, i sure hope that the binkp proposal gets completed
ml> soon...

What is incomplete in binkd?

As I see it, the problem at hand is solely due to a flaw in mbcico.

ml> with all the binkd systems out there, it is definitely in widespread
ml> use...

No argument there...

ml> however, i think the mess in ukraine may have some side effects
ml> outside the parties involved... i hope they are doing ok over there...

I am optimistic regarding Fidonet and Ukrania. I expect the Ukranian members of
the binkd team to be able to continue their support fot binkd. But if not,
binkd is open source, so someone else can alway take over.


Cheers, Michiel

[mark lewis]

On Thu, 06 Mar 2014, Michiel van der Vlist wrote to mark lewis:

ml> especially since the one side is telling the other that it is only
ml> 1.0 capable... or... oh wait... does IREX advertise 1.1 and is only
ml> 1.0? that's where this started...

MvdV> Yes there is a problem with Irex. It advertises 1.1, but ithas
MvdV> its own implementation which is not quite compatible with binkd.

MvdV> So they have to gear down to 1.0

ahh, right and IREX was left hanging without any support or updates to fix
these problems :(

ml> with IREX not being able to work and so the mbcico link set the option
ml> to force 1.0 mode for the IREX node...

MvdV> Yes.

ml> i've never run IREX and i forget what gets logged on the main machine
ml> when they connect...

MvdV> 1.1

that's a shame but there's nothing that can be done about it, either...

ml> with all of this, i sure hope that the binkp proposal gets completed
ml> soon...

MvdV> What is incomplete in binkd?

"binkp proposal" != binkd ;)

binkp 1.1 is still a proposal and hasn't been completed and raised to a
standard in several years... binkp 1.0 is a standard, though...

MvdV> As I see it, the problem at hand is solely due to a flaw in
MvdV> mbcico.

ml> with all the binkd systems out there, it is definitely in widespread
ml> use...

MvdV> No argument there...

ml> however, i think the mess in ukraine may have some side effects
ml> outside the parties involved... i hope they are doing ok over there...

MvdV> I am optimistic regarding Fidonet and Ukrania. I expect the
MvdV> Ukranian members of the binkd team to be able to continue their
MvdV> support fot binkd. But if not, binkd is open source, so someone
MvdV> else can alway take over.

true but they should be here(1) and involved in thsi conversation instead of
leaving "us" to question and speculate... "they" are the ones who designed the
protocol and main implementation yet we rarely ever hear from them... sure, we
get the automated FAQ posting but little to nothing else... heck, i've pointed
out a problem in the FAQ and asked for a fix but no one who can do anything to
fix it has responded to even acknowledged it... it has been at least 8 months
or so since i first brought it up :/

)\/(ark

One of the great tragedies of life is the murder of a beautiful theory by a
gang of brutal facts. --Benjamin Franklin

[Michiel van der Vlist]

Hello mark,

On Thursday March 06 2014 20:10, you wrote to me:

ml>> ... or... oh wait... does IREX advertise 1.1 and is only 1.0? that's
ml>> where this started...

MvdV>> Yes there is a problem with Irex. It advertises 1.1, but ithas
MvdV>> its own implementation which is not quite compatible with binkd.

Or more precisely: not entirely compatible with mbcico.

Binkd does not seem to have a problem with Irex.

MvdV>> So they have to gear down to 1.0

"They" = mbcico users.

ml> ahh, right and IREX was left hanging without any support or updates to
ml> fix these problems :(

Right. Irex is abandonware.

ml>> i've never run IREX and i forget what gets logged on the main
ml>> machine when they connect...

MvdV>> 1.1

ml> that's a shame but there's nothing that can be done about it,
ml> either...

Not from the Irex side no. The rest of Fidonet shall just gave to live with it.
The irony is that the world of Fidonet does seem to cope with it, no one has
problems connectingwith Irex, but that now the binkd community has a problem
conneting with some mbcico nodes as a side effect of a a fix in mbcico to solve
a problem with Irex....

ml>> with all of this, i sure hope that the binkp proposal gets completed
ml>> soon...

MvdV>> What is incomplete in binkd?

ml> "binkp proposal" != binkd ;)

Ok...

ml> binkp 1.1 is still a proposal and hasn't been completed and raised to
ml> a standard in several years... binkp 1.0 is a standard, though...

I will put it on the todo list...

MvdV>> I am optimistic regarding Fidonet and Ukrania. I expect the
MvdV>> Ukranian members of the binkd team to be able to continue their
MvdV>> support fot binkd. But if not, binkd is open source, so someone
MvdV>> else can alway take over.

ml> true but they should be here(1) and involved in thsi conversation
ml> instead of leaving "us" to question and speculate... "they" are the
ml> ones who designed the protocol and main implementation yet we rarely
ml> ever hear from them... sure, we get the automated FAQ posting but
ml> little to nothing else... heck, i've pointed out a problem in the FAQ
ml> and asked for a fix but no one who can do anything to fix it has
ml> responded to even acknowledged it... it has been at least 8 months or
ml> so since i first brought it up :/

That's Fidonet for you. People start a project and then they loose interest.
Temporarely or permanent. Happens all the time.

Pavel was spotted in ENET.SYSOP recently however, so there is hope.


Cheers, Michiel

[Kees van Eeten]

Hello Michiel!

07 Mar 14 11:20, you wrote to mark lewis:

MvdV> That's Fidonet for you. People start a project and then they loose
MvdV> interest. Temporarely or permanent. Happens all the time.

That is not fair to the people who started these projects. The normal
history is that someone has a "problem" or an "itch " with how things go.
He gets an idea how to solve it and starts building the program. At a
certain stage cooperation of others is needed, or others are interested.
When it s good, it reaches a top in its development, that period is very
demanding on the lead developer. At a certain stage the program does more
than de lead developer and it is o.k. for him. To him the program is a
finished product. The outside world then blames him for loosing interest.

Now someone finds a problem that is trivial to the developer. His line of
thinking could be, well YOU know and understand the problem, fix it, the
source code is availabe. It it is usefull, send me the diffs and if I agree
with the solution, I will include it in the next release.

That is how it works most of the time,

Kees

[Michiel van der Vlist]

Hello Kees,

On Friday March 07 2014 11:39, you wrote to me:

MvdV>> That's Fidonet for you. People start a project and then they
MvdV>> loose interest. Temporarely or permanent. Happens all the time.

KE> That is not fair to the people who started these projects.

If you put it that way, perhaps not. I did not mean to denigrate or blaim
anyone. It was meant as a simple observation, but now that you mention it, I
can see that it did not come out quit the way I intended.

My apologies to anyone who was offended.


Cheers, Michiel

[Vince Coen]

Hello Michiel!

Post by Michiel van der Vlist
So this is more than mbcico just misinforming the other side about the
version in effect, it is a case of unilaterally changing the version
in effect AFTER having reached an agreement on what version to use...
This is asking for problems. Forcing a downgrade to 1.0 should only be
done on outgoing calls...

You are missing a point here, this ONLY occurs if the node has been set up as
using v1.0. The default is v1.1 so this should only be an issue if the
receiving
mbse sysop has downgraded the connection. Here is has never been set to v1.0,
clearly all my downlinks that use binkd are on the current versions.


Vince

[Michiel van der Vlist]

Hello Vince,

Post by Michiel van der Vlist
So this is more than mbcico just misinforming the other side about
the version in effect, it is a case of unilaterally changing the
version in effect AFTER having reached an agreement on what version
to use...

VC> You are missing a point here,

The point is that there is a problem.

VC> this ONLY occurs if the node has been set up as using v1.0.

Yes, we have been able to track down the conditions under which the problem
occurs. Configuring a node as v1.0 is the only one we found. As yet....

VC> The default is v1.1 so this should only be an issue if the receiving
VC> mbse sysop has downgraded the connection.

Which is precisely the issue that I ran into.

VC> Here is has never been set to v1.0, clearly all my downlinks that use
VC> binkd are on the current versions.

The world of Fidonet is bigger than your "here" Vince. I have stumbled on two
nodes in my net that had me configured as 1.0 in their MBSE setup. That worked
when I used Irex. When I switched to binkp I had problems connecting with them.

One of them I could contact and he removed the 1.0 setting for me. That solved
the problem. The other one is in hibernation and the problem continues.

There IS a problem and the cause is a bug in mbcico that reports 1.1 when it is
configured for 1.0 for the node in question.

Going in denial mode won't make the problem go away.


Cheers, Michiel

[Vince Coen]

Hello Michiel!

Post by Michiel van der Vlist
There IS a problem and the cause is a bug in mbcico that reports 1.1
when it is configured for 1.0 for the node in question.

I will have a look at the code to modify it to reflect the nodes binkd
settings
if set to 1.0.

Will try and do so this w/e.




Vince

[Michiel van der Vlist]

Hello Vince,

On Friday March 07 2014 18:08, you wrote to me:

VC> I will have a look at the code to modify it to reflect the nodes binkd
VC> settings if set to 1.0.

Good! ;=_

VC> Will try and do so this w/e.

Let me know when you have something ready for testing.


Cheers, Michiel

[Michiel van der Vlist]

Hello Vince,

On Friday March 07 2014 18:08, you wrote to me:

VC> I will have a look at the code to modify it to reflect the nodes binkd
VC> settings if set to 1.0.

VC> Will try and do so this w/e.

So far no luck:

D:\FIDO\BINKD>binkd -p -P250/1 binkd.cfg
10:35 [3388] BEGIN standalone, binkd/1.1a-49/Win32 -p -P250/1 binkd.cfg
10:35 [3388] creating a poll for 2:250/***@fidonet (`d' flavour)
10:35 [3388] clientmgr started
+ 10:35 [8724] call to 2:250/***@fidonet
10:35 [8724] trying f1.n250.z2.binkp.net [81.179.6.57]...
? 10:35 [8724] connection to 2:250/***@fidonet failed: {W32 API error 10061}
Connection refused
10:35 [3388] the queue is empty, quitting...

Cheers, Michiel

[Vince Coen]

Hello Michiel!

11 Mar 14 10:38, you wrote to me:

VC>> I will have a look at the code to modify it to reflect the nodes
VC>> binkd
VC>> settings if set to 1.0.

VC>> Will try and do so this w/e.

Now had a look as have spent the last 4+ days repairing a major issue having
deleted in error the entire bbs directory so have had to try and rebuild using
a two year old one.

Now had a look at the binkd.c code and as far as I can see it looks correct
(although a retest with full logging on may change that decision).
If system has be regressed to binkd v1.0 protocol mbcico will announce to
sender that is what is the protocol we are using by simulating v1.0 instead of
v1.1.

The same applies to an Irex connection where irex is versions 2.24 trough 2.29
that have a range of bugs and mbcico will wwork around them but I am
'assuming'
that no-one use such old s/w?

There again no one should really be using binkd v1.0 as well!

To enable another test both ends MUST be running a) mbse set for calling node
as binkd v1.0 and the sender using binkd v1.0 and no other.
In addition both ends must turn on FULL logging which I must admit I do not
recall doing.

Give me a few days and I will reset you up as v1.0 mode only but you must have
binkd v1.0 to test otherweise it is a waste of time.

Post by Michiel van der Vlist
D:\FIDO\BINKD>binkd -p -P250/1 binkd.cfg
10:35 [3388] BEGIN standalone, binkd/1.1a-49/Win32 -p -P250/1
flavour) 10:35 [3388] clientmgr started + 10:35 [8724] call to
{W32 API error 10061}
Connection refused
10:35 [3388] the queue is empty, quitting...
Cheers, Michiel

Vince

[Joe Delahaye]

Re: Error 10054
By: Vince Coen to Michiel van der Vlist on Tue Mar 11 2014 20:36:06

VC> The same applies to an Irex connection where irex is versions 2.24 trough
VC> 2.29 that have a range of bugs and mbcico will wwork around them but I am
VC> 'assuming'
VC> that no-one use such old s/w?


Many people are still using Irex. Mostly version 2.29, although there is a
later beta out there. That is what I am using.

[Wilfred van Velzen]

Hi Joe,

On 11 Mar 14 20:09, Joe Delahaye wrote to Vince Coen:
about: "Error 10054":

JD> Many people are still using Irex. Mostly version 2.29, although there
JD> is a later beta out there. That is what I am using.

There is atleast 1 node that uses an even newer beta:

# telnet xanadubbs.ca binkp
Trying 68.148.101.174...
Connected to xanadubbs.ca.
SYS Xanadu BBS
ZYZ Charles Cruden
LOC Edmonton, Alberta, Canada
NDL IBN,ITN,IVM,CM
TIME 2014/03/12 00:41:53 -7:00

VER Internet Rex 2.67 beta1 OS/2 (binkp/1.1)

1:342/***@fidonet
1:342/***@fidonet
81:970/***@fidonet
111:1200/***@fidonet
169:1/***@fidonet

Maybe that one has the binkp 1.1 problem fixed?

Wilfred.

[Joe Delahaye]

Re: Re: Error 10054
By: Wilfred van Velzen to Joe Delahaye on Wed Mar 12 2014 08:40:12

WV> There is atleast 1 node that uses an even newer beta:
WV> VER Internet Rex 2.67 beta1 OS/2 (binkp/1.1)

WV> 1:342/***@fidonet

WV> Maybe that one has the binkp 1.1 problem fixed?

Perhaps, but that version is not available. I think that the version I am
using, which I am told also should not be out here, is 2.31

[Wilfred van Velzen]

Hi Joe,

On 2014-03-12 10:13:08, you wrote to me:

WV>> There is atleast 1 node that uses an even newer beta:
WV>> VER Internet Rex 2.67 beta1 OS/2 (binkp/1.1)

WV>> 1:342/***@fidonet

WV>> Maybe that one has the binkp 1.1 problem fixed?

JD> Perhaps, but that version is not available.

Maybe Charles can be persuaded to release that version? He must have been
testing it for many years now...? ;)

Bye, Wilfred.

[Joe Delahaye]

Re: Re: Error 10054
By: Wilfred van Velzen to Joe Delahaye on Wed Mar 12 2014 15:34:14

WV> Maybe Charles can be persuaded to release that version? He must have been
WV> testing it for many years now...? ;)

That would be nice, but, getting an answer from him these days is almost
impossible

[Wilfred van Velzen]

Hi Joe,

On 12 Mar 14 18:30, Joe Delahaye wrote to Wilfred van Velzen:
about: "Re: Error 10054":

WV>> Maybe Charles can be persuaded to release that version? He must have
WV>> been testing it for many years now...? ;)

JD> That would be nice, but, getting an answer from him these days is almost
JD> impossible

"These days"!? How long has it been that he wrote an echomail in any area? (In
particular the IREX area)

The last one I found:

2006-03-20 18:32:14 Charles Cruden Marc Lewis SMTP timeout problem

So that's 8 years ago. In 2005 he wrote:

============================================================================
From: Charles Cruden
To: Dale A Cook
Date: 2005-12-15 22:02:08
Subject: IREX 2.3 +

Any Idea when next version of IREX might be ready for purchase ??????
I'll be your first customer & will be using it to provide mail for all
who need(echomail)?????

I'm trying to find time to work on an update for Rex 2.29, as it needs one.
I was hoping to work on it during my Christmas holidays, since I've been
working overtime at work since August. It now looks like Christmas
holidays may end up being delayed, so ATM I have no idea when the next
version will be ready.

OTOH, it would be nice to have a social life sometime too....

-+-
+ Origin: Xanadu: an odd little spot in Edmonton, Alberta (1:342/806)
============================================================================


Wilfred.

[Joe Delahaye]

Re: Re: Irex
By: Wilfred van Velzen to Joe Delahaye on Thu Mar 13 2014 09:12:17

WV> "These days"!? How long has it been that he wrote an echomail in any
WV> area? (In particular the IREX area)


Well, 'these days' can go back a ways <G>

[mark lewis]

On Thu, 13 Mar 2014, Wilfred van Velzen wrote to Joe Delahaye:

WvV> The last one I found:

WvV> 2006-03-20 18:32:14 Charles Cruden Marc Lewis SMTP timeout
WvV> problem

WvV> So that's 8 years ago. In 2005 he wrote:

that was a public post... since then, i've seen no public posts from him in
widely distributed areas... if he has posted in a public area, it has been in
an area only available to his locla network, AFAICS...

)\/(ark

One of the great tragedies of life is the murder of a beautiful theory by a
gang of brutal facts. --Benjamin Franklin

[Michiel van der Vlist]

Hello Joe,

On Wednesday March 12 2014 18:30, you wrote to Wilfred van Velzen:

WV>> Maybe Charles can be persuaded to release that version? He must
WV>> have been testing it for many years now...? ;)

JD> That would be nice, but, getting an answer from him these days is
JD> almost impossible

I have been trying for almost a decade to get in touch with him. "almost
impossible" is an understatement. He simply does not respond. I have given up.
I have been very patient, but there is a time when one realises it is time to
move on. I liked Irex and it fitted in very well with my InterMail (POTS
Mailer). I do however not need POTS any more, I have had no call other than for
testing in well over five years. I have dropped POTS support, nobody
complained. So out goes InterMail. Irex has lots of whistles and bells, but all
I ever used beyond testing was the binkp section. I want IPv6 and Irex does not
support it, and I gave up hope that it ever will. Binkd supposts IPv6 and I
decided binkd is all I need. I am done with Irex and I learned not to turn back
on a relation that did not work out.


Exit Irex.


Cheers, Michiel

[Joe Delahaye]

Re: Error 10054
By: Michiel van der Vlist to Joe Delahaye on Thu Mar 13 2014 20:43:45

MV> I have been trying for almost a decade to get in touch with him. "almost
MV> impossible" is an understatement. He simply does not respond. I have given
MV> up. I have been very patient, but there is a time when one realises it is
MV> time to move on. I liked Irex and it fitted in very well with my InterMail
MV> (POTS Mailer). I do however not need POTS any more, I have had no call
MV> other than for testing in well over five years. I have dropped POTS
MV> support, nobody complained. So out goes InterMail. Irex has lots of
MV> whistles and bells, but all I ever used beyond testing was the binkp
MV> section. I want IPv6 and Irex does not support it, and I gave up hope that
MV> it ever will. Binkd supposts IPv6 and I decided binkd is all I need. I am
MV> done with Irex and I learned not to turn back on a relation that did not
MV> work out.


I use the binkd plus the FTP part. FTP for getting the filebone from Janis. I
also run Taurus for POTS callers (I still get a few), and have shut off the
binkd in that. Too confusing in my mind to set up. I have a application that
transfers POTS calls to a telnet node and it would not work in IM as it was not
32 bit. So IM hit the bit bucket, but I still use IE for writing netmails

[Wilfred van Velzen]

Hi Joe,

On 13 Mar 14 20:56, Joe Delahaye wrote to Michiel van der Vlist:
about: "Error 10054":

JD> I also run Taurus for POTS callers (I still get a few),

Regular downlinks? Or the occasional bbs visitor?

Wilfred.

[Joe Delahaye]

Re: Re: Error 10054
By: Wilfred van Velzen to Joe Delahaye on Fri Mar 14 2014 08:23:33

JD>> I also run Taurus for POTS callers (I still get a few),

WV> Regular downlinks? Or the occasional bbs visitor?


I have both, and both are occassional actually <G>. At least one of my
downlinks at times uss the POTS link for downloading his mail. Since I am not
paying for that line (I threatened to cut it off and cut other services a while
ago <G>) I will leave it.

For Now.

[mark lewis]

On Wed, 12 Mar 2014, Joe Delahaye wrote to Wilfred van Velzen:

WV> Maybe Charles can be persuaded to release that version? He must
WV> have been testing it for many years now...? ;)

JD> That would be nice, but, getting an answer from him these days is
JD> almost impossible

i guess that depends on several unknown factors... it seems that folks in his
net don't have problems communicating with him when necessary... perhaps that
depends on the topic? i dunno...

)\/(ark

One of the great tragedies of life is the murder of a beautiful theory by a
gang of brutal facts. --Benjamin Franklin

[Joe Delahaye]

Re: Error 10054
By: mark lewis to Joe Delahaye on Thu Mar 13 2014 20:23:33

JD>> That would be nice, but, getting an answer from him these days is
JD>> almost impossible

ML> i guess that depends on several unknown factors... it seems that folks in
ML> his net don't have problems communicating with him when necessary...
ML> perhaps that depends on the topic? i dunno...


Do they actually communicate, or is the system on Robot, and just spits out the
mail?

[mark lewis]

On Thu, 13 Mar 2014, Joe Delahaye wrote to mark lewis:

JD>> That would be nice, but, getting an answer from him these days is
JD>> almost impossible

ML> i guess that depends on several unknown factors... it seems that
ML> folks in
ML> his net don't have problems communicating with him when necessary...
ML> perhaps that depends on the topic? i dunno...


JD> Do they actually communicate, or is the system on Robot, and just
JD> spits out the mail?

they have to communicate for net business... i'm not aware of any way for their
netseg to be updated when necessary without manual intervention... at least as
far as adding or removing nodes goes... it is possible that existing nodes can
adjust their individual nodesegs, though... i've done that here in the past and
it worked pretty well ;)

)\/(ark

One of the great tragedies of life is the murder of a beautiful theory by a
gang of brutal facts. --Benjamin Franklin

[Wilfred van Velzen]

Hi mark,

On 13 Mar 14 20:23, mark lewis wrote to Joe Delahaye:
about: "Error 10054":

JD>> That would be nice, but, getting an answer from him these days is
JD>> almost impossible

ml> i guess that depends on several unknown factors... it seems that folks in
ml> his net don't have problems communicating with him when necessary...
ml> perhaps that depends on the topic? i dunno...

I suppose if he didn't atleast address net matters, he wouldn't be the host
anymore...

Wilfred.

[mark lewis]

On Fri, 14 Mar 2014, Wilfred van Velzen wrote to mark lewis:

JD>> That would be nice, but, getting an answer from him these days is
JD>> almost impossible

ml> i guess that depends on several unknown factors... it seems that
ml> folks in
ml> his net don't have problems communicating with him when necessary...
ml> perhaps that depends on the topic? i dunno...

WvV> I suppose if he didn't atleast address net matters, he wouldn't be
WvV> the host anymore...

right ;)

)\/(ark

One of the great tragedies of life is the murder of a beautiful theory by a
gang of brutal facts. --Benjamin Franklin

[Michiel van der Vlist]

Hello mark,

On Thursday March 13 2014 20:23, you wrote to Joe Delahaye:

JD>> That would be nice, but, getting an answer from him these days is
JD>> almost impossible

ml> i guess that depends on several unknown factors... it seems that folks
ml> in his net don't have problems communicating with him when
ml> necessary...

All very well, but that is a different kettle of fish. Irex is a commercial
product. I PAID for it. For commercial products there are different rules than
for freeware distributed as a hobby.

ml> perhaps that depends on the topic? i dunno...

I wrote to him about the topic of Irex in my capacity as a paying customer for
a commercial product. When I pay for software, I not only pay for the right to
use it, I also pay for the support. Which I do not get. You can't brush that
off with "he is a busy man", "real life got in the way", bla, bla bla. Irex is
a commercial product, it is not a hobby, it is real life. I have been very
patient, but now I am done with it. Exit Irex.


Cheers, Michiel

[Vince Coen]

Hello Wilfred!

12 Mar 14 08:40, you wrote to Joe Delahaye:

JD>> Many people are still using Irex. Mostly version 2.29, although
JD>> there is a later beta out there. That is what I am using.

Post by Wilfred van Velzen
VER Internet Rex 2.67 beta1 OS/2 (binkp/1.1)
Maybe that one has the binkp 1.1 problem fixed?

That is a big difference between versions.

Why on earth have sysops not upgraded I wonder ?


Vince

[Wilfred van Velzen]

Hi Vince,

Post by Wilfred van Velzen
VER Internet Rex 2.67 beta1 OS/2 (binkp/1.1)
Maybe that one has the binkp 1.1 problem fixed?

VC> That is a big difference between versions.

VC> Why on earth have sysops not upgraded I wonder ?

Because it is not publicly available. Maybe you didn't notice (it's in the
lines you didn't quote). But this is Charles Crudens system, the author of
irex. ;)
Apparantly he has been developing irex, without sharing his work with the fido
community...

Bye, Wilfred.

[Roy Witt]

Brer Vince Coen wrote to Brer Wilfred van Velzen about Error 10054:

JD>>> Many people are still using Irex. Mostly version 2.29, although
JD>>> there is a later beta out there. That is what I am using.

Post by Wilfred van Velzen
VER Internet Rex 2.67 beta1 OS/2 (binkp/1.1)
Maybe that one has the binkp 1.1 problem fixed?

VC> That is a big difference between versions.

Yeup.

VC> Why on earth have sysops not upgraded I wonder ?

#1, the 2.67 version isn't available to anyone
#2. the only versions available are 2.29 or a beta 2.31
#3, for all we know, what Charles is using is an OS/2 only version

For testing purposes, I have a IREX only node setup on 1:387/10 and
anyone is welcome to use it ... otherwise 387/22 is capable of Binkd
connections.


R\%/itt - K5RXT

"It is the fault of our science that it wants to explain all, and
if it explain not, then it says there is nothing to explain."
Bram Stoker (1847-1912)

Thus, we have "Climate Change Science" - which isn't capable of
explaining anything.


--- GoldED+/W32 1.1.5-31012

[Joe Delahaye]

Re: Error 10054
By: Vince Coen to Wilfred van Velzen on Wed Mar 12 2014 13:07:41

VC> That is a big difference between versions.

VC> Why on earth have sysops not upgraded I wonder ?


It is not available

[Vince Coen]

Hello Joe!

11 Mar 14 20:09, you wrote to me:

VC>> The same applies to an Irex connection where irex is versions
VC>> 2.24 trough 2.29 that have a range of bugs and mbcico will wwork
VC>> around them but I am 'assuming' that no-one use such old s/w?

Post by Joe Delahaye
Many people are still using Irex. Mostly version 2.29, although there
is a later beta out there. That is what I am using.

Noted, I am again 'assuming' that the code works for Irex connections as I do
not think any of my downlinks use it.

Should point out the code for Irex and Binkd has been in use for many years
with very minor changes since first build.



Vince

[Joe Delahaye]

Re: Error 10054
By: Vince Coen to Joe Delahaye on Wed Mar 12 2014 13:04:51

Post by Joe Delahaye
Many people are still using Irex. Mostly version 2.29, although there
is a later beta out there. That is what I am using.

VC> Noted, I am again 'assuming' that the code works for Irex connections as I
VC> do not think any of my downlinks use it.

Only the logs would be able to tell you that <G>


VC> Should point out the code for Irex and Binkd has been in use for many
VC> years with very minor changes since first build.

I dont know about Binkd, but Irex certainly has not changed in many years. No
development at all on it for at least 10 years if not longer.

[Michiel van der Vlist]

Hello Joe,

On Tuesday March 11 2014 20:09, you wrote to Vince Coen:

JD> Many people are still using Irex. Mostly version 2.29, although there
JD> is a later beta out there. That is what I am using.

I tried the 2.31 beta on my point system. It worked, but it did not fix any of
the issues I had with the public release version (2.29). I did not notice any
difference so I never bother to upgrade my main system.

well, as I wrote in another message: that is history.


Cheers, Michiel

[Joe Delahaye]

Re: Error 10054
By: Michiel van der Vlist to Joe Delahaye on Thu Mar 13 2014 21:07:13

MV> I tried the 2.31 beta on my point system. It worked, but it did not fix
MV> any of the issues I had with the public release version (2.29). I did not
MV> notice any difference so I never bother to upgrade my main system.

MV> well, as I wrote in another message: that is history.


Well, I tried it on my main system after backing up the 2.29. It worked, so it
is still running. I may eventually change to something else, but, I like the
multi-facets of Irex.

[Michiel van der Vlist]

Hello Vince,

On Tuesday March 11 2014 20:36, you wrote to me:

VC> Now had a look as have spent the last 4+ days repairing a major issue
VC> having deleted in error the entire bbs directory so have had to try
VC> and rebuild using a two year old one.

Ouch!...

VC> The same applies to an Irex connection where irex is versions 2.24
VC> trough 2.29 that have a range of bugs and mbcico will wwork around
VC> them but I am 'assuming' that no-one use such old s/w?

Irex 2.29 is the most recent public release. Dated 27-10-01. But still in
widespread use.
VC> There again no one should really be using binkd v1.0 as well!

There is still a lot of software around that only does binkp 1.0. I have
several downlinks runnig older versions of the Argus/Radius/Taurus family...

VC> Give me a few days and I will reset you up as v1.0 mode only but you
VC> must have binkd v1.0 to test otherweise it is a waste of time.

The problem I have is that my recent version of binkd will not properl inteface
with mbcico is forced to 1.0. So that is wha I want to test first.

Post by Michiel van der Vlist
D:\FIDO\BINKD>binkd -p -P250/1 binkd.cfg
10:35 [3388] BEGIN standalone, binkd/1.1a-49/Win32 -p -P250/1 binkd.cfg
10:35 [3388] clientmgr started +
f1.n250.z2.binkp.net [81.179.6.57]... ?
10061} Connection refused
10:35 [3388] the queue is empty, quitting...

I still can not connect to your system....


Cheers, Michiel

[Vince Coen]

Hello Michiel!

Post by Michiel van der Vlist
Hello mark,

This is what my system shows in the logs (but I am NOT using detailed debug
info reporting etc):


------------------------------------
+ 04-Mar-2014 20:02:57 mbcico[24405] GeoIP location: Netherlands, NL EU
+ 04-Mar-2014 20:02:57 mbcico[24405] Start inbound Binkp session
+ 04-Mar-2014 20:02:57 mbcico[24405] Binkp: start session
+ 04-Mar-2014 20:02:57 mbcico[24405] System : Blijf Tonijn
+ 04-Mar-2014 20:02:57 mbcico[24405] Sysop : Michiel van der Vlist
+ 04-Mar-2014 20:02:57 mbcico[24405] Location: Driebergen, NL
+ 04-Mar-2014 20:02:57 mbcico[24405] Flags :
CM,MO,IBN:fido.vlist.eu,U,RPK,NPK,ENC,NC
+ 04-Mar-2014 20:02:57 mbcico[24405] Time : Tue, 4 Mar 2014 21:02:52 +0100
+ 04-Mar-2014 20:02:57 mbcico[24405] Uses : binkd/1.1a-49/Win32 binkp/1.1
+ 04-Mar-2014 20:02:57 mbcico[24405] address : 2:280/***@fidonet
+ 04-Mar-2014 20:02:57 mbcico[24405] address : 2:2/***@fifonet
+ 04-Mar-2014 20:02:57 mbcico[24405] address : 2:28/***@fidonet
+ 04-Mar-2014 20:02:57 mbcico[24405] Binkp: remote is a listed system
+ 04-Mar-2014 20:02:57 mbcico[24405] Options: Call WaZOO EMSI Freqs Zmodem
ZedZap Hydra PLZ GZ/BZ2 NoNR
+ 04-Mar-2014 20:02:57 mbcico[24405] Options : NDA EXTCMD CRYPT
+ 04-Mar-2014 20:02:57 mbcico[24405] Binkp: MD5 unprotected session
+ 04-Mar-2014 20:02:57 mbcico[24405] Binkp: EXTCMD is active
+ 04-Mar-2014 20:02:57 mbcico[24405] Binkp: forcing downgrade to binkp/1.0
protocol
+ 04-Mar-2014 20:02:57 mbcico[24405] Binkp: mail 0, files 0 bytes
+ 04-Mar-2014 20:02:57 mbcico[24405] Binkp: session finished, rc=0
+ 04-Mar-2014 20:02:59 mbcico[24405] Incoming call successful (rc=0)
+ 04-Mar-2014 20:02:59 mbcico[24405] Connected 2.00s
04-Mar-2014 20:02:59 mbcico[24405] MBCICO finished in 2.00s
------------------------------------

So you are using a 1.1 system that my system is changing the protocol to v1.0.

Now I do not know what the differences are but guessing a restriction on
capability for v1.0.

The real test would be to run the older version eg v1.0 against mbse setup to
keep v1.0 for that node and see what happens.

Let me know if you can and I will place on hold a file & a mail for you so we
can see what happens.

Vince
ml>> sound like it may be a bug but i don't know about it being only
ml>> cosmetic... i would have to study the binkp protocols details to
ml>> see how it communicates the level/version of binkp being support
ml>> and/or offered...

Post by Michiel van der Vlist
This is a log snippet (loglevel 10) from my connect with Vince earlier
04 Mar 20:58:57 [6768] Read 44 bytes
04 Mar 20:58:57 [6768] got block: 44 (msg)
04 Mar 20:58:57 [6768] rcvd msg NUL VER
mbcico/1.0.1/GNU/Linux-x86_64 binkp/1.1 - 04 Mar 20:58:57 [6768] VER
mbcico/1.0.1/GNU/Linux-x86_64 binkp/1.1 04 Mar 20:58:57 [6768] remote
uses binkp v.1.1
My system reports "remote uses binkp v1.1" immidiately after receiving
the other side's banner. I conclude that it derives the protocol
version from the banner.

VC>>> Confirm the above and I will pass to the mbse echo for reference
VC>>> and discussion before looking at the code by myself or one of
VC>>> the other support team.

ml>> i'll let those involved with the problem do the confirming... i'm
ml>> only a bystander watching the proceedings and pointing out things
ml>> that may be being missed O:)

Post by Michiel van der Vlist
I get the same results with Vince's system as with 280/19 before. An
error 10054 when mbcico is forced to 1.0 mode.
05 Mar 00:32:10 [6620] Read 59 bytes
05 Mar 00:32:10 [6620] got block: 59 (msg)
05 Mar 00:32:10 [6620] rcvd msg NUL VER Radius/4.009-02.01.2003 (New
Year Release)/ binkp/1.0 - 05 Mar 00:32:10 [6620] VER
Radius/4.009-02.01.2003 (New Year Release)/ binkp/1.0 05 Mar 00:32:10
[6620] remote uses binkp v.1.0
Again, my binkd reads the banner string and gleens the protocol
version from that.

[Michiel van der Vlist]

Hello Vince,

On Wednesday March 05 2014 19:30, you wrote to me:

VC> + 04-Mar-2014 20:02:57 mbcico[24405] GeoIP location: Netherlands, NL
VC> EU
VC> + 04-Mar-2014 20:02:57 mbcico[24405] Start inbound Binkp session
VC> + 04-Mar-2014 20:02:57 mbcico[24405] Binkp: start session
VC> + 04-Mar-2014 20:02:57 mbcico[24405] System : Blijf Tonijn
VC> + 04-Mar-2014 20:02:57 mbcico[24405] Sysop : Michiel van der Vlist
VC> + 04-Mar-2014 20:02:57 mbcico[24405] Location: Driebergen, NL
VC> + 04-Mar-2014 20:02:57 mbcico[24405] Flags :
VC> CM,MO,IBN:fido.vlist.eu,U,RPK,NPK,ENC,NC
VC> + 04-Mar-2014 20:02:57 mbcico[24405] Time : Tue, 4 Mar 2014
VC> 21:02:52 +0100

My system sends: NUL VER binkd/1.1a-49/Win32 binkp/1.1

VC> + 04-Mar-2014 20:02:57 mbcico[24405] Uses : binkd/1.1a-49/Win32
VC> binkp/1.1

My system sends: ADR 2:280/***@fidonet 2:2/***@fifonet 2:28/***@fidonet

VC> + 04-Mar-2014 20:02:57 mbcico[24405] address : 2:280/***@fidonet
VC> + 04-Mar-2014 20:02:57 mbcico[24405] address : 2:2/***@fifonet
VC> + 04-Mar-2014 20:02:57 mbcico[24405] address : 2:28/***@fidonet

So now your system knows my addresses and that it uses binkp ver 1.1

VC> + 04-Mar-2014 20:02:57 mbcico[24405] Binkp: MD5 unprotected session

And now the systems decide on an uprotected session.

Then my systems receives this:

rcvd msg NUL VER mbcico/1.0.1/GNU/Linux-x86_64 binkp/1.1

And then your system does this:

VC> + 04-Mar-2014 20:02:57 mbcico[24405] Binkp: forcing downgrade to
VC> binkp/1.0 protocol

VC> So you are using a 1.1 system that my system is changing the protocol
VC> to v1.0.

Yes it changes to 1.0 but lets my system think it is in 1.1 mode!

VC> The real test would be to run the older version eg v1.0 against mbse
VC> setup to keep v1.0 for that node and see what happens.

I do not have an older vesrion available. I just started with binkp, this is th
first and only version I ever used.

VC> Let me know if you can and I will place on hold a file & a mail for
VC> you so we can see what happens.

I don't think further testing will bring new insight. It is obvious what
happens. Your system tells mine it is in 1.1 mode, while it isn't.

This is not merely a cosmetic bug in mbcico, it is a clear flaw in mbcico's
binkp 1.1 implementation as documented in FTS-1026 and FSP-1024.

Yes, I know, FSP-1024 is not a standard yet, it is a proposal. But look at who
the author is: it is Michiel Broek, the author of MBSE. So it goes against his
own proposal!

The course of action is clear: mbcico needs to be fixed so that it advertises
ver 1.0 when it forces itself in 1.0 mode.


Cheers, Michiel

[Kees van Eeten]

Hello Michiel!

06 Mar 14 15:32, you wrote to Vince Coen:

MvdV> The course of action is clear: mbcico needs to be fixed so that it
MvdV> advertises ver 1.0 when it forces itself in 1.0 mode.

It should not force itself to 1.0 when te opposit system tells it, it is
using v1.1.

On an outgoing session when 1.0 is set, it should be advertised in
the greeting line. Michiel Broek must have had a special case in mind, but
now it does not work as it should.

Kees

[Michiel van der Vlist]

Hello Kees,

On Thursday March 06 2014 16:07, you wrote to me:

MvdV>> The course of action is clear: mbcico needs to be fixed so that
MvdV>> it advertises ver 1.0 when it forces itself in 1.0 mode.

KE> It should not force itself to 1.0 when te opposit system tells it, it
KE> is using v1.1.

In and by itself that should not have to be a problem, IF it signals back that
it is in 1.0 mode. On an incoming connection it can do that after it has
received the addres information from the caller.

KE> On an outgoing session when 1.0 is set, it should be advertised in
KE> the greeting line. Michiel Broek must have had a special case in
KE> mind, but now it does not work as it should.

Putting the pieces together, I gather that the option to gear down to 1.0 was
to solve problems with connecting to Irex. Irex advertises itself as 1.1, but
it has it own ideas of what 1.1 actually is. Apparently it would not talk well
to mbcico in 1.1 mode. Michiel Broek solved it by optionally downgrading mbcico
to 1.0.

He made the error of misleading the other side by still advertising 1.1

That error should be corrected.

Cheers, Michiel

[Nicholas Boel]

Hello Michiel,

On 07 Mar 14 11:09, Michiel van der Vlist wrote to Kees van Eeten:

MV> Putting the pieces together, I gather that the option to gear down to
MV> 1.0 was to solve problems with connecting to Irex. Irex advertises
MV> itself as 1.1, but it has it own ideas of what 1.1 actually is.
MV> Apparently it would not talk well to mbcico in 1.1 mode. Michiel Broek
MV> solved it by optionally downgrading mbcico to 1.0.

MV> He made the error of misleading the other side by still advertising
MV> 1.1

MV> That error should be corrected.

That puts another question out there. If mbcico is changed to report binkp
v1.0 when it is forced to that mode, will that break connections with IREX
systems since Irex is reporting v1.1 (even though it's wrong)?

This was probably a special workaround *only* for IREX, with the sole purpose
of it never being used with anything else. Obviously you ran into it because
you were using IREX and then switched to binkd.

I see the issue with it not working with binkd, but then again, it wasn't
created for use with binkd, either.

I'm not sure if the currently proposed "fix" that has been mentioned is the
right choice here. The problem may lie deeper than that.

I use binkd here, and connect to Irex systems, binkd systems, and mbcico
systems just fine. Some options seem to be able to be used for one, while they
cannot be used with others otherwise things won't work as they should.

Apparantly IREX reports v1.1, which is why mbcico reports the same, THEN
mbcico downgrades to v1.0 (keep in mind, this most likely was a workaround
for IREX only). So if mbcico is changed to report v1.0 (as it probably
should), will the connections with IREX continue to work?

Maybe to clarify things, one could check to see how binkd connects to IREX
systems. See if there's any kind of forcing to v1.0 mode without any
user/sysop set options. That way the "option" to force v1.0 mode could be
removed from mbcico so the mistake would never happen again, but the actual
force upon a check for "IREX" in the VER string could happen automagically in
the software itself (maybe how binkd does it? I don't know, I didn't look).

Either way, if it's a workaround in order to work with IREX, I think the
workaround should stay, but just be done differently so that the sysop cannot
make the mistake of setting it wrong for any links, or in your case, when one
switches softwares THEN realizes something is wrong - which is even worse
with the amount of systems on autopilot these days where the sysop cannot be
contacted to fix it.

Just my two cents.

Regards,
Nick

[mark lewis]

On Fri, 07 Mar 2014, Nicholas Boel wrote to Michiel van der Vlist:

NB> That puts another question out there. If mbcico is changed to
NB> report binkp v1.0 when it is forced to that mode, will that break
NB> connections with IREX systems since Irex is reporting v1.1 (even
NB> though it's wrong)?

no, it should not... that is *if* IREX properly drops back to binkp 1.0 mode
when it sees that the other side is only 1.0 capable...

the only thing that will happen then is that the additional features of 1.1
cannot be used...

)\/(ark

[Michiel van der Vlist]

Hello mark,

On Friday March 07 2014 11:11, you wrote to Nicholas Boel:

NB>> That puts another question out there. If mbcico is changed to
NB>> report binkp v1.0 when it is forced to that mode, will that
NB>> break connections with IREX systems since Irex is reporting v1.1
NB>> (even though it's wrong)?

ml> no, it should not... that is *if* IREX properly drops back to binkp
ml> 1.0 mode when it sees that the other side is only 1.0 capable...

ml> the only thing that will happen then is that the additional features
ml> of 1.1 cannot be used...

As Irex does not have problems to connect to older versions of the
Argus/Radius/Taurus family that report 1.0, I expect no problems with mbcico
when it is foreced down to 1.0 and properly advertises that.


Cheers, Michiel

[mark lewis]

On Tue, 11 Mar 2014, Michiel van der Vlist wrote to mark lewis:

NB>> That puts another question out there. If mbcico is changed to
NB>> report binkp v1.0 when it is forced to that mode, will that
NB>> break connections with IREX systems since Irex is reporting v1.1
NB>> (even though it's wrong)?

ml> no, it should not... that is *if* IREX properly drops back to
ml> binkp 1.0 mode when it sees that the other side is only 1.0
ml> capable...

ml> the only thing that will happen then is that the additional
ml> features of 1.1 cannot be used...

MvdV> As Irex does not have problems to connect to older versions of
MvdV> the Argus/Radius/Taurus family that report 1.0, I expect no
MvdV> problems with mbcico when it is foreced down to 1.0 and properly
MvdV> advertises that.

agreed! what's wrong with us? ;) O:)

)\/(ark

[Michiel van der Vlist]

Hello Nicholas,

On Friday March 07 2014 09:22, you wrote to me:

MV>> He made the error of misleading the other side by still advertising
MV>> 1.1

MV>> That error should be corrected.

NB> That puts another question out there. If mbcico is changed to report
NB> binkp v1.0 when it is forced to that mode, will that break connections
NB> with IREX systems since Irex is reporting v1.1 (even though it's
NB> wrong)?

I don't think that will be a problem because Irex does not have problems with
other binkp mailers that report 1.0. But the only way to make sure is to try
it...

NB> This was probably a special workaround *only* for IREX, with the sole
NB> purpose of it never being used with anything else.

Maybe, but we are just guessing here. If it is indeed a special work around
just for Irex, a more logical approach would have been to hunt for "Irex" in
the version string and act on that.

NB> Obviously you ran into it because you were using IREX and then
NB> switched to binkd.

That is what it looks like. If it is, I may be the first to report the problem,
but I most likely will not be the last. Irex is abondonware, it will never do
IPv6, so more people will follow my lead an dump Irex in favour of binkd.

NB> I see the issue with it not working with binkd, but then again, it
NB> wasn't created for use with binkd, either.

Like any other binkp mailer, it was designed to connect to any other mailer
using the binkp protocol.

NB> I'm not sure if the currently proposed "fix" that has been mentioned
NB> is the right choice here. The problem may lie deeper than that.

There is only one way to find out...

NB> Apparantly IREX reports v1.1, which is why mbcico reports the same,

No, that is not how it works. mbcico reporting 1.1 is not a repsonse to Irex
reporting 1.1. It just reports 1.1. period.

Each mailer tells the other what it can do. They then decide on what they have
in common.
NB> THEN mbcico downgrades to v1.0 (keep in mind, this most likely was a
NB> workaround for IREX only). So if mbcico is changed to report v1.0 (as
NB> it probably should), will the connections with IREX continue to work?

There is one way to find out...


Cheers, Michiel

[Vince Coen]

Hello Michiel!

Post by Michiel van der Vlist
No, that is not how it works. mbcico reporting 1.1 is not a repsonse
to Irex reporting 1.1. It just reports 1.1. period.

mbse reports what it is set up to do for a specific node.

Post by Michiel van der Vlist
Each mailer tells the other what it can do. They then decide on what
they have in common.

NB>> THEN mbcico downgrades to v1.0 (keep in mind, this most likely
NB>> was a workaround for IREX only).

Yes there are a series of workrounds for Irex v2.24 through 2.29 but they are
different for the binbk reduced service of v1.0 as far as I can tell from the
binkd.c code.


NB>> So if mbcico is changed to
NB>> report v1.0 (as it probably should), will the connections with
NB>> IREX continue to work?

Post by Michiel van der Vlist
There is one way to find out...

mbcico will report v1.0 protocol for binkd v1.0 if setup for the inbound node
that is previously set up otherwise only 1.1 and following standard handshake
protocols.


Vince

[Michiel van der Vlist]

Hello Vince,

Post by Michiel van der Vlist
No, that is not how it works. mbcico reporting 1.1 is not a
repsonse to Irex reporting 1.1. It just reports 1.1. period.

VC> mbse reports what it is set up to do for a specific node.

It didn't last time I got a connect...


Cheers, Michiel

[Nicholas Boel]

Hello Michiel,

On 11 Mar 14 10:49, Michiel van der Vlist wrote to Nicholas Boel:

NB>> I'm not sure if the currently proposed "fix" that has been
NB>> mentioned is the right choice here. The problem may lie deeper
NB>> than that.

MV> There is only one way to find out...

So what's that, fix it once - find out it doesn't work, then fix it again?
That's all I'm saying here, is that it should be thought out and done _right_
the first time.

If Irex reports v1.1 and doesn't actually support it, then have a check upon
connect for "IREX" and if that is true, ignore the binkp version check and
continue forced to v1.0. Once that works, remove the _option_ to force to v1.0
so that the mistake of switching it on or off will never be made again.

NB>> Apparantly IREX reports v1.1, which is why mbcico reports the
NB>> same,

MV> No, that is not how it works. mbcico reporting 1.1 is not a repsonse
MV> to Irex reporting 1.1. It just reports 1.1. period.

Right. I'm sure I had something else in mind there, and that obviously came
out wrong. Either way, Irex is reporting wrong. IMO, there should be any
"setting" or sysop option to force change the protocol. That just leads to
confusion and problems (like what just happened).

MV> Each mailer tells the other what it can do. They then decide on what
MV> they have in common.

So what exactly happens when an Irex system connects to mbcico while NOT
forced into v1.0 mode?

If they decide on what they have in common, then that's not happening properly
due to Irex reporting wrong. Which is probably safe to assume is the reason
why the option was created in the first place.

My only opinion here is that while it's being fixed, the check should be done
internally, and not be able to be switched by the sysop in the future. This
should completely alleviate any future problems.

NB>> THEN mbcico downgrades to v1.0 (keep in mind, this most likely
NB>> was a workaround for IREX only). So if mbcico is changed to
NB>> report v1.0 (as it probably should), will the connections with
NB>> IREX continue to work?

MV> There is one way to find out...

That's easy for the people to say when they aren't submitting the patches. :)

Hopefully there's enough interest left out there for someone to do something
about it.

Regards,
Nick

[Michiel van der Vlist]

Hello Nicholas,

On Tuesday March 11 2014 16:49, you wrote to me:

NB>>> I'm not sure if the currently proposed "fix" that has been mentioned
NB>>> is the right choice here. The problem may lie deeper than that.

MV>> There is only one way to find out...

NB> So what's that, fix it once - find out it doesn't work, then fix it
NB> again?

That is how progress usually works: stumble and fall, get up and try again.

NB> That's all I'm saying here, is that it should be thought out
NB> and done _right_ the first time.

The /right/ way to do it would be to fix the bugs in Irex. But that is not
going to happen because Irex is closed source abandonware. So ANY work around
will just be that: a work arund.

NB> If Irex reports v1.1 and doesn't actually support it, then have a
NB> check upon connect for "IREX" and if that is true, ignore the binkp
NB> version check and continue forced to v1.0.

Just what I suggested in a previous messages, but I am going to leave it at
that because I am no longer an interested party. I do not and porobably never
will use mbcicio and I have said goodbye to Irex.

NB> Once that works, remove the _option_ to force to v1.0 so that the
NB> mistake of switching it on or off will never be made again.

The option to forcibly downgrade to 1.0 might be useful for working around
other problems. So I would not advocate to drop it completely. Just a warning
to use it with caution.

MV>> Each mailer tells the other what it can do. They then decide on
MV>> what they have in common.

NB> So what exactly happens when an Irex system connects to mbcico while
NB> NOT forced into v1.0 mode?

I do not know. As I wrote, I have said goodbye to Irex. I still have the old
system on standby, so I can help to do some tests with Irex, but I do not want
to invest time and energy in Irex any more. For me it is water under the
bridge.


Cheers, Michiel

[Kees van Eeten]

Hello Michiel!

26 Feb 14 11:27, you wrote to All:

MvdV> It turns out, I actually can receive from- and send mail to the
MvdV> offending system. But after the transfer is completed the other system
MvdV> forcebly closes the session and although the mail transfer was
MvdV> completed, my side marks the session as failed and just keeps on
MvdV> trying...

Yes that is the same as what I get, with 2:280/1016.
I forgot to mention that in previous messages.

So it may be somewhere in the end of session handshake.

Kees

[Michiel van der Vlist]

Hello Kees,

On Wednesday February 26 2014 12:02, you wrote to me:

MvdV>> It turns out, I actually can receive from- and send mail to the
MvdV>> offending system. But after the transfer is completed the other
MvdV>> system forcebly closes the session and although the mail
MvdV>> transfer was completed, my side marks the session as failed and
MvdV>> just keeps on trying...

KE> Yes that is the same as what I get, with 2:280/1016.
KE> I forgot to mention that in previous messages.

KE> So it may be somewhere in the end of session handshake.

Looks like it. Ask him if he also forces binkp 1.0 for you and if so ask him to
change it...


Cheers, Michiel

[Wilfred van Velzen]

Hi,

On 2014-02-26 15:50:13, Michiel van der Vlist wrote to Kees van Eeten:
about: "Error 10054":

MvdV> Looks like it. Ask him if he also forces binkp 1.0 for you and if so
MvdV> ask him to change it...

Strange if he did so, because I don't think Kees ever used irex?

Bye, Wilfred.

[Michiel van der Vlist]

Hello Wilfred,

On Wednesday February 26 2014 17:53, you wrote to me:

MvdV>> Looks like it. Ask him if he also forces binkp 1.0 for you and
MvdV>> if so ask him to change it...

WV> Strange if he did so, because I don't think Kees ever used irex?

Let's wait for the "if" and speculate about the why later...

Cheers, Michiel

[Wilfred van Velzen]

Hi,

On 2014-02-26 20:27:55, Michiel van der Vlist wrote to Wilfred van Velzen:
about: "Error 10054":

MvdV>>> Looks like it. Ask him if he also forces binkp 1.0 for you and
MvdV>>> if so ask him to change it...

WV>> Strange if he did so, because I don't think Kees ever used irex?

MvdV> Let's wait for the "if" and speculate about the why later...

Good plan! I'm staying tuned... ;)

Bye, Wilfred.

[Kees van Eeten]

Hello Wilfred!

26 Feb 14 17:53, you wrote to Michiel van der Vlist:

MvdV>> Looks like it. Ask him if he also forces binkp 1.0 for you and if so
MvdV>> ask him to change it...

WvV> Strange if he did so, because I don't think Kees ever used irex?

That is correct, but I never had problems when connecting with 2:280/1027.
Only with 2:280/1016, who runs Mbcico 0.50.0/GNU/Linux-i386 binkp/1.0 ;)

So my take is that either there is a glitch in de mbcico bibkp/1.0
implementation, or the regular binkp does not switch back properly.

Binkp has no problems connecting with other packages that only support
binkp/1.0 so again mbse is suspect.

As I have no sentiments for people who are not willing to bring their
software up to date even when updates are avalable, it is not my problem.

All goes well if the session is initiated by the mbse system, so 2:280/1016
polls for his mails and everybody is happy.

Kees