Text 10513, 359 rader
Skriven 2013-09-28 12:37:26 av mark lewis (1:3634/12.0)
Kommentar till text 10479 av Michiel van der Vlist (2:280/5555)
Ärende: IPv4 and IPv6
=====================
On Thu, 26 Sep 2013, Michiel van der Vlist wrote to mark lewis:
MvdV>> I have completely disabled automatic calling out in my POTS
MvdV>> mailer. On the very rare occasion that I need/want to make an
MvdV>> outgoing POTS call, I start it manually. That was easier than
MvdV>> filtering all the rubbish in the nodelist that could make it
MvdV>> automatically call unreachable nodes. Here POTS is a relic from
MvdV>> the past...
ml> i'm sorry that your chosen mailer did not keep up with the
ml> capabilities that were being developed back then...
MvdV> No need to be sorry, I never needed those extra capabilities. My
MvdV> POTS mailer is a POTS mailer and has never been used for anyting
MvdV> other than making POTS connections.
because, as i pointed out above, it did not keep up with development back
then... so it languished on the vine until it simply rotted away... if it had
kept up and at least made it as far as the mailer i choose to use for my main
operations, it would still be in use today ;)
MvdV>> Wait a minute... we we talking IPv6/IPv4 SPECIFIC flags, not IP
MvdV>> flags in general...
ml> same difference...
MvdV> The difference is that those IPv6 only nodes that you do not
MvdV> want to call do not exist...
yet...
ml> my mailer uses IBN, IFC and similar to prevent outbound calls...
ml> if a system also has ITN or IVM, then it will call them...
MvdV> I consider FTS-1 or EMSI over Telnet or Vmodem an interesting
MvdV> experiment from the early days of Fido over IP.
only some timings needed relaxing for the most part... i'm not aware of
anything else needing to be done to allow for the extended traversal time of
network packets carrying the xmodem, telink, sealink, zmodem+ protocol packets
in a congested pipe... relaxing the timings that were used in dedicated POTS
pipes enabled the communications to work much more reliably...
MvdV> It is like the early automobiles that looked very much like the
MvdV> carriages used with horses. But cars developed and so did Fido
MvdV> over IP. We now have cars that perform better than the horseless
MvdV> carriage eand we now have the Binkp protocol which is much
MvdV> better suited to fit the reuirements of transporting Fidonet
MvdV> data over TCP/IP.
nice analogy but...
ml> there is no need for my system to attempt to try to connect with
ml> an IPv6 only system since they cannot talk to each other at all...
MvdV> It will not attempt to do that, since there aren't any.
yet...
MvdV>> Since you do not have IPv6, and they have IPv4, you have no
MvdV>> need to know that they are also IPv6 capable. And that goes for
MvdV>> everyone who is IPv4 only. The IPv4 only don't need it. The
MvdV>> dual stack guys do not need it. Nobody needs it.
ml> not yet they don't but it will come...
MvdV> Or not.
mmmhumm...
MvdV> Maybe FidoNet will be dead before we see the First IPv6 only
MvdV> node.
doubtful ;)
MvdV> Maybe when we see the first IPv6 only node, all the rest will
MvdV> already have at least outgoing IPv6 capability IPv6, so that
MvdV> "your problem" is solved before it is born. Or maybe something
MvdV> else happens...
maybe but likely not... not unless something really major happens in the next
several years... but it won't alter my main system applications nor the job
they are required to perform numerous times a day...
FWIW: i get mailer-to-mailer connections over telnet/vmodem on a daily basis
from Z2... there are also some from Z1 and i think even Z3 hits me on
telnet/vmodem occasionally when we have mail to transfer...
ml> just like the ISDN flags were used to prevent POTS systems from
ml> trying to connect with ISDN systems... especially ISDN only
ml> systems...
MvdV> I always used "300" to prevent making POTS calls to isdn only
MvdV> nodes.
i didn't because it was a valid speed and it was useful at times of bad
connections... especially to some back up in the deep mountains and rough
country... i had one connection way back when that was on a party line... that
one was always fun to connect with ;) :)
MvdV> (I still think allowing ISDN only nodes was a mistake
MvdV> that could and therefore should have been avoided, but that's
MvdV> another story)
:)
ml> please remember the reasoning for having these flags and being able
ml> to use them for restricting outbound calls...
MvdV> No need to explain, I have used flags to prevent my POTS mailer
MvdV> from calling binkp capable nodes and let the IP mailer do the
MvdV> job.
MvdV> Unfortunately sloppy nodelist clercks have made that method
MvdV> unreliable. It happened too often that mail went out via POTS,
MvdV> that could have been delivered by binkp. So I completely disabled
MvdV> automatic dialing out by POTS.
i ran into similar until i got my modem control and routing configured
properly... it is one of the reasons why i have to take the extra steps needed
today to add (secure) binkp connections to my setup... this is also one reason
why, if binkp breaks down (eg: 'net connectivity is broken for some reason),
that one cannot connect to me via pots and pick up their waiting mail... i have
to perform special tasks to enable the mail to be picked up via a traditional
POTS connection... i'm slowly working on a method where this should not be
necessary but it is just taking time to work through everything and ensure that
nothing is missed...
ml> while you are at it, let's also not forget that not every system
ml> is the same or has all of the same capabilities ;)
MvdV> Of course. I even have discarded capabilities that I tried out
MvdV> because I found them more of a liability than an asset...
:)
ml>> i don't need experience with IPv6 to know that none of my systems
ml>> can connect to an IPv6 only system...
MvdV>> There are no IPv6 only Fidonet systems.
ml> there will be... you can count on it...
MvdV> Maybe. And if/when they do "your problem" may have solved itself
MvdV> already.
i rather doubt it... remember, i was still running OS/2 Warp 3 Connect up until
about a year ago... i do not plan on moving further than my current OS/2
installation unless i am forced to by something which IPv6 doesn't come close
to doing...
MvdV>> You are trying to cross a bridge that is still beyond the
MvdV>> horizon...
ml> sorry but it is not...
MvdV> Yes it is.
ml> it is on my horizon and has been for a few years...
MvdV> There are no IPv6 only nodes.
you sure are one-eyed (monooptic/myopic/narrow visioned) at times...
MvdV> When there is just one, you can just as easily block it by node
MvdV> number as by flag. When there are two it is just 10 seconds more
MvdV> work. When there are three, we can consider a flag. If the
MvdV> problem is not solved in another way by then...
that means more manual scrutiny than i have given my system in years... thanks
but no thanks... the flag will allow the job to be done by all nodes with no
manual intervention for each node that pops up...
MvdV>> Those should not run servers as they have no control over the
MvdV>> traffic...
ml> right... tell that to all the ones that DO run servers on metered
ml> services...
MvdV> "Hey guys, you should not run servers on a metered service!" OK?
hahahahaha... i don't think they got it ;)
ml> have you never tried to connect to a web server and been met with
ml> a message to the effect of "this server has exceeded its monthly
ml> traffic allotment"?? i have... many times...
MvdV> I have not and I have never even heard about that problem until
MvdV> just now.
i keep telling you that you lead a sheltered life yet you "know everything" or
at least speak out as if you do ;) no offense meant but it is true... if i
could access my data on my other machine, i would provide you with a link to
such... several of them, actually... but i can't because that machine is down
for repairs which are taking much longer than anticipated :(
ml>> we've already seen what happens when ones alloted monthly
ml>> connection traffic is consumed by others... it is one reason why
ml>> we have no more nodes listed in Africa and why that zone no
ml>> longer exists :/
MvdV>> Nonsense.
ml> no, it is not...
MvdV> I think it is.
at times like this, i'm sorry for you that you can't or simply won't accept the
facts...
ml> that is no where near the point i was making and has absolutely
ml> nothing to do with it... i was speaking directly of russel tiedt's
ml> connectivity to the international world... it was limited to a
ml> monthly quota and when it ran out (mostly due to his children
ml> pulling traffic over it instead of using their internal to africa
ml> only connection) then no one outside of africa could contact his
ml> system and he could not contact anyone outside of africa... this
ml> happened numerous times...
MvdV> Russel Tiedt. Yes he is (or was?) a nice guy. But... he had his
MvdV> oddities.
none that i am aware of... other than the connectivity situation in africa
where he lives...
ml> i know specifically because i had mail waiting for his system to
ml> come and pick up numerous times
MvdV> So did I and often it just sat there for weeks or longer because
MvdV> he was out of reach.
because of his quota having been all used up...
ml> as well as our conversations being cut short until the beginning
ml> of the next month when the quota count was reset...
MvdV> Yeah and then his computer was stolen. And then thiefs stole the
MvdV> copper in the street,
this is all true... hell, there was a radio station in california that was
knocked off the air due to copper thieves... they cut the lines while they were
powered up and made off with the copper... these were the lines going up the
mountain to the antenna site... railways have also had problems with copper
signaling cables being stolen... i personally know several folks that did that
and paid the price for it...
MvdV> And then his dog ate the modem. And the cat had kittens.
now you are just being stupid and obnoxious...
MvdV> His excuses for his repeated absences became so numerous and
MvdV> inconsistent that they lost credibility.
not that i saw and i daresay that i had more contact with him and his system
than you did... he was pulling a number of echos from here for numerous years
and i was directly routing all Z5 traffic that came thru here to his system...
what started off as a once a week connection became a daily connection for a
while... then the quota problems started when his ISP changed things around and
implemented a cost based metered connection structure... traffic internal to
africa was unlimited for a reasonable small flatrate... international
connections were a higher rate and metered...
MvdV> The decline of Z5 followed the same pattern that we saw in Z6.
MvdV> People leaving because they lose interest and find greener
MvdV> pastures.
mmmhummm... i suppose you are not aware of holger granholm's problems since
march 2013, then? he is in the auckland islands and is POTS only for various
reasons... he wrote, in a recently arrived message (a bunch starting back in
march just showed up the other day), that he was thinking about pulling the
plug because there was no traffic when he polled his feed... he thought the
network had "gone away"... but he stayed and kept polling and finally something
broke thru somewhere and suddenly he was inundated with old messages that had
been stuck somewhere... it seems that his feed (2:201/111) had a problem with
the next feed (2:201/0) or something else was causing things to be jammed up
further upstream (2:203/0)...
here is the path of one of holger's posts in WIN95 from july 27 2012...
PATH: 20/228 201/111 0 203/0 320/119 261/38 123/500
and here is the path of one of his delayed but recently arrived messages (march
28 2013)
PATH: 20/228 201/111 0 203/0 320/119 123/500
and his latest non-delayed post (september 27 2013...
PATH: 20/228 201/111 0 203/0 320/119 123/500
i don't know when andrew (1:320/119) switched his WIN95 feed from janis to
ross... that might be where the problem was but holger reported a lack of posts
in most of the few areas he carries... he says that even FN_SYSOP was all dried
up and withered... i show 2490 messages in FN_SYSOP since march 29 2013 so
holger should have had plenty to wade thru in at least that one area... he
wonders if it is possible that that area is being filtered?
[aside]
the nodelist shows both 2:201/111 and 2:201/0 as having the same domain and
POTS numbers but a poll to 2:201/111 fails...
+ 28 Sep 13:23:34 [4257] call to 2:201/111@fidonet
28 Sep 13:23:35 [4257] trying bejo.dyndns.org [90.225.13.250]...
28 Sep 13:23:35 [4257] connected
+ 28 Sep 13:23:35 [4257] outgoing session with 90.225.13.250
- 28 Sep 13:23:36 [4257] OPT ENC-DES-CBC
CRAM-MD5-514dea558a6066fb8bb54be62baa04dd
+ 28 Sep 13:23:36 [4257] Remote requests MD mode
- 28 Sep 13:23:36 [4257] SYS Capital Net
- 28 Sep 13:23:36 [4257] ZYZ Christer Jonson
- 28 Sep 13:23:36 [4257] LOC Haninge, Sweden
- 28 Sep 13:23:36 [4257] PHN
- 28 Sep 13:23:36 [4257] NDL MO,CM,IBN:bejo.dyndns.org
- 28 Sep 13:23:36 [4257] TIME Sat, 28 Sep 2013 17:23:35 +0200
- 28 Sep 13:23:36 [4257] VER Argus/3.210/ binkp/1.0
? 28 Sep 13:23:36 [4257] Cannot find domain for zone 2, assuming 'fidonet'
+ 28 Sep 13:23:36 [4257] addr: 2:201/0@fidonet
? 28 Sep 13:23:36 [4257] called 2:201/111@fidonet, but remote has no such AKA
+ 28 Sep 13:23:36 [4257] holding 2:201/111@fidonet (2013/09/28 13:33:36)
+ 28 Sep 13:23:36 [4257] done (to 2:201/111@fidonet, failed, S/R: 0/0 (0/0
bytes))
28 Sep 13:23:36 [4257] session closed, quitting...
sadly it appears that someone is misconfigured for some reason... that or the
nodelist is wrong for 2:201/111...
[/aside]
back to the above about folks leaving... i'm not saying that you are not
correct in your statement above but i am saying that people also leave because
their feed stops flowing for some reason and they can't get any answers if they
ask which seems to confirm that the network has "gone away" so they just pull
the plug... i have to wonder how many of those russian nodes flying fidonet.net
domains in their nodelist entries did the same when their feeds dried up after
the domain was lost...
MvdV> A ZC that keeps up appearances but in the end has to admit that
MvdV> (s)he is the last one standing. Z4 is now repeating that
MvdV> history...
so you say... i, for one, am not so one-eyed as to believe that that is the
only reason...
ml> i was even working with him with the firewall software i support
ml> so that it would be able to handle routing to both connections so
ml> that his children would not cause his quota to run out like it
ml> did...
MvdV> And then he lost interest and pulled the plug...
no... there was more to it as far as the firewall routing stuff went... there
were at least two hospitalizations on my side of the fence during that time and
both involved several months of recuperation... it was more than two or three
years later before he was forced to pull the plug by local to him
circumstances...
)\/(ark
* Origin: (1:3634/12)
|