[KLUG Members] some network questions

[Adam Tauno Williams]

> >>Nope,  the input parameters result in an undefined result; so it should
> >not be expected to make sense, like division by zero.
> >You might not have meant it that way but the dividing by zero comparison
> >makes  really sence: the situation ought not to makes sence. I like that
> >explanation. Thank you.
> The comparison is a little bit suspect, because a computer is expected 
> to error out and stop executing the program (gracefully, you hope) when 
> it encounters a division by zero error.  

It is just a matter od semantics, but no such expectation exists for "a
computer'.  If the developer does not define an exception handler for
divide-by-zero nothing resembling graceful happens.  Do a divide by zero
in machine language on a bare-metal platform like a Z80 based
controller, even if it doesn't go kaput you'll have lost all control of
where the sequence of events is heading.

> "Stopping execution" is not 
> exactly an ideal solution for a network device, so they're expected to 
> keep going in spite of instructions that don't make any sense. 

And it is a pain to protect against every combination of bad parameters.
That is the purpose of a configurator,  but since not every combination
of legitimate parameters can be anticipated (and curses to those who
try) the system should just take whatever it is given.  Most of us have
probably encountered handy wizards that won't let you ever the
parameters required.

> Since a subnet mask with a zero in the middle shouldn't happen, there's 
> no standard for what to do about it, so it is very likely to very 
> between operating system, OS versions, and hardware.

Yep.

> >>But it does make sense.  RARP is defeating your subnetting by turning the
> >whole mess into a really slow LAN - that is what RARP is (or was) for,
> >non-routable protocols could be bridged over WAN links.
> Think you could explain that a bit?  I ignored this discussion at first, 
> thinking RARP was a routing protocol I wasn't familiar with (hey, it 
> sounds a lot like RIP), but some quick googling suggests that it's an 
> alternative to DHCP for diskless workstations.  

That is, or was, the primary purpose of RARP.

> How would getting a protocol level address (IP or similar?) from a hardware 
> level address (MAC) help you go across a subnet if you're dealing with
a protocol 
> that doesn't know subnets?  Is this like ethernet bridging where you
forward 
> MAC information across the link?

Yes,  a RARP service can collect MAC addresses and creates a central arp
table.  Then the RARP service can play havoc on the routing.  It is an
obsolete service; so obsolete that RARP support was dropped from the
main kernel tree...... and they still have DEC LAT support (if that
means anything to you)!

> >>Different compression techniques often only support given protocols or
> >have topology expectations - so they are always sort of a wild card
> >Okee and thats why rarp gets it running while it does not make sence :-
> >This finaly puts things in its place. Great!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.kalamazoolinux.org/pipermail/members/attachments/20051123/2b4a7b34/attachment-0001.bin