FAQ
Hi All,

I'm running into a problem with a pretty old freeware perl script called
"readnews" it is in an archive named "readnews-1.85.tar.gz" that is
available here:

http://web.archive.org/web/20080616183736/http://www.scn.org/~bb615/scripts/readnews-1.85.tar.gz

I used these plus inn to create a private bulletin board setup. The
system works perfectly under FreeBSD 6.4 running perl 5.8.8, and appears
to work under Ubuntu running perl 5.10.1 but fails immediately under
FreeBSD 8.1 running perl 5.10.1

The problem is in this fragment of listgroups.pl:

.
.
.

sub ConnectToNewsServer
{
# get news host name
($name, $aliases, $proto) = getprotobyname ('tcp');
if ($port !~ /^\d+$/)
{
($name, $aliases, $port) = getservbyname ($port, 'tcp');
}
if ($newshost =~ /(\d+)\.(\d+)\.(\d+)\.(\d+)/)
{
$thataddr = pack ('C4', $1, $2, $3, $4);
}
else
{
if ($newshost =~ /(\w+)(\.\w+)*/)
{
($name, $aliases, $type, $len, $thataddr) = gethostbyname
($newshost);
}
else
{
print "Error: NNTP host not specified in proper format\n";
exit 1;
}
}

# get socket
$this = pack ($sockaddr, $AF_INET, 0, $thisaddr);
$that = pack ($sockaddr, $AF_INET, $port, $thataddr);
if (!socket (S, $AF_INET, $SOCK_STREAM, $proto))
{
print "Error: socket failed $1\n";
exit 1;
}

# bind to socket
if (!bind (S, $this))
{
print "Error: bind to $this failed $1\n";
exit 1;
}

# connect to socket
if (!connect (S, $that))
{
print "Can't connect to $newshost tcp/ip port $port. Error: $1\n";
exit 1;
}

# buffer the socket
select (S);
$| = 1;
select (STDOUT);

# read server status
$_ = <S>;
($status, $rest) = split (/ /, $_, 2);
if ($status == 200 || $status == 201)
{
# 200 server ready - posting allowed
# 201 server ready - no posting allowed
}
else
{
print "$newshost refused connection: status $status - $rest\n";
exit 0;
}
}


Everytime I run it I get the immediate error

"Can't connect to XXXX tcp/ip port 119. Error: "

(I removed the name of the actual server system)

I've tried this on several FreeBSD systems and get the same problem
on all of them.

If it was a firewall thing I would expect the code to hang
then fail, but this just exits immediately, like it can't
create the socket.

I know the code is a decade old and probably isn't the
recommended way of doing things nowadays but we want to
upgrade the server and this is what is keeping me from
doing it, and I don't want to really tear into the thing
and use something else.

Any suggestions?

Thanks,
Ted

