I want this from my first day in Fido =)
MvdV> So... translate it into Russian and post it in binkd.ru. MaybeI want this from my first day in Fido =)
Completed, but it's doubtful. I'm waiting for a response: "Commit
patch to the git" =)
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.
I know binkd runs on multiple OS's, but still it relies on 'getaddrinfo' and its sorting rules :)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 =)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.
3. if possible to make the choice of IPv6-only by means of a binkd,
then why impossible to make priorities? =\
3. if possible to make the choice of IPv6-only by means of aDid I say it is impossible? I proposed to discuss and find a common
binkd, then why impossible to make priorities? =\
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?
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.
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?
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. ;-)
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 :)
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.
NULL
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 ...
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...
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.
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.
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.
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 ;)
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 ;)
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 :)
If anyone know how to build binkd for Windows let me know :)
- 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.
If anyone know how to build binkd for Windows let me know :)
With cygwin it's easy:
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?
Please give it a try and let me know the results here or by netmail.
Please give it a try and let me know the results here or by
netmail.
Works! :)
-
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! :)
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.
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.
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.
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?
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 ...
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?
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?
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.
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...
 ml> i don't have a clue what DOS networking stacks may have these days...  ml> freeDOS might have IPv6 by now but i've not looked at it in a long  ml> time... winwhatever, *nix and mac, sure...
AFAIK, there is no 16 bit OS that supports IPv6.
I still must test with a node with a dual stack node with an invalid
IPv4 address ...
AFAIK, there is no 16 bit OS that supports IPv6.
Well... http://www.contiki-os.org/
But probably zero people use contiki with ipv6 on 8bit (or 16bit) cpus
for Fidonet.
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/
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.
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
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.
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
That concludes today's testing. ;-)
I will keep binkd-static 1.1a97 running on 280/5555 for now, it seems
to be stable enough...
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
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
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.
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.
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. :-)
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.
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.
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.
:)
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.
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:
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. ;-)
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
Is this error present in 1.1a-95?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
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?
Could you test it with binkd-static-perl-zlib-bzlib2.exe version?
It's compiled with different MSVC, comparing to Andrei's one.
Oh, and BTW, this error that I reported fior Andrei's version...Could you test it with binkd-static-perl-zlib-bzlib2.exe version?
... no longer occurs in your compile. :-)
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.
Sysop: | sneaky |
---|---|
Location: | Ashburton,NZ |
Users: | 25 |
Nodes: | 8 (0 / 8) |
Uptime: | 147:37:42 |
Calls: | 1,905 |
Calls today: | 1 |
Files: | 11,079 |
Messages: | 935,196 |