Hello Binkd Team,

Recently we have seen IPv6 nodes that use 6to4 tunneling for their IPv6 internet connection.

Most OSs default to IPv4 when the destination IPv6 is a 6to4 address (2002::/16) and IPv4 is available. There are good reasons for that, 6to4 is notoriously unreliable.

Nevertheless, the IPv6 fans among us like to make IPv6 connections with these nodes. Binkd offers the -6 option in the NODE statemant in binkd's config. That
works. It forces an IPv6 connect.

But... It is a "hard force", the -6 option only tries IPv6. Without the -6 option IPv4 is tried when IPv6 fails, but with the -6 option ONLY IPv6 is tried. So when the tunnel fails, one can not make a connect.

I therefore request that the following "soft force" options are added in addition to the -6 and -4 options:


-64 Binkd ignores the OS preference and tries to first make an IPv6
connect. If that fails, it tries an IPv4 connect.

-46 Binkd ignores the OS preference and tries to first make an IPv4
connect. If that fails, it tries an IPv6 connect.


Thank you.



Cheers, Michiel

---
* Origin: http://www.vlist.eu (2:280/5555)

Michiel van der Vlist wrote to Binkd team <=-

I therefore request that the following "soft force" options are added
in addition to the -6 and -4 options:

-64 Binkd ignores the OS preference and tries to first make an IPv6
connect. If that fails, it tries an IPv4 connect.

-46 Binkd ignores the OS preference and tries to first make an IPv4
connect. If that fails, it tries an IPv6 connect.

That could be useful in some scenarios. In my case, my IPv6 connectivity (native) is better than IPv4 (tunneled), so it's better for me to try IPv6 first in most cases, then fall back to IPv4 if necessary.


... Hey! This is just like the REAL world!
--- MultiMail/Win32 v0.49
* Origin: Freeway BBS - freeway.apana.org.au (3:633/410)

Hi, Michiel!

31 jan 17 18:31, Michiel van der Vlist wrote Binkd team:

MvdV> I therefore request that the following "soft force" options are
MvdV> added in addition to the -6 and -4 options:
MvdV> -64 Binkd ignores the OS preference and tries to first make an
MvdV> IPv6 connect. If that fails, it tries an IPv4 connect.
MvdV> -46 Binkd ignores the OS preference and tries to first make an
MvdV> IPv4 connect. If that fails, it tries an IPv6 connect.

Good idea!

WBR, Alexandr.

--- "OS X/binkd/hpt-1.9-cur/GoldEd+-1.1.5-b20161221" ---
* Origin: -Waiting for the sun? -No, for a call or event. (2:5053/58.1)

=============================================================================
* Forwarded by Michiel van der Vlist (2:280/5555)
* Area : IPV6 (IPv6 Discussion)
* From : Janne Johansson, 2:221/6 (Wednesday February 01 2017 16:44)
* To : Michiel van der Vlist
* Subj : Feature request: soft IPv6 force ============================================================================= On 2017-02-01 01:39, Michiel van der Vlist : Tony Langdon wrote:

*** Answering a msg posted in area BINKD (Binkd mailer).

Hello Tony,

On Wednesday February 01 2017 09:34, you wrote to me:

-64 Binkd ignores the OS preference and tries to first make an
IPv6 connect. If that fails, it tries an IPv4 connect.

[..]

That could be useful in some scenarios. In my case, my IPv6 connectivity (native) is better than IPv4 (tunneled), so it's better
for me to try IPv6 first in most cases, then fall back to IPv4 if necessary.

Native IPv6 and IPv4 via a tunnel is the opposite of what many of us
have. Quite exceptional. For now. It may not be so exceptional in the
future.

But is IPv6 not the default on your system? Is is different from my
situation (Windows, native dual stack) where IPv6 is the default
connectiom method, except when the destination has a 6to4 IPv6 address? (2002::/16)

I wonder if "default connection method" might be "default resolving
method" on some OSes, if given a hostname. There is a difference in
which protocol OSes will try first if given both v4 and v6, so having a
button to make binkd make a specific choice might be a good idea.

-+-
+ Origin: *** nntp://fidonews.mine.nu *** Finland *** (2:221/6.0) =============================================================================


Cheers, Michiel

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

Good ${greeting_time}, Michiel!

11 Dec 17 21:51, you wrote to Binkd team:

MvdV> I therefore request that the following "soft force" options are added
MvdV> in addition to the -6 and -4 options:
MvdV> -64 Binkd ignores the OS preference and tries to first make an IPv6
MvdV> connect. If that fails, it tries an IPv4 connect.
MvdV> -46 Binkd ignores the OS preference and tries to first make an IPv4
MvdV> connect. If that fails, it tries an IPv6 connect.

Wow! You read my thoughts. I too for a long time want such option.

With best regards, Alexandr.

--- "OS X/binkd/hpt-1.9-cur/GoldEd+-1.1.5-b20170303" ---
* Origin: 24 hours in a day, 24 beers in a case, Hmmm... (2:5053/58.1)

Hello Alexandr,

On Wednesday December 13 2017 13:44, you wrote to me:

MvdV>> -64 Binkd ignores the OS preference and tries to first make an
MvdV>> IPv6 connect. If that fails, it tries an IPv4 connect.
MvdV>> -46 Binkd ignores the OS preference and tries to first make
MvdV>> an IPv4 connect. If that fails, it tries an IPv6 connect.

Wow! You read my thoughts. I too for a long time want such option.

So how about translating my message into Russian and post it in RU.BINKD?


Cheers, Michiel

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

Good ${greeting_time}, Michiel!

*** Answering a msg posted in area CarbonArea (îδ½∞µÑ ñ½∩ ¼Ñ¡∩).

13 Dec 17 11:41, you wrote to me:

MvdV>>> -64 Binkd ignores the OS preference and tries to first make
MvdV>>> an IPv6 connect. If that fails, it tries an IPv4 connect.
MvdV>>> -46 Binkd ignores the OS preference and tries to first make
MvdV>>> an IPv4 connect. If that fails, it tries an IPv6
MvdV>>> connect.

Wow! You read my thoughts. I too for a long time want such
option.

MvdV> So how about translating my message into Russian and post it in
MvdV> RU.BINKD?

Of course! I think that even without translation everyone will understand =)

With best regards, Alexandr.

--- "OS X/binkd/hpt-1.9-cur/GoldEd+-1.1.5-b20170303" ---
* Origin: 24 hours in a day, 24 beers in a case, Hmmm... (2:5053/58.1)

Good ${greeting_time}, Michiel!

15 Apr 18 15:00, you wrote to Binkd team:

MvdV> I therefore request that the following "soft force" options are
MvdV> added in addition to the -6 and -4 options:
MvdV> -64 Binkd ignores the OS preference and tries to first make an
MvdV> IPv6 connect. If that fails, it tries an IPv4 connect.
MvdV> -46 Binkd ignores the OS preference and tries to first make an
MvdV> IPv4 connect. If that fails, it tries an IPv6 connect.

I want this from my first day in Fido =)

With best regards, Alexandr.

--- "GoldED+/LNX 1.1.5-b20170303" ---
* Origin: 24 hours in a day, 24 beers in a case, Hmmm... (2:5053/58)

Hello Alexandr,

On Sunday April 15 2018 19:33, you wrote to me:

MvdV>> I therefore request that the following "soft force" options are
MvdV>> added in addition to the -6 and -4 options:
MvdV>> -64 Binkd ignores the OS preference and tries to first make
MvdV>> an IPv6 connect. If that fails, it tries an IPv4 connect. -46
MvdV>> Binkd ignores the OS preference and tries to first make an IPv4
MvdV>> connect. If that fails, it tries an IPv6 connect.

I want this from my first day in Fido =)

So... translate it into Russian and post it in binkd.ru. Maybe someone over there will pick it up...


Cheers, Michiel

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

Good ${greeting_time}, Michiel!

*** Answering a msg posted in area CarbonArea (îδ½∞µÑ ñ½∩ ¼Ñ¡∩).

15 Apr 18 22:55, you wrote to me:

MvdV>>> I therefore request that the following "soft force" options
MvdV>>> are added in addition to the -6 and -4 options: -64 Binkd
MvdV>>> ignores the OS preference and tries to first make an IPv6
MvdV>>> connect. If that fails, it tries an IPv4 connect. -46 Binkd
MvdV>>> ignores the OS preference and tries to first make an IPv4
MvdV>>> connect. If that fails, it tries an IPv6 connect.