Search Discussions

  • Jim Gibson at Feb 24, 2011 at 3:19 am

    At 6:16 PM -0800 2/23/11, Ted Mittelstaedt wrote:
    Hi All,

    I'm running into a problem with a pretty old freeware perl script called
    "readnews" it is in an archive named "readnews-1.85.tar.gz" that is
    available here:

    http://web.archive.org/web/20080616183736/http://www.scn.org/~bb615/scripts/readnews-1.85.tar.gz

    [program fragment snipped]
    Everytime I run it I get the immediate error

    "Can't connect to XXXX tcp/ip port 119. Error: "

    (I removed the name of the actual server system)
    Can you connect via telnet?

    telnet XXXX 119

    Can you ping the server?

    ping XXXX

    Those will tell you if it is a connectivity problem.
    I've tried this on several FreeBSD systems and get the same problem
    on all of them.

    If it was a firewall thing I would expect the code to hang
    then fail, but this just exits immediately, like it can't
    create the socket.
    It can create the socket, but the socket cannot connect to the server socket.
    I know the code is a decade old and probably isn't the
    recommended way of doing things nowadays but we want to
    upgrade the server and this is what is keeping me from
    doing it, and I don't want to really tear into the thing
    and use something else.

    Any suggestions?
    Well I know that it is not what you want to hear, but it is probably
    time to rewrite the program using a module that has already been
    written and done all of the hard work for you. See the Net::NNTP
    module on CPAN or search <http://search.cpan.org> for NNTP for
    alternatives.

    --
    Jim Gibson
    Jim@Gibson.org
  • Ted Mittelstaedt at Feb 24, 2011 at 4:24 am

    On 2/23/2011 7:18 PM, Jim Gibson wrote:
    At 6:16 PM -0800 2/23/11, Ted Mittelstaedt wrote:
    Hi All,

    I'm running into a problem with a pretty old freeware perl script called
    "readnews" it is in an archive named "readnews-1.85.tar.gz" that is
    available here:

    http://web.archive.org/web/20080616183736/http://www.scn.org/~bb615/scripts/readnews-1.85.tar.gz

    [program fragment snipped]
    Everytime I run it I get the immediate error

    "Can't connect to XXXX tcp/ip port 119. Error: "

    (I removed the name of the actual server system)
    Can you connect via telnet?

    telnet XXXX 119

    Can you ping the server?

    ping XXXX

    Those will tell you if it is a connectivity problem.
    Yes, I can, that works just fine.
    I've tried this on several FreeBSD systems and get the same problem
    on all of them.

    If it was a firewall thing I would expect the code to hang
    then fail, but this just exits immediately, like it can't
    create the socket.
    It can create the socket, but the socket cannot connect to the server
    socket.
    I know the code is a decade old and probably isn't the
    recommended way of doing things nowadays but we want to
    upgrade the server and this is what is keeping me from
    doing it, and I don't want to really tear into the thing
    and use something else.

    Any suggestions?
    Well I know that it is not what you want to hear, but it is probably
    time to rewrite the program using a module that has already been written
    and done all of the hard work for you. See the Net::NNTP module on CPAN
    or search <http://search.cpan.org> for NNTP for alternatives.
    Think of this as a chance to educate. If you were teaching a math
    class in elementary school and a child asked how to add 2 + 2 would
    you tell them to get a calculator? The NNTP protocol is very simple and
    this only uses a few of it's commands.

    The code works on older FreeBSD, and on a modern Ubuntu system running
    the same version of Perl as on the newer FreeBSD. I have to thus
    assume the problem isn't the code, the problem is something inherent
    in how Perl is implemented on FreeBSD 8.X. I just don't know what it is.

    Ted
  • John W. Krahn at Feb 24, 2011 at 7:32 am

    Ted Mittelstaedt wrote:
    Think of this as a chance to educate. If you were teaching a math
    class in elementary school and a child asked how to add 2 + 2 would
    you tell them to get a calculator? The NNTP protocol is very simple and
    this only uses a few of it's commands.

    The code works on older FreeBSD, and on a modern Ubuntu system running
    the same version of Perl as on the newer FreeBSD. I have to thus
    assume the problem isn't the code, the problem is something inherent
    in how Perl is implemented on FreeBSD 8.X. I just don't know what it is.
    That all depends on how you define "works"? The program 'readmsg' has
    some serious problems with incorrect regular expressions. And if you
    compile the programs with warnings enabled you will get a few messages.



    John
    --
    Any intelligent fool can make things bigger and
    more complex... It takes a touch of genius -
    and a lot of courage to move in the opposite
    direction. -- Albert Einstein
  • Ted Mittelstaedt at Feb 24, 2011 at 9:15 am

    On 2/23/2011 11:32 PM, John W. Krahn wrote:
    Ted Mittelstaedt wrote:
    Think of this as a chance to educate. If you were teaching a math
    class in elementary school and a child asked how to add 2 + 2 would
    you tell them to get a calculator? The NNTP protocol is very simple and
    this only uses a few of it's commands.

    The code works on older FreeBSD, and on a modern Ubuntu system running
    the same version of Perl as on the newer FreeBSD. I have to thus
    assume the problem isn't the code, the problem is something inherent
    in how Perl is implemented on FreeBSD 8.X. I just don't know what it is.
    That all depends on how you define "works"?
    Displays the posts (articles) on a web interface.
    The program 'readmsg' has
    some serious problems with incorrect regular expressions.
    I'm sure it does. Cheap hacks have always characterized Usenet.
    And if you
    compile the programs with warnings enabled you will get a few messages.
    Well, unfortunately there is a huge lack of web-to-Usenet interfaces out
    there that are open source (ie: free) Most folks that are content with
    a Usenet webinterface can get their web access from Google Groups. So
    there is little incentive for many ISP's to field a web-to-news
    interface and far less than that for anyone to write one.

    The readnews interface is one of the few out there and although it is
    probably classed as "antique" software, it still works fine.

    Ted

    John
  • John W. Krahn at Feb 24, 2011 at 10:00 am

    Ted Mittelstaedt wrote:
    On 2/23/2011 11:32 PM, John W. Krahn wrote:
    Ted Mittelstaedt wrote:
    Think of this as a chance to educate. If you were teaching a math
    class in elementary school and a child asked how to add 2 + 2 would
    you tell them to get a calculator? The NNTP protocol is very simple and
    this only uses a few of it's commands.

    The code works on older FreeBSD, and on a modern Ubuntu system running
    the same version of Perl as on the newer FreeBSD. I have to thus
    assume the problem isn't the code, the problem is something inherent
    in how Perl is implemented on FreeBSD 8.X. I just don't know what it is.
    That all depends on how you define "works"?
    Displays the posts (articles) on a web interface.
    The program 'readmsg' has
    some serious problems with incorrect regular expressions.
    I'm sure it does. Cheap hacks have always characterized Usenet.
    And if you
    compile the programs with warnings enabled you will get a few messages.
    Well, unfortunately there is a huge lack of web-to-Usenet interfaces out
    there that are open source (ie: free) Most folks that are content with
    a Usenet webinterface can get their web access from Google Groups. So
    there is little incentive for many ISP's to field a web-to-news
    interface and far less than that for anyone to write one.
    It has already been written, and I've even used it myself: Net::NNTP

    The readnews interface is one of the few out there and although it is
    probably classed as "antique" software, it still works fine.
    Antique yes! It is written for Perl4 which is about 18 years old.



    John
    --
    Any intelligent fool can make things bigger and
    more complex... It takes a touch of genius -
    and a lot of courage to move in the opposite
    direction. -- Albert Einstein
  • Ted Mittelstaedt at Feb 25, 2011 at 7:57 am

    On 2/24/2011 2:00 AM, John W. Krahn wrote:
    Ted Mittelstaedt wrote:
    On 2/23/2011 11:32 PM, John W. Krahn wrote:
    Ted Mittelstaedt wrote:
    Think of this as a chance to educate. If you were teaching a math
    class in elementary school and a child asked how to add 2 + 2 would
    you tell them to get a calculator? The NNTP protocol is very simple and
    this only uses a few of it's commands.

    The code works on older FreeBSD, and on a modern Ubuntu system running
    the same version of Perl as on the newer FreeBSD. I have to thus
    assume the problem isn't the code, the problem is something inherent
    in how Perl is implemented on FreeBSD 8.X. I just don't know what it
    is.
    That all depends on how you define "works"?
    Displays the posts (articles) on a web interface.
    The program 'readmsg' has
    some serious problems with incorrect regular expressions.
    I'm sure it does. Cheap hacks have always characterized Usenet.
    And if you
    compile the programs with warnings enabled you will get a few messages.
    Well, unfortunately there is a huge lack of web-to-Usenet interfaces out
    there that are open source (ie: free) Most folks that are content with
    a Usenet webinterface can get their web access from Google Groups. So
    there is little incentive for many ISP's to field a web-to-news
    interface and far less than that for anyone to write one.
    It has already been written, and I've even used it myself: Net::NNTP
    That's not a web interface that is just a module that can be used
    to create one. Many people say they have written such a thing and
    even deployed them but I can't find much code out there. Is the
    interface you wrote using this available, for example?

    There are a number of PHP webnews interfaces and I have also deployed
    some of those for fun. All have their warts. And most are slower than
    this script. Not that that matters much nowadays, with hardware what
    it is.

    When I first put up this system it was in 1999 and I found no
    webinterface code then either, although the situation was the same,
    people saying they were using it but no examples. The SCN scripts
    came out a year earlier and they ran on FreeBSD 3. Once you get
    people trained to use an interface and the interface works and is
    stable, you keep using it as long as it runs on the newer platforms.
    The readnews interface is one of the few out there and although it is
    probably classed as "antique" software, it still works fine.
    Antique yes! It is written for Perl4 which is about 18 years old.
    But this is a sales point. Many people have 18 year old cars that still
    run and they drive every day. You have to understand that with non-
    technical members of the general public they absolutely detest this
    constant harping on upgrading to the newest and latest software. They
    have never bought into it and still don't. It isn't the consumers who
    want new software every year, it's the software vendors that push it
    on them.

    I guarantee to you that LOTS of people would still today be buying
    brand new PC's with Windows XP loaded on them if they could.

    Linux would never have made the inroads against Windows that it has
    today if it could not run older software. For that matter there are
    people running decade-old versions of Microsoft Office on Windows 7.

    Software lasts, man, and there's good money in supporting it. Look at
    all those COBOL programmers who made a mint in 1999 due to Y2K. I'll
    bet most of those programs are still running today.

    Ted


    John
  • Ted Mittelstaedt at Feb 24, 2011 at 8:10 am
    OK since nobody helped me (sniff, sniff) I had to figure it out myself.

    Here is the problem code in the fragment:

    $sockaddr = 'S n a4 x8';

    replacing it with

    $sockaddr = 'x C n a4 x8';

    fixed the problem. The template for the pack command was wrong.

    Th first two bytes are length (0) and family, both of which are unsigned
    char, so 'x C' (or 'n') handles those.

    I got this from a similar socket problem posting dug out of
    a mailing list posting from 2003.

    Perhaps a better way to fix this would be to rewrite it to
    do something like:

    use Socket;

    $that = sockaddr_in($port,inet_aton($newshost));

    ($newshost is the FQDN of the new host, $thataddr is the IP# of the news
    host)

    but as I said before, I don't want to rewrite everything.

    Ted
    On 2/23/2011 8:24 PM, Ted Mittelstaedt wrote:
    On 2/23/2011 7:18 PM, Jim Gibson wrote:
    At 6:16 PM -0800 2/23/11, Ted Mittelstaedt wrote:
    Hi All,

    I'm running into a problem with a pretty old freeware perl script called
    "readnews" it is in an archive named "readnews-1.85.tar.gz" that is
    available here:

    http://web.archive.org/web/20080616183736/http://www.scn.org/~bb615/scripts/readnews-1.85.tar.gz

    [program fragment snipped]
    Everytime I run it I get the immediate error

    "Can't connect to XXXX tcp/ip port 119. Error: "

    (I removed the name of the actual server system)
    Can you connect via telnet?

    telnet XXXX 119

    Can you ping the server?

    ping XXXX

    Those will tell you if it is a connectivity problem.
    Yes, I can, that works just fine.
    I've tried this on several FreeBSD systems and get the same problem
    on all of them.

    If it was a firewall thing I would expect the code to hang
    then fail, but this just exits immediately, like it can't
    create the socket.
    It can create the socket, but the socket cannot connect to the server
    socket.
    I know the code is a decade old and probably isn't the
    recommended way of doing things nowadays but we want to
    upgrade the server and this is what is keeping me from
    doing it, and I don't want to really tear into the thing
    and use something else.

    Any suggestions?
    Well I know that it is not what you want to hear, but it is probably
    time to rewrite the program using a module that has already been written
    and done all of the hard work for you. See the Net::NNTP module on CPAN
    or search <http://search.cpan.org> for NNTP for alternatives.
    Think of this as a chance to educate. If you were teaching a math
    class in elementary school and a child asked how to add 2 + 2 would
    you tell them to get a calculator? The NNTP protocol is very simple and
    this only uses a few of it's commands.

    The code works on older FreeBSD, and on a modern Ubuntu system running
    the same version of Perl as on the newer FreeBSD. I have to thus
    assume the problem isn't the code, the problem is something inherent
    in how Perl is implemented on FreeBSD 8.X. I just don't know what it is.

    Ted
  • Uri Guttman at Feb 24, 2011 at 8:43 am
    "TM" == Ted Mittelstaedt writes:


    TM> $sockaddr = 'x C n a4 x8';
    TM> Th first two bytes are length (0) and family, both of which are
    TM> unsigned char, so 'x C' (or 'n') handles those.

    TM> use Socket;

    TM> $that = sockaddr_in($port,inet_aton($newshost));

    TM> ($newshost is the FQDN of the new host, $thataddr is the IP# of the
    TM> news host)

    TM> but as I said before, I don't want to rewrite everything.

    jeez.

    use IO::Socket ;

    my $sock = IO::Socket->new( "$host:$port" ) ;

    done.

    use a module for at least that. dealing with pack templates for socket
    addresses is insane and never needed anymore.

    uri

    --
    Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
    ----- Perl Code Review , Architecture, Development, Training, Support ------
    --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
  • Ted Mittelstaedt at Feb 24, 2011 at 9:51 am

    On 2/24/2011 12:42 AM, Uri Guttman wrote:
    "TM" == Ted Mittelstaedt<tedm@mittelstaedt.us> writes:


    TM> $sockaddr = 'x C n a4 x8';
    TM> Th first two bytes are length (0) and family, both of which are
    TM> unsigned char, so 'x C' (or 'n') handles those.

    TM> use Socket;

    TM> $that = sockaddr_in($port,inet_aton($newshost));

    TM> ($newshost is the FQDN of the new host, $thataddr is the IP# of the
    TM> news host)

    TM> but as I said before, I don't want to rewrite everything.

    jeez.

    use IO::Socket ;

    my $sock = IO::Socket->new( "$host:$port" ) ;

    done.

    use a module for at least that. dealing with pack templates for socket
    addresses is insane and never needed anymore.
    Uri, I am perfectly aware of what constitutes modern programming
    practice. And the fact of the matter is that your very wrong, because
    if I was going to rewrite this code the correct way would be to use one
    of the NNTP Perl modules (NNTP Client for example) The listgroups
    script could probably be replaced by something along the lines of

    use News::NNTPClient;

    $nntp = new News::NNTPClient("xxx.xxx.xxx","",2);

    outer loop
    get a listgroup list
    iterate through it

    inner loop
    get an article list from the current group
    iterate through it and write the stuff out
    end inner loop

    end outer loop


    But I will point out that perl modules are built in a pyramid, you
    have ones like NNTPClient that use IO::Socket and that module
    uses Socket and that module uses...what? Well, it turns out it
    uses the same approach that's in the listgroups.pl script.

    If your answer to a bug in the program is to hack out the
    section and replace it with a module, your basically saying
    that you don't know how the section works. So your going to
    drop in a black box that does the same as that section. In
    other words, you don't know how the black box works anymore
    than you know how the section your hacking out works.

    And the day that a new platform comes along and the module your
    using blows up on that then you will be just as screwed as
    I was. Worse, probably, because I didn't give up I kept plugging
    away at it. You won't, you will just complain loudly for the
    maintainer of the IO::Socket module to fix it and do nothing until he does.

    I'm not proposing that someone take and write a brand new project
    from scratch.

    For new perl code you want to use as many of the WIDELY USED
    modules that have ONGOING SUPPORT as you can. That is a given.

    But for older, running code that breaks on new platforms, wouldn't
    you rather just correct the bug in it than spend all that time
    rewriting it?

    Ted
  • Uri Guttman at Feb 24, 2011 at 5:30 pm
    "TM" == Ted Mittelstaedt writes:
    TM> On 2/24/2011 12:42 AM, Uri Guttman wrote:

    TM> Uri, I am perfectly aware of what constitutes modern programming
    TM> practice. And the fact of the matter is that your very wrong, because
    TM> if I was going to rewrite this code the correct way would be to use
    TM> one of the NNTP Perl modules (NNTP Client for example) The listgroups
    TM> script could probably be replaced by something along the lines of

    s/your/you're/

    and i know about using the nntp module. but your last post was jusy
    about crappy low level socket stuff and that bothered me more. that
    isn't even a rewrite or changing the logic. it was one line to replace
    about 10 hard to fix lines. drop in replacement is not a rewrite.

    TM> But I will point out that perl modules are built in a pyramid, you
    TM> have ones like NNTPClient that use IO::Socket and that module
    TM> uses Socket and that module uses...what? Well, it turns out it
    TM> uses the same approach that's in the listgroups.pl script.

    IO::Socket is in core perl. it is not a heavy dependency. the issue
    isn't whether a module uses other modules but your time wasted fixing
    socket stuff that doesn't need fixing. if you thing spending time there
    is worth it vs a single line of code, that is your problem. see how well
    it does on your resume! :)

    TM> If your answer to a bug in the program is to hack out the
    TM> section and replace it with a module, your basically saying
    TM> that you don't know how the section works. So your going to
    TM> drop in a black box that does the same as that section. In
    TM> other words, you don't know how the black box works anymore
    TM> than you know how the section your hacking out works.

    bullshit. simple as that. i can hack at any level i feel like having
    done it for over 3 decades. i have done massive amounts of socket work
    in c and perl. i choose to be lazy and use the right module for the
    job. that is a skill i promote when i job hunt.

    TM> And the day that a new platform comes along and the module your
    TM> using blows up on that then you will be just as screwed as I was.
    TM> Worse, probably, because I didn't give up I kept plugging away at
    TM> it. You won't, you will just complain loudly for the maintainer
    TM> of the IO::Socket module to fix it and do nothing until he does.

    huh?? you don't get it. that is basic client socket connection. that
    hasn't changed in eons. if you think depending on that is a ball and
    chain, you are not worth talking to.

    TM> I'm not proposing that someone take and write a brand new project
    TM> from scratch.

    TM> For new perl code you want to use as many of the WIDELY USED
    TM> modules that have ONGOING SUPPORT as you can. That is a given.

    TM> But for older, running code that breaks on new platforms, wouldn't
    TM> you rather just correct the bug in it than spend all that time
    TM> rewriting it?

    nope. you spent way more time fixing this than even a modest rewrite
    would have taken. and i am not even talking nntp here. the reason it
    blew up was BECAUSE it did the low level stuff poorly and wasn't
    portable. that is what bit you. you have it backwards.

    uri

    --
    Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
    ----- Perl Code Review , Architecture, Development, Training, Support ------
    --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
  • Ted Mittelstaedt at Feb 28, 2011 at 9:54 am

    On 2/24/2011 9:29 AM, Uri Guttman wrote:
    "TM" == Ted Mittelstaedt<tedm@mittelstaedt.us> writes:
    TM> On 2/24/2011 12:42 AM, Uri Guttman wrote:

    TM> Uri, I am perfectly aware of what constitutes modern programming
    TM> practice. And the fact of the matter is that your very wrong, because
    TM> if I was going to rewrite this code the correct way would be to use
    TM> one of the NNTP Perl modules (NNTP Client for example) The listgroups
    TM> script could probably be replaced by something along the lines of

    s/your/you're/

    and i know about using the nntp module. but your last post was jusy
    about crappy low level socket stuff and that bothered me more. that
    isn't even a rewrite or changing the logic. it was one line to replace
    about 10 hard to fix lines. drop in replacement is not a rewrite.
    Ah, but that same template problem appeared in the other 2 scripts
    that are part of this software package. Also I think it may have been
    used in multiple places in each script. In the interests of keeping the
    original question simple I omitted that. Expending the effort to fix
    one script fixes all 3. Of course when I embarked on the attempt to fix
    the one I didn't know the other 2 scripts would have the identical fix
    but I suspected - since their failure symptoms were very similar.
    TM> But I will point out that perl modules are built in a pyramid, you
    TM> have ones like NNTPClient that use IO::Socket and that module
    TM> uses Socket and that module uses...what? Well, it turns out it
    TM> uses the same approach that's in the listgroups.pl script.

    IO::Socket is in core perl. it is not a heavy dependency. the issue
    isn't whether a module uses other modules but your time wasted fixing
    socket stuff that doesn't need fixing. if you thing spending time there
    is worth it vs a single line of code, that is your problem. see how well
    it does on your resume! :)
    Once more, this was not a design decision to write new code it was a
    repair decision.

    Re read my original post. At the time I first started looking at this
    I had no idea the problem was in the socket code. It could have just as
    easily been an operating system issue. Since the script worked on a
    modern Ubuntu system I assumed the problem wasn't in the script.

    Sure I knew the script has some hoary old code in it. But just because
    code is old does not mean it's bad. Particularly when the code has been
    around for a decade and worked on several different FreeBSD versions.

    Consider it again. The script worked on FreeBSD 6.4 running Perl 5.8.8
    It worked on the current version of Ubuntu running perl 5.10.1. And it
    failed on FreeBSD 8 running perl 5.10.1 Why would it be reasonable to
    assume that the script was the problem? The birds eye view would say
    that it was a new bug introduced in FreeBSD 8. Particularly when the
    old and new version of FreeBSD is 32 bit and the new hardware was a
    pentium 4 and the old hardware a pentium 3.
    TM> If your answer to a bug in the program is to hack out the
    TM> section and replace it with a module, your basically saying
    TM> that you don't know how the section works. So your going to
    TM> drop in a black box that does the same as that section. In
    TM> other words, you don't know how the black box works anymore
    TM> than you know how the section your hacking out works.

    bullshit. simple as that. i can hack at any level i feel like having
    done it for over 3 decades. i have done massive amounts of socket work
    in c and perl. i choose to be lazy and use the right module for the
    job. that is a skill i promote when i job hunt.
    Good for you. But I was not talking specifically about you but in
    general. In your specific case since you know everything from the low
    to the high level you POSSIBLY could have taken one look at the script
    that was not working and had a "gut feeling" that even though the
    early indicators pointed to an operating system bug, the problem still
    was the script because the code in it was old. You might have then
    taken a leap of faith that you were right and then cut out the socket
    code and replaced it with calls to IO:Socket and then sat back in
    satisfaction when everything worked. You wouldn't have even bothered
    in that case trying to figure out why the socket code didn't work since
    you just would have assumed it was broken.
    TM> And the day that a new platform comes along and the module your
    TM> using blows up on that then you will be just as screwed as I was.
    TM> Worse, probably, because I didn't give up I kept plugging away at
    TM> it. You won't, you will just complain loudly for the maintainer
    TM> of the IO::Socket module to fix it and do nothing until he does.

    huh?? you don't get it. that is basic client socket connection. that
    hasn't changed in eons. if you think depending on that is a ball and
    chain, you are not worth talking to.
    I didn't say that was a ball and chain. What I was trying to illustrate
    was that ultimately Perl depends on the implementation of the operating
    system function calls and it helps to understand those calls. Perl
    today is much more modularized than it used to be, that helps in many
    areas but it particularly helps in this kind of problem because it is
    always easier to troubleshoot a large piece of software if it is divided
    up internally than if it is just one big
    monolithic whole, because you can test each segment. The ball and chain
    here is the operating system.

    And even then, it's not really that because the OS is just machine code
    to the CPU anyway. Once more, more modularization.

    I think you and I are more in agreement than you think. You say that
    people should operate in the upper layers of Perl and use the modules.
    Yet you boast about being able to hack at any level. Well, your
    boasting because you know that this is an advantage. If you really and
    truly thought that your skills were equal to a perl coder who didn't
    understand anything at a low level and just used the modules then you
    wouldn't be boasting. But you know what I have been saying is true -
    that while a programmer should use the modules, there are times that
    if a module isn't working right that you have to dive into the lower
    level and figure it out. You can do that while Joe Admin who thinks
    that C is something he finds in his alphabet soup cannot.
    TM> I'm not proposing that someone take and write a brand new project
    TM> from scratch.

    TM> For new perl code you want to use as many of the WIDELY USED
    TM> modules that have ONGOING SUPPORT as you can. That is a given.

    TM> But for older, running code that breaks on new platforms, wouldn't
    TM> you rather just correct the bug in it than spend all that time
    TM> rewriting it?

    nope. you spent way more time fixing this than even a modest rewrite
    would have taken. and i am not even talking nntp here. the reason it
    blew up was BECAUSE it did the low level stuff poorly and wasn't
    portable. that is what bit you. you have it backwards.
    Except that I didn't know that this is what bit me until I made a
    guess that this was what it was and lo and behold, I fixed it.

    Hindsight is easy. Correcting the template proves that the original
    code was poorly written, because if the original author really and truly
    understood the pack call he would have used the correct template. The
    template was wrong the day it was written back in 1998 and it only
    worked through what they call "dumb luck" meaning we really don't know
    why broken code works on some operating systems and it's not worth
    investigating to figure it out. And if I had known at the very
    beginning of trying to fix the script that the reason it was broken
    in the socket code was because the code was poorly written then I
    might have taken a different repair path and just planned on removing
    those 10 lines and replacing them with an IO::Socket call wherever they
    appeared in the scripts.

    Ted
    uri
  • John W. Krahn at Feb 24, 2011 at 10:05 am

    Ted Mittelstaedt wrote:
    OK since nobody helped me (sniff, sniff) I had to figure it out myself.

    Here is the problem code in the fragment:

    $sockaddr = 'S n a4 x8';

    replacing it with

    $sockaddr = 'x C n a4 x8';

    fixed the problem. The template for the pack command was wrong.

    Th first two bytes are length (0) and family, both of which are unsigned
    char, so 'x C' (or 'n') handles those.
    Why is 'x8' at the end of that string? Do you know what is does and why
    it is there?

    Have you read and of W. Richard Stevens' books?



    John
    --
    Any intelligent fool can make things bigger and
    more complex... It takes a touch of genius -
    and a lot of courage to move in the opposite
    direction. -- Albert Einstein
  • Ted Mittelstaedt at Feb 25, 2011 at 7:33 am

    On 2/24/2011 2:05 AM, John W. Krahn wrote:
    Ted Mittelstaedt wrote:
    OK since nobody helped me (sniff, sniff) I had to figure it out myself.

    Here is the problem code in the fragment:

    $sockaddr = 'S n a4 x8';

    replacing it with

    $sockaddr = 'x C n a4 x8';

    fixed the problem. The template for the pack command was wrong.

    Th first two bytes are length (0) and family, both of which are unsigned
    char, so 'x C' (or 'n') handles those.
    Why is 'x8' at the end of that string?
    8 null bytes of padding

    Do you know what is does

    A description of what it does is available here:

    http://www.linuxjournal.com/article/2057

    it basically pads out the binary data that is being fed to
    the connect() function to the correct length for the 16 byte
    binary structure connect() uses.

    The Perl connect() function requires SOCKET, NAME. In the code
    the author used "S" as the socket. The connect function (per
    the docs) "requires NAME to be a packed address of the appropriate type
    for the socket."

    The original pack template of S n a4 x8 was "An unsigned short value of
    16 bits" (2 bytes) "unsigned short in network big endian value" (2
    bytes) "string of arbitrary binary value 4 long" (4 bytes) "8 null
    bytes" (8 bytes) This gives us our 16 bytes dictated in <netinet/in.h>

    IMHO the author probably used 'S n a4 x8' because that pack template
    appears in most if not all of the various tutorials and texts
    scattered around the Internet. (and which all contain a lot of hand
    waving when it comes to the nitty-gritty) Remember my warning about
    using black boxes you don't want to understand!

    The corrected pack template of x C n a4 x8 was "Null byte" (1 byte)
    "unsigned char value" (1 byte) "unsigned short in network big endian
    value" (2 bytes) "string of arbitrary binary value 4 long" (4 bytes) "8
    null bytes" (8 bytes) This also gives us our 16 bytes with one
    critical difference - the pack command now knows that the data that
    it's expected to stuff into byte 2 is an unsigned char value.

    These were used in:

    $that = pack ($sockaddr, $AF_INET, $port, $thataddr);

    So, after applying the template the main change is that we
    are stuffing AF_INET into byte 2 is an unsigned char value.

    In other words, it's x is 0, AF_INET is C, port 119 is n,
    and the IP address is a4, and the last 8 bytes is zeros. (x8)

    At least, this is MY understanding of it. If it is wrong, say
    so!

    The $64,000 question in all of this is WHY DID THE 'S n a4 x8'
    WORK in the older FreeBSD 6.4 version, the current Ubuntu version,
    and in a lot of other code people have used. It appears to be
    basically wrong. I'd love to know why it "worked". And incidentally
    the original person who pointed this out years ago on another
    mailing list (that led me to this solution) didn't have an
    answer for that, either.

    FreeBSD has a reputation for being very nasty to wrong-written
    code. Linux has a reputation for accepting all sorts of
    wrong-written code and "trying to do the right thing" I would
    assume that the newer Perl version became more strict somehow,
    and the newer FreeBSD version glommed on to that in it's
    Perl build, while the Perl install on Ubuntu made it less strict in
    accordance with Linux'es more laid-back philosophy about working with
    sloppy code. There is probably a Perl compile flag that can be
    set if I recompiled Perl on FreeBSD 8 that would break it again
    so the original wrong code would "work"

    and why
    it is there?

    Have you read and of W. Richard Stevens' books?
    No, I did the "Internetworking with TCP/IP" series by Comer, not the
    TCP/IP Illustrated" series by Stevens. That was a while ago when
    we still used real paper books. ;-)

    Ted

    John
  • Shawn wilson at Feb 25, 2011 at 8:48 am
    You want quick and dirty? Figure out how the nntp module works. Then figure
    out at what point your program is calling that function and with what
    parameters. Then replace that function with yours. Then figure out what the
    program is looking for for output and fix the output that the Net::NNTP
    module returns to match what the program wants and you're back in business.

    The right way: scrap the whole thing. Get catalyst and use the NNTP module
    with that. If you do it that way you can even give it a nice new look. Hell,
    you could even add some css while you're at it.

    ... third option, figure out what module is giving those functions and see
    if its still maintained and how it works now. Or find an equivalent module
    and use that.

    You want a simple solution. Fact is, while I've been having fun /trying/ to
    figure out 20 year old ioccc (c code) I don't think anyone really wants to
    look at perl code even half that old.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupbeginners @
categoriesperl
postedFeb 24, '11 at 2:16a
activeFeb 28, '11 at 9:54a
posts15
users5
websiteperl.org

People

Translate

site design / logo © 2021 Grokbase