Re: [PLUG] proc filesystem

["Michael C. Toren" <mct@toren.net>]

> As should be predictable, this falls flat on its face on multi-homed
> hosts:

It was written with multihomed hosts in mind (almost every host with
a network connection, having both a loopback interface and an egress
interface, is effectively "multihomed" from the point of view of this
script), and I believe it works as advertised:

> sf0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         inet 66.92.234.100 netmask 0xffffff00 broadcast 66.92.234.255
> sf1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         inet 10.0.0.1 netmask 0xff000000 broadcast 10.0.0.255
> sf2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         inet 192.168.0.4 netmask 0xffffff00 broadcast 192.168.0.255

> grappa:~% ip.pl
> 66.92.234.100

When you connect to 207.106.1.2, your source address will be 66.92.234.100,
presumably because your default route points to a host which is reachable
over your sf0 interface.

> grappa:~% ip.pl 66.92.234.98
> 66.92.234.98

When you connect to 66.92.234.98, your source address will be 66.92.234.98,
I'm guessing because this is a virtualhost, or IP alias, local to the system
you're running ip.pl on.

> grappa:~% ip.pl 10.0.0.234
> 10.0.0.1
> grappa:~% ip.pl 192.168.0.3
> 192.168.0.4

For 10.0.0.234 your source address will be 10.0.0.1, the IP address of your
sf1 interface, and for 192.168.0.3 your source will be 192.168.0.4, the IP
address of your sf2 interface.

Try telneting to those addresses from the same machine you ran ip.pl on,
and running netstat to confirm what local address was selected by the
system.

> (Well, flat on its face in the "telling you the local IP address"
> department... it is doing exactly what it's asked, but not the best
> it could.

How could it do better?  The problem is that the term "local IP address" is
vague, and that it's completely dependent upon where you'll be connecting.

> Istr a way to iterate through the interfaces in C... can't
> you get at that through Socket.pm? I'm in the middle of something
> else right now, but I'll go check when I'm done.)

It's very difficult to do portably, even in C, but tcptraceroute's
getinterfaces() function attempts to.  There's also a perl module on CPAN,
Net::Interface, which provides a similar interface to perl.  It's not
possible to do with Socket.pm alone.

> Btw, mct, cute choice on the default remote host. I guess it can
> probably take the load.

I can guarantee it, no matter what the current load is on ns1.netaxs.com,
as the perl script I pasted doesn't generate any packets :-)  It calls
connect() on a UDP socket to fill in the local IP address based on the
specified destination, and then calls getsockname() to query that address,
but it never writes any data to the socket.  As UDP is stateless and has no
connection overhead, calling connect() alone has no impact on the network.

> Works fine on:
> NetBSD uriel 1.5.3_ALPHA NetBSD 1.5.3_ALPHA (URIEL) #2: Wed Jan 16 07:12:29 EST 2002     gr@uriel.eclipsed.net:/usr/src/sys/arch/macppc/compile/URIEL macppc
> NetBSD grappa 1.6F NetBSD 1.6F (GRAPPA) #8: Thu Aug 15 00:54:54 EDT 2002     gr@grappa:/mp3/tmp/netbsd/src/sys/arch/i386/compile/GRAPPA i386

Thanks, I'll add them to the list.

-mct