odd socket behavior with ZoneAlarm

A

AC

This is very strange and I'm posting it here in case someone else runs into
this problem. ZA (ZoneAlarm) messes up Perl applications that read from
sockets using the syntax

my $line = <SOCK>;

causing them to hang indefinately, even if the server closes the socket. You
can get past this by using the following code snippet instead:

my $line = "";
if (defined (recv(SOCK, $line, 1024, 0))) {
print $line;
}

Does anyone know what ZoneAlarm might be doing? Is it messing with the line
terminator that the server uses? The internal XP firewall does not interfere
with Perl programs this way.

Many Thanks,

Allan
 
A

AC

YYUsenet said:
This is OT here, but I think that Zone Alarm is just trying to block any
unauthorized program from receiving data through sockets.

--
k g a b e r t (at) x m i s s i o n (dot) c o m

*Use Mozzila/Firefox*!
http://www.spreadfirefox.com/?q=user/register&r=71209

Actually I disagree about the offtopic issue. This is a problem with running
Perl in conjunction with third party products. This problem does not occur
with any other non-Perl executables that I have. If this isn't the right
forum, what is? (Please don't suggest the ZA forums. They don't even know
what Perl is.)

On the other comment, firewalls do indeed block traffic. The question I had
was why does the usual line reading fail but using the recv() function
succeed? What is the implementation of "$line = <SOCKET>"?

Inquiring minds want to know.

AC
 
P

phaylon

AC said:
Actually I disagree about the offtopic issue. This is a problem with
running Perl in conjunction with third party products.

Yes, but I would think the problem lies at the third party product in
first way in this case, so it is offtopic. If Linux' iptables made
problems, it would be also off-topic.
 
D

D. Marxsen

phaylon said:
Yes, but I would think the problem lies at the third party product in
first way in this case, so it is offtopic. If Linux' iptables made
problems, it would be also off-topic.

Sorry, but I agree with AC.
There is a problem in the interaction of Perl with a firewall and Perl does
behave differently when trying different approaches.
So it would be very helpful if someone could shed some light on the
difference of both attempts. I would like to know it!

We have to be careful not to behave like two companies, pushing
responsibility to and fro (we all hate that, don't we?). This is frustrating
and helps no-one.

Just my two cents.

Detlef


PS: Sorry that I couldn't help.
 
P

phaylon

D. Marxsen said:
There is a problem in the interaction of Perl with a firewall and Perl
does behave differently when trying different approaches.

Sure, if you code different things, perl often feels free to act
different.
So it would be very helpful if someone could shed some light on the
difference of both attempts. I would like to know it!

What's the problem with looking at perldoc -f recv?
We have to be careful not to behave like two companies, pushing
responsibility to and fro (we all hate that, don't we?). This is
frustrating and helps no-one.

Yeah, but it will get kinda unperlish if there would be more perl+Apache,
perl+Redhat, perl+SuSE, perl... You know what I mean?

Don't understand me wrong, you can write about whatever you want, but I
just don't think the problem that one firewall (I think there are other's
where it worked) has so much to do with Perl. I mean, we don't know what
this firewall actually does, how it relies to the system it is running on,
how it's configured, how it _can_ be configured. Sure, there are some
people in here, who know ZA. But there are much more at the ZA forums.
Where is the problem in writing a little script (which already exists) and
ask the ZA guys why it works without ZA, but not with an activated (and
configured, or has anyone "forgotten" to read the docs?) one.

just my 2c.
 
A

AC

phaylon said:
Sure, if you code different things, perl often feels free to act
different.


What's the problem with looking at perldoc -f recv?


Yeah, but it will get kinda unperlish if there would be more perl+Apache,
perl+Redhat, perl+SuSE, perl... You know what I mean?

Don't understand me wrong, you can write about whatever you want, but I
just don't think the problem that one firewall (I think there are other's
where it worked) has so much to do with Perl. I mean, we don't know what
this firewall actually does, how it relies to the system it is running on,
how it's configured, how it _can_ be configured. Sure, there are some
people in here, who know ZA. But there are much more at the ZA forums.
Where is the problem in writing a little script (which already exists) and
ask the ZA guys why it works without ZA, but not with an activated (and
configured, or has anyone "forgotten" to read the docs?) one.

just my 2c.

I try to be really sensitive to off-topic posts and get irritated by others
who do it. So I did not post to this group lightly.

My original question stands. This problem is an odd interaction between Perl
and some third pary product. If I post in the ZoneAlarm forums, folks either
say "I don't know Perl" or "This is a Perl problem". If I post here, some
folks say "this is off topic." I did a search for the newsgroup
*firewallsperl* but couldn't find it. ;-)
 
S

Sisyphus

AC said:
This is very strange and I'm posting it here in case someone else runs into
this problem. ZA (ZoneAlarm) messes up Perl applications that read from
sockets using the syntax

