Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Net::Ping Problems

by Paulster2 (Priest)
on Oct 21, 2003 at 23:16 UTC ( [id://301104]=perlquestion: print w/replies, xml ) Need Help??

Paulster2 has asked for the wisdom of the Perl Monks concerning the following question:

While trying to port code from our Enterprise server to one of our Blade workstations, I was working through changing directory pointers and so forth. One of the problems I encountered was a problem with Net::Ping, in that I kept getting an error saying “Can’t get tcp protocol by name” or “Can’t get udp protocol by name” depending on which method I was using. I was able ping on the command line to the destination, but still unable to make the code work. The portion of the code was easily tracked down to a part of the Net::Ping module that reads like this:

elsif ($self->{“proto”} eq “tcp”) { $self->{“proto_num”} = (getprotobyname(‘tcp’))[2] || croak(“Can’t get tcp protocol by name”); $self->{“port_num”} = (getservbyname(‘echo’, ‘tcp’))[2] || croak(“Can’t get tcp protocol by name”); $self->{“fh”} = FileHandle->new(); }

I was able to tweak this module a little bit, with pretty good results, as I was able to go back to the original code I was using with minimal porting. It now looks something like this:

elsif ($self->{“proto”} eq “tcp”) { $self->{“proto_num”} = (getprotobyname(‘tcp’))[2]; # || # croak(“Can’t get tcp protocol by name”); $self->{“port_num”} = (getservbyname(‘echo’, ‘tcp’))[2]; # || # croak(“Can’t get tcp protocol by name”); $self->{“fh”} = FileHandle->new(); }

By forcing the module to continue instead of “croak”ing, I was able to let it complete and get the comeback that it needed to succeed. I also changed (earlier in the module) the max timeout value. This is important because the code I am using has to go out and check over 125 workstations. If some of them are dead, the timeout multiplies fast. I was able to use Shell.pm and run it through the command line from within the program, but the time minimum timeout value allowed is one second, so the other day when all of our workstations were down due to an impending power outage, it took forever for that part of the code to run. Using Net::Ping seems to run much faster.

My questions are these to anyone who might be a little bit more experienced than I:

What, if anything, might this break if left this way, and why would this cause a problem in the first place? Since I am using 5.6.0, was this problem fixed with 5.8 (or newer)? Is this a know problem or am I just hosed (no I’m not from Canada)?

Any thoughts would be appreciated.
PS: Sorry for the book.

Replies are listed 'Best First'.
Re: Net::Ping Problems (aka I should have posted it here first instead of the PerlMonks Discussion page!)
by Abigail-II (Bishop) on Oct 22, 2003 at 00:17 UTC
    The fact that you can't find the prototype by name, or the service by name suggest that the databases in /etc/protocols and /etc/services have problems. Either they are unreadable (permissions? chrooted environment?), empty, corrupt, or are lacking elementary entries, none of which should happen on a standard Solaris install. The fact they fail is more likely to be an OS issue than a Perl issue (but it could be a Perl issue).

    As for the question whether this breaks something, that's hard to say. That all depends on what the code is doing with the values. Since your program seems to be running ok without having the results of the get*byname functions, my question is, is the program using the values?

    Abigail

      I have checked the /etc/services and found that the port is activated as it should be. I have not, however checked the /etc/protocols to see if there are any problems. I will also check the perms. Thanks for the suggestions.

      As far as I can tell, the program is running fine as is, and is not using the other functions/values. So, I guess that is a good thing, and I really shouldn't be to worried about it. Thanks again.
      Paul

Re: Net::Ping Problems
by grinder (Bishop) on Oct 22, 2003 at 06:12 UTC

    If a sysadmin decides, somewhere down the track, that tcp echo ports should be turned off for security reasons, your script will fail. In that event, you will have to switch to ICMP, and such a script can only be run as root. Note that this is what you do when you "ping from the command line". If you look closely at the ping binary, you will see that it is suid root.

    There is nothing wrong with patching the Net::Ping source code per se to achieve your ends, but now it's something to remember when you upgrade Perl (read: something you are going to forget :). In other words "one more damned thing to go wrong."

    A better solution would be to eval the Net::Ping call, that way, if and when it fails, you'll trap the error and be able to continue your script. (The croak message will be delivered to the $@ variable -- you might want to (sys)?log it somewhere).

    You might also want to investigate Parallel::ForkManager, which, as its names suggests, will let you run a farm of pingers. This will stop single timeouts from dragging your program's run-time into the ground.

      Thanks for the suggestions, I will check into Parallel::ForkManager tomorrow when I get into work!
      Paul

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://301104]
Approved by hossman
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others goofing around in the Monastery: (4)
As of 2024-03-29 12:25 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found