all my home devices have now working on ipv6, test point is http://ipv6.junc.eu/
all my home devices have now working on ipv6, test point is http://ipv6.junc.eu/
i just get still bad results on ipv6-test sites, but why fix it ? :=)
Benny Pedersen wrote to All <=-
i just get still bad results on ipv6-test sites, but why fix it ? :=)
trying ipv6.junc.eu [2a01:7e00:e000:146::2]...
07 Mar 2018 21:03, Tommi Koivula wrote to Benny Pedersen:
trying ipv6.junc.eu [2a01:7e00:e000:146::2]...
thanks but dont use hostnames that is not in nodelist :=)
trying ipv6.junc.eu [2a01:7e00:e000:146::2]...
thanks but dont use hostnames that is not in nodelist :=)
Ok.. But the nodelisted hostname does not answer.
=== Cut ===
20:14 [7284] BEGIN, binkd/1.1a-96/CYGWIN_NT-6.1 -p -P 230/0 binkd.cfg
20:14 [7284] creating a poll for 2:230/0@fidonet (`d' flavour)
20:14 [7284] clientmgr started
+ 20:14 [3684] call to 2:230/0@fidonet
20:14 [3684] trying f0.n230.z2.nodelist.fidonet.fi
[2a06:4000:d078:0:e4c:1ad9:
8af1:a3c4]...
? 20:14 [3684] connection to 2:230/0@fidonet failed: Connection timed out === Cut ===
+ 20:14 [3684] call to 2:230/0@fidonet
20:14 [3684] trying f0.n230.z2.nodelist.fidonet.fi
i see themultixpoint.junc.eu in both, the fidonet nodelist and the binkd.txt file...
host themultixpoint.junc.eu
host f0.n230.z2.nodelist.fidonet.fi
Ok.. But the nodelisted hostname does not answer.
trying ipv6.junc.eu [2a01:7e00:e000:146::2]...
thanks but dont use hostnames that is not in nodelist :=)
Ok.. But the nodelisted hostname does not answer.i don't see the below hostname in the nodelist...
if some could advise on TP-LINK Achor C9 firmware, i know there is
3dr party firmware for it, but dont know yet if thay solve my problem
or not
OpenWrt/LEDE 17.01.4 supports Archer C9 v1.
all was plug and play with that firmware, what i just needed was to
set static lan mac addr and do fidonet portforwards, no other configs
was needed to make it work
Great! And it offers plenty of IPv6 goodness ;)
OpenWrt/LEDE 17.01.4 supports Archer C9 v1.
Benny Pedersen -> Markus Reschke skrev 2018-03-14 21:55:
Ahem, maybe not the most efficient route:
X-JAM-PATH2D: 261/38 393/68 770/1 280/464 203/0 2
Looks pretty fast. :D
missing wifi firmware in that build, oh well
solved with a wifi expander
or could get some wifi ap hardware now
what do others do ?
I count to 31 packages on their web site. What package do I need
for my LinkSys WRT54GL?
With 4MB Flash and 16MB RAM it isn't supported anymore by any recent OpenWrt version.
Ahem, maybe not the most efficient route:
X-JAM-PATH2D: 261/38 393/68 770/1 280/464 203/0 2
Why?
Other hardware revision with a different WiFi chipset or WiFi chipset with proprietary driver?
solved with a wifi expanderI'd go for a dedicated AP.
With 4MB Flash and 16MB RAM it isn't supported anymore by any recentThat's what I suspected. Thanks for the info though.
OpenWrt version.
Looks pretty fast. :D
Thanks to the FidoWeb yes, but still not the most efficient path from within R20.
Ahem, maybe not the most efficient route:
X-JAM-PATH2D: 261/38 393/68 770/1 280/464 203/0 2
my tp-link can have opentracker6 installed on spare memory :)
my tp-link can have opentracker6 installed on spare memory :)
Meanwhile several router models with dual-core ARM and 512MB RAM are supported by OpwenWrt. For additional disk space simply add an USB
stick.
Looks pretty fast. :D
Thanks to the FidoWeb yes, but still not the most efficientthere is no provision in anything FTN for figuring out and
path from within R20.
following the fastest path from one system to another
so there's no way to figure any sort of ""efficient path"" from
anywhere to anywhere else...
Looks pretty fast. :D
Thanks to the FidoWeb yes, but still not the most efficient path
from within R20.
there is no provision in anything FTN for figuring out and following
the fastest path from one system to another
Most of the Fidonet doesn't need that.
so there's no way to figure any sort of ""efficient path"" from
anywhere to anywhere else...
There is at least one quite similar to OSPF, but documenting it would
take a whole eternity - first translate the "brief" description from Russian, after that write an FSP... just for 10...20 more nodes to
have a bit faster netmail delivery?
Ahem, maybe not the most efficient route:
X-JAM-PATH2D: 261/38 393/68 770/1 280/464 203/0 2
I agree with mark, there is no provision for the most efficient
route, and in de the web. The fastest route is alway the winner. As
the promotor of the Web, you should be aware of that.
You don't want the most efficient route,
Thanks to the FidoWeb yes, but still not the most efficient path
from within R20.
there is no provision in anything FTN for figuring out and following
the fastest path from one system to another
Most of the Fidonet doesn't need that.
so there's no way to figure any sort of ""efficient path"" from
anywhere to anywhere else...
There is at least one quite similar to OSPF, but documenting it would
take a whole eternity - first translate the "brief" description from
Russian, after that write an FSP... just for 10...20 more nodes to
have a bit faster netmail delivery?
we're talking about echomail, though... but yes, it isn't worth it to
try to do anything to figure it out... documenting not withstanding...
it would require non-mail traffic and a lot of probing of mailers and tossers to somehow pull routing information that can be consolidated
into some sort of a map... that was painful back in the day when it
was done and many refused to provide such mappings because it is none
of anyone else's business where one's mailer(s) connect for mail transfers...
we're talking about echomail, though... but yes, it isn't worth it to
try to do anything to figure it out... documenting not
withstanding... it would require non-mail traffic and a lot of
probing of mailers and tossers to somehow pull routing information
that can be consolidated into some sort of a map... that was painful
back in the day when it was done and many refused to provide such
mappings because it is none of anyone else's business where one's
mailer(s) connect for mail transfers...
The internet wouldn't work with that attitude.
I think we should move this discussion to another echo.
Michiel van der Vlist wrote to Kees van Eeten <=-
It depends on the definition of "efficient". As IPv6 evangelist, I
prefer a path that avoids nodes that do not support IPv6. In the above example only two nodes do not support IPv6, so while it is not optimal, it is not all that bad either...
I prefer a path that avoids nodes that do not support IPv6. In
the above example only two nodes do not support IPv6, so while
it is not optimal, it is not all that bad either...
From a message transfer point of view, IP protocol doesn't matter.
Most people would regard timely delivery as the measure of
"efficiency".
If the fastest path goes via IPv4 or even dialup, who cares?
(other than people in this echo ;) ).
That said, I will encourage IPv6 support where possible, and run IPv6
on all of my systems that support it (which is almost everything).
i am still seems blocked inbound on ipv6 with my isp, sorry, so i have enabled my vps xinetd redirect that still works
i will talk with my isp tommorow about that problem, and possible why inbound ipv6 is border blocked :(
oubound works even from global scoped ip in ifconfig
Michiel van der Vlist wrote to Tony Langdon <=-
From a message transfer point of view, IP protocol doesn't matter.
Some claim that IPv6 is slightly faster than IPv4. http://www.potaroo.net/ispcol/2016-08/v6perf.html
But even if that claim can be substantiated, it is irrelevant for Fidonet.
Most people would regard timely delivery as the measure of
"efficiency".
Reliability and stability of the connection is also a factor I'd say.
If the fastest path goes via IPv4 or even dialup, who cares?
In the case of dialup: those who's dial up line involves cost, as often was the case in the POTS only days...
(other than people in this echo ;) ).
Well, /here/ is where the people in this echo can be found. So most of the people that read this probably do care. Call me en elitist, but supporting IPv6 still isn't an automatism. It requires some extra
effort. My guess is that those willing and able to make that extra
effort have a tighter bond to their system than those who do not
bother. On average of course, but my impressiosn is that there are a
lot of nodes that just run on inertia rather than active sysop involvement. You will find less of those among the members of the IPv6 club.
That said, I will encourage IPv6 support where possible, and run IPv6
on all of my systems that support it (which is almost everything).
Same here. Plus that when adding new links and having to make a choice,
I prefer to link to the IPv6 capable node over linking to the IPv4 only node.
On average of course, but my impressiosn is that there are a lot of
nodes that just run on inertia rather than active sysop involvement.
You will find less of those among the members of the IPv6 club.
Yes, you need to take active steps in a lot of cases,
IPv6 may not be automatically enabled in some Fido software (that
supports it). Network wise, it depends on your ISP. Mine enables IPv6
by default and all of the routers they provide support IPv6 out of the box, so at the network level it should "just work".
Wasn't the case for me, but that's because I added IPv6 before it went into production. It was still a trial service (back in early 2011),
and I had to turn it on to enable the trial, once I had a router that
was IPv6 capable. That trial service did eventually become the
production service I'm on today.
Same here. Plus that when adding new links and having to make a
choice, I prefer to link to the IPv6 capable node over linking
to the IPv4 only node.
Me too, I think around 50% of my upstream links have IPv6 here.
Michiel van der Vlist wrote to Tony Langdon <=-
For starters: 30% of the nodes in my list of IPv6 capable nodes still connect via a tunnel. Setting uo a tunnel certainly requires taking active steps.
IPv6 may not be automatically enabled in some Fido software (that
supports it). Network wise, it depends on your ISP. Mine enables IPv6
by default and all of the routers they provide support IPv6 out of the box, so at the network level it should "just work".
Your ISp is a pioneer. Many ISPs around the world are still dragging their feet. So " just work" is still the exception rather than te rule.
I have native Dual Stack now for over a year, but my ISP is also one of the slow ones. Plus that now their policy is to go DS -Light. New customers get DS-Light. On request they can be converted ti IPv4 only. That is another spoke in the whell of "just work".
Same here. Plus that when adding new links and having to make a
choice, I prefer to link to the IPv6 capable node over linking
to the IPv4 only node.
Me too, I think around 50% of my upstream links have IPv6 here.
Same here, around 50%. In future, I may even drop some IPv4 only links
to up the percentage. ;-)
I've just got to 7 years of native dual stack here.
Same here, around 50%. In future, I may even drop some IPv4 only
links to up the percentage. ;-)
That's not an option, the IPv4 uplinks are sole providers for
othernets. :) While I'm a big supporter of IPv6, it's not the hill I choose to die on. :)
Michiel van der Vlist wrote to Tony Langdon <=-
Hello Tony,
On Tuesday March 20 2018 09:32, you wrote to me:
I've just got to 7 years of native dual stack here.
Lucky you... ;-)
That's not an option, the IPv4 uplinks are sole providers for
othernets. :) While I'm a big supporter of IPv6, it's not the hill I choose to die on. :)
If in effect you are the IPv6/IPv4 gateway to those othernets, you are excused, ;-)
I was not planning on dropping all IPv4 links. Just a few redundant
links to massage the statistics, ;-)
If in effect you are the IPv6/IPv4 gateway to those othernets,
you are excused, ;-)
Well, if someone did want to get an IPv6 feed, I would be happy to
oblige, if the net coordinator was happy with that. Certainly a way
to make sure DS-Lite nodes can be sent mail without having to poll all
the time.
I was not planning on dropping all IPv4 links. Just a few
redundant links to massage the statistics, ;-)
Haha fudging the books? ;)
Michiel van der Vlist wrote to Tony Langdon <=-
Are there any DS-Lite nodes yet over there? AFAIK there are no DS-Lite nodes in Fidonet yet. But if they come, it should not b a big problem
to accomodate them. There are enough IPv6 nodes to give them a feed.
Also there is Feste-IP.net. If DS-Lite gets a foorhold in your part of the world, I am sure similar services will surface over there.
I was not planning on dropping all IPv4 links. Just a few
redundant links to massage the statistics, ;-)
Haha fudging the books? ;)
Giving preference to one service over another is an established way to promote something.
| Sysop: | Winzlo |
|---|---|
| Location: | Minnesota, USA |
| Users: | 11 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 495940:12:28 |
| Calls: | 82 |
| Files: | 1,070 |
| D/L today: |
27 files (11,920K bytes) |
| Messages: | 286,975 |