I want this from my first day in Fido =)

MvdV> So... translate it into Russian and post it in binkd.ru. Maybe
MvdV> someone over there will pick it up...

Completed, but it's doubtful. I'm waiting for a response: "Commit patch to the git" =)

With best regards, Alexandr.

--- "GoldED+/LNX 1.1.5-b20170303" ---
* Origin: 24 hours in a day, 24 beers in a case, Hmmm... (2:5053/58)

Hello Alexandr,

On Monday April 16 2018 14:00, you wrote to me:

MvdV>> So... translate it into Russian and post it in binkd.ru. Maybe
MvdV>> someone over there will pick it up...

Completed, but it's doubtful. I'm waiting for a response: "Commit
patch to the git" =)

Let's wait and see what happens. As they say around here: no shot is always a miss.

Thanks anyway.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: Michiel's laptop (2:280/5555.1)

Greetings, traveler ...

16 Apr 18 12:28, you wrote to Alexandr Kruglikov:

MvdV>>> So... translate it into Russian and post it in binkd.ru. Maybe
MvdV>>> someone over there will pick it up...

Completed, but it's doubtful. I'm waiting for a response: "Commit
patch to the git" =)

Let's wait and see what happens. As they say around here: no shot is

always a miss.

binkd relies on getaddrinfo (as any other UNIX tool dealing with sockets) which
in turn returns addresses sorted in accordance with RFC3484. I'm not saying you
can not berak the sorting rules in your particular app, but at least this is not recommended. If you like to tune sorting order on your system, you always have /etc/gai.conf. For exmaple, by putting there "precedence ::ffff:0:0/96 100" you will prefer v4 over v6. Not sure is this somehting you did not know or
wanted to do.
If it is not, we can dicsuss it further to see is it really feasible to impement in binkd internal precedence rules or not.


\aID


--- GoldED+/BSD 1.1.5-b20170303
* Origin: Hugayda Station (2:463/1331)

Good ${greeting_time}, Andrei!

19 Apr 18 18:10, you wrote to Michiel van der Vlist:

binkd relies on getaddrinfo (as any other UNIX tool dealing with
sockets) which in turn returns addresses sorted in accordance with RFC3484. I'm not saying you can not berak the sorting rules in your particular app, but at least this is not recommended. If you like to
tune sorting order on your system, you always have /etc/gai.conf. For exmaple, by putting there "precedence ::ffff:0:0/96 100" you will
prefer v4 over v6. Not sure is this somehting you did not know or
wanted to do. If it is not, we can dicsuss it further to see is it
really feasible to impement in binkd internal precedence rules or not.

1. we talking about not only *nix.
2. i know about netsh interface ipv6 add prefixpolicy =)
3. if possible to make the choice of IPv6-only by means of a binkd, then why impossible to make priorities? =\

With best regards, Alexandr.

--- "GoldED+/LNX 1.1.5-b20170303" ---
* Origin: 24 hours in a day, 24 beers in a case, Hmmm... (2:5053/58)

Greetings, traveler ...

20 Apr 18 13:20, you wrote to me:

binkd relies on getaddrinfo (as any other UNIX tool dealing with
sockets) which in turn returns addresses sorted in accordance
with RFC3484. I'm not saying you can not berak the sorting rules
in your particular app, but at least this is not recommended. If
you like to tune sorting order on your system, you always have
/etc/gai.conf. For exmaple, by putting there "precedence
::ffff:0:0/96 100" you will prefer v4 over v6. Not sure is this
somehting you did not know or wanted to do. If it is not, we can
dicsuss it further to see is it really feasible to impement in
binkd internal precedence rules or not.

1. we talking about not only *nix.

I know binkd runs on multiple OS's, but still it relies on 'getaddrinfo' and its sorting rules :)

2. i know about netsh interface ipv6 add prefixpolicy =)
3. if possible to make the choice of IPv6-only by means of a binkd,
then why impossible to make priorities? =\

Did I say it is impossible? I proposed to discuss and find a common ground before proposing chnges to the code :) You are reading RU.HUSKY/RU.BINKD and should know our FTN community is picky on patches and if you don't want to end up with 'BinkD-Plus', you have to be prepared to defend your position.

As for IPv6-only and IPv4-only, this is made by choosing an address family, like AF_INET4, AF_INET6 or AF_INET and these are mutually exclusive. Only in case AF_INET is proveded to 'getaddrinfo' it will give yuo full, ordered list of endpoints to connect to. And mentioned RFC3484 says order should be respected (should, not must).

So, is this statement correct:
1. Introduce new configuration option for FTN node object to force IPv6 or IPv4
precedence, disrespecting the OS rules for this node only;
2. Introduce new command line argument to force current IPv6 or IPv4 precedence
for binkd process;
3. Intruduce new global configuration option to force IPv6 or IPv4 precedence;

Is this all or am I missing something?

\aID


--- GoldED+/BSD 1.1.5-b20170303
* Origin: Hugayda Station (2:463/1331)

Good ${greeting_time}, Andrei!

*** Answering a msg posted in area CarbonArea (Mail for me).

20 Apr 18 12:43, you wrote to me:

3. if possible to make the choice of IPv6-only by means of a
binkd, then why impossible to make priorities? =\

Did I say it is impossible? I proposed to discuss and find a common
ground before proposing chnges to the code :) You are reading RU.HUSKY/RU.BINKD and should know our FTN community is picky on
patches and if you don't want to end up with 'BinkD-Plus', you have to
be prepared to defend your position.

Course, I know this community rule very well (and all engineers): If it works fine - don't touch anything there. =))

As for IPv6-only and IPv4-only, this is made by choosing an address family, like AF_INET4, AF_INET6 or AF_INET and these are mutually exclusive. Only in case AF_INET is proveded to 'getaddrinfo' it will
give yuo full, ordered list of endpoints to connect to. And mentioned RFC3484 says order should be respected (should, not must).

Thanks for the explanation! I'm poorly versed in programming, and this is very informative. But is it not possible to do a check, for example, like this (I repeat, I'm weakly programming):

while(ip_is_present)
{
if(rp->ai_family == AF_INET6)
else if(rp->ai_family == AF_INET)
session = socket(rp->ai_family, rp->ai_socktype, 0);
if (session == FAILURE)
continue;
}

that is, first try to use AF_INET6 and in case of connection failure - AF_INET?

So, is this statement correct:
1. Introduce new configuration option for FTN node object to force
IPv6 or IPv4 precedence, disrespecting the OS rules for this node
only;

Yes, that's what we want! =)

2. Introduce new command line argument to force current IPv6 or
IPv4 precedence for binkd process;

I do not see much point in this option. In my humble opinion =) it is better to
configure each node individually.

3. Intruduce new global configuration option to force IPv6 or IPv4 precedence;

I do not see any point in this option. =)

Is this all or am I missing something?

That's all. Maybe Michael will add something?

With best regards, Alexandr.

--- "GoldED+/LNX 1.1.5-b20170303" ---
* Origin: 24 hours in a day, 24 beers in a case, Hmmm... (2:5053/58)

Hello Andrei,

On Thursday April 19 2018 18:10, you wrote to me:

binkd relies on getaddrinfo (as any other UNIX tool dealing with
sockets) which in turn returns addresses sorted in accordance with RFC3484.

I am aware that binkd was first written for Linus and that windows ports came later.

I'm not saying you can not berak the sorting rules in your
particular app, but at least this is not recommended. If you like to
tune sorting order on your system, you always have /etc/gai.conf. For exmaple, by putting there "precedence ::ffff:0:0/96 100" you will
prefer v4 over v6. Not sure is this somehting you did not know or
wanted to do. If it is not, we can dicsuss it further to see is it
really feasible to impement in binkd internal precedence rules or not.

I am a Windows man and I know that netsh has options to set the preferences. I haven't delved into that, but I am sure I can find out how it works if need be.

However... changing the system preference affects all applications. That may not be what one wants. For Fidonet a slow or less reliable connection is not too bad. The robots will just retry if it does not works at first try. So to promote IPv6 in Fidonet one can set an IPv6 preference for binkd, despite the fact that the IPv6 connection is less reliable than IPv4.

