[lug] Perl 101

[rm at fabula.de]

On Fri, Apr 19, 2002 at 01:44:10PM -0600, rise wrote:
> On Fri, 19 Apr 2002, John Hernandez wrote:
> 
> > This is probably a nitpick, but that's not precisely true.  They are
> > actually as "routable" as other addresses.
> 
> To be pedantic, the RFC specifies:
> 
>    Because private addresses have no global meaning, routing
>    information about private networks shall not be propagated on
>    inter-enterprise links, and packets with private source or
>    destination addresses should not be forwarded across such
>    links. Routers in networks not using private address space,
>    especially those of Internet service providers, are expected to be
>    configured to reject (filter out) routing information about private
>    networks. If such a router receives such information the rejection
>    shall not be treated as a routing protocol error.
> 
> They're often called "non-routable" because routing across the
> Internet is the primary interesting case and "globally non-routable"
> costs a whole word slot in conversation (oh, horror of horrors).  Yes,
> you can use them within a single enterprise and route them to your
> heart's content, but you can't get them routed across the Internet
> which I'd call a significant decrease in routability.

Unless your provider is as smart as a bean-bag :-) I once traced a ping
to an 192.168.... address all the way up to our national gateway -- the 
phone support of the ISP mumbled something about " ... we need it for 
IP accounting". Never assume that packets to these  addresses won't get
routed.

>[..]
> 
> I'd be more inclined to guess firewalling that dislikes some
> particular of Net::Ping's ICMP packets - he does note that he sees
> activity lights for the pings and that code works for me with every
> pingable IP I've tried (including setting up 192.168.1.108 on one of
> my local interfaces).  The best way is probably to slap something
> user-friendly like ipgrab on the interface and compare a command-line
> ping with one from Net::Ping.  This kind of stuff is why Paul Barry's
> perl networking book starts by building a packet sniffer for debugging
> (well, that and it's fun).


Hmmmmm. Tried the posted code (BTW, publishing a perl book that doesn't introduce 
test of a return code? Talk about teaching good coding habits early ...).
The following is my modified version:

#----file : /tmp/ping.pl ----
#!/usr/bin/perl

use Net::Ping;

$hostname = "192.168.2.80";
$timeout = 50;

my res;

if ($res = pingecho($hostname, $timeout)) {
        print "host is alive\n";
        }
else { print "Dead as a bean!\n"; }
print "$res\n";
exit; 

#--end file -----

bash-2.05$ perl /tmp/ping.pl 
Dead as a bean!
0
bash-2.05$ 

Ok, i traced this and on the network i see the echo request as well as the 
echo reply from the remote host. I'd say something is fishy in the perl module
(note: pingecho _is_ deprecated).

 Ralf

> -- 
> Jonathan Conway						      rise at knavery.net
> history is paling & my surge protection failed, & so I FRIED
> 						- Concrete Blonde, "Fried"
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug