Error 10054

[Michiel van der Vlist]

Hello All,

Does any one know what this means:

? 17:14 [2296] recv: {W32 API error 10054} An existing connection was forcibly
closed by the remote host


Cheers, Michiel

[mark lewis]

On Fri, 14 Feb 2014, Michiel van der Vlist wrote to All:

MvdV> Does any one know what this means:

MvdV> ? 17:14 [2296] recv: {W32 API error 10054} An existing connection
MvdV> was forcibly closed by the remote host

uncle google says that m$ says the following...

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

[quote]
WSAECONNRESET
10054


Connection reset by peer.

An existing connection was forcibly closed by the remote host. This
normally results if the peer application on the remote host is suddenly
stopped, the host is rebooted, the host or remote network interface is
disabled, or the remote host uses a hard close (see setsockopt for more
information on the SO_LINGER option on the remote socket). This error may also
result if a connection was broken due to keep-alive activity detecting a
failure while one or more operations are in progress. Operations that were in
progress fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.
[/quote]

HTH

)\/(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 14 2014 14:45, you wrote to me:

ml> An existing connection was forcibly closed by the remote host.
ml> This normally results if the peer application on the remote host is
ml> suddenly stopped, the host is rebooted, the host or remote network
ml> interface is disabled, or the remote host uses a hard close (see
ml> setsockopt for more information on the SO_LINGER option on the remote
ml> socket). This error may also result if a connection was broken due to
ml> keep-alive activity detecting a failure while one or more operations
ml> are in progress. Operations that were in progress fail with
ml> WSAENETRESET. Subsequent operations fail with WSAECONNRESET. [/quote]

Hmmm... that gives me litle information on what I can do about it. Let me post
some more log info:

+ 22:10 [412] call to 2:280/***@fidonet
22:11 [412] trying binkp.dreamlandbbs.com [213.126.141.188]...
22:11 [412] connected
+ 22:11 [412] outgoing session with 213.126.141.188
- 22:11 [412] OPT CRAM-MD5-8920519c34014eb2b6e92baae0048058
+ 22:11 [412] Remote requests MD mode
- 22:11 [412] SYS Dreamland BBS
- 22:11 [412] ZYZ Lukas de Groen
- 22:11 [412] LOC Houten - The Netherlands
- 22:11 [412] NDL CM,XX,IBN,IFC,IFT,ITN
- 22:11 [412] TIME Fri, 14 Feb 2014 22:11:35 +0100
- 22:11 [412] VER mbcico/0.95.13/GNU/Linux-x86_64 binkp/1.1
- 22:11 [412] PHN 213.126.141.188
- 22:11 [412] OPM Dreamland BBS, your great source for files!
+ 22:11 [412] addr: 2:280/***@fidonet
+ 22:11 [412] addr: 2:280/***@fidonet
+ 22:11 [412] addr: 110:30/***@linuxnet (n/a or busy)
+ 22:11 [412] addr: 115:31/***@pascalnet (n/a or busy)
+ 22:11 [412] addr: 115:31/***@pascalnet (n/a or busy)
+ 22:11 [412] addr: 115:3100/***@pascalnet (n/a or busy)
+ 22:11 [412] addr: 115:3100/***@pascalnet (n/a or busy)
+ 22:11 [412] pwd protected session (MD5)
- 22:11 [412] OPT EXTCMD GZ BZ2 PLZ
+ 22:11 [412] Remote supports EXTCMD mode
- 22:11 [412] TRF 0 0
+ 22:11 [412] Remote has 0b of mail and 0b of files for us
? 22:11 [412] recv: {W32 API error 10054} An existing connection was forcibly
closed by th
e remote host
+ 22:11 [412] done (to 2:280/***@fidonet, failed, S/R: 0/0 (0/0 bytes))
22:11 [412] restoring poll with `c' flavour
22:11 [412] session closed, quitting...

Does anyone else have this problem with him?

I have this problem since I switched to binkd 1-1A49. I had no problem
connecting with him with Irex...



Cheers, Michiel

[Fred Riccio]

Hello Michiel!

14 Feb 14 22:10, Michiel van der Vlist wrote to mark lewis:


MvdV> - 22:11 [412] TRF 0 0
MvdV> + 22:11 [412] Remote has 0b of mail and 0b of files for us
MvdV> ? 22:11 [412] recv: {W32 API error 10054} An existing connection
MvdV> was forcibly closed by the remote host
MvdV> + 22:11 [412] done (to 2:280/***@fidonet, failed, S/R: 0/0 (0/0


MvdV> Does anyone else have this problem with him?

I tried a poll and didn't get any sort of error. I think what is happening is
that his end drops the connection before you can send your second M_EOB

[Michiel van der Vlist]

Hello Fred,

On Friday February 14 2014 16:33, you wrote to me:

MvdV>> ? 22:11 [412] recv: {W32 API error 10054} An existing
MvdV>> connection was forcibly closed by the remote host + 22:11 [412]
MvdV>> done (to 2:280/***@fidonet, failed, S/R: 0/0 (0/0

FR> I tried a poll and didn't get any sort of error. I think what is
FR> happening is that his end drops the connection before you can send
FR> your second M_EOB

Hmm... looks like I stumbled on an incompatibility between my version of binkd
and his mbcico/0.95.13/GNU/Linux-x86_64...


Cheers, Michiel

[Nicholas Boel]

Hello Michiel,

On 15 Feb 14 13:39, Michiel van der Vlist wrote to Fred Riccio:

FR>> I tried a poll and didn't get any sort of error. I think what is
FR>> happening is that his end drops the connection before you can
FR>> send your second M_EOB

MV> Hmm... looks like I stumbled on an incompatibility between my version
MV> of binkd and his mbcico/0.95.13/GNU/Linux-x86_64...

Now that I actually notice you're referring to a system running MBSE (mbcico),
I've actually been seeing errors connecting to my RC as well, who runs the
same (except version 0.92.0 of mbcico). I only connect to him once a week, but
that one connection sometimes takes 10 failed attempts before connecting
successfully once.

So I can second your incompatibility issue I guess.

Regards,
Nick

[Michiel van der Vlist]

Hello Nicholas,

On Saturday February 15 2014 10:21, you wrote to me:

MV>> Hmm... looks like I stumbled on an incompatibility between my
MV>> version of binkd and his mbcico/0.95.13/GNU/Linux-x86_64...

NB> Now that I actually notice you're referring to a system running MBSE
NB> (mbcico), I've actually been seeing errors connecting to my RC as
NB> well, who runs the same (except version 0.92.0 of mbcico).

It seems Kees has problems with some MBSE systems as well, although there is no
consistency. I have problems with some MBSE systems and others like you and
Kees have problems with some systems. But they are not always the same
systems...


Cheers, Michiel

[Nicholas Boel]

Hello Michiel,

On 15 Feb 14 23:14, Michiel van der Vlist wrote to Nicholas Boel:

MV>>> Hmm... looks like I stumbled on an incompatibility between my
MV>>> version of binkd and his mbcico/0.95.13/GNU/Linux-x86_64...

NB>> Now that I actually notice you're referring to a system running
NB>> MBSE (mbcico), I've actually been seeing errors connecting to my
NB>> RC as well, who runs the same (except version 0.92.0 of mbcico).

MV> It seems Kees has problems with some MBSE systems as well, although
MV> there is no consistency. I have problems with some MBSE systems and
MV> others like you and Kees have problems with some systems. But they are
MV> not always the same systems...

For another test, you could try 1:120/544 (RJ Clay's system/ftn.rocasa.net),
which is another mbcico/MBSE user. See if it happens to you there as well.

When I manually force a poll, it seems to connect and disconnect fine (yet
there was no files transferred), but when I send my weekly nodelist segment,
I end up with about 6-10 connection errors while attempting to send that
file.

I've changed that one option "-nd" to "-nr" but won't find out if it errors
until the next time my segment goes up, which I believe is late Wednesdays.

Regards,
Nick

[Michiel van der Vlist]

Hello Nicholas,

On Saturday February 15 2014 16:38, you wrote to me:

NB> For another test, you could try 1:120/544 (RJ Clay's
NB> system/ftn.rocasa.net), which is another mbcico/MBSE user. See if it
NB> happens to you there as well.

Nope. No problem connecting with him. Not just with a bare poll, and not with
sending files. (He is an FTS member and he is in my node manager fot FTSC
stuff.)

Very odd...


Cheers, Michiel

[Nicholas Boel]

Hello Michiel,

On 16 Feb 14 00:47, Michiel van der Vlist wrote to Nicholas Boel:

NB>> For another test, you could try 1:120/544 (RJ Clay's
NB>> system/ftn.rocasa.net), which is another mbcico/MBSE user. See if
NB>> it happens to you there as well.

MV> Nope. No problem connecting with him. Not just with a bare poll, and
MV> not with sending files. (He is an FTS member and he is in my node
MV> manager fot FTSC stuff.)

Ah. Then it's possible my error is either not related to yours, where in my
case I'm using the "-nd" switch and mbcico doesn't work well with it, or it is
related to yours but it all depends on your connection with the other person
using mbcico. It could also possibly be some kind of setting in mbcico that
doesn't work well with binkd.

MV> Very odd...

Indeed. Especially while so far it's seeming to be random and untraceable.
Since I've changed a setting on my end, I'll see if it affects anything the
next time I send my segment up. If there's no errors this time around, then it
was most likely that one switch I was using.

That still leaves your odd issue out there though.

Regards,
Nick

[Michiel van der Vlist]

Hello Nicholas,

On Saturday February 15 2014 22:57, you wrote to me:

MV>> Nope. No problem connecting with him. Not just with a bare poll,
MV>> and not with sending files. (He is an FTS member and he is in my
MV>> node manager fot FTSC stuff.)

NB> Ah. Then it's possible my error is either not related to yours, where
NB> in my case I'm using the "-nd" switch

I tried calling with the "-nd" switch set. No difference.

NB> and mbcico doesn't work well with it, or it is related to yours but it
NB> all depends on your connection with the other person using mbcico. It
NB> could also possibly be some kind of setting in mbcico that doesn't
NB> work well with binkd.

It is a pity Michiel Broek has left Fidonet. He might have been in a postion to
shed some light on this.


Cheers, Michiel

[mark lewis]

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

ml> An existing connection was forcibly closed by the remote host.
ml> This normally results if the peer application on the remote host is
ml> suddenly stopped, the host is rebooted, the host or remote network
ml> interface is disabled, or the remote host uses a hard close (see
ml> setsockopt for more information on the SO_LINGER option on the remote
ml> socket). This error may also result if a connection was broken due to
ml> keep-alive activity detecting a failure while one or more operations
ml> are in progress. Operations that were in progress fail with
ml> WSAENETRESET. Subsequent operations fail with WSAECONNRESET. [/quote]

MvdV> Hmmm... that gives me litle information on what I can do about
MvdV> it.

technically speaking, there is nothing you can do when the remote end forces
the connection closed...

MvdV> Let me post some more log info:

[trim]

MvdV> Does anyone else have this problem with him?

i can poll and record the traffic with tcpdump and see what's going on... do
you have mail waiting for that system?

MvdV> I have this problem since I switched to binkd 1-1A49. I had no
MvdV> problem connecting with him with Irex...

it is possible that his binkp engine doesn't support some newer features of
binkp... i haven't kept up with mbcico's development... you were using IREX
before which we know doesn't support the newer features of binkp... what other
older versions of binkd have you tried, if any? i'm currently running 1.1A48 on
my OS2 system which is what i'll use for my polling test...

)\/(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 14 2014 18:42, you wrote to me:

MvdV>> Hmmm... that gives me litle information on what I can do about it.

ml> technically speaking, there is nothing you can do when the remote end
ml> forces the connection closed...

Presently I seem to be the only one with this problem, so it would seem that I
am not doing what the others do...

ml> i can poll and record the traffic with tcpdump and see what's going
ml> on... do you have mail waiting for that system?

Yes, I had. I get the same error when I remove the waiting mail and do a bare
foot poll.

MvdV>> I have this problem since I switched to binkd 1-1A49. I had no
MvdV>> problem connecting with him with Irex...

ml> it is possible that his binkp engine doesn't support some newer
ml> features of binkp...

Possibly, but then my side is supposed to gear down for compatibility isn't it?

ml> you were using IREX before which we know doesn't support the newer
ml> features of binkp...

Even worse, it is only compatible up to 1.1. It says 1.1 but has its own
flavour of it..

ml> what other older versions of binkd have you tried, if any?

None. It was only yesterday that I switched from Irex to binkd. Version 1.1a49
is the only version I ever had.

ml> i'm currently running 1.1A48 on my OS2 system which is what i'll use
ml> for my polling test...

Perhaps I stumbled on a bug in 1.1a49?


Cheers, Michiel

[Wilfred van Velzen]

Hi,

On 2014-02-15 13:41:26, Michiel van der Vlist wrote to mark lewis:
about: "Error 10054":

MvdV> Perhaps I stumbled on a bug in 1.1a49?

With 1.1a-47 on linux I don't get any error:

+ 15 Feb 16:47:08 [9667] call to 2:280/***@fidonet
15 Feb 16:47:09 [9667] trying f1027.n280.z2.binkp.net [213.126.141.188]...
15 Feb 16:47:09 [9667] connected
+ 15 Feb 16:47:09 [9667] outgoing session with
ip-213-126-141-188.ip.prioritytelecom.net [213.126.141.188]
- 15 Feb 16:47:09 [9667] OPT CRAM-MD5-b3eaf94e168046f44d13887a67d224a8
+ 15 Feb 16:47:09 [9667] Remote requests MD mode
- 15 Feb 16:47:09 [9667] SYS Dreamland BBS
- 15 Feb 16:47:09 [9667] ZYZ Lukas de Groen
- 15 Feb 16:47:09 [9667] LOC Houten - The Netherlands
- 15 Feb 16:47:09 [9667] NDL CM,XX,IBN,IFC,IFT,ITN
- 15 Feb 16:47:09 [9667] TIME Sat, 15 Feb 2014 16:47:09 +0100
- 15 Feb 16:47:09 [9667] VER mbcico/0.95.13/GNU/Linux-x86_64 binkp/1.1
- 15 Feb 16:47:09 [9667] PHN 213.126.141.188
- 15 Feb 16:47:09 [9667] OPM Dreamland BBS, your great source for files!
+ 15 Feb 16:47:09 [9667] addr: 2:280/***@fidonet
+ 15 Feb 16:47:09 [9667] addr: 2:280/***@fidonet
+ 15 Feb 16:47:09 [9667] addr: 110:30/***@linuxnet (n/a or busy)
+ 15 Feb 16:47:09 [9667] addr: 115:31/***@pascalnet (n/a or busy)
+ 15 Feb 16:47:09 [9667] addr: 115:31/***@pascalnet (n/a or busy)
+ 15 Feb 16:47:09 [9667] addr: 115:3100/***@pascalnet (n/a or busy)
+ 15 Feb 16:47:09 [9667] addr: 115:3100/***@pascalnet (n/a or busy)
- 15 Feb 16:47:09 [9667] OPT EXTCMD GZ BZ2 PLZ
+ 15 Feb 16:47:09 [9667] Remote supports EXTCMD mode
+ 15 Feb 16:47:09 [9667] Remote supports GZ mode
+ 15 Feb 16:47:09 [9667] Remote supports BZ2 mode
- 15 Feb 16:47:09 [9667] TRF 0 0
+ 15 Feb 16:47:09 [9667] Remote has 0b of mail and 0b of files for us
+ 15 Feb 16:47:09 [9667] done (to 2:280/***@fidonet, OK, S/R: 0/0 (0/0 bytes))
15 Feb 16:47:09 [9667] session closed, quitting...
15 Feb 16:47:09 [2532] rc(9667)=0

I'll try 1.1a-49 later on. Stay tuned. ;)

Bye, Wilfred.

[Wilfred van Velzen]

Hi,

On 2014-02-15 16:47:51, Wilfred van Velzen wrote to Michiel van der Vlist:
about: "Re: Error 10054":

MvdV>> Perhaps I stumbled on a bug in 1.1a49?

WvV> With 1.1a-47 on linux I don't get any error:

WvV> I'll try 1.1a-49 later on. Stay tuned. ;)

49 doesn't make a difference...

Bye, Wilfred.

[Wilfred van Velzen]

Hi Michiel,

On 17 Feb 14 23:32, Wilfred van Velzen wrote to Michiel van der Vlist:
about: "Re: Error 10054":

WvV>> With 1.1a-47 on linux I don't get any error:

WvV>> I'll try 1.1a-49 later on. Stay tuned. ;)

WvV> 49 doesn't make a difference...

Neither with the Win64 version I'm using on this point system:

18 Feb 11:30:17 [5456] BEGIN standalone, binkd/1.1a-49/Win64 -pP 2:280/1027
d:\com\binkd\binkd.cfg
18 Feb 11:30:17 [5456] creating a poll for 2:280/***@fidonet (`d' flavour)
18 Feb 11:30:17 [5456] clientmgr started
+ 18 Feb 11:30:17 [4640] call to 2:280/***@fidonet
18 Feb 11:30:17 [4640] trying f1027.n280.z2.binkp.net [213.126.141.188]...
18 Feb 11:30:17 [4640] connected
...
+ 18 Feb 11:30:17 [4640] Remote has 0b of mail and 0b of files for us
+ 18 Feb 11:30:17 [4640] done (to 2:280/***@fidonet, OK, S/R: 0/0 (0/0 bytes))
18 Feb 11:30:17 [4640] session closed, quitting...
18 Feb 11:30:17 [5456] the queue is empty, quitting...


Wilfred.

[Kees van Eeten]

Hello Wilfred!

18 Feb 14 11:38, you wrote to Michiel van der Vlist:

WvV> Neither with the Win64 version I'm using on this point system:

WvV> 18 Feb 11:30:17 [5456] BEGIN standalone, binkd/1.1a-49/Win64 -pP
WvV> 2:280/1027 d:\com\binkd\binkd.cfg 18 Feb 11:30:17 [5456] creating a poll

I have never had any problems with 2:280/1027 only with 2:280/1016

Kees

[Wilfred van Velzen]

Hi Kees,

On 2014-02-18 11:58:34, you wrote to me:

WvV>> 18 Feb 11:30:17 [5456] BEGIN standalone, binkd/1.1a-49/Win64 -pP
WvV>> 2:280/1027 d:\com\binkd\binkd.cfg 18 Feb 11:30:17 [5456] creating a
WvV>> poll

KvE> I have never had any problems with 2:280/1027 only with 2:280/1016

1016 Also works perfectly well for me...


Bye, Wilfred.

[Kees van Eeten]

Hello Wilfred!

18 Feb 14 13:06, you wrote to me:

WvV>>> 2:280/1027 d:\com\binkd\binkd.cfg 18 Feb 11:30:17 [5456] creating a
WvV>>> poll

KvE>> I have never had any problems with 2:280/1027 only with 2:280/1016

WvV> 1016 Also works perfectly well for me...

It is verymuch system dependent, if I try 2:280/1016 from my system based
on the Raspberry Pi, all is well.
The Binkd on my Raspberry Pi is compiled from the same source files as the
binkd I run on my main system, a 64bit 3 core AMD.
Both run Debian/Linux as underlaying OS.

So it may verywell be a timing problem on one side or the other.

Kees

[Wilfred van Velzen]

Hi,

On 2014-02-18 13:42:42, Kees van Eeten wrote to Wilfred van Velzen:
about: "Error 10054":

KvE>>> I have never had any problems with 2:280/1027 only with 2:280/1016

WvV>> 1016 Also works perfectly well for me...

KvE> It is verymuch system dependent,

Of both the sender and receiver.

KvE> if I try 2:280/1016 from my system based on the Raspberry Pi, all is
KvE> well. The Binkd on my Raspberry Pi is compiled from the same source
KvE> files as the binkd I run on my main system, a 64bit 3 core AMD. Both
KvE> run Debian/Linux as underlaying OS.

Btw: As you are running linux, you can't be getting the same "W32 API error" as
Michiel is getting:

MvdV> ? 21:17 [2364] recv: {W32 API error 10054} An existing connection
MvdV> was forcibly c he remote host

So is this the same problem?

KvE> So it may verywell be a timing problem on one side or the other.

I was thinking in that direction too...

Bye, Wilfred.

[Kees van Eeten]

Hello Wilfred!

18 Feb 14 19:39, you wrote to me:

WvV> Btw: As you are running linux, you can't be getting the same "W32 API
WvV> error" as Michiel is getting:

MvdV>> ? 21:17 [2364] recv: {W32 API error 10054} An existing connection
MvdV>> was forcibly c he remote host

WvV> So is this the same problem?

17 Feb 11:20:35 [10366] truncated /var/spool/ftn/out.002/00000f93.mo0
? 17 Feb 11:20:37 [10366] recv: connection closed by foreign host
+ 17 Feb 11:20:38 [10366] done (to 2:280/***@fidonet, failed, S/R: 1/0 (1074/0
bytes))
17 Feb 11:20:38 [10366] restoring poll with `f' flavour

Is this close enough?

KvE>> So it may verywell be a timing problem on one side or the other.

WvV> I was thinking in that direction too...

Well some day when I get a roundtoit. It is not on the top of my list.
It may require setting up mbse on a fast and on a slow system.

Michiels problem is in connections with Lukas de Groen, who has expressed
the intention to leave Fidonet in the not to far future and I have the
problem when connecting to Jan Bredenbeek and we have used a workaround
for a couple of years now.

Kees

[Wilfred van Velzen]

Hi,

On 2014-02-18 19:59:40, Kees van Eeten wrote to Wilfred van Velzen:
about: "Error 10054":

WvV>> Btw: As you are running linux, you can't be getting the same "W32
WvV>> API
WvV>> error" as Michiel is getting:

MvdV>>> ? 21:17 [2364] recv: {W32 API error 10054} An existing connection
MvdV>>> was forcibly c he remote host

WvV>> So is this the same problem?

KvE> 17 Feb 11:20:35 [10366] truncated /var/spool/ftn/out.002/00000f93.mo0
KvE> ? 17 Feb 11:20:37 [10366] recv: connection closed by foreign host
KvE> + 17 Feb 11:20:38 [10366] done (to 2:280/***@fidonet, failed, S/R: 1/0
KvE> (1074/0 bytes)) 17 Feb 11:20:38 [10366] restoring poll with `f' flavour

KvE> Is this close enough?

The error looks the same.

I notice there is a 2 second gap between the previous line and the line with
error.

It's a pitty, Michiels log lines don't show the seconds:

+ 22:11 [412] Remote has 0b of mail and 0b of files for us
? 22:11 [412] recv: {W32 API error 10054} An existing connection was forcibly
closed by the remote host

+ 21:17 [2364] Remote has 0b of mail and 0b of files for us
? 21:17 [2364] recv: {W32 API error 10054} An existing connection was forcibly
c he remote host

But with the 2 second gap, I don't think a subtle timing error is likely the
cause of this. But rather a protocol handling bug in the mbse code. Like not
"flushing" the output buffers to the receiver before closing the connection...

Bye, Wilfred.

[andrew clarke]

18 Feb 14 21:41, you wrote to Kees van Eeten:

KvE>> 17 Feb 11:20:35 [10366] truncated /var/spool/ftn/out.002/00000f93.mo0
KvE>> ? 17 Feb 11:20:37 [10366] recv: connection closed by foreign host
KvE>> + 17 Feb 11:20:38 [10366] done (to 2:280/***@fidonet, failed, S/R: 1/0
KvE>> (1074/0 bytes))

WV> I notice there is a 2 second gap between the previous line and the
WV> line with error.

Shot in the dark here, but it's plausible the remote system is segfaulting,
resulting in a coredump. which could explain the 2 second delay.

[Wilfred van Velzen]

Hi andrew,

On 2014-02-19 19:01:16, you wrote to me:

KvE>>> 17 Feb 11:20:35 [10366] truncated
KvE>>> /var/spool/ftn/out.002/00000f93.mo0 ? 17 Feb 11:20:37 [10366] recv:
KvE>>> connection closed by foreign host + 17 Feb 11:20:38 [10366] done (to
KvE>>> 2:280/***@fidonet, failed, S/R: 1/0 (1074/0 bytes))

WV>> I notice there is a 2 second gap between the previous line and the
WV>> line with error.

ac> Shot in the dark here, but it's plausible the remote system is
ac> segfaulting,
ac> resulting in a coredump. which could explain the 2 second delay.

I think Kees and Michiel should ask for the logs for these connections from the
systems concerned. That could maybe shed some more light on what's happening.

Bye, Wilfred.

[Michiel van der Vlist]

Hello Wilfred,

On Wednesday February 19 2014 09:26, you wrote to andrew clarke:

ac>> Shot in the dark here, but it's plausible the remote system is
ac>> segfaulting, resulting in a coredump. which could explain the 2
ac>> second delay.

WV> I think Kees and Michiel should ask for the logs for these connections
WV> from the systems concerned. That could maybe shed some more light on
WV> what's happening.

Perhaps it would. Problem is that one of he sysops is in the process of leaving
Fidonet and the other is very unresponsive...


Cheers, Michiel

[Wilfred van Velzen]

Hi Michiel,

On 2014-02-19 12:50:10, you wrote to me:

WV>> I think Kees and Michiel should ask for the logs for these
WV>> connections from the systems concerned. That could maybe shed some
WV>> more light on what's happening.

MvdV> Perhaps it would. Problem is that one of he sysops is in the process of
MvdV> leaving Fidonet and the other is very unresponsive...

Nevertheless, you should still ask... ;) (seriously!)

Bye, Wilfred.

[mark lewis]

Following up a post on Wed, 19 Feb 2014, from Wilfred van Velzen to andrew clarke:

ac> Shot in the dark here, but it's plausible the remote system is
ac> segfaulting, resulting in a coredump. which could explain the 2
ac> second delay.

WvV> I think Kees and Michiel should ask for the logs for these
WvV> connections from the systems concerned. That could maybe shed some
WvV> more light on what's happening.

agreed... the question is if there is an avenue outside of FTN that can be used
if direct comms between the entities is experiencing a problem like this...

)\/(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 14:08, you wrote to me:

WvV>> I think Kees and Michiel should ask for the logs for these
WvV>> connections from the systems concerned. That could maybe shed
WvV>> some more light on what's happening.

ml> agreed... the question is if there is an avenue outside of FTN that
ml> can be used if direct comms between the entities is experiencing a
ml> problem like this...

Don't worry, I have other means of contact. Plus that they are within 30
minutes driving...


Cheers, Michiel

[Michiel van der Vlist]

Hello Wilfred,

On Tuesday February 18 2014 21:41, you wrote to Kees van Eeten:

WV> I notice there is a 2 second gap between the previous line and the
WV> line with error.

WV> It's a pitty, Michiels log lines don't show the seconds:

WV> + 22:11 [412] Remote has 0b of mail and 0b of files for us
WV> ? 22:11 [412] recv: {W32 API error 10054} An existing connection was
WV> forcibly closed by the remote host

Looking at the screen however, I can see a few seconds delay between the two
lines...


Cheers, Michiel

[Wilfred van Velzen]

Hi Michiel,

On 2014-02-19 12:48:31, you wrote to me:

WV>> It's a pitty, Michiels log lines don't show the seconds:

WV>> + 22:11 [412] Remote has 0b of mail and 0b of files for us
WV>> ? 22:11 [412] recv: {W32 API error 10054} An existing connection was
WV>> forcibly closed by the remote host

MvdV> Looking at the screen however, I can see a few seconds delay between the
MvdV> two lines...

Btw: strange your logging doesn't show seconds, as we are using the same binkd
version. What is the loglevel you set in your binkd.cfg? Mine is set to 4.


Bye, Wilfred.

[Michiel van der Vlist]

Hello Wilfred,

On Wednesday February 19 2014 13:50, you wrote to me:

MvdV>> Looking at the screen however, I can see a few seconds delay
MvdV>> between the two lines...

WV> Btw: strange your logging doesn't show seconds, as we are using the
WV> same binkd version. What is the loglevel you set in your binkd.cfg?
WV> Mine is set to 4.

Same.

However, the seconds DO show in the log, just not on the screen:

+ 14 Feb 14:05:11 [3080] addr: 2:280/***@fidonet
+ 14 Feb 14:05:11 [3080] addr: 2:280/***@fidonet
+ 14 Feb 14:05:11 [3080] addr: 110:30/***@linuxnet (n/a or busy)
+ 14 Feb 14:05:11 [3080] addr: 115:31/***@pascalnet (n/a or busy)
+ 14 Feb 14:05:11 [3080] addr: 115:31/***@pascalnet (n/a or busy)
+ 14 Feb 14:05:11 [3080] addr: 115:3100/***@pascalnet (n/a or busy)
+ 14 Feb 14:05:11 [3080] addr: 115:3100/***@pascalnet (n/a or busy)
+ 14 Feb 14:05:11 [3080] pwd protected session (MD5)
- 14 Feb 14:05:11 [3080] OPT EXTCMD GZ BZ2 PLZ
+ 14 Feb 14:05:11 [3080] Remote supports EXTCMD mode
- 14 Feb 14:05:11 [3080] TRF 0 0
+ 14 Feb 14:05:11 [3080] Remote has 0b of mail and 0b of files for us
? 14 Feb 14:05:13 [3080] recv: {W32 API error 10054} An existing connection wa
+ 14 Feb 14:05:13 [3080] done (to 2:280/***@fidonet, failed, S/R: 0/0 (0/0 byte
14 Feb 14:05:14 [3080] restoring poll with `c' flavour
14 Feb 14:05:14 [3080] session closed, quitting...

But now that I look at the log I see another strange thing. The error did NOT
occur the week before when I had this system configured as 280/5555.6:

09 Feb 23:14:44 [5088] BEGIN standalone, binkd/1.1a-49/Win32 -p -P 19
09 Feb 23:14:44 [5088] creating a poll for 2:280/***@fidonet (`d' flavo
09 Feb 23:14:44 [5088] clientmgr started
+ 09 Feb 23:14:44 [7740] call to 2:280/***@fidonet
09 Feb 23:14:44 [7740] trying f19.n280.z2.binkp.net [213.126.141.188].
09 Feb 23:14:44 [7740] connected
+ 09 Feb 23:14:44 [7740] outgoing session with 213.126.141.188
- 09 Feb 23:14:44 [7740] OPT CRAM-MD5-512f19ce773f811a106e0b7aa3f69978
+ 09 Feb 23:14:44 [7740] Remote requests MD mode
- 09 Feb 23:14:44 [7740] SYS Dreamland BBS
- 09 Feb 23:14:44 [7740] ZYZ Lukas de Groen
- 09 Feb 23:14:44 [7740] LOC Houten - The Netherlands
- 09 Feb 23:14:44 [7740] NDL CM,XX,IBN,IFC,IFT,ITN
- 09 Feb 23:14:44 [7740] TIME Sun, 09 Feb 2014 23:14:51 +0100
- 09 Feb 23:14:44 [7740] VER mbcico/0.95.13/GNU/Linux-x86_64 binkp/1.1
- 09 Feb 23:14:44 [7740] PHN 213.126.141.188
- 09 Feb 23:14:44 [7740] OPM Dreamland BBS, your great source for files!
+ 09 Feb 23:14:44 [7740] addr: 2:280/***@fidonet
+ 09 Feb 23:14:45 [7740] addr: 2:280/***@fidonet
+ 09 Feb 23:14:45 [7740] addr: 110:30/***@linuxnet (n/a or busy)
+ 09 Feb 23:14:45 [7740] addr: 115:31/***@pascalnet (n/a or busy)
+ 09 Feb 23:14:45 [7740] addr: 115:31/***@pascalnet (n/a or busy)
+ 09 Feb 23:14:45 [7740] addr: 115:3100/***@pascalnet (n/a or busy)
+ 09 Feb 23:14:45 [7740] addr: 115:3100/***@pascalnet (n/a or busy)
- 09 Feb 23:14:45 [7740] OPT EXTCMD GZ BZ2 PLZ
+ 09 Feb 23:14:45 [7740] Remote supports EXTCMD mode
- 09 Feb 23:14:45 [7740] TRF 0 0
+ 09 Feb 23:14:45 [7740] Remote has 0b of mail and 0b of files for us
+ 09 Feb 23:14:45 [7740] done (to 2:280/***@fidonet, OK, S/R: 0/0 (0/0 bytes
09 Feb 23:14:45 [7740] session closed, quitting...
09 Feb 23:14:45 [5088] the queue is empty, quitting...

Odd...


Cheers, Michiel

[Wilfred van Velzen]

Hi Michiel,

On 2014-02-19 15:46:23, you wrote to me:

MvdV> However, the seconds DO show in the log, just not on the screen:

Ok, it was the screen you copied it from. I never look at the screen. ;)

MvdV> + 14 Feb 14:05:11 [3080] addr: 115:3100/***@pascalnet (n/a or busy)
MvdV> + 14 Feb 14:05:11 [3080] pwd protected session (MD5)
MvdV> - 14 Feb 14:05:11 [3080] OPT EXTCMD GZ BZ2 PLZ

MvdV> 14 Feb 14:05:14 [3080] restoring poll with `c' flavour 14 Feb

MvdV> But now that I look at the log I see another strange thing. The
MvdV> error did NOT occur the week before when I had this system
MvdV> configured as 280/5555.6:

MvdV> 09 Feb 23:14:44 [5088] creating a poll for 2:280/***@fidonet (`d'
MvdV> flavo

MvdV> + 09 Feb 23:14:45 [7740] addr: 115:3100/***@pascalnet (n/a or busy)
MvdV> - 09 Feb 23:14:45 [7740] OPT EXTCMD GZ BZ2 PLZ

MvdV> Odd...

Maybe. I notice a few more differences:

- 'c' flavour vs 'd'
- pwd protected vs no pwd


Bye, Wilfred.

[Michiel van der Vlist]

Hello Wilfred,

On Wednesday February 19 2014 16:28, you wrote to me:

MvdV>> But now that I look at the log I see another strange thing. The
MvdV>> error did NOT occur the week before when I had this system
MvdV>> configured as 280/5555.6:

MvdV>> 09 Feb 23:14:44 [5088] creating a poll for 2:280/***@fidonet
MvdV>> (`d' flavo

MvdV>> + 09 Feb 23:14:45 [7740] addr: 115:3100/***@pascalnet (n/a or
MvdV>> busy) - 09 Feb 23:14:45 [7740] OPT EXTCMD GZ BZ2 PLZ

MvdV>> Odd...

WV> Maybe. I notice a few more differences:

WV> - 'c' flavour vs 'd'
WV> - pwd protected vs no pwd

I also could connect to 280/1016 from my point 6:

09 Feb 23:17:18 [4384] creating a poll for 2:280/***@fidonet (`d' flavour
09 Feb 23:17:18 [4384] clientmgr started
+ 09 Feb 23:17:18 [5992] call to 2:280/***@fidonet
09 Feb 23:17:18 [5992] trying f1016.n280.z2.binkp.net [188.142.112.203]...
09 Feb 23:17:18 [5992] connected
+ 09 Feb 23:17:18 [5992] outgoing session with 188.142.112.203
- 09 Feb 23:17:18 [5992] OPT PLZ CRAM-MD5-f31eac17c51021cb5784babf9e25962d
+ 09 Feb 23:17:18 [5992] Remote requests MD mode
- 09 Feb 23:17:18 [5992] SYS bbs.bredenbeek.net
- 09 Feb 23:17:18 [5992] ZYZ Jan Bredenbeek
- 09 Feb 23:17:18 [5992] LOC Hilversum, NL
- 09 Feb 23:17:18 [5992] NDL MO,CM,XA,IBN,IFC,ITN
- 09 Feb 23:17:18 [5992] TIME Sun, 09 Feb 2014 23:17:27 +0100
- 09 Feb 23:17:18 [5992] VER mbcico/0.50.0/GNU/Linux-i386 binkp/1.1
- 09 Feb 23:17:18 [5992] PHN -unpublished-
- 09 Feb 23:17:19 [5992] OPM SYNCNET BBS
+ 09 Feb 23:17:19 [5992] addr: 2:280/***@fidonet
- 09 Feb 23:17:19 [5992] TRF 0 0
+ 09 Feb 23:17:19 [5992] Remote has 0b of mail and 0b of files for us
+ 09 Feb 23:17:19 [5992] done (to 2:280/***@fidonet, OK, S/R: 0/0 (0/0 byte
09 Feb 23:17:19 [5992] session closed, quitting...
09 Feb 23:17:19 [4384] the queue is empty, quitting...

And it failed when calling as 280/5555, 280/0 and 2:2/20:

│ 15 Feb 21:17:09 [988] creating a poll for 2:280/***@fidonet (`d' flavour
│ 15 Feb 21:17:09 [988] clientmgr started
│+ 15 Feb 21:17:09 [2364] call to 2:280/***@fidonet
│ 15 Feb 21:17:09 [2364] trying f1016.n280.z2.binkp.net [188.142.112.203]..
│ 15 Feb 21:17:09 [2364] connected
│+ 15 Feb 21:17:09 [2364] outgoing session with 188.142.112.203
│- 15 Feb 21:17:09 [2364] OPT PLZ CRAM-MD5-0336e32d25677830a5bb62c7db623d40
│+ 15 Feb 21:17:09 [2364] Remote requests MD mode
│- 15 Feb 21:17:09 [2364] SYS bbs.bredenbeek.net
│- 15 Feb 21:17:09 [2364] ZYZ Jan Bredenbeek
│- 15 Feb 21:17:09 [2364] LOC Hilversum, NL
│- 15 Feb 21:17:09 [2364] NDL MO,CM,XA,IBN,IFC,ITN
│- 15 Feb 21:17:09 [2364] TIME Sat, 15 Feb 2014 21:17:04 +0100
│- 15 Feb 21:17:09 [2364] VER mbcico/0.50.0/GNU/Linux-i386 binkp/1.1
│- 15 Feb 21:17:09 [2364] PHN -unpublished-
│- 15 Feb 21:17:09 [2364] OPM SYNCNET BBS
│+ 15 Feb 21:17:09 [2364] addr: 2:280/***@fidonet
│- 15 Feb 21:17:10 [2364] TRF 0 0
│+ 15 Feb 21:17:10 [2364] Remote has 0b of mail and 0b of files for us
│? 15 Feb 21:17:12 [2364] recv: {W32 API error 10054} An existing connection
│+ 15 Feb 21:17:12 [2364] done (to 2:280/***@fidonet, failed, S/R: 0/0 (0/0
│ 15 Feb 21:17:12 [2364] restoring poll with `d' flavour

This time it is both 'd' flavour and no password.

Schiet mij maar lek...

Cheers, Michiel

[Kees van Eeten]

Hello Michiel!

19 Feb 14 17:13, you wrote to Wilfred van Velzen:

MvdV> 21:17:10 [2364] Remote has 0b of mail and 0b of files for us |? 15 Feb
MvdV> 21:17:12 [2364] recv: {W32 API error 10054} An existing connection |+ 15
MvdV> Feb 21:17:12 [2364] done (to 2:280/***@fidonet, failed, S/R: 0/0 (0/0 |
MvdV> 15 Feb 21:17:12 [2364] restoring poll with `d' flavour

MvdV> This time it is both 'd' flavour and no password.
MvdV> Schiet mij maar lek...

In the first session it was not password protected, the other side will not
offer any files.
In the second a recv was initiated, and that fails.

Kees

[Michiel van der Vlist]

Hello Kees,

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


MvdV>> 21:17:10 [2364] Remote has 0b of mail and 0b of files for us |?
MvdV>> 15 Feb
MvdV>> 21:17:12 [2364] recv: {W32 API error 10054} An existing
MvdV>> connection |+ 15 Feb 21:17:12 [2364] done (to
MvdV>> 2:280/***@fidonet, failed, S/R: 0/0 (0/0 | 15 Feb 21:17:12
MvdV>> [2364] restoring poll with `d' flavour

MvdV>> This time it is both 'd' flavour and no password.
MvdV>> Schiet mij maar lek...

KE> In the first session it was not password protected, the other side
KE> will not offer any files. In the second a recv was initiated, and that
KE> fails.

It was not password protected in both cases.


Cheers, Michiel

[Wilfred van Velzen]

Hi,

On 2014-02-19 17:13:20, Michiel van der Vlist wrote to Wilfred van Velzen:
about: "Error 10054":

MvdV> Schiet mij maar lek...

Could you repeat the test with 'loglevel 10' ?

Bye, Wilfred.

[Michiel van der Vlist]

Hello Wilfred,

On Tuesday February 18 2014 11:38, you wrote to me:


WvV>>> I'll try 1.1a-49 later on. Stay tuned. ;)

WvV>> 49 doesn't make a difference...

WV> Neither with the Win64 version I'm using on this point system:

It is a mystery....


Cheers, Michiel

[Access Denied]

Hello Michiel,

On 19 Feb 14 12:45, Michiel van der Vlist wrote to Wilfred van Velzen:

MV> It is a mystery....

Just an FYI, it looks like my system connected without error this week while
sending up my net segment. So it appears mbcico doesn't like the '-nd' switch
very much.

Removing that and adding the '-nr' switch seems to work much better with the
MBSE node I'm connecting to. So I'd have to take a shot by saying that it
seems it wasn't the same error as you were having.

Regards,
Nick

[Michiel van der Vlist]

Hello Access,

On Thursday February 20 2014 23:25, you wrote to me:

AD> Just an FYI, it looks like my system connected without error this week
AD> while sending up my net segment. So it appears mbcico doesn't like the
AD> '-nd' switch very much.

AD> Removing that and adding the '-nr' switch seems to work much better
AD> with the MBSE node I'm connecting to. So I'd have to take a shot by
AD> saying that it seems it wasn't the same error as you were having.

Possibly. OTOH, the errors may be related in that they stem from a common
origin. E.g. a buffer overflow...


Cheers, Michiel

[Nicholas Boel]

Hello Michiel,

On 21 Feb 14 15:59, Michiel van der Vlist wrote to Access Denied:

Let's start out with apologizing for using an alias here. I must have been in
a hurry and didn't realize it at the time.

AD>> Removing that and adding the '-nr' switch seems to work much
AD>> better with the MBSE node I'm connecting to. So I'd have to take
AD>> a shot by saying that it seems it wasn't the same error as you
AD>> were having.

MV> Possibly. OTOH, the errors may be related in that they stem from a
MV> common origin. E.g. a buffer overflow...

Very true. If there's anything else I can do, or any test polls you'd like me
to try (since I'm on linux - maybe to see if it happens in all versions, etc),
just let me know.

Regards,
Nick

[Michiel van der Vlist]

Hello Nicholas,

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

MV>> Possibly. OTOH, the errors may be related in that they stem from
MV>> a common origin. E.g. a buffer overflow...

NB> Very true. If there's anything else I can do, or any test polls you'd
NB> like me to try (since I'm on linux - maybe to see if it happens in all
NB> versions, etc), just let me know.

Tnx, but for now I am stuck. The problems seems to be on the other side, so we
have to wakeup someone on MBSE side of the fence...


Cheers, Michiel

[Nicholas Boel]

Hello Michiel,

On 15 Feb 14 13:41, Michiel van der Vlist wrote to mark lewis:

ml>> technically speaking, there is nothing you can do when the remote
ml>> end forces the connection closed...

MV> Presently I seem to be the only one with this problem, so it would
MV> seem that I am not doing what the others do...

Are you by chance using the "-nr" or "-nd" options in your node line for this
link? I've noticed some systems cannot handle those (moreso the -nd option)
and cause all sorts of errors.

I usually try to use the "-nd" option, but if I notice that the other system
cannot support it, or there's a lot of questionable errors and early
disconnects from said system, I disable it for that specific link which
usually fixes the connection issues.

MvdV>>> I have this problem since I switched to binkd 1-1A49. I had no
MvdV>>> problem connecting with him with Irex...

I'm using 1.1a49 also, and haven't seen that issue. Although I'm using the
Linux version compiled myself. That is one thing I have noticed though
(above), which isn't a binkd issue, but is an issue of unsupported software or
software that never implemented updates to binkp.

ml>> it is possible that his binkp engine doesn't support some newer
ml>> features of binkp...

MV> Possibly, but then my side is supposed to gear down for compatibility
MV> isn't it?

In most cases. Though some things like the "-nd" option are even mentioned in
the docs that it can cause errors with some systems that don't support the
same on their end.

MV> None. It was only yesterday that I switched from Irex to binkd.
MV> Version 1.1a49 is the only version I ever had.

MV> Perhaps I stumbled on a bug in 1.1a49?

Perhaps. Otherwise you may just be forcing an option that the other end
doesn't support, which can happen occasionally. Some links can't even handle
CRAM-MD5 authentication (-md option), and can only send plain text
authentication (yikes!).

Regards,
Nick

[Michiel van der Vlist]

Hello Nicholas,

On Saturday February 15 2014 10:09, you wrote to me:

MV>> Presently I seem to be the only one with this problem, so it
MV>> would seem that I am not doing what the others do...

NB> Are you by chance using the "-nr" or "-nd" options in your node line
NB> for this link?

No...

NB> I've noticed some systems cannot handle those (moreso
NB> the -nd option) and cause all sorts of errors.

Hmmm..

ml>>> it is possible that his binkp engine doesn't support some newer
ml>>> features of binkp...

MV>> Possibly, but then my side is supposed to gear down for
MV>> compatibility isn't it?

NB> In most cases. Though some things like the "-nd" option are even
NB> mentioned in the docs that it can cause errors with some systems that
NB> don't support the same on their end.

I have not played around with any of those options.

MV>> None. It was only yesterday that I switched from Irex to binkd.
MV>> Version 1.1a49 is the only version I ever had.

MV>> Perhaps I stumbled on a bug in 1.1a49?

NB> Perhaps. Otherwise you may just be forcing an option that the other
NB> end doesn't support, which can happen occasionally. Some links can't
NB> even handle CRAM-MD5 authentication (-md option), and can only send
NB> plain text authentication (yikes!).

Stay tuned...


Cheers, Michiel

[mark lewis]

On Sat, 15 Feb 2014, Michiel van der Vlist wrote to mark lewis:

MvdV>> Hmmm... that gives me litle information on what I can do about
MvdV>> it.

ml> technically speaking, there is nothing you can do when the remote
ml> end forces the connection closed...

MvdV> Presently I seem to be the only one with this problem, so it
MvdV> would seem that I am not doing what the others do...

it is possible... i just polled each of the three given addresses (1L120/544,
2:280/19, 2:280/1016) with no problems...

[trim]

MvdV> Perhaps I stumbled on a bug in 1.1a49?

i don't know... probably not... i'm running the following...

2014-02-13 04:00:45 BNKDWRAP VER : Binkd 1.1a-40 (Jan 4 2014 01:00:09/OS2)
2014-02-13 04:00:53 BNKDWRAP EXTRA : Compilation flags: gcc (klibc), zlib,
bzlib2, https, ntlm, amiga_4d_outbound, bwlim.
2014-02-13 04:00:54 BNKDWRAP EXTRA : Facilities: fsp1035 rfc2553emu


above, at the top, you mention that you might not be doing what others are
doing... with that in mine, here's how i set my connection stuff in my
binkd.cfg... the very last section after all other settings is where i set up
for the connections with other machines... it reads like so...

<<snip>>
#######################################
# #
# set up the default node options and #
# include conns.txt and binkd.txt #
# #
#######################################
defnode * -nr
include conns.txt
include binkd.txt
<EoF>

defnode sets non-reliable for all nodes not otherwise configured or listed...

conns.txt contains the systems i connect to with their session paswords,
fileboxes and any other options like -md and the delivery flavor options...
none of the entries have anything set in the -options column (3rd)... no -nr,
no -nd, no -md, no -nomd and no -ip...

binkd.txt is the distributed binkd.txt compiled from the nodlist...


i list my connections and binkd files as include because it is much easier to
update just them and let binkd detect the change and reload them... i can
change either file externally at any time and binkd will detect it in about 60
seconds (based on the rescan-delay setting IIRC)...

HTH

)\/(ark

[mark lewis]

On Sat, 15 Feb 2014, Michiel van der Vlist wrote to mark lewis:

MvdV>> Hmmm... that gives me litle information on what I can do about
MvdV>> it.

ml> technically speaking, there is nothing you can do when the remote
ml> end forces the connection closed...

MvdV> Presently I seem to be the only one with this problem, so it
MvdV> would seem that I am not doing what the others do...

it is possible... i just polled each of the three given addresses (1:120/544,
2:280/19, 2:280/1016) with no problems...

[trim]

MvdV> Perhaps I stumbled on a bug in 1.1a49?

i don't know... probably not... i'm running the following...

BNKDWRAP VER : Binkd 1.1a-40 (Jan 4 2014 01:00:09/OS2)
BNKDWRAP EXTRA : Compilation flags: gcc (klibc), zlib, bzlib2, https, ntlm,
amiga_4d_outbound, bwlim.
BNKDWRAP EXTRA : Facilities: fsp1035 rfc2553emu

[oops! just noticed i'm at 1.1a-40... i thought i was up to at least a48...]

above, at the top, you mention that you might not be doing what others are
doing... with that in mine, here's how i set my connection stuff in my
binkd.cfg... the very last section after all other settings is where i set up
for the connections with other machines... it reads like so...

<<snip>>
#######################################
# #
# set up the default node options and #
# include conns.txt and binkd.txt #
# #
#######################################
defnode * -nr
include conns.txt
include binkd.txt
<EoF>

defnode sets non-reliable for all nodes not otherwise configured or listed...

conns.txt contains the systems i connect to with their session paswords,
fileboxes and any other options like -md and the delivery flavor options...
none of the entries have anything set in the -options column (3rd)... no -nr,
no -nd, no -md, no -nomd and no -ip...

binkd.txt is the distributed binkd.txt compiled from the nodlist...


i list my connections and binkd files as include because it is much easier to
update just them and let binkd detect the change and reload them... i can
change either file externally at any time and binkd will detect it in about 60
seconds (based on the rescan-delay setting IIRC)...

HTH

)\/(ark

[Michiel van der Vlist]

Hello mark,

On Sunday February 16 2014 13:58, you wrote to me:

MvdV>> Presently I seem to be the only one with this problem, so it
MvdV>> would seem that I am not doing what the others do...

ml> it is possible... i just polled each of the three given addresses
ml> (1:120/544, 2:280/19, 2:280/1016) with no problems...

So there seems to be a problem, some have it, some don't but so far we have not
discovered why only some have it and others dont'...

MvdV>> Perhaps I stumbled on a bug in 1.1a49?

ml> i don't know... probably not... i'm running the following...

Since the problems (so far) only emerge with mbcico, it looks like an
incompatibility problem. Since Irex does not have the problem and Irex atiaclly
does binkp 1.0, I speculate that it has something to do with binkp v 1.1

Perhaps we should ask the binkd team to add an option to force binkd to make a
1.0 connect....

ml> #######################################
ml> defnode * -nr
ml> include conns.txt
ml> include binkd.txt
ml> <EoF>

Mine is not much different.

ml> defnode sets non-reliable for all nodes not otherwise configured or
ml> listed...

I don't have that, but it is not relevant as the problem node in question is in
the config.

ml> conns.txt contains the systems i connect to with their session
ml> paswords, fileboxes and any other options like -md and the delivery
ml> flavor options...

Same here, except that I call it nodes.cfg

ml> binkd.txt is the distributed binkd.txt compiled from the nodlist...

I don't use that, I have set the root domain to binkp.net.

Also irrelevant as the node in question is in nodes.cfg.

ml> i list my connections and binkd files as include because it is much
ml> easier to update just them and let binkd detect the change and reload
ml> them... i can change either file externally at any time and binkd will
ml> detect it in about 60 seconds (based on the rescan-delay setting
ml> IIRC)...

Same here.


Cheers, Michiel

[mark lewis]

On Mon, 17 Feb 2014, Michiel van der Vlist wrote to mark lewis:

MvdV> Since the problems (so far) only emerge with mbcico, it looks
MvdV> like an incompatibility problem. Since Irex does not have the
MvdV> problem and Irex atiaclly does binkp 1.0, I speculate that it has
MvdV> something to do with binkp v 1.1

MvdV> Perhaps we should ask the binkd team to add an option to force
MvdV> binkd to make a 1.0 connect....

it is a possibility but how would we specify that on the command line driven
poll or specify it in the nodelist so that it will be used by the scripts that
create the binkd.txt file from the nodelist?

ml> #######################################
ml> defnode * -nr
ml> include conns.txt
ml> include binkd.txt
ml> <EoF>

MvdV> Mine is not much different.

ml> defnode sets non-reliable for all nodes not otherwise configured or
ml> listed...

MvdV> I don't have that, but it is not relevant as the problem node in
MvdV> question is in the config.

none of the nodes are in my configs other than the plain entry in binkd.txt
generated from the nodelist... this may be relevent because i understand that
setting an item and not overriding it later leaves the item set...

have you tried adding -nr to the node's entry in your nodes.cfg? it would be
the 3rd column of the entry...

eg:
node 2:280/***@fidonet -nr theirdomain flavour - -

flavour would be - for normal, c for crash, h for hold, d for direct... the
last two dashes may not be used if you don't use fileboxes... they are for the
outbox and inbox if you do use fileboxes or i think the dashes may tell binkd
to use the common BSO outbound...

theirdomain may be a dash if one loads binkd.txt after their "nodes.cfg"
file... that way the nodelist entry for their entry, as generated from the
nodelist, will be used... the key here and above is that later items in the
same field will override the ones already set previously... IIRC...

since you don't use the distributed binkd.txt, the above line should be pretty
close to what you may have for that system...

aside: i am not aware of any way to load more than one -option in the 3rd
column... it may be possible that each is space separated and leads with a '-'
but i've never attempted an entry like

node 2:280/***@fidonet -nr -md theirdomain flavour - -

so i don't know if this is possible or not...

[ASIDE]
one thing that has me (slightly) worried is that there has been no response
from the binkd developers/maintainers in this area since this topic was
started... after the number of posts and the days during this discussion, it
would seem that at least one of them would say something on this situation... i
understand that some parts of the area over there are having a pretty nasty
conflict to deal with, though... however, i didn't think that it emcompassed
all of the developers/maintainers countries :/
[/ASIDE]

)\/(ark

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

[Nicholas Boel]

Hello mark,

On 17 Feb 14 18:46, mark lewis wrote to Michiel van der Vlist:

ml> aside: i am not aware of any way to load more than one -option in the
ml> 3rd column... it may be possible that each is space separated and
ml> leads with a '-' but i've never attempted an entry like

ml> node 2:280/***@fidonet -nr -md theirdomain flavour - -

ml> so i don't know if this is possible or not...

Yep, that's completely possible. I usually use either "-md -nr" or "-md -nd"
as I choose to not use the defnode option.

Regards,
Nick

[mark lewis]

On Tue, 18 Feb 2014, Nicholas Boel wrote to mark lewis:

ml> aside: i am not aware of any way to load more than one -option in the
ml> 3rd column... it may be possible that each is space separated and
ml> leads with a '-' but i've never attempted an entry like

ml> node 2:280/***@fidonet -nr -md theirdomain flavour - -

ml> so i don't know if this is possible or not...

NB> Yep, that's completely possible. I usually use either "-md -nr" or
NB> "-md -nd" as I choose to not use the defnode option.

i've always used defnode and never had any problems... if i understand
correctly, this also means that all my connections are -nr since i do not
override it in any of my entries... i've never found a need to force -md or -nd
or anything else...

)\/(ark

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

[Nicholas Boel]

Hello mark,

On 18 Feb 14 09:05, mark lewis wrote to Nicholas Boel:

ml> i've always used defnode and never had any problems... if i understand
ml> correctly, this also means that all my connections are -nr since i do
ml> not override it in any of my entries... i've never found a need to
ml> force -md or -nd or anything else...

As far as I know, the "-md" option only creates more secure connections by
using CRAM-MD5. I'd rather use encrypted password over plain text ones, is
all.

Regards,
Nick

[mark lewis]

On Tue, 18 Feb 2014, Nicholas Boel wrote to mark lewis:

ml> i've always used defnode and never had any problems... if i
ml> understand correctly, this also means that all my connections are
ml> -nr since i do not override it in any of my entries... i've never
ml> found a need to force -md or -nd or anything else...

NB> As far as I know, the "-md" option only creates more secure
NB> connections by using CRAM-MD5. I'd rather use encrypted password
NB> over plain text ones, is all.

the mailers are supposed to negotiate the best connection using the most secure
method... trying to force a mode on a system that doesn't support that mode
will cause problems... i'm a big fan of letting automation perform its tasks
and keeping the fumbling human factor out of the process once it is fully
operational ;)

)\/(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 13:55, you wrote to Nicholas Boel:

ml> On Tue, 18 Feb 2014, Nicholas Boel wrote to mark lewis:

NB>> As far as I know, the "-md" option only creates more secure
NB>> connections by using CRAM-MD5. I'd rather use encrypted password
NB>> over plain text ones, is all.

ml> the mailers are supposed to negotiate the best connection using the
ml> most secure method... trying to force a mode on a system that doesn't
ml> support that mode will cause problems... i'm a big fan of letting
ml> automation perform its tasks and keeping the fumbling human factor out
ml> of the process once it is fully operational ;)

Agreed. Letting the mailers figure it out by themselves is the preferred
method. That is why it puzzles me why you enforce -nr mode by default. Can you
elaborate on that choice?

Having said that: There may be circumstances why one would not let the mailers
figure it out by themselves. For example when there is a known problem that can
be worked around by forcing a less than optimal mode. Forcing 1.0 mode when a
negotiated 1.1 mode would not work. But of course that would be done a a per
node basis, never in the defnode statement.


Cheers, Michiel

[mark lewis]

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

ml> On Tue, 18 Feb 2014, Nicholas Boel wrote to mark lewis:

NB>> As far as I know, the "-md" option only creates more secure
NB>> connections by using CRAM-MD5. I'd rather use encrypted password
NB>> over plain text ones, is all.

ml> the mailers are supposed to negotiate the best connection using the
ml> most secure method... trying to force a mode on a system that doesn't
ml> support that mode will cause problems... i'm a big fan of letting
ml> automation perform its tasks and keeping the fumbling human factor out
ml> of the process once it is fully operational ;)

MvdV> Agreed. Letting the mailers figure it out by themselves is the
MvdV> preferred method. That is why it puzzles me why you enforce -nr
MvdV> mode by default. Can you elaborate on that choice?

the thinking is/was for unknown systems... it just seemed prudent to set them
as non-reliable since i did/do not know what their reliability status or factor
is... i set this all up way way back when binkd .4 or .5 was the available
version not long after it first appeared... i'm not aware of anything in
particular that setting -nr may cause problems with... i may be missing
something, though... it was a long time back when i set it up and the docs were
not easy to understand back then... altavista translate was about all that was
available to even attempt translations with...

MvdV> Having said that: There may be circumstances why one would not
MvdV> let the mailers figure it out by themselves. For example when
MvdV> there is a known problem that can be worked around by forcing a
MvdV> less than optimal mode. Forcing 1.0 mode when a negotiated 1.1
MvdV> mode would not work. But of course that would be done a a per
MvdV> node basis, never in the defnode statement.

true :)

)\/(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:32, you wrote to me:

MvdV>> Agreed. Letting the mailers figure it out by themselves is the
MvdV>> preferred method. That is why it puzzles me why you enforce -nr
MvdV>> mode by default. Can you elaborate on that choice?

ml> the thinking is/was for unknown systems... it just seemed prudent to
ml> set them as non-reliable since i did/do not know what their
ml> reliability status or factor is...

This link here:
http://www.doe.carleton.ca/~nsoveiko/fido/binkd/man/binkd.man.html

Says this about the -nr option:


-nr

stands for Non Reliable link mode, this works only on outbound calls with
another mailer supporting this option (e.g. binkd/0.9+). It forces binkd to
turn off the protocol optimisation that is based on assumption that TCP/IP
connections are rarely aborted. Essentially, it sets file window size to one
and mandates desired file offset to be requested by the transmitting side, so
that there is protocol resync at the beginning of transmission of each file.
The option solves the only problem with binkd having not enough time to start
receiving file from non-zero offset before IP link is down. So don't use it
unless you have this problem -- it's really not effective.


From how I read it, I gather that setting it as a default is eh... not
recommended.

ml> i set this all up way way back when binkd .4 or .5 was the available
ml> version not long after it first appeared... i'm not aware of anything
ml> in particular that setting -nr may cause problems with...

If the other side does not support it, the connection will fail..

ml> i may be missing something, though... it was a long time back when i
ml> set it up and the docs were not easy to understand back then...
ml> altavista translate was about all that was available to even attempt
ml> translations with...

I see...

MvdV>> Having said that: There may be circumstances why one would not
MvdV>> let the mailers figure it out by themselves. For example when
MvdV>> there is a known problem that can be worked around by forcing a
MvdV>> less than optimal mode. Forcing 1.0 mode when a negotiated 1.1
MvdV>> mode would not work. But of course that would be done a a per
MvdV>> node basis, never in the defnode statement.

ml> true :)

So we agree. This is becoming a habit.... ;-)


Cheers, Michiel

[mark lewis]

On Tue, 25 Feb 2014, Michiel van der Vlist wrote to mark lewis:

ml> the thinking is/was for unknown systems... it just seemed prudent
ml> to set them as non-reliable since i did/do not know what their
ml> reliability status or factor is...

MvdV> This link here:
MvdV> http://www.doe.carleton.ca/~nsoveiko/fido/binkd/man/binkd.man.htm
MvdV> l

MvdV> Says this about the -nr option:

[trim]

wow! that's the easiest to read and understand explanation i've read for that
option... it looks like there has been some documentation work done over the
years ;)

reading that, i remembered another factor that might have influenced my use of
the -nr option... we're way out in the country and our DSL lines get
troublesome at times... at least until we wring the water or blown the dust out
of them... either way, they get noisy and the connection can bounce up and down
at times... when the IP changes is one thing but sometimes i get the same IP
back... if there's a binkp transfer going on, i don't want to have problems
with partially sent files that get jammed up... i don't know if -nr would be
used for this but it is a scenario where the tcp/ip connection is dropped in
the middle of a transfer...

MvdV> From how I read it, I gather that setting it as a default is
MvdV> eh... not recommended.

ml> i set this all up way way back when binkd .4 or .5 was the
ml> available version not long after it first appeared... i'm not
ml> aware of anything in particular that setting -nr may cause
ml> problems with...

MvdV> If the other side does not support it, the connection will
MvdV> fail..

ahhh... i was thinking that it would be requested like other options and either
agreed on being used or not...

ml> i may be missing something, though... it was a long time back
ml> when i set it up and the docs were not easy to understand back
ml> then... altavista translate was about all that was available to
ml> even attempt translations with...

MvdV> I see...

yeah, it was quite a while back... i'm still working on translating the Taurus
docs every once in a while... it isn't so easy because i have to do each
sentence or paragraph at a time to be able to paste it back into the web
page... using a translator it isn't as "clean" but after it has been
translated, then i plan on going back and cleaning it up so that it is
"smoother" and easier to follow...

MvdV>> Having said that: There may be circumstances why one would not
MvdV>> let the mailers figure it out by themselves. For example when
MvdV>> there is a known problem that can be worked around by forcing a
MvdV>> less than optimal mode. Forcing 1.0 mode when a negotiated 1.1
MvdV>> mode would not work. But of course that would be done a a per
MvdV>> node basis, never in the defnode statement.

ml> true :)

MvdV> So we agree. This is becoming a habit.... ;-)

;) ;)

)\/(ark

[Nicholas Boel]

Hello Michiel,

On 25 Feb 14 00:50, Michiel van der Vlist wrote to mark lewis:

MV> Says this about the -nr option:

MV> -nr

MV> stands for Non Reliable link mode, this works only on outbound calls
MV> with another mailer supporting this option (e.g. binkd/0.9+). It
MV> forces binkd to turn off the protocol optimisation that is based on
MV> assumption that TCP/IP connections are rarely aborted. Essentially, it
MV> sets file window size to one and mandates desired file offset to be
MV> requested by the transmitting side, so that there is protocol resync
MV> at the beginning of transmission of each file. The option solves the
MV> only problem with binkd having not enough time to start receiving file
MV> from non-zero offset before IP link is down. So don't use it unless
MV> you have this problem -- it's really not effective.

MV> From how I read it, I gather that setting it as a default is eh... not
MV> recommended.

While it may not be recommended for every link, have you tried it with the
links that are failing for you?

"The option solves the only problem with binkd having not enough time to start
receiving file from non-zero offset before IP link is down."

Sounds like something that could very well be happening in your case.

Regards,
Nick

[Michiel van der Vlist]

Hello Nicholas,

On Tuesday February 25 2014 17:40, you wrote to me:

MV>> -nr

MV>> stands for Non Reliable link mode, this works only on outbound
MV>> calls with another mailer supporting this option (e.g.
[..]
MV>> file from non-zero offset before IP link is down. So don't use it
MV>> unless you have this problem -- it's really not effective.

MV>> From how I read it, I gather that setting it as a default is
MV>> eh... not recommended.

NB> While it may not be recommended for every link, have you tried it with
NB> the links that are failing for you?

Yes, I tried. Made no difference that I could see.

NB> "The option solves the only problem with binkd having not enough time
NB> to start receiving file from non-zero offset before IP link is down."

NB> Sounds like something that could very well be happening in your case.

Maybe, but as I said, using the -nr option did not solve my problem.


Cheers, Michiel

[Michiel van der Vlist]

Hello mark,

On Monday February 17 2014 18:46, you wrote to me:

MvdV>> Perhaps we should ask the binkd team to add an option to force
MvdV>> binkd to make a 1.0 connect....

ml> it is a possibility but how would we specify that on the command line
ml> driven poll or specify it in the nodelist so that it will be used by
ml> the scripts that create the binkd.txt file from the nodelist?

Forcing 1.0 mode would only be used for those nodes that have problems. No, it
should not be in the nodelist. A flag to tell the world if the node in question
supports 1.1 does no good. The suspicion is that there is an incompatibility
between mbcico and the windows version of binkd. Advertising 1.1 capability in
the nodelist does nt help to work around the problem. What I suggest is an
override that can be set on an individual node.

So it should be a switch for the node keyword in binkd.cfg

Something like:

node 19 -10 -nr binkp.dreamlandbbs.com password

MvdV>> I don't have that, but it is not relevant as the problem node
MvdV>> in question is in the config.

ml> none of the nodes are in my configs other than the plain entry in
ml> binkd.txt generated from the nodelist...

How about passwords?

ml> this may be relevent because i understand that setting an item and not
ml> overriding it later leaves the item set...

That is my understandig too.

ml> have you tried adding -nr to the node's entry in your nodes.cfg? it
ml> would be the 3rd column of the entry...

Yes, I tried that. Makes no difference.

ml> aside: i am not aware of any way to load more than one -option in the
ml> 3rd column... it may be possible that each is space separated and
ml> leads with a '-' but i've never attempted an entry like

ml> node 2:280/***@fidonet -nr -md theirdomain flavour - -
ml> so i don't know if this is possible or not...


According to
http://www.doe.carleton.ca/~nsoveiko/fido/binkd/man/binkd.man.html#config.node

That should be kosher

[Wilfred van Velzen]

Hi Michiel,

On 2014-02-19 12:22:52, you wrote to mark lewis:

MvdV> The suspicion is that there is an incompatibility between mbcico and
MvdV> the windows version of binkd.

Kees has the same problem (or so it seems) with the linux version of binkd.

Bye, Wilfred.

[Michiel van der Vlist]

Hello Wilfred,

On Wednesday February 19 2014 13:45, you wrote to me:

MvdV>> The suspicion is that there is an incompatibility between
MvdV>> mbcico and the windows version of binkd.

WV> Kees has the same problem (or so it seems) with the linux version of
WV> binkd.

The problem looks the same, but I am not sure if it is...


Cheers, Michiel

[mark lewis]

On Wed, 19 Feb 2014, Michiel van der Vlist wrote to mark lewis:

MvdV>> I don't have that, but it is not relevant as the problem node
MvdV>> in question is in the config.

ml> none of the nodes are in my configs other than the plain entry in
ml> binkd.txt generated from the nodelist...

MvdV> How about passwords?

i do not have any sessions with the three systems that i polled... since i
don't have sessions with them, i don't have passwords for them... they are bare
random nodes from the nodelist as far as my system knows... it get all their
contact info from some form of nodelist... either the actual FTN St. Loius
format nodelist or (currently) the distributed binkd.txt nodelist created from
the St. Louis nodelist via a perl script...

ml> this may be relevent because i understand that setting an item and not
ml> overriding it later leaves the item set...

MvdV> That is my understandig too.

ml> have you tried adding -nr to the node's entry in your nodes.cfg? it
ml> would be the 3rd column of the entry...

MvdV> Yes, I tried that. Makes no difference.

interesting...

ml> aside: i am not aware of any way to load more than one -option in the
ml> 3rd column... it may be possible that each is space separated and
ml> leads with a '-' but i've never attempted an entry like

ml> node 2:280/***@fidonet -nr -md theirdomain flavour - -
ml> so i don't know if this is possible or not...


MvdV> According to
MvdV> http://www.doe.carleton.ca/~nsoveiko/fido/binkd/man/binkd.man.htm
MvdV> l#config.node

MvdV> That should be kosher

someone else, nick i think, confirmed this, too... i've never needed anything
in that "3rd column" so i've never messed with it... apparently my defnode
entry with -nr is propogated to all nodes because it is not overridden
elsewhere... that based on the above override understanding that we seem to
agree on...

i have not had a chance to record a session with the system you first reported
having a problem with... i don't see a need unless i can reproduce the
problem... unfortunately, i cannot with my current OS/2 binkd version (which i
still need/want) to update and see if it breaks then...

)\/(ark

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

[mark lewis]

On Mon, 17 Feb 2014, Michiel van der Vlist wrote to mark lewis:

MvdV> Since the problems (so far) only emerge with mbcico, it looks
MvdV> like an incompatibility problem. Since Irex does not have the
MvdV> problem and Irex atiaclly does binkp 1.0, I speculate that it has
MvdV> something to do with binkp v 1.1

MvdV> Perhaps we should ask the binkd team to add an option to force
MvdV> binkd to make a 1.0 connect....

i forgot to mention in my previous reply but really, those having the problem
should see about capturing the network traffic for the failing conversations so
the traffic can be analyzed... this is really the only and best way to figure
out the problem... a failing conversation needs to be analyzed...

for those with a *nix box directly between them and the internet (aka their
firewall), they should be able to use tcpdump to capture the full
conversation... those on winwhatever boxen can use wireshark to do the capture
and analysis... i tend to use wireshark for the analysis and perusal of the
pcap (packet capture) file anyway...

)\/(ark

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

[Tommi Koivula]

MvdV> + 22:11 [412] Remote has 0b of mail and 0b of files for us
MvdV> ? 22:11 [412] recv: {W32 API error 10054} An existing connection was
MvdV> forcibly closed by the remote host
MvdV> + 22:11 [412] done (to 2:280/***@fidonet, failed, S/R: 0/0 (0/0 bytes))
MvdV> 22:11 [412] restoring poll with `c' flavour
MvdV> 22:11 [412] session closed, quitting...

MvdV> Does anyone else have this problem with him?

[6072] BEGIN, binkd/1.1a-49/CYGWIN_NT-5.1 -pP 280/19 binkd.cfg
[6072] creating a poll for 2:280/***@fidonet (`d' flavour)
[6072] clientmgr started
[5076] call to 2:280/***@fidonet
[5076] trying f19.n280.z2.binkp.net [213.126.141.188]...
[5076] connected
[5076] outgoing session with ip-213-126-141-188.ip.prioritytele
[5076] OPT CRAM-MD5-ecb722f8949f400b89b0f671c391540c
[5076] Remote requests MD mode
[5076] SYS Dreamland BBS
[5076] ZYZ Lukas de Groen
[5076] LOC Houten - The Netherlands
[5076] NDL CM,XX,IBN,IFC,IFT,ITN
[5076] TIME Sat, 15 Feb 2014 16:26:30 +0100
[5076] VER mbcico/0.95.13/GNU/Linux-x86_64 binkp/1.1
[5076] PHN 213.126.141.188
[5076] OPM Dreamland BBS, your great source for files!
[5076] addr: 2:280/***@fidonet
[5076] addr: 2:280/***@fidonet
[5076] addr: 110:30/***@linuxnet (n/a or busy)
[5076] addr: 115:31/***@pascalnet (n/a or busy)
[5076] addr: 115:31/***@pascalnet (n/a or busy)
[5076] addr: 115:3100/***@pascalnet (n/a or busy)
[5076] addr: 115:3100/***@pascalnet (n/a or busy)
[5076] OPT EXTCMD GZ BZ2 PLZ
[5076] Remote supports EXTCMD mode
[5076] Remote supports GZ mode
[5076] Remote supports BZ2 mode
[5076] TRF 0 0
[5076] Remote has 0b of mail and 0b of files for us
[5076] done (to 2:280/***@fidonet, OK, S/R: 0/0 (0/0 bytes))
[5076] session closed, quitting...
[6072] rc(5076)=0
[6072] the queue is empty, quitting...

No problems, using:

Binkd 1.1a-49 (Feb 15 2014 17:23:20/CYGWIN_NT-5.1)
Compilation flags: gcc, zlib, bzlib2, https, ntlm, amiga_4d_outbound,
bwlim. Facilities: fsp1035 ipv6

'Tommi

[Nicholas Boel]

Hello Tommi,

On 15 Feb 14 17:31, Tommi Koivula wrote to Michiel van der Vlist:

TK> [5076] Remote has 0b of mail and 0b of files for us
TK> [5076] done (to 2:280/***@fidonet, OK, S/R: 0/0 (0/0 bytes))
TK> [5076] session closed, quitting...
TK> [6072] rc(5076)=0
TK> [6072] the queue is empty, quitting...

TK> No problems, using:

TK> Binkd 1.1a-49 (Feb 15 2014 17:23:20/CYGWIN_NT-5.1)
TK> Compilation flags: gcc, zlib, bzlib2, https, ntlm, amiga_4d_outbound,
TK> bwlim. Facilities: fsp1035 ipv6

While reporting the same issue with another mbcico system, I've noticed that
my manual polls work just fine with the link I'm referring to (1:120/544).
Though every Wednesday when my nodelist segment goes out via filebox, there
are errors connecting to his system. I'll save my binkd logs for next week
and see what errors I'm receiving.

For the record, when connecting to an mbcico system, it says "Remote requests
NR mode" while I had the "-nd" option enabled. I have switched this option to
"-nr" instead and will see if the error stops as well. It has been pretty
consistant over the past few months, but I didn't make a big deal of it
because eventually (within 10 failed connections) there would be one
successful one finally.

I'm willing to bet it has something to do with the "-nd" option though, since
that's where I've had issues in the past with other systems. I believe that
option is also documented to NOT work with all systems, either.. so I'm not
putting blame anywhere yet besides my own configuration.

Regards,
Nick

[Michiel van der Vlist]

Hello All,

The plot thickens. I get the same error with 2:280/1016:


+ 21:17 [2364] call to 2:280/***@fidonet
21:17 [2364] trying f1016.n280.z2.binkp.net [188.142.112.203]...
21:17 [2364] connected
+ 21:17 [2364] outgoing session with 188.142.112.203
- 21:17 [2364] OPT PLZ CRAM-MD5-0336e32d25677830a5bb62c7db623d40
+ 21:17 [2364] Remote requests MD mode
- 21:17 [2364] SYS bbs.bredenbeek.net
- 21:17 [2364] ZYZ Jan Bredenbeek
- 21:17 [2364] LOC Hilversum, NL
- 21:17 [2364] NDL MO,CM,XA,IBN,IFC,ITN
- 21:17 [2364] TIME Sat, 15 Feb 2014 21:17:04 +0100
- 21:17 [2364] VER mbcico/0.50.0/GNU/Linux-i386 binkp/1.1
- 21:17 [2364] PHN -unpublished-
- 21:17 [2364] OPM SYNCNET BBS
+ 21:17 [2364] addr: 2:280/***@fidonet
- 21:17 [2364] TRF 0 0
+ 21:17 [2364] Remote has 0b of mail and 0b of files for us
? 21:17 [2364] recv: {W32 API error 10054} An existing connection was forcibly
c
he remote host
+ 21:17 [2364] done (to 2:280/***@fidonet, failed, S/R: 0/0 (0/0 bytes))
21:17 [2364] restoring poll with `d' flavour
21:17 [2364] session closed, quitting...
21:17 [988] the queue is empty, quitting...



Cheers, Michiel

[Kees van Eeten]

Hello Michiel!

15 Feb 14 21:22, you wrote to All:

MvdV> Hello All,

MvdV> The plot thickens. I get the same error with 2:280/1016:

As I told you in a private mail, I get this error as well, but not with
connection to 2:280/1027.

I have net yet tried to change the encryption mode as Nicholas suggested,
but.

MvdV> + 21:17 [2364] call to 2:280/***@fidonet
MvdV> 21:17 [2364] trying f1016.n280.z2.binkp.net [188.142.112.203]...
MvdV> 21:17 [2364] connected
MvdV> + 21:17 [2364] outgoing session with 188.142.112.203
MvdV> - 21:17 [2364] OPT PLZ CRAM-MD5-0336e32d25677830a5bb62c7db623d40
MvdV> + 21:17 [2364] Remote requests MD mode
MvdV> - 21:17 [2364] SYS bbs.bredenbeek.net
MvdV> - 21:17 [2364] ZYZ Jan Bredenbeek
MvdV> - 21:17 [2364] LOC Hilversum, NL
MvdV> - 21:17 [2364] NDL MO,CM,XA,IBN,IFC,ITN
MvdV> - 21:17 [2364] TIME Sat, 15 Feb 2014 21:17:04 +0100
MvdV> - 21:17 [2364] VER mbcico/0.50.0/GNU/Linux-i386 binkp/1.1
MvdV> - 21:17 [2364] PHN -unpublished-
MvdV> - 21:17 [2364] OPM SYNCNET BBS
MvdV> + 21:17 [2364] addr: 2:280/***@fidonet
MvdV> - 21:17 [2364] TRF 0 0
MvdV> + 21:17 [2364] Remote has 0b of mail and 0b of files for us
MvdV> ? 21:17 [2364] recv: {W32 API error 10054} An existing connection was
MvdV> forcibly c he remote host + 21:17 [2364] done (to 2:280/***@fidonet,
MvdV> failed, S/R: 0/0 (0/0 bytes)) 21:17 [2364] restoring poll with `d'
MvdV> flavour
MvdV> 21:17 [2364] session closed, quitting... 21:17 [988] the queue is empty,
MvdV> quitting...

The mbse that is connected here 0.50.0/GNU/Linux-i386 does not support
encryption mode, at least it does not show in this session header,
however the session shutdown always occurs when the calling host goes
into receive mode. Outgoing mail is always handled properly prior to
this switch. I cannot recall what happens when to other side offers a file,
but I have a faint recollection, that the sudden shutdown is the after that
file transfer.

Kees