But if you use the same system for other application, you do not want those other applications to be affected. Browsing over a forced bad IPv6 connection is no fun. Plus that browsers and other applications may heve other mechanism in force. Such as happy eyeballs.

That is why I would prefer not to change the system preference but let binkd have its own overide mechanism instead.


Cheers, Michiel

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

Hello Andrei,

On Friday April 20 2018 12:43, you wrote to Alexandr Kruglikov:

So, is this statement correct:
1. Introduce new configuration option for FTN node object to force
IPv6 or IPv4 precedence, disrespecting the OS rules for this node
only;

Yep, that is the heart of my feature request.

2. Introduce new command line argument to force current IPv6 or
IPv4 precedence for binkd process;

3. Intruduce new global
configuration option to force IPv6 or IPv4 precedence;

2 and 3 are not really needed. But it won't hurt either. But if it is implemented Option 1 should overide 2 and 3 and 2 should override 2.

Is this all or am I missing something?

That's it. ;-)


Cheers, Michiel

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

Greetings, traveler ...

20 Apr 18 21:59, you wrote to me:

So, is this statement correct:
1. Introduce new configuration option for FTN node object to
force IPv6 or IPv4 precedence, disrespecting the OS rules for
this node only;

Yep, that is the heart of my feature request.

Is this all or am I missing something?

That's it. ;-)

This sounds like a plan, I'll give it a try on a spare time. Will let you know if it will work :)


\aID


--- GoldED+/BSD 1.1.5-b20170303
* Origin: Hugayda Station (2:463/1331)

Hello Andrei,

On Monday April 23 2018 00:08, you wrote to me:

Is this all or am I missing something?

That's it. ;-)

This sounds like a plan, I'll give it a try on a spare time. Will let
you know if it will work :)

Great! We will wait patiently. ;)


Cheers, Michiel

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

Greetings, travelers ...

20 Apr 18 21:59, Michiel van der Vlist wrote to me:

So, is this statement correct:
1. Introduce new configuration option for FTN node object to
force IPv6 or IPv4 precedence, disrespecting the OS rules for
this node only;

Yep, that is the heart of my feature request.

I may need your help here. Again.
I have identified the place and way to implement this request: most feasible and elegant from my point of view will be to perform an 'addrinfo' structures list reordering before passing it forward. This could be done in very controlled manner and whole feature this wasy will be activted by compile time option.

Now to the tricky part :)
One can imagine addrinfo structure list as a list of pre-ordered IP addresses. The 'getaddrinfo' doing this as we know depending on gai.conf settings on somehting similair. In the simpliest case, with standard IPv6 over IPv4 precedence we'll end up with the list of:

IPv6 #1 -> ... -> IPv6 #N -> IPv4 #1 -> ... -> IPv4 #N -> NULL

Quick and dirty way to reorder it is to find IPv4 #1 and put into the head, then find last IPv4 #N and put it's pointer to the IPv6 #1 and finally IPv6 #N to -> NULL.
But ... (remember Ned Stark) ... there is possibiliy, as far as I can read from
RFC, the list will be mix of v4 and v6 addresses. So we'll have:

IPv6 #1 -> IPv6 #N -> IPv4 #1 ... -> IPv4 #N -> IPv6 #N+1 -> ... -> IPv6 #N+M

NULL

This is possible so far in case IPv4 over IPv6 tunneling has lower precedence, than IPv4, but pure IPv6 is still prefered.

Bearing your idea in mind, how should requested feature deal with such lists?

p.s. To do not induct your way of thinking I would no post my solution. At least not now :)

Cheers,

\aID


--- GoldED+/BSD 1.1.5-b20170303
* Origin: Hugayda Station (2:463/1331)

Hello Andrei,

On Tuesday April 24 2018 16:13, you wrote to All:

I may need your help here. Again.

I will try...

I have identified the place and way to implement this request: most feasible and elegant from my point of view will be to perform an 'addrinfo' structures list reordering before passing it forward. This could be done in very controlled manner and whole feature this wasy
will be activted by compile time option.

OK.

Now to the tricky part :)
One can imagine addrinfo structure list as a list of pre-ordered IP addresses. The 'getaddrinfo' doing this as we know depending on
gai.conf settings on somehting similair. In the simpliest case, with standard IPv6 over IPv4 precedence we'll end up with the list of:

IPv6 #1 -> ... -> IPv6 #N -> IPv4 #1 -> ... -> IPv4 #N -> NULL

I must confess I had not yet considered the case of a list of more than one address of each...

Quick and dirty way to reorder it is to find IPv4 #1 and put into the head, then find last IPv4 #N and put it's pointer to the IPv6 #1 and finally IPv6 #N to -> NULL.

So far so good.

But ... (remember Ned Stark) ... there is possibiliy, as far as I can
read from RFC, the list will be mix of v4 and v6 addresses. So we'll
have:

Oh...

IPv6 #1 -> IPv6 #N -> IPv4 #1 ... -> IPv4 #N -> IPv6 #N+1 -> ... ->
IPv6 #N+M -> NULL

This is possible so far in case IPv4 over IPv6 tunneling has lower precedence, than IPv4, but pure IPv6 is still prefered.

Bearing your idea in mind, how should requested feature deal with such lists?

The reason for asking for a "soft IPv6 force" was to promote IPv6 in Fidonet. Normally IPv6 will be tried first, but in case of tunneling, changing te prefence may be required to have binkd try IPv6 first and then try IPv4 if IPv6
fails.

Hence the -64 option. The -46 option was just added for completeness and symmetry. It is not needed for the underlying objective: promote IPv6.

So as far as I am concerned I would not mind if only -64 is implemented.

If (first entry in the list is IPv6) do nothing;
else
{
find IPv6 #1 in the list;
if (not found) do nothing;
else move IPv6 #1 to top of list;
}

This will ensure that IPv6 will be tried first. What happens next when the first IPv6 try fails, does not matter much.

Hope this helps.

( Of course adding -46 is just a matter of interchanging IPv6 and IPv4 in the above procedure, but not really important. )


Cheers, Michiel

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

Greetings, traveler ...

25 Apr 18 22:16, you wrote to me:

The reason for asking for a "soft IPv6 force" was to promote IPv6 in Fidonet. Normally IPv6 will be tried first, but in case of tunneling, changing te prefence may be required to have binkd try IPv6 first and
then try IPv4 if IPv6 fails.

Aha, I see, so I've got it a bit different. Then indeed we can simplify rules to these:
'-64' - try first available IPv6 address first, fallback to standard list if failed;
'-46' - try first availbale IPv4 address first, fallback to standard list if failed;

Will try to progress this weekend. I'm running macOS and FreeBSD so these are 2
obvius build targets, what is your OS so I'd try to deply a VM to test for it as well?

I have doubts I can manage to make it work on OS/2 or DOS, but some descent Windows might be possible ...

\aID


--- GoldED+/BSD 1.1.5-b20170303
* Origin: Hugayda Station (2:463/1331)

Hello Andrei,

On Friday April 27 2018 10:44, you wrote to me:

Aha, I see, so I've got it a bit different. Then indeed we can
simplify rules to these: '-64' - try first available IPv6 address
first, fallback to standard list if failed; '-46' - try first
availbale IPv4 address first, fallback to standard list if failed;

Yep! That would do it.

Will try to progress this weekend. I'm running macOS and FreeBSD so
these are 2 obvius build targets, what is your OS so I'd try to deply
a VM to test for it as well?

I run my main Fido system on Win XP 32 bit. My point system on Win 7 32 bit.

I have doubts I can manage to make it work on OS/2 or DOS, but some descent Windows might be possible ...

OS/2 and DOS are IPv4 only, so none of what we discussed applies I'd say...


Cheers, Michiel

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

On 2018 Apr 27 10:44:28, you wrote to Michiel van der Vlist:

I have doubts I can manage to make it work on OS/2 or DOS, but some descent Windows might be possible ...

at this time, i don't think i'd worry about OS/2... it is doubtful that it will
get an IPv6 stack any time soon... i don't have a clue what DOS networking stacks may have these days... freeDOS might have IPv6 by now but i've not looked at it in a long time... winwhatever, *nix and mac, sure...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... I went from wine, women & song to beer, the old lady & TV.
---
* Origin: (1:3634/12.73)

On 2018 Apr 27 10:44:28, you wrote to Michiel van der Vlist:

I have doubts I can manage to make it work on OS/2 or DOS, but some descent Windows might be possible ...

at this time, i don't think i'd worry about OS/2... it is doubtful that it will
get an IPv6 stack any time soon... i don't have a clue what DOS networking stacks may have these days... freeDOS might have IPv6 by now but i've not looked at it in a long time... winwhatever, *nix and mac, sure...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... I went from wine, women & song to beer, the old lady & TV.
---
* Origin: (1:3634/12.73)

Hello mark,

On Friday April 27 2018 09:24, you wrote to Andrei Dzedolik:

at this time, i don't think i'd worry about OS/2... it is doubtful
that it will get an IPv6 stack any time soon...

OS/2 is dead. It does not support IPv6 and never will. The makers of its successor, EcomStation promised they would add IPv6 but it never emerged and by
now Ecomstation is a dead end as well. The latetst successor, ArcaOs, had no support for IPv6 either and the makers say there are no plans for IPv6 yet. So forget about OS/2 and its successors.

i don't have a clue what DOS networking stacks may have these days... freeDOS might have IPv6 by now but i've not looked at it in a long
time... winwhatever, *nix and mac, sure...

AFAIK, there is no 16 bit OS that supports IPv6.

Anyway. IPv6 was born in 1995, more then two decades ago. I say that any OS that doesn't havae it yet, almost at the end of the second decade of the 21st century, has missed the boat and is not worth any rescue attempt. Let's forget about the dinasours and move on.

Just my EUR 0.02.

Cheers, Michiel

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

Hello Andrei,

Friday April 27 2018 16:19, I wrote to you:

Will try to progress this weekend. I'm running macOS and FreeBSD
so these are 2 obvius build targets, what is your OS so I'd try
to deply a VM to test for it as well?

I run my main Fido system on Win XP 32 bit. My point system on Win 7
32 bit.

If you have a Windows version, I will happily help testing..


Cheers, Michiel

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

On 2018 Apr 28 10:51:24, you wrote to me:

at this time, i don't think i'd worry about OS/2... it is doubtful
that it will get an IPv6 stack any time soon...

OS/2 is dead.

sorry but it is NOT dead... certainly not with a new variation of it being actively worked on and distributed...

It does not support IPv6 and never will.

i know and stated as much ;)

[trim]

i don't have a clue what DOS networking stacks may have these days...
freeDOS might have IPv6 by now but i've not looked at it in a long
time... winwhatever, *nix and mac, sure...

AFAIK, there is no 16 bit OS that supports IPv6.

there is a 32bit freedos project...

Anyway. IPv6 was born in 1995, more then two decades ago. I say that
any OS that doesn't havae it yet, almost at the end of the second
decade of the 21st century, has missed the boat and is not worth any rescue attempt. Let's forget about the dinasours and move on.

the adoption of 32bit took a while... the adoption of 64bit is taking longer...
i'm surprised they haven't announced 128bit yet so we can have this ""discussion"" again in another 50 years when 128bit is still just being adopted ;)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... I think gin is erotic.
---
* Origin: (1:3634/12.73)

Hello mark,

On Saturday April 28 2018 06:43, you wrote to me:

OS/2 is dead.

sorry but it is NOT dead... certainly not with a new variation of it
being actively worked on and distributed...

Those "variations" are not OS/2. They may be look and feel alikes but they are not IBM OS/2. THAT OS/2 is dead. Dead in the sense that there will be no more updates. And so it will never support IPv6.

It does not support IPv6 and never will.

i know and stated as much ;)

"never" != "not anytime soon".

[trim]

i don't have a clue what DOS networking stacks may have these
days... freeDOS might have IPv6 by now but i've not looked at it
in a long time... winwhatever, *nix and mac, sure...

AFAIK, there is no 16 bit OS that supports IPv6.

there is a 32bit freedos project...

I have left DOS behind a long time ago. I don't look back. So like you, I have no idea what this 32bit freedos is. I can not rule out that it supports IPv6, but it would surprise me.

Anyway. IPv6 was born in 1995, more then two decades ago. I say
that any OS that doesn't havae it yet, almost at the end of the
second decade of the 21st century, has missed the boat and is not
worth any rescue attempt. Let's forget about the dinasours and
move on.

the adoption of 32bit took a while...

A bit longer than the shift from 8 to 16 bits, but not all than long...

the adoption of 64bit is taking longer...

But not all that relevant regarding the adoption of IPv6. IPv6 runs fine on 32 bit. Binkd runs fine on 32 bit. The 64 bit versions do not perform notably better. Not for this application.

i'm surprised they haven't announced 128bit yet so we can have this ""discussion"" again in another 50 years when 128bit is still just
being adopted ;)

50 years? I doubt I will still be around by then. I do not expect the average human life expectancy to increase fast enough for that...



Cheers, Michiel

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

Hello mark!

28 Apr 18 06:43, mark lewis wrote to Michiel van der Vlist:

the adoption of 32bit took a while... the adoption of 64bit is taking longer... i'm surprised they haven't announced 128bit yet so we can
have this ""discussion"" again in another 50 years when 128bit is
still just being adopted ;)

Depends on what you expect from "128bit". Systems using 128bit integers exist since 1970 or so. IPv6 uses 128bit addresses, ZFS is a 128bit file system. Modern GPUs have a 128bit data bus.

CPUs with 128bit for multimedia have been designed already in the late 1990's:

---
<https://ieeexplore.ieee.org/document/799870/>
A microprocessor with a 128-bit CPU, ten floating-point MAC's, four floating-point dividers, and an MPEG-2 decoder
---


Regards,
Gerrit

... 4:07PM up 111 days, 18 hrs, 9 users, load averages: 0.19, 0.21, 0.17

--- Msged/BSD 6.1.2
* Origin: A love pays love for lying (2:240/12)

On 2018 Apr 28 16:07:20, you wrote to me:

the adoption of 32bit took a while... the adoption of 64bit is taking
longer... i'm surprised they haven't announced 128bit yet so we can
have this ""discussion"" again in another 50 years when 128bit is
still just being adopted ;)

Depends on what you expect from "128bit".

in general it is a poke at the "16bit programs are better", "32bit programs are
better", "64bit programs are better" mantras ;)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... There's no fool like an old fool - you can't beat experience.
---
* Origin: (1:3634/12.73)

Greetings, travelers ...

28 Apr 18 11:30, Michiel van der Vlist wrote to me:

Will try to progress this weekend. I'm running macOS and FreeBSD
so these are 2 obvius build targets, what is your OS so I'd try
to deply a VM to test for it as well?

I run my main Fido system on Win XP 32 bit. My point system on
Win 7 32 bit.

If you have a Windows version, I will happily help testing..

I have build and tested macOS version with -46 and -64 options, seems to work. Wokring on building win32 binary ... Last time I've seen Visual Studio was 10 years ago or so. If anyone know how to build binkd for Windows let me know :)

\aID


--- GoldED+/BSD 1.1.5-b20170303
* Origin: Hugayda Station (2:463/1331)

Greetings, travelers ...

28 Apr 18 16:54, I wrote to All:

Will try to progress this weekend. I'm running macOS and
FreeBSD so these are 2 obvius build targets, what is your OS so
I'd try to deply a VM to test for it as well?

I run my main Fido system on Win XP 32 bit. My point system on
Win 7 32 bit.

If you have a Windows version, I will happily help testing..

I have build and tested macOS version with -46 and -64 options, seems
to work. Wokring on building win32 binary ... Last time I've seen
Visual Studio was 10 years ago or so. If anyone know how to build
binkd for Windows let me know :)

I should say it was the hardest part of all, but seems I've managed to setup a build environment on my Windows 7 VM.

So here it is:
- http://hugayda.aid.in.ua/binkd/binkd-static_v1.1a-97_x86_vc90.zip
- http://hugayda.aid.in.ua/binkd/binkd-static_v1.1a-97_x86_vc90.zip.md5

There is a single binkd-static.exe built by VC90 with target /x86 /xp. I hope it will run. At least it runs on my VM.

Here is my sample test config:

... v4 over v6 ...
node 463/1331 -46 hugayda.aid.in.ua <Password>

... v6 over v4 ...
node 463/1331 -64 hugayda.aid.in.ua <Password>

Please give it a try and let me know the results here or by netmail.

Cheers,

\aID


--- GoldED+/BSD 1.1.5-b20170303
* Origin: Hugayda Station (2:463/1331)

Hi Andrei.

28 Apr 18 16:54:32, you wrote to All:

If anyone know how to build binkd for Windows let me know :)

With cygwin it's easy:

copy mkfls\unix\*
sh configure --with-bwlim --with-proxy
make all

:)

'Tommi

--- Binkd 1.1a-96 (Apr 28 2018 22:29:32/CYGWIN_NT-6.1)
* Origin: *** nntp://fidonews.mine.nu *** Finland *** (2:221/6)

Hi Andrei.

28 Apr 18 18:42:12, you wrote to All:

- http://hugayda.aid.in.ua/binkd/binkd-static_v1.1a-97_x86_vc90.zip

... v4 over v6 ...
node 463/1331 -46 hugayda.aid.in.ua <Password>

... v6 over v4 ...
node 463/1331 -64 hugayda.aid.in.ua <Password>

Please give it a try and let me know the results here or by netmail.

Works! :)

'Tommi

---
* Origin: *** nntp://fidonews.mine.nu *** Finland *** (2:221/6)

Greetings, traveler ...

28 Apr 18 22:29, you wrote to me:

If anyone know how to build binkd for Windows let me know :)

With cygwin it's easy:

Yeah, cigwin is like Wine on Linux .. but doesn't binaries compiled under cygwin require cygwin libs to run? Or you can make a proper static build there as well?


\aID


--- GoldED+/BSD 1.1.5-b20170303
* Origin: Hugayda Station (2:463/1331)

Hi Andrei.

28 Apr 18 19:47:44, you wrote to me:

If anyone know how to build binkd for Windows let me know :)

With cygwin it's easy:

Yeah, cigwin is like Wine on Linux .. but doesn't binaries compiled under cygwin require cygwin libs to run?

Yes. But I have cygwin installed where I compile and run binkd. :)

Or you can make a proper static build there as well?

I have never tried to do that.

'Tommi

---
* Origin: 2001:470:1f15:cb0:f1d0:2:221:6 (2:221/6)

Hello Andrei,

On Saturday April 28 2018 18:42, you wrote to All:

Please give it a try and let me know the results here or by netmail.

There are a few poblems. First I had to remove the commands related to compression from my config. There is an error at startup:

D:\FIDO\BINKD>binkd-static binkd.cfg
21:47 [3120] BEGIN standalone, binkd/1.1a-97/Win32 binkd.cfg
21:47 [3120] servmgr started
21:47 [2420] clientmgr started
? 21:47 [3120] servmgr setsockopt (IPV6_V6ONLY): {W32 API error 10042}
An unknown, invalid, or unsupported option or level was
specified in a getsockopt or setsockopt call
- 21:47 [3120] servmgr listen on [2001:1c02:1100:d700:f1d0:2:280:5555]:24555
? 21:47 [3120] servmgr setsockopt (IPV6_V6ONLY): {W32 API error 10042}
An unknown, invalid , or unsupported option or level was
specified in a getsockopt or setsockopt call
- 21:47 [3120] servmgr listen on [2001:1c02:1100:d700:f1d0:2:280:5555]:24554
- 21:47 [3120] servmgr listen on 0.0.0.0:24554

And then when I try to call 2:5020/9696 (T-6to4) it always calls out on IPv6, no matter if I specify -64, -46 or just -4.


Cheers, Michiel

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

Hello Tommi,

On Saturday April 28 2018 22:42, you wrote to Andrei Dzedolik:

Please give it a try and let me know the results here or by
netmail.

Works! :)

Can I have your *.exe?


Cheers, Michiel

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

Greetings, traveler ...

28 Apr 18 22:42, you wrote to me:

-
http://hugayda.aid.in.ua/binkd/binkd-static_v1.1a-97_x86_vc90.zip

... v4 over v6 ...
node 463/1331 -46 hugayda.aid.in.ua <Password>

... v6 over v4 ...
node 463/1331 -64 hugayda.aid.in.ua <Password>

Please give it a try and let me know the results here or by
netmail.

Works! :)

You know, we have a saying which could be translated as "Brevity is the soul of
wit" ;) I'm sure you can feed me with more details: does subj feature works as expected? What options did you try?

\aID


--- GoldED+/BSD 1.1.5-b20170303
* Origin: Hugayda Station (2:463/1331)

Hello Andrei,

Saturday April 28 2018 21:47, I wrote to you:

And then when I try to call 2:5020/9696 (T-6to4) it always calls out
on IPv6, no matter if I specify -64, -46 or just -4.

Update.

The above is when I run the server and create a poll with a second incarnation of binkd with "binkd-static -nP5020/9696 binkd.cfg" Then it calls out always using IPv6.

When I do not run the server and just start the client with:

binkd-static -pP5020/9696 binkd.cfg

then the -4 -6 -46 and -64 commands work as expected.


Cheers, Michiel

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

Greetings, traveler ...

28 Apr 18 21:47, you wrote to me:

Please give it a try and let me know the results here or by
netmail.

There are a few poblems. First I had to remove the commands related to compression from my config. There is an error at startup:

Aha, this is intersting can you share the node line which didn't work?

D:\FIDO\BINKD>binkd-static binkd.cfg
21:47 [3120] BEGIN standalone, binkd/1.1a-97/Win32 binkd.cfg
21:47 [3120] servmgr started
21:47 [2420] clientmgr started
? 21:47 [3120] servmgr setsockopt (IPV6_V6ONLY): {W32 API error 10042}
An unknown, invalid, or unsupported option or level was
specified in a getsockopt or setsockopt call
- 21:47 [3120] servmgr listen on [2001:1c02:1100:d700:f1d0:2:280:5555]:24555 ? 21:47 [3120] servmgr setsockopt (IPV6_V6ONLY): {W32 API error 10042}
An unknown, invalid , or unsupported option or level
was
specified in a getsockopt or setsockopt call
- 21:47 [3120] servmgr listen on [2001:1c02:1100:d700:f1d0:2:280:5555]:24554 - 21:47 [3120] servmgr
listen on 0.0.0.0:24554

Which version you were running with this config before mine? Can you share your
config?
To be honest I didn't touch nor test server pieces of code, onlu client and I did my tests with 'binkd -c -P'.
Perhaps there is some work to do in a server side too, you config (or at least pieces of it where you 'bind' binkd) might be helpfull.

And then when I try to call 2:5020/9696 (T-6to4) it always calls out
on IPv6, no matter if I specify -64, -46 or just -4.

Let me try this one ...


\aID


--- GoldED+/BSD 1.1.5-b20170303
* Origin: Hugayda Station (2:463/1331)

Greetings, traveler ...

28 Apr 18 22:08, you wrote to me:

Hello Andrei,

Saturday April 28 2018 21:47, I wrote to you:

And then when I try to call 2:5020/9696 (T-6to4) it always calls
out on IPv6, no matter if I specify -64, -46 or just -4.

Update.

The above is when I run the server and create a poll with a second incarnation of binkd with "binkd-static -nP5020/9696 binkd.cfg" Then
it calls out always using IPv6.

When I do not run the server and just start the client with:

binkd-static -pP5020/9696 binkd.cfg

then the -4 -6 -46 and -64 commands work as expected.

Yeah, just tried to call this node myself and -46/-64 works for -P mode.
So, did I get you right: you have a binkd service running, you have 5020/9696 in binkd.cfg as 'node' with '-64' and you are polling it by starting binkd with
-nP option? Is this how it fails?


\aID


--- GoldED+/BSD 1.1.5-b20170303
* Origin: Hugayda Station (2:463/1331)

Hello Andrei,

On Saturday April 28 2018 20:27, you wrote to me:

There are a few poblems. First I had to remove the commands
related to compression from my config.

This I had to disable:

#zlevel 9 ░ #zminsize 1024 ░ #zallow *.PKT ░ #zdeny *.SU? *.MO? *.TU? *.WE? *.TH? *.FR? *.SA? ░ #zdeny *.ZIP *.RAR *.ARJ *.HA *.LHA *.7Z *.GZ *.TGZ *.BZ2 *.XZ *.[ALRZ][0-9][0-9]
#zallow * ░ # ░

There is an error at startup:

Aha, this is intersting can you share the node line which didn't work?

listen [2001:1c02:1100:d700:f1d0:2:280:5555]:24555
listen [2001:1c02:1100:d700:f1d0:2:280:5555]:24554
bindaddr [2001:1c02:1100:d700:f1d0:2:280:5555]
listen 0.0.0.0

node 2:5020/9696 -6 skovpen.org -

Which version you were running with this config before mine?

D:\FIDO\BINKD>binkd -vv
Binkd 1.1a-95 (Dec 10 2016 21:44:31/Win32)
Compilation flags: mingw32, zlib, perldl, https, ntlm, amiga_4d_outbound, bwlim, ipv6.
Facilities: fts5004 ipv6

D:\FIDO\BINKD>

Can you share your config? To be honest I didn't touch nor test server pieces of code, onlu client

Aha. As I mentioned in my other message, it seems to work in client mode.

and I did my tests with 'binkd -c -P'.
Perhaps there is some work to do in a server side too, you config (or
at least pieces of it where you 'bind' binkd) might be helpfull.

See above.

And then when I try to call 2:5020/9696 (T-6to4) it always calls
out on IPv6, no matter if I specify -64, -46 or just -4.

Let me try this one ...

What I have not been able to test yet, is what happens if the attempt to connect via IPv6 fails. It should fall back to IPv4, (or the other way around) but I have not been able to test that.


Cheers, Michiel

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

Greetings, traveler ...

29 Apr 18 15:17, you wrote to me:

And there still is this when starting te server:

D:\FIDO\BINKD>binkd-static -C binkd.cfg
15:19 [2280] BEGIN standalone, binkd/1.1a-97/Win32 -C binkd.cfg
15:19 [2280] servmgr started
15:19 [2352] clientmgr started
? 15:19 [2280] servmgr setsockopt (IPV6_V6ONLY): {W32 API error 10042}
An unknown, invalid, or unsupported option or level was
specified in a getsockopt or setsockopt call
- 15:19 [2280] servmgr listen on [2001:1c02:1100:d700:f1d0:2:280:5555]:24555 ? 15:19 [2280] servmgr setsockopt (IPV6_V6ONLY): {W32 API error 10042}
An unknown, invalid, or unsupported option or level was
specified in a getsockopt or setsockopt call
- 15:19 [2280] servmgr listen on [2001:1c02:1100:d700:f1d0:2:280:5555]:24554 - 15:19 [2280] servmgr
listen on 0.0.0.0:24554

It may have something to do with the libs versions I've linked Windows build with, I'll try to see what does these mean ... Perhaps I have to rebuild it with newer VC or something.


\aID


--- GoldED+/BSD 1.1.5-b20170303
* Origin: Hugayda Station (2:463/1331)

Greetings, traveler ...

29 Apr 18 16:29, you wrote to me:

That concludes today's testing. ;-)

I will keep binkd-static 1.1a97 running on 280/5555 for now, it seems
to be stable enough...

Good outcome! I'll submit poll reuest to offcical binkd repository today, so we
may have official 1.1a97 by next weekend or somehting :)


\aID


--- GoldED+/BSD 1.1.5-b20170303
* Origin: Hugayda Station (2:463/1331)

Greetings, traveler ...

28 Apr 18 22:53, you wrote to me:

This I had to disable:

#zlevel 9
░ #zminsize 1024
░ #zallow *.PKT
░ #zdeny *.SU? *.MO? *.TU? *.WE? *.TH? *.FR? *.SA?
░ #zdeny *.ZIP *.RAR *.ARJ *.HA *.LHA *.7Z *.GZ *.TGZ *.BZ2 *.XZ *.[ALRZ][0-9][0-9] #zallow *
░ #
░

This is expected as I didn't compile zlib support - I jsut have no zlib for Windows. As soon as my pathc will be accepted into the trunk (if it will be), you'll have official binary with all fancy libs support, including perls and ntlm/

There is an error at startup:

Aha, this is intersting can you share the node line which didn't
work?

listen [2001:1c02:1100:d700:f1d0:2:280:5555]:24555
listen [2001:1c02:1100:d700:f1d0:2:280:5555]:24554
bindaddr [2001:1c02:1100:d700:f1d0:2:280:5555]
listen 0.0.0.0

node 2:5020/9696 -6 skovpen.org -

Which version you were running with this config before mine?

D:\FIDO\BINKD>binkd -vv
Binkd 1.1a-95 (Dec 10 2016 21:44:31/Win32)
Compilation flags: mingw32, zlib, perldl, https, ntlm,
amiga_4d_outbound, bwlim, ipv6.
Facilities: fts5004 ipv6

Meanwhile if you rely on any of these features (like bwlim or ntlm) - let me know, I'll re-make custom binary for you.


\aID


--- GoldED+/BSD 1.1.5-b20170303
* Origin: Hugayda Station (2:463/1331)

Greetings, travelers ...

Implementation for the feature requested bellow has been submitted for review as pool request #10 to the GitHub master: https://github.com/pgul/binkd/pull/10


15 Apr 18 15:00, Michiel van der Vlist wrote to Binkd team:

Hello Binkd Team,

Recently we have seen IPv6 nodes that use 6to4 tunneling for their
IPv6 internet connection.

Most OSs default to IPv4 when the destination IPv6 is a 6to4 address (2002::/16) and IPv4 is available. There are good reasons for that,
6to4 is notoriously unreliable.

Nevertheless, the IPv6 fans among us like to make IPv6 connections
with these nodes. Binkd offers the -6 option in the NODE statemant in binkd's config. That works. It forces an IPv6 connect.

But... It is a "hard force", the -6 option only tries IPv6. Without
the -6 option IPv4 is tried when IPv6 fails, but with the -6 option
ONLY IPv6 is tried. So when the tunnel fails, one can not make a
connect.

I therefore request that the following "soft force" options are added
in addition to the -6 and -4 options:

-64 Binkd ignores the OS preference and tries to first make an IPv6
connect. If that fails, it tries an IPv4 connect.

-46 Binkd ignores the OS preference and tries to first make an IPv4
connect. If that fails, it tries an IPv6 connect.

Thank you.

Cheers, Michiel

\aID


--- GoldED+/BSD 1.1.5-b20170303
* Origin: Hugayda Station (2:463/1331)

Greetings, traveler ...

30 Apr 18 06:10, I wrote to you:

D:\FIDO\BINKD>binkd-static -C binkd.cfg
15:19 [2280] BEGIN standalone, binkd/1.1a-97/Win32 -C binkd.cfg
15:19 [2280] servmgr started
15:19 [2352] clientmgr started
? 15:19 [2280] servmgr setsockopt (IPV6_V6ONLY): {W32 API error
10042}
An unknown, invalid, or unsupported option or
level was
specified in a getsockopt or setsockopt call
- 15:19 [2280] servmgr listen on
[2001:1c02:1100:d700:f1d0:2:280:5555]:24555 ? 15:19 [2280]
servmgr setsockopt (IPV6_V6ONLY): {W32 API error 10042}
An unknown, invalid, or unsupported option or
level was
specified in a getsockopt or setsockopt call
- 15:19 [2280] servmgr listen on
[2001:1c02:1100:d700:f1d0:2:280:5555]:24554 - 15:19 [2280]
servmgr listen on 0.0.0.0:24554

It may have something to do with the libs versions I've linked Windows build with, I'll try to see what does these mean ... Perhaps I have to rebuild it with newer VC or something.

