Hello All!

just in case, if qico runs in xinetd with -a auto, then binkp clients stale, this is a bug in binkd

----- msged.txt begins -----
Date: 2018-01-29 08:01:20
From: Benny Pedersen of 2:230/0
To: Sergey Poziturin
Subj: hotdoged stopped ...
Attr: Snt Loc Scn
Conf: HOTDOGED

Hello Sergey!

18 Oct 2017 09:14, Sergey Poziturin wrote to Benny Pedersen:

no more possible for me to use it, it try to dial me, but no files
transfered :/

How did this happen?

found the qico bug:

/usr/sbin/qico -a auto
/usr/sbin/qico -a binkp

only the last one works

so binkp protocol clients does not always work with autodetect in qico, so i loose emsi on same port as binkp

----- qico begins -----
service binkp
{
disable = no
protocol = tcp
flags = IPv4
port = 24554
socket_type = stream
wait = no
user = xpoint
server = /usr/sbin/qico
server_args = -a binkp
}
----- qico ends -----

works :=)

wonder if thats same problem i have with aftershook ?

Hmm.

hope its not the problem

note 2:230/0 is now supporting ipv6


----- msged.txt ends -----

Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.9.76-gentoo-r1 (i686))
* Origin: I will always keep a PC running CPM 3.0 (2:230/0)

Hello Benny,

Tuesday January 30 2018, Benny Pedersen wrote to All:

just in case, if qico runs in xinetd with -a auto, then binkp clients stale, this is a bug in binkd

^^^^^^^^^^^^

It is rather in qico.


Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20170303
* Origin: Moscow, Russia (2:5020/1042)

Hello Benny,

On Tuesday January 30 2018 13:47, you wrote to All:

just in case, if qico runs in xinetd with -a auto, then binkp clients stale, this is a bug in binkd

No, it is not a bug. You are trying to make it do it was never designed for.

so binkp protocol clients does not always work with autodetect in
qico, so i loose emsi on same port as binkp

Of course it does not work. Binkp was never designed to share a port. Like most
protocols, it was designed to have a port of its own.

The solution is easy: forget about EMSI. Binkp was optimized for use over IP, EMSI was not. Who needs EMSI when you have binkp?

Cheers, Michiel

...I am not a member of the more is better club.

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.eu (2:280/5555)

Hello Michiel!

30 Jan 18 14:46, you wrote to Benny Pedersen:

just in case, if qico runs in xinetd with -a auto, then binkp clients
stale, this is a bug in binkd

MvdV> No, it is not a bug. You are trying to make it do it was never designed
MvdV> for.

so binkp protocol clients does not always work with autodetect in
qico, so i loose emsi on same port as binkp

MvdV> Of course it does not work. Binkp was never designed to share a port.
MvdV> Like most protocols, it was designed to have a port of its own.

MvdV> The solution is easy: forget about EMSI. Binkp was optimized for use
MvdV> over IP, EMSI was not. Who needs EMSI when you have binkp?

I think you are confusing the matter. The way I would implement the auto
detect, is to look at the fingerprint of waht comes in first. Does it look
like a binkp or like an EMSI handshake and switch accordingly.

qico should probably just needs an upgrade in its protocol recognistion.

I think we have had more or less the same with an other mailer, where the
calling system had to make shure that a lower version of the binkp protocol
should be used.

But the workaround is there, don't use auto but diffrent port instead. ;))

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hello Michael!

30 Jan 2018 16:09, Michael Dukelsky wrote to Benny Pedersen:

just in case, if qico runs in xinetd with -a auto, then binkp clients
stale, this is a bug in binkd

^^^^^^^^^^^^

It is rather in qico.

binkd timeout ?

binkd client to binkd server no problem, but that does imho not mean its not any problems in binkd client code

i am happy if its only a qico problem, so others can ignore it :/


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.9.76-gentoo-r1 (i686))
* Origin: I will always keep a PC running CPM 3.0 (2:230/0)

Hello Michiel!

30 Jan 2018 14:46, Michiel van der Vlist wrote to Benny Pedersen:

MvdV> No, it is not a bug. You are trying to make it do it was never
MvdV> designed for.

i will not take that debat here, you fail aswell here

MvdV> Of course it does not work. Binkp was never designed to share a
MvdV> port. Like most protocols, it was designed to have a port of its
MvdV> own.

correct binkp was never designed for other then binkp, true

but qico have always supported multiple protocols on same port

MvdV> The solution is easy: forget about EMSI. Binkp was optimized for use
MvdV> over IP, EMSI was not. Who needs EMSI when you have binkp?

with that rule i could easely take out AAAA in my fidonet hostname

be carefull


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.9.76-gentoo-r1 (i686))
* Origin: I will always keep a PC running CPM 3.0 (2:230/0)

Hello Benny,

Tuesday January 30 2018, Benny Pedersen wrote to Michael Dukelsky:

just in case, if qico runs in xinetd with -a auto, then binkp
clients stale, this is a bug in binkd

^^^^^^^^^^^^
It is rather in qico.

binkd timeout ?

binkd client to binkd server no problem, but that does imho not mean
its not any problems in binkd client code

i am happy if its only a qico problem, so others can ignore it :/

If the same problem is with other binkp clients (for example Hotdoged, Aftershock) and qico server, then it is rather a problem in qico, isn't it?

Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20170303
* Origin: Moscow, Russia (2:5020/1042)

Hello Kees!

30 Jan 2018 15:40, Kees van Eeten wrote to Michiel van der Vlist:

But the workaround is there, don't use auto but diffrent port
instead. ;))

and its still not proved its a qico bug, i just showed a working work around the problem

i could try bforce if it compiles, or ifcico, dont know if it matter


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.9.76-gentoo-r1 (i686))
* Origin: I will always keep a PC running CPM 3.0 (2:230/0)

Hello Michael!

30 Jan 2018 18:45, Michael Dukelsky wrote to Benny Pedersen:

If the same problem is with other binkp clients (for example Hotdoged, Aftershock) and qico server, then it is rather a problem in qico,
isn't it?

if binkd stale on that fail in qico, then its binkd bug aswell as in qico itself

if it just timeout with that bug in qico, there is no bug in binkd


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.9.76-gentoo-r1 (i686))
* Origin: I will always keep a PC running CPM 3.0 (2:230/0)

Hello Benny!

30 Jan 18 19:09, you wrote to me:

But the workaround is there, don't use auto but diffrent port
instead. ;))

and its still not proved its a qico bug, i just showed a working work around the problem

Indeed.

i could try bforce if it compiles, or ifcico, dont know if it matter

I do not know about bforce, ifcico does not support binkp and mbcico from
the mbse package cannot distinguish between binkp and emsi.
A different paramater is given from inetd or xinetd and two portnumbers are
used. Neither ifcico nor mbcico can listen on a port directly, the inet demon
is always needed.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)