"No error" condition

[Stas Degteff]

Hello Nick.

08 Mar 12 16:27, you wrote to me:

SD>> This log message speaks to us: remote send invalid command "M_GET"
SD>> to you. Third number (offset) should be not more first (length).
SD>>
SD>> ==== (from first message in this subject) ====
SD>> 20120307 08:10:07 [28936] VER Internet Rex 2.29 Win32 (binkp/1.1)
SD>> ==== ====
SD>> I can't make support for Internet Rex. Sysop of the remote node
SD>> should tell author of his software

NA> Internet Rex is no longer supported, but I have not heard of this
NA> problem affecting other systems. I have many systems connecting here
NA> with Internet Rex with no problems.

Any binkp 1.0 system should not affects to this bug of internet rex. (Why bug?
offset can't be great size!)

NA> Is there any workaround that can be done in BinkD?

Workaround may be only one: after receiving invalid M_GET receiver should reply
M_ERR with diagnostic message and close socket. See binkp specification.

Stas
Jabber-ID: ***@grumbler.org
GPG key 0x72186DB9 (keyserver: hkp://wwwkeys.eu.pgp.net)
... Golded+, Husky & RNTrack maintainer, Binkd developer&webmaster

[Nick Andre]

On 10 Mar 12 01:45:24, Stas Degteff said the following to Nick Andre:

SD> NA> Internet Rex is no longer supported, but I have not heard of this
SD> NA> problem affecting other systems. I have many systems connecting here
SD> NA> with Internet Rex with no problems.
SD>
SD> Any binkp 1.0 system should not affects to this bug of internet rex. (Why b
SD> offset can't be great size!)

Internet Rex is very popular and is used by a lot of people. Unfortunately
the author cannot or will not fix the bugs it has. That is a seperate
discussion best had in another echo... don't want to get off topic here.

SD> NA> Is there any workaround that can be done in BinkD?
SD>
SD> Workaround may be only one: after receiving invalid M_GET receiver should
SD> reply M_ERR with diagnostic message and close socket. See binkp specificati

I'm not asking about the specification. I'm asking that if the remote side is
attempting to GET-seek to a position which does not exist... can't BinkP just
tell the other system that it has seeked to that position meanwhile it is
starting at the beginning-of-file?

Lets look at it this way. If I crash the remote system running Internet Rex
because I'm screwing around with the GET code, then I'm very happy because
I've alerted that Sysop to a problem. That Sysop then has no choice but to fix
the issue by cleaning up their mess so everything works again.

Nick

[Benny Pedersen]

Hello Nick!

08 Mar 2012 08:05, Nick Andre wrote to Stas Degteff:

NA> 08 Mar 08:00:34 [19868] session closed, quitting...
NA> ? 08 Mar 08:00:34 [19868] receiving of 5E85FF78.SU0 interrupted at 0
NA> 08 Mar 08:00:34 [19868] 5E85FF78.SU0: empty partial

md5 of 0 byte files ?


Regards Benny

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

[Benny Pedersen]

Hello Nick!

08 Mar 2012 16:27, Nick Andre wrote to Stas Degteff:

NA> Is there any workaround that can be done in BinkD?

try disable compressed pkt

eg send unpacked in pkt files


Regards Benny

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