As per MSDN (https://msdn.microsoft.com/en-us/library/windows/desktop/ms738574)
IPV6_V6ONLY support was added to Windows starting from Vista. This option just not in XP IP stack, I guess warning may be safely ignored.


\aID


--- GoldED+/BSD 1.1.5-b20170303
* Origin: Hugayda Station (2:463/1331)

Hello Andrei,

On Monday April 30 2018 06:15, you wrote to me:

This I had to disable:

#zlevel 9
░ #zminsize 1024
░ #zallow *.PKT
░ #zdeny *.SU? *.MO? *.TU? *.WE? *.TH? *.FR? *.SA?
░ #zdeny *.ZIP *.RAR *.ARJ *.HA *.LHA *.7Z *.GZ *.TGZ *.BZ2 *.XZ
*.[ALRZ][0-9][0-9] #zallow *
░ #
░

This is expected as I didn't compile zlib support - I jsut have no
zlib for Windows. As soon as my pathc will be accepted into the trunk
(if it will be), you'll have official binary with all fancy libs
support, including perls and ntlm/

No big deal. I can do without compression for the duration of the test.

D:\FIDO\BINKD>binkd -vv
Binkd 1.1a-95 (Dec 10 2016 21:44:31/Win32)
Compilation flags: mingw32, zlib, perldl, https, ntlm,
amiga_4d_outbound, bwlim, ipv6.
Facilities: fts5004 ipv6

Meanwhile if you rely on any of these features (like bwlim or ntlm) -
let me know, I'll re-make custom binary for you.

No need. I do not use bwlim or ntlm.


Cheers, Michiel

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

Hello Andrei,

On Monday April 30 2018 06:32, you wrote to All:

Greetings, travelers ...

Implementation for the feature requested bellow has been submitted for review as pool request #10 to the GitHub master: https://github.com/pgul/binkd/pull/10

Great!, So now we wait. ;-)


Cheers, Michiel

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

Hello Andrei,

On Monday April 30 2018 07:25, you wrote to me:

As per MSDN (https://msdn.microsoft.com/en-us/library/windows/desktop/ms738574) IPV6_V6ONLY support was added to Windows starting from Vista. This
option just not in XP IP stack, I guess warning may be safely ignored.

I tried it on my laptop that runs Windows 7. The error does not show there. So it looks like this is indeed an XP issue.

It will probably disappear with Max Vasilyev's compilation. And if not, we will
just ignore...


Cheers, Michiel

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

Hello All!

30 Apr 18 06:32, Andrei Dzedolik wrote to you:

Implementation for the feature requested bellow has been submitted for review as pool request #10 to the GitHub master: https://github.com/pgul/binkd/pull/10

mingw32, msvc10x86, msvc10x64 versions for testing:

https://sites.google.com/site/vasilyevmax/fido/binkd11a97-64-46-option-test.zip

* Originally in BINKD
* Crossposted in RU.BINKD

WBR, Max. piwamoto!»¿ßѼ-¡ÑΓ
--- ߬πτáε »« FleetStreet'π :-(((
* Origin: Personal Reality (2:5057/77)

Hello Max,

On Saturday May 05 2018 20:44, you wrote to All:

mingw32, msvc10x86, msvc10x64 versions for testing:

https://sites.google.com/site/vasilyevmax/fido/binkd11a97-64-46-option -test.zip

Great! Now running the mingw32 version. First impression is that it works as expected. I will keep it running for tonight.

Thank you very much.


Cheers, Michiel

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

Hello Max,

Saturday May 05 2018 22:45, I wrote to you:

Great! Now running the mingw32 version. First impression is that it
works as expected. I will keep it running for tonight.

Oh, and BTW, this error that I reported fior Andrei's version...

21:47 [3120] servmgr started
21:47 [2420] clientmgr started
? 21:47 [3120] servmgr setsockopt (IPV6_V6ONLY): {W32 API error 10042}
An unknown, invalid, or unsupported option or level was
specified in a getsockopt or setsockopt call

... no longer occurs in your compile. :-)


Cheers, Michiel

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

Oh, and BTW, this error that I reported fior Andrei's version...

21:47 [3120] servmgr started
21:47 [2420] clientmgr started
? 21:47 [3120] servmgr setsockopt (IPV6_V6ONLY): {W32 API error 10042}
An unknown, invalid, or unsupported option or level was
specified in a getsockopt or setsockopt call

... no longer occurs in your compile. :-)

That's because you are "Now running the mingw32 version", I believe.

'Tommi

---
* Origin: ================================== (2:221/360)

Oh, and BTW, this error that I reported fior Andrei's version...

21:47 [3120] servmgr started
21:47 [2420] clientmgr started
? 21:47 [3120] servmgr setsockopt (IPV6_V6ONLY): {W32 API error 10042}
An unknown, invalid, or unsupported option or level was
specified in a getsockopt or setsockopt call

... no longer occurs in your compile. :-)

That's because you are "Now running the mingw32 version", I believe.

'Tommi

---
* Origin: ================================== (2:221/360)

Hello Tommi,

On Monday May 07 2018 13:38, you wrote to me:

An unknown, invalid, or unsupported option or
level was specified in a getsockopt or setsockopt call

... no longer occurs in your compile. :-)

That's because you are "Now running the mingw32 version", I believe.

Yes, I am running the mingw version.

D:\FIDO\BINKD>binkd1a97 -vv
Binkd 1.1a-IrvinDitz-fork-97 (May 5 2018 20:07:09/Win32)
Compilation flags: mingw32, zlib, perldl, https, ntlm,
amiga_4d_outbound, bwlim, ipv6.
Facilities: fts5004 ipv6

It has been running stable since Saturday.


Cheers, Michiel

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

On Monday May 07 2018 13:38, you wrote to me:

An unknown, invalid, or unsupported option or
level was specified in a getsockopt or setsockopt call

... no longer occurs in your compile. :-)

That's because you are "Now running the mingw32 version", I
believe.

Yes, I am running the mingw version.

And if you try the msvc version, I assume that message is still there. :)

'Tommi

---
* Origin: ================================== (2:221/360)

Hello Tommi,

On Tuesday May 08 2018 15:40, you wrote to me:

That's because you are "Now running the mingw32 version", I
believe.

Yes, I am running the mingw version.

And if you try the msvc version, I assume that message is still there.
:)

I can't test that, Max only compiled a Mingw version.


Cheers, Michiel

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

And if you try the msvc version, I assume that message is still
there. :)

I can't test that, Max only compiled a Mingw version.

Not true:

[D:\fido\BinkD\test]wget https://sites.google.com/site/vasilyevmax/fido/binkd11a97-64-46-option-test.zip

[D:\fido\BinkD\test]unzip -l binkd11a97-64-46-option-test.zip
Archive: binkd11a97-64-46-option-test.zip
Length Date Time Name
--------- ---------- ----- ----
0 05-05-2018 20:24 mingw32-binkd-ipv6-perldl-zlib/
339968 05-05-2018 20:15 mingw32-binkd-ipv6-perldl-zlib/binkd-mingw-ipv6-perldl-zlib.exe
0 05-05-2018 20:24 msvc10-binkd-ipv6-static-perl-zlib-bzlib2/
435712 05-05-2018 20:19 msvc10-binkd-ipv6-static-perl-zlib-bzlib2/binkd-static-perl-zlib-bzlib2.exe
0 05-05-2018 20:24 msvc10x64-binkd-ipv6-static-perl-zlib-bzlib2/
527872 05-05-2018 20:23 msvc10x64-binkd-ipv6-static-perl-zlib-bzlib2/binkd64-static-perl-zlib-bzlib2.exe

'Tommi

---
* Origin: ================================== (2:221/360)

Hello Tommi,

On Tuesday May 08 2018 17:53, you wrote to me:

And if you try the msvc version, I assume that message is still
there. :)

I can't test that, Max only compiled a Mingw version.

Not true:

Hmmm... those weren't all in the archive when I downloaded it.

You know what: you test it. ;-)


Cheers, Michiel

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

And if you try the msvc version, I assume that message is still
there. :)

I can't test that, Max only compiled a Mingw version.

Not true:

Hmmm... those weren't all in the archive when I downloaded it.

Sure... :D :D :D

You know what: you test it. ;-)

Naah. In my cygwin version those messages are not there. Mingw is pretty much the same. I also have no need for your -64/46 thing, so I'll pass.

'Tommi

---
* Origin: ================================== (2:221/6.10)

And if you try the msvc version, I assume that message is still
there. :)

I can't test that, Max only compiled a Mingw version.

Not true:

Hmmm... those weren't all in the archive when I downloaded it.

Sure... :D :D :D

You know what: you test it. ;-)

Naah. In my cygwin version those messages are not there. Mingw is pretty much the same. I also have no need for your -64/46 thing, so I'll pass.

'Tommi

---
* Origin: ================================== (2:221/6.10)

Hello Tommi,

On Wednesday May 09 2018 06:05, you wrote to me:

I can't test that, Max only compiled a Mingw version.

For Win32...

Not true:

Hmmm... those weren't all in the archive when I downloaded it.

Sure... :D :D :D

These two *.exe are in the archive that I downloaded from Max's site:

binkd-mingw-ipv6-perldl-zlib.exe
binkd64-static-perl-zlib-bzlib2.exe

The first one is the one I use now, the second one is a 64 bit version that will not run on my Win32 machine.


Cheers, Michiel

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

Hello Michiel!

06 May 18 20:56, you wrote to me:

Oh, and BTW, this error that I reported fior Andrei's version...
... no longer occurs in your compile. :-)

Could you test it with binkd-static-perl-zlib-bzlib2.exe version?
It's compiled with different MSVC, comparing to Andrei's one.

WBR, Max. piwamoto!»¿ßѼ-¡ÑΓ
--- ߬πτáε »« FleetStreet'π :-(((
* Origin: Personal Reality (2:5057/77)

Hello Max,

On Sunday May 13 2018 23:11, you wrote to me:

Oh, and BTW, this error that I reported fior Andrei's version...
... no longer occurs in your compile. :-)

Could you test it with binkd-static-perl-zlib-bzlib2.exe version?
It's compiled with different MSVC, comparing to Andrei's one.

D:\FIDO\BINKD>1-1a97\binkd-static-perl-zlib-bzlib2 binkd.cfg
22:22 [3608] BEGIN standalone, binkd/1.1a-IrvinDitz-fork-97/Win32 binkd.cfg
22:22 [3608] servmgr started
22:22 [652] clientmgr started
? 22:22 [3608] servmgr setsockopt (IPV6_V6ONLY): {W32 API error
10042} An unknown, invalid , or unsupported option or
level was specified in a getsockopt or setsockopt call
- 22:22 [3608] servmgr listen on [2001:1c02:1100:d700:f1d0:2:280:5555]:24555
? 22:22 [3608] servmgr setsockopt (IPV6_V6ONLY): {W32 API error 10042}
An unknown, invalid, or unsupported option or level was specified in a getsockopt or setsockopt call
- 22:22 [3608] servmgr listen on [2001:1c02:1100:d700:f1d0:2:280:5555]:24554
- 22:22 [3608] servmgr listen on 0.0.0.0:24554

Same error as with Andrei's compile, but first impression is that it is otherwise OK.


Cheers, Michiel

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

Hello Max,

Sunday May 13 2018 22:23, I wrote to you:

Could you test it with binkd-static-perl-zlib-bzlib2.exe version?
It's compiled with different MSVC, comparing to Andrei's one.

There is something alse I wish to report.

The mingw versions were never stable with the -C option on my system. Ever so often it crashes when the config file(s) change. (WIN XP PRO SP3 32 bit)

The static version does not seem to have this problem. To rigourously test it, I created an event that touches a semaphore file every minutes. In my binkd.cfg
there is this include statement.

include d:\\fido\\binkd\\every5.sema

So binkp reloads the config every 5 minutes. It has been running that way since
this morning. So far so good, no crashes.


Cheers, Michiel

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

Hello Andrei,

Sunday April 29 2018 12:47, I wrote to you:

This is exactly how it should work. Feel free to use skovpen.vlist.eu
to try to repeat my findings,

I will test the server mode next...

OK, server mode. Settings the same as for client mode in pevious test.

Starting server with binkd-static binkd.cfg and creating a poll with

another incarnation of: binkd-static -nP5020/9696 binkd.cfg


<none> binkd calls out with IPv4 and successfully connects

-64 binkd tries to connect with IPv6, fails, connects IPv4

-46 binkd calls out with IPv4 and successfully connects

-6 binkd attempts IPv6, fails and repeats until max max try

-4 binkd calls out with IPv4 and successfully connects

All as expected.

I am starting to think that I made an error in yesterday's test. I think I forgot to reload the config between testing the options.

Mea Culpa.

OK, repeating yesterday's server test calling skopven.org:


<none> binkd calls out with IPv4 and successfully connects

-64 binkd calls out with IPv6 and successfully connects

-46 binkd calls out with IPv4 and successfully connects

-6 binkd calls out with IPv6 and successfully connects

-4 binkd calls out with IPv4 and successfully connects

As it should... ;-)

So... it would seem that yesterday's test are invalid. Sorry if that put you on
the wrong foot.


I still must test with a node with a dual stack node with an invalid IPv4 address ...


And there still is this when starting te server:

D:\FIDO\BINKD>binkd-static -C binkd.cfg
15:19 [2280] BEGIN standalone, binkd/1.1a-97/Win32 -C binkd.cfg
15:19 [2280] servmgr started
15:19 [2352] clientmgr started
? 15:19 [2280] servmgr setsockopt (IPV6_V6ONLY): {W32 API error 10042}
An unknown, invalid, or unsupported option or level was
specified in a getsockopt or setsockopt call
- 15:19 [2280] servmgr listen on [2001:1c02:1100:d700:f1d0:2:280:5555]:24555
? 15:19 [2280] servmgr setsockopt (IPV6_V6ONLY): {W32 API error 10042}
An unknown, invalid, or unsupported option or level was
specified in a getsockopt or setsockopt call
- 15:19 [2280] servmgr listen on [2001:1c02:1100:d700:f1d0:2:280:5555]:24554
- 15:19 [2280] servmgr listen on 0.0.0.0:24554

It does not seem to have any effect. It may be just a warning...


Cheers, Michiel

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

Hello Michiel,

On Sunday April 29 2018 15:17, I wrote to Andrei Dzedolik:

I still must test with a node with a dual stack node with an invalid
IPv4 address ...

Here is what I did. I created a DNS for dd6.vlist.eu. It has the AAAA record of
fido6.ddutch.nl abd an A record of 1.1.1.1

I called 280/5006 with host name dd6.vlist.eu

<none> binkd calls out with IPv6 and successfully connects

-64 binkd calls out with IPv6 and successfully connects

-46 binkd tries to connect with IPv4, fails, connects IPv6

-6 binkd calls out with IPv6 and successfully connects

-4 binkd attempts IPv4, fails and repeats until max max try

All as expected.

That concludes today's testing. ;-)

I will keep binkd-static 1.1a97 running on 280/5555 for now, it seems to be stable enough...


Cheers, Michiel

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

Hello Janne,

On Sunday April 29 2018 17:09, you wrote to me:

AFAIK, there is no 16 bit OS that supports IPv6.

Well... http://www.contiki-os.org/

So there you go... ;-)

But probably zero people use contiki with ipv6 on 8bit (or 16bit) cpus
for Fidonet.

Doubtful indeed...


Cheers, Michiel

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

Hello Michiel!

13 May 18 22:23, you wrote to me:

Could you test it with binkd-static-perl-zlib-bzlib2.exe version?
It's compiled with different MSVC, comparing to Andrei's one.

D:\FIDO\BINKD>1-1a97\binkd-static-perl-zlib-bzlib2 binkd.cfg
22:22 [3608] BEGIN standalone, binkd/1.1a-IrvinDitz-fork-97/Win32 binkd.cfg 22:22 [3608] servmgr started 22:22 [652] clientmgr started ? 22:22 [3608] servmgr setsockopt (IPV6_V6ONLY): {W32 API error

Is this error present in 1.1a-95?

WBR, Max.
--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: Uptime 337 day(s) 17:47:56.110 (2:5057/19)

Hello Max,

On Wednesday May 16 2018 15:59, you wrote to me:

D:\FIDO\BINKD>1-1a97\binkd-static-perl-zlib-bzlib2 binkd.cfg
22:22 [3608] BEGIN standalone,
binkd/1.1a-IrvinDitz-fork-97/Win32 binkd.cfg 22:22 [3608] servmgr
started 22:22 [652] clientmgr started ?
22:22 [3608] servmgr setsockopt (IPV6_V6ONLY): {W32 API error

Is this error present in 1.1a-95?

No.

D:\FIDO6\BINKD>\fido\binkd\1-1a95\binkd-static-perl-zlib-bzlib2.exe binkd.cfg
14:31 [2412] BEGIN standalone, binkd/1.1a-95/Win32 binkd.cfg
14:31 [2412] servmgr started
14:31 [3608] clientmgr started
- 14:31 [2412] servmgr listen on [2001:1c02:1100:d700:f1d0:2:280:5556]:24554


But please note: the error only occurs with Windows XP. Not with Win 7. A good incentive to say goodbye to XP. ;-)

Plus that it does not seem to have any negative effect. As far as I can see it can be safely ignored.


Cheers, Michiel

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