in reply to Perl network programming

On the face of it, a function (pack_sockaddr_in) is being called with something with length 0, instead of length 4. Given the name of the function and the fact that it's expecting a '4', I'd guess that it wants an IP address.

So my best guess is that you're running a script which gets an IP address from somewhere (perhaps on the command line as an option, perhaps from a config file, perhaps it queries the system to find one) and this isn't happening, so the variable which normally contains the IP address is empty - causing the error.

So you might want to check whatever documentation you have for this script (or read the source) to see how it gets the IP address it listens on. You might also want to check that if the box has any additional IP addresses, they are all present.

Of course, this is all supposition. For trouble-shooting, some useful things to know are:

Good luck.

p.s. The comments boxes on perlmonks take HTML, not plain text. Amongst other things, this means that your comment appears on one long line (and is harder to read) unless you break it up with <p> or <br> tags. You can use the 'Preview' button to see how others will see your comment.

Replies are listed 'Best First'.
Re^2: Perl network programming
by Viki@Stag (Sexton) on Oct 03, 2007 at 08:15 UTC
    Thank you all for the reply.

    Actually i read a configuration file for the IP address. I have tried running the same code inside a private LAN (all machines having private IPs) where it worked fine. But when i try it using public IPs it shows this error.

    Is that scenario causing this error, or is it faulting in reading the config file.
[reply]
      My money's on the config file. Perhaps a permissions problem?

      If so, the script could probably benefit from better error detection. If an IP address is required (as it seems to be) the code should validate that it has an IP address early on, and give a more informative error message.

      Some tools for chasing down the problem:

      • use 'strace' to see what the script does when it runs. If it fails to open() a config file, you'll see an error code (e.g. EPERM) which tells you why. The output of strace is voluminous, but you can send it to a file and grep it.
      • add some debugging to your script. log the value of the ip address at different stages of the processing.
      • make sure your script is handling errors correctly (a good way is to just 'die' if an unrecoverable problem occurs. e.g: 
        my $cfg_file = "/my/config/file";
open(my $fh, "<", $cfg_file)
    or die "can't read config file [$cfg_file] for reading: $!";

        [download]
        Note that we putting $! in your error handling gives you the reason why the open failed, which may help you track down the problem.
      As others have noted, I'm speculating wildly because we can't see your code. On the other hand, if your script is large it may not be useful to see all of it.

      If you can try reducing your script to the minimum amount which reproduces the problem that would be useful. You'll also often find that doing that helps you find the problem yourself.

      Good luck.

[reply]
[d/l]
[select]
        $cfile = $ENV{'OCONFFILE'};
        open( CFILE, $cfile ) || return "FAIL0:No such file: $cfile!\n";

        The code given above is the actual part tht gets the config file path & opens the file for read.

        As u said the code is huge for me to post it. Anyway i got around the issue, it was with setting the global variable OCONFFILE to correct path.

        jbert, thanks once again
[reply]
      It might be caused by the phase of the moon... we don't know without seeing some code.

      -David

[reply]

In Section Seekers of Perl Wisdom