"No error" condition

[Stas Degteff]

Hello Nick.

09 Mar 12 16:59, you wrote to me:

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

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

Binkp-mailer can tell the remote only "OK" or "ERROR", not more.

GET with offset behind EOF can be result of fault/inconsistency of file system.
I see only one action: tell remote sysop about error

After receiving invalid M_GET, before 1.0a-608 binkd simple touch requested
file and drop the session. In next session this file should be tranmitted
normally.

In binkd 1.0a-608 Paul Gulchuck implemented check of M_GET parameters and now
binkd send M_ERR to remote and also touch file. Sysop of remote node should
notice the error message in the log/screen

NA> Lets look at it this way. If I crash the remote system running
NA> Internet Rex because I'm screwing around with the GET code, then I'm
NA> very happy because I've alerted that Sysop to a problem.

This illegal method of solving problem, sorry.


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

[Fred Riccio]

Hello Stas and Nick!

10 Mar 12 14:50, Stas Degteff wrote to Nick Andre:

SD> Hello Nick.

SD> 09 Mar 12 16:59, you wrote to me:

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

I'm wondering if turning off Non-reliable mode for the irex node would help in
this case (with a -nr on the binkd config file's NODE line). My thinking is
that binkD would not send an M_File message with a -1 offset (like in binkp
1.0) so the Irex node would just respond with an M_Get / offset 0.

What do you think?


Regards,
Fred

[Nicholas Boel]

Re: "No error" condition
By: Fred Riccio to Stas Degteff on Sat Mar 10 2012 09:40 am

Post by Fred Riccio
I'm wondering if turning off Non-reliable mode for the irex node would
help in this case (with a -nr on the binkd config file's NODE line). My
thinking is that binkD would not send an M_File message with a -1 offset
(like in binkp 1.0) so the Irex node would just respond with an M_Get /
offset 0.

It sounds like it's worth a shot. I would maybe even suggest -nd mode since
it is a further extension of NR mode, and it supercedes the -nr mode. That
would only lead me to believe that it includes everything -nr would, yet adding
in 'no dupes' features.

--
Nick aka axisd - telnet://bbs.pharcyde.org
http://pharcyde.org

[Stas Degteff]

Hello Fred.

10 Mar 12 09:40, you wrote to me:


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

FR> I'm wondering if turning off Non-reliable mode for the irex node would
FR> help in this case (with a -nr on the binkd config file's NODE line).
FR> My thinking is that binkD would not send an M_File message with a -1
FR> offset (like in binkp 1.0) so the Irex node would just respond with an
FR> M_Get / offset 0.

FR> What do you think?

Your idea can't work because:
ever binkp-mailer received M_FILE for existing (partial) file, it immediate
sends M_GET with specified offset.



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

[Benny Pedersen]

Hello Nick!

09 Mar 2012 16:59, Nick Andre wrote to Stas Degteff:

NA> the issue by cleaning up their mess so everything works again.

yep but who will turn over to use binkd on w32 ?


Regards Benny

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

[Benny Pedersen]

Hello Stas!

10 Mar 2012 14:50, Stas Degteff wrote to Nick Andre:

SD> In binkd 1.0a-608 Paul Gulchuck implemented check of M_GET parameters
SD> and now binkd send M_ERR to remote and also touch file. Sysop of
SD> remote node should notice the error message in the log/screen

this error is in qico aswell ?


Regards Benny

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

[Stas Degteff]

Hello Benny!

10 Mar 12 19:40, you wrote to me:

SD>> In binkd 1.0a-608 Paul Gulchuck implemented check of M_GET
SD>> parameters and now binkd send M_ERR to remote and also touch
SD>> file. Sysop of remote node should notice the error message in the
SD>> log/screen

BP> this error is in qico aswell ?

I don't known about qico :)

Stas
Jabber-ID: ***@grumbler.org
GPG key 0x72186DB9 (keyserver: hkp://wwwkeys.eu.pgp.net)

... Golded+, Husky & RNTrack maintainer, Binkd developer&webmaster

[Benny Pedersen]

Hello Stas!

11 Mar 2012 13:55, Stas Degteff wrote to Benny Pedersen:

SD> I don't known about qico :)

i try to understand my dlink dsr 1000n it can do fully ipv6 and lots of tunnels
vpn stuff, but it cant be setup as loadbalancer at the same time, this hold me
back to change to this :(

its like one can have wather in mout and blowing air in baloons at the same
time, naa not really :)

think how does binkd -r608 handle ipv6/ipv4 from root-domain binkp.net ?, will
it use ina: hostname from nodelists for both ?


Regards Benny

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

[Stas Degteff]

Hello Benny!

12 Mar 12 11:09, you wrote to me:

BP> think how does binkd -r608 handle ipv6/ipv4 from root-domain binkp.net
BP> ?, will it use ina: hostname from nodelists for both ?

I don't know about usability of the IPv6 support in the binkd. You may request
author of the IPv6-related patches, it subscribed to this echo :)


Stas
Jabber-ID: ***@grumbler.org
GPG key 0x72186DB9 (keyserver: hkp://wwwkeys.eu.pgp.net)

... Golded+, Husky & RNTrack maintainer, Binkd developer&webmaster

[Andre Grueneberg]

Hi Stas

Stas Degteff schrieb:

BP>> think how does binkd -r608 handle ipv6/ipv4 from root-domain binkp.net
BP>> ?, will it use ina: hostname from nodelists for both ?
SD> I don't know about usability of the IPv6 support in the binkd. You
SD> may request author of the IPv6-related patches, it subscribed to
SD> this echo :)

To me this rather is a question about how binkp.net works.
Binkd just resolves via binkp.net and if some entry has a AAAA record, it will
be used as per the OS's getaddrinfo() implementation.

CU Andre E-Mail: ***@grueneberg.de

[Benny Pedersen]

Hello Andre!

14 Mar 2012 13:45, Andre Grueneberg wrote to Stas Degteff:

AG> To me this rather is a question about how binkp.net works.
AG> Binkd just resolves via binkp.net and if some entry has a AAAA record,
AG> it will be used as per the OS's getaddrinfo() implementation.

as long CNAME is used in binkp.net it works, but there is records of A in
binkp.net no ?

and what about SRV ?


Regards Benny

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

[Andre Grueneberg]

Hi Benny

Benny Pedersen schrieb:

AG>> To me this rather is a question about how binkp.net works.
AG>> Binkd just resolves via binkp.net and if some entry has a AAAA record,
AG>> it will be used as per the OS's getaddrinfo() implementation.
BP> as long CNAME is used in binkp.net it works, but there is records
BP> of A in binkp.net no ?

In how far is this special to any other case of getaddrinfo() usage? Either
there's a CNAME or there are A or AAAA ... that's common for DNS.

BP> and what about SRV ?

In case there's an SRV (and binkd is compiled with FSP1035 support), the SRV(s)
will be resolved into the hostname and port behind it and this is fed into
getaddrinfo(). In case there are multipe SRVs, these should be ordered by
priority (and weight should be considered). In binkp.net there's no priority or
weight ... and the binkd implementation doesn't support it.

Example:
_binkp._tcp.a SRV 0 0 24554 b
_binkp._tcp.a SRV 0 0 24555 c
b A 1.1.1.1
b AAAA 2001:db8::1
b A 1.1.1.2
c AAAA 2001:db8::2

Depending on OS's getaddrinfo() implementation (order of IPv6 and IPv4), binkd
might try the following (depending on order of resolver result):
[2001:db8::1]:24554
1.1.1.1:24554
1.1.1.2:24554
[2001:db8::2]:24555

So basically it's OS dependent.

CU Andre E-Mail: ***@grueneberg.de

[mark lewis]

NA> Lets look at it this way. If I crash the remote system running
NA> Internet Rex because I'm screwing around with the GET code, then I'm
NA> very happy because I've alerted that Sysop to a problem.

SD> This illegal method of solving problem, sorry.

+10000000000000000000000000~

)\/(ark

[Nick Andre]

On 10 Mar 12 14:50:42, Stas Degteff said the following to Nick Andre:

SD> In binkd 1.0a-608 Paul Gulchuck implemented check of M_GET parameters and n
SD> binkd send M_ERR to remote and also touch file. Sysop of remote node should
SD> notice the error message in the log/screen

Thanks, I shall look for 1.0a-608.

SD> NA> Lets look at it this way. If I crash the remote system running
SD> NA> Internet Rex because I'm screwing around with the GET code, then I'm
SD> NA> very happy because I've alerted that Sysop to a problem.
SD>
SD> This illegal method of solving problem, sorry.

In this context I really don't care if its an "illegal" method. I'm not
being persecuted or charged with a crime if the other side crashes, I'm
concerned -if its possible-. Obviously I am intelligent enough to understand
that it is breaking standards to do so.

The above was merely an opinion to illustrate my point that the
remote side has a problem (as you saw) and the workarounds possible here.

Nick

[Nick Andre]

On 11 Mar 12 22:06:33, Mark Lewis said the following to Stas Degteff:

ML> NA> Lets look at it this way. If I crash the remote system running
ML> NA> Internet Rex because I'm screwing around with the GET code, then I'm
ML> NA> very happy because I've alerted that Sysop to a problem.
ML>
ML> SD> This illegal method of solving problem, sorry.
ML>
ML> +10000000000000000000000000~

Duhhhhhhhhhhhh, such an educated and well-thought-out reply.

Nick