HP3000-L Archives

September 2003, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Gavin Scott <[log in to unmask]>
Reply To:
Gavin Scott <[log in to unmask]>
Date:
Fri, 12 Sep 2003 17:48:06 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (27 lines)
James writes:
> Hmmm... kewl... Not sure if this is a bug or what, but the
> problem (or feature) is not specific to FTP.

This sort of problem seems to be quite common in older network tools written
in C, or that use older network helper functions (written in C).  In this
case it's probably calling atoi() on each part of the address and moving the
result into the 8-bit field in an address structure without (in typical C
style) any range checking that would notice that all the higher-order bits
are getting shaved off.

The other common "feature" of IP Address parsing that bites people is that
atoi() (I believe) implements some conventions of C in that numbers with a
leading zero are interpreted as being octal, so if you try to be clever and
list your IP Addresses so that they line up nicely as in: 010.010.013.022
then you can spend a very very long time staring at this wondering why it's
not working or why it's actually getting to 8.8.11.18.  You can get away
with this on most 3000 stuff (in fact NMMGR likes to put things in this
format), but occasionally something (bootp maybe) will happen to pass the
numbers though something that knows about the octal convention and then it
stops working even though it *looks* perfect.

G.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2