my $line = <SOCK>;

causing them to hang indefinately, even if the server closes the socket. You
can get past this by using the following code snippet instead:

my $line = "";
if (defined (recv(SOCK, $line, 1024, 0))) {
print $line;
}

Does anyone know what ZoneAlarm might be doing? Is it messing with the line
terminator that the server uses? The internal XP firewall does not interfere
with Perl programs this way.

I have ZA installed on a Windows 2000 box - that runs a simple (perl)
client that connects to a server on a linux box. But I can't duplicate
the problem. Do you have a complete (preferably minimal) script that
demonstrates the problem ?

I use IO::Socket and find that the following works fine:

@lines = <$socket>;

If I do :

$line = <$socket>;

then $line returns only the first line of the response from the server
(but it certainly doesn't hang).

I suspect that you might be using the Socket module, which perhaps
behaves differently.

Cheers,
Rob
 
A

AC

I apologize to those who feel (with some justification) that this is
off-topic...

Using read() fails and using recv() or sysread() succeeds. I do have a
simple client and server that fail. By the way, I think that the free
version of ZA is ok, its the ZA Security Suite that is bad.

I am half suspicious that ZA and possibly other firewalls are mucking with
the text sent across, like changing the newline (this would explain the
hanging).

Here is a client and server that break. I grabbed them off this newsgroup
and they work on my developement machine, but fail on my test machine (by
having the client hang)...

======================
sockettest_srv.pl

#!/usr/bin/perl -w
use strict;

BEGIN { $ENV{PATH} = '/usr/ucb:/bin' }

use Socket;
use Carp;

use IO::Socket; # for autoflush

my $EOL = "\015\012";

sub logmsg { print "$0 $$: @_ at ", scalar localtime, "\n" }

my $port = shift || 2345;
my $proto = getprotobyname('tcp');

($port) = $port =~ /^(\d+)$/ or die "invalid port";
socket(Server, PF_INET, SOCK_STREAM, $proto) || die "socket: $!";
setsockopt(Server, SOL_SOCKET, SO_REUSEADDR,
pack("l", 1)) || die "setsockopt:
$!";
bind(Server, sockaddr_in($port, INADDR_ANY)) || die "bind: $!";
listen(Server,SOMAXCONN) || die "listen: $!";
logmsg "server started on port $port";
my $paddr;
$SIG{CHLD} = \&REAPER;

for ( ; $paddr = accept(Client,Server); close Client)
{
autoflush Client 1;

my($port,$iaddr) = sockaddr_in($paddr);
my $name = gethostbyaddr($iaddr,AF_INET);

logmsg "connection from $name [",
inet_ntoa($iaddr), "]
at port $port";
print Client "From the server, hello there, $name, it's now ",
scalar localtime, $EOL;
}

======================
sockettest_cl.pl

#!/usr/bin/perl -w

use strict;
use Socket;

my ($remote,$port, $iaddr, $paddr, $proto, $line);

$remote = shift || 'localhost';

$port = shift || 2345; # random port
if ($port =~ /\D/) { $port = getservbyname($port, 'tcp') }

die "No port" unless $port;

$iaddr = inet_aton($remote) || die "no host: $remote";
$paddr = sockaddr_in($port, $iaddr);
$proto = getprotobyname('tcp');

my $sockhand;
print "Socket open...\n";
socket($sockhand, PF_INET, SOCK_STREAM, $proto) || die "socket: $!";

print "Socket connect...\n";
connect($sockhand, $paddr) || die "connect: $!";

if (0)
{
print "recv(Socket) read lines...\n";

my $data = "";

while (defined (recv($sockhand, $data, 1024, 0)) && length($data) > 0)
{
print $data;
}
}
else
{
print "<Socket> read lines...\n";

while (defined($line = <$sockhand>))
{
print $line;
}
}

print "Socket close\n";
close ($sockhand) || die "close: $!";
 
S

Sisyphus

AC said:
Using read() fails and using recv() or sysread() succeeds. I do have a
simple client and server that fail. By the way, I think that the free
version of ZA is ok, its the ZA Security Suite that is bad.

Looks like that may well be the case. I have only the free version and
your scripts work fine for me for both if(0) and if(1).

Sorry - I don't think I can improve on your speculation re the cause of
the problem.

However, if the server is altered so that it does not send $EOL at the
end of the message, then I still find no problem with the client script.
Even a simple '$line = <$sockhand>;' still works fine for me. It just
means that $line doesn't terminate with a newline. That seems to me to
be inconsistent with your speculation.

Being unable to reproduce the problem makes it hard for me to offer
anything very useful :)

Cheers,
Rob
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,169
Messages
2,570,919
Members
47,458
Latest member
Chris#

Latest Threads

Top