[nos-bbs] FTP wierd socket from domain.txt

[(Skip) K8RRA]

Hi Jay, 

On Sat, 2007-05-26 at 14:24 -0400, Jay Nugent wrote:
> Greetings,
> 
> On Fri, 25 May 2007, (Skip) K8RRA wrote:

> > I have traced the strange IP 206.112.100.132 back into the domain.txt
> > file of my neighbor.  It belongs to the domain "rtimer.ampr.org".  There
> > are four entries for this domain that seems senseless?  
> 
>    Really????  What are they?
My neighbor is Dave (who also reads this reflector) and maybe he would
attach a copy of it to email for you.  It probably originated from you
but got revised by having the update switch ON.  As of today the update
switch is OFF.  I have edited it - there were several things I threw
away, plus two lines got concatenated somehow.  I need to chat with him
before my edited version goes live - so I'll ask him to email you both
versions for your inspection.
> 
>    # host 206.112.100.132
>      132.100.112.206.in-addr.arpa is an alias for 132.128.100.112.206.in-addr.arpa.
>      132.128.100.112.206.in-addr.arpa domain name pointer unknown.
> 
>    Looks like the DNS 'ptr' record points to another record which then 
> points to no where :(
Hey - some day you might want to lead me thru that 40-bit address above
- neither 32 nor 64 bit / I don't want to know today...
> 
>    # host rtimer.ampr.org
>      Host rtimer.ampr.org not found: 3(NXDOMAIN)
> 
>    And there is no record for 'rtimer.ampr.org' -- so it is unresolvable 
> back to any IP address, let alone one in the 44/8 space.
YUP
> 
>    So please fill me in as to what this has anything to do at all with 
> regard to the 'rtimer' setting which controls the "IP reassembly 
> time-out"?
Here it is:
Dave WA8RSA has been my link to the world for a year + and as you know
we have struggled with thruput and reliability.  For example right now I
have SMTP traffic for ve1ama in queue for the past 20 hrs.  His mail
goes out sporadically at best, but eventually the path will clear and it
will go (as in the past?).  Also there is mail for wa8rsa that already
has been delivered 4 times and not removed from my queue.  I am waiting
for SMTP to clear the queue so I can see the transaction difference from
a trace I am running.

To answer your question, A week(+) ago I generated a 90K text file as an
FTP transfer benchmark.  The first transfer went flawlessly and not
actually "too slow", but there was room for improvement.  Thus I began
revising my configuration (not Daves).  An early revision I made was to
change paclen from 200 to 256 bytes.  That change caused segmentation
for the first time.  From that time until now FTP has acted badly.  Now
comes rtimer=4 on his end (I don't remember why it is called out and set
so low / not 30 as you point out).  However for the past year we had no
segmentation so rtimer was never utilized.

Suddenly FTP could not instantiate the ftpd socket for data transfer
(because?) the IP was this bogus 112... number.  Like you, I could not
find what it meant, and until yesterday where it (probably?) came from.
Hey it is a *guess*, but the difference between success and failure
seems to be segmentation and a VERY SHORT rtimer.  In fact, it would not
surprise me it is so short that internally to Daves jnos there are
multiple restarts going on simultaneously --> srtt runs around 30
seconds sometimes...

As I said somewhere along the line this smells like a buffer overrun and
so I do not get too tied up seeing rtimer.ampr.org as a domain when
rtimer is a suspected offender in some other part of the package.  The
domain name does not belong in domain text!
> 

>    Very true.  So how did you come up with the idea that this timer had 
> anything whatsoever to do with needing to perform a DNS resolve for an 
> address?   This makes absolutely no sense.   Care to share your step by 
> step anaylsis of how you came to this conclusion? 
I agree - no sense at all.
But the *fastest* way to generates errors is with a computer.
And when it does make error - the error does not need to make sense!
> 

>    What was your ORIGINAL problem that led you down this dark and dingy 
> street of smoke and mirrors????
Does this answer most of your question?
A copy of the domain.txt might help - or might not be needed.

I expect Dave and I will be able to settle on better configuration in
the next week.  Likely without segmentation again.  Then all this
excitement will be over?
> 
>       --- Jay  WB8TKL


73
de [George (Skip) VerDuin] K8RRA k