hope listen is non blocking!

[dev]

hi all,
this code worked fine last time, but now its just not going to lines after listen, y?, ( it worked last time), what could be the reason,(its working fine on other machine),no errors, but not going after listen,
and i hope i am right to think that listen is non blocking, am i not right?

is there some thing related to some configaration files?

sock=socket(AF_INET,SOCK_STREAM,0);
53 if(sock == -1) // error
54 {
55 perror("\n error in socket : ");
56 exit(-1);
57 }
58
59 sa.sin_family=AF_INET;
60 sa.sin_port=htons(server_port);
61 // sa.sin_addr.s_addr=inet_addr(server_ipaddress);
62 sa.sin_addr.s_addr=INADDR_ANY;
63
64 printf("\n socket sucessful ");
65
66 if( bind(sock,(struct sockaddr*)&sa,sizeof(struct sockaddr_in))
== -1) // error
67 {
68 perror("\n error in bind : ");
69 exit(-1);
70 }
71 printf("\n bind sucessful ");
72
73 if(listen(sock,2) == -1) // error
74 {
75 printf("\n in errror of listen " );
76
77 perror("\n error in listen : ");
78 exit(-1);
79 }
80
81
82 printf("\n server listening ............ ");


dev

[emihaly]

Yes, listen is nonblock and accept after listen is default blocking.

[emihaly]

This is my code from server and work well.

sock_limit.rlim_max=16000;
rt = setrlimit(RLIMIT_NOFILE,&sock_limit);

if (rt == -1)
reportlog("Error: Increasing socket limit to 16000 fail");

rt = getrlimit(RLIMIT_NOFILE,&sock_limit);

if (rt == -1)
reportlog("Error: Can't detect second limits");
else
{
sprintf(res_str,"STATS: Maximum socket descriptors : %d",sock_limit.rlim_max);
reportlog(res_str);
}

SKIP_SET_LIMIT:

i_socket = socket(AF_INET,SOCK_STREAM,0);
if (i_socket < 0)
{
reportlog("CREATE SOCKET: Central Socket Error. Start I/O fail");
return 0;
}

if(setsockopt(i_socket,SOL_SOCKET,SO_REUSEADDR,&_t mp,sizeof(int)) == -1)
{
reportlog("CREATE SOCKET: setsockopt over Socket Error");
return 0;
}

serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
serv_addr.sin_port = htons(15001);

if (bind(i_socket,(struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0)
{
reportlog("BINDING: Assigning a name to a socket Error fail");
return 0;
}

if (listen(i_socket,SOMAXCONN)== -1)
{
reportlog("SOCKET: General listen socket Error");
return 0;
}

int t1=pthread_create(&TID,NULL,Compressor,(void *) see);
if (t1 != 0)
{
reportlog("THREADS: Thread init Error fail. Too much system process ?");
return 0;
}

if(( accp_flag = fcntl(i_socket,F_GETFL,0)) < 0)
{
reportlog("SOCKET: Main NONBLOCK set problem");
return 0;
}

if(fcntl(i_socket,F_SETFL,accp_flag|O_NONBLOCK) <0)
{
reportlog("SOCKET: Main NONBLOCK set problem");
return 0;
}

int reset_socket = socket(AF_INET,SOCK_STREAM,0);
int reload_socket = socket(AF_INET,SOCK_STREAM,0);
int status_socket = socket(AF_INET,SOCK_STREAM,0);

if (reset_socket < 0 || reload_socket < 0 || status_socket < 0)
{
reportlog("CREATE SOCKET: Central Socket Error. Start I/O fail");
return 0;
}

if(setsockopt(reset_socket,SOL_SOCKET,SO_REUSEADDR ,&_tmp,sizeof(int)) == -1)
{
reportlog("CREATE SOCKET: setsockopt over Socket Error");
return 0;
}

if(setsockopt(reload_socket,SOL_SOCKET,SO_REUSEADD R,&_tmp,sizeof(int)) == -1)
{
reportlog("CREATE SOCKET: setsockopt over Socket Error");
return 0;
}

if(setsockopt(status_socket,SOL_SOCKET,SO_REUSEADD R,&_tmp,sizeof(int)) == -1)
{
reportlog("CREATE SOCKET: setsockopt over Socket Error");
return 0;
}

serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
serv_addr.sin_port = htons(15002);

if (bind(reset_socket,(struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0)
{
reportlog("BINDING: Assigning a name to a socket Error fail");
return 0;
}

serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
serv_addr.sin_port = htons(15003);

if (bind(reload_socket,(struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0)
{
reportlog("BINDING: Assigning a name to a socket Error fail");
return 0;
}

serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
serv_addr.sin_port = htons(15004);

if (bind(status_socket,(struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0)
{
reportlog("BINDING: Assigning a name to a socket Error fail");
return 0;
}

if (listen(reset_socket,SOMAXCONN)== -1)
{
reportlog("SOCKET: General listen socket Error");
return 0;
}

if (listen(reload_socket,SOMAXCONN)== -1)
{
reportlog("SOCKET: General listen socket Error");
return 0;
}

if (listen(status_socket,SOMAXCONN)== -1)
{
reportlog("SOCKET: General listen socket Error");
return 0;
}

if(( accp_flag = fcntl(reset_socket,F_GETFL,0)) < 0)
{
reportlog("SOCKET: Main NONBLOCK set problem");
return 0;
}

if(fcntl(reset_socket,F_SETFL,accp_flag|O_NONBLOCK ) <0)
{
reportlog("SOCKET: Main NONBLOCK set problem");
return 0;
}

if(( accp_flag = fcntl(reload_socket,F_GETFL,0)) < 0)
{
reportlog("SOCKET: Main NONBLOCK set problem");
return 0;
}

if(fcntl(reload_socket,F_SETFL,accp_flag|O_NONBLOC K) <0)
{
reportlog("SOCKET: Main NONBLOCK set problem");
return 0;
}

if(( accp_flag = fcntl(status_socket,F_GETFL,0)) < 0)
{
reportlog("SOCKET: Main NONBLOCK set problem");
return 0;
}

if(fcntl(status_socket,F_SETFL,accp_flag|O_NONBLOC K) <0)
{
reportlog("SOCKET: Main NONBLOCK set problem");
return 0;
}

[RobSeace]

Are you sure it's not making it past the listen()? If you're just
relying on that printf() to tell you, you might just be getting
tricked by stdio buffering... Normally, stdout is buffered, so
printf()'s won't necessarily immediately show up, unless you
fflush(stdout)...

But, yeah, listen() really shouldn't block for any reason... It
doesn't do any I/O; it's just setting up some kernel internals
in preperation to receiving incoming connections...

[dev]

hello all,

my listen is still not working , but the prob is not fflush(stdout), i feel it is something to do with the configration files which controls the access and permissons to ports,

so can u give me a list of all configraion files associated with ports and networking in linux,Red Hat 7.2.


with thanks

dev

[RobSeace]

What do you mean by "not working", exactly? Is listen()
failing? (If so, what errno?) Or, are you still saying it's actually
hanging inside the listen(), and not returning?? (If so, have you
really verified this via "strace", or something similar?) Or, do
you just mean that you can't connect, once you are listening?
(If so, does your listening port show up in "netstat -a" output?
Perhaps you have firewall rules in place... On RH, take a look
at "/etc/sysconfig/iptables"... Or, maybe "ipchains", or something
similar to that...)

[dev]

hi Rob,

my code doesnot go to line below connect(), ie no errors, it just hangs on connect() there, no action,errors or anything else., thus not returning anything.so what could be wrong, ?
the same code runs fine on SCO unix relese 5 machine.and the same code had runned on Red hat 7.2(which i am working on),2 days back. also none of my other codes which was working 2 days back is also not working now, thus i feel its nothing to do with the code, its something to do with the configration of machine, as i am just a user(not su), i am not sure what the root had changed in 2 days,
so what and file can affect the netwoking programes?

dev

[RobSeace]

connect()?? Where are you doing a connect()?? I thought
the problem was listen(), you said before??

If you mean clients aren't able to connect, then I'd bet it's a
firewall in action, as I said... Often, firewalls are configured to
just drop incoming SYNs, rather than respond with a RST...
(A very unfriendly configuration, BTW... People who do that
annoy me... ;-/) So, that would explain why a client would
hang in connect(): their system is just continually trying to
resend the SYN... But, after a while, it should time out...
(Perhaps a LONG while, though...)

But, anyway, like I say: it sounds like someone setup some
firewall rules on the machine... If you don't have root on the
machine, well you'll have to ask someone who does about it,
I guess...

[Loco]

If you mean clients aren't able to connect, then I'd bet it's a
firewall in action, as I said... Often, firewalls are configured to
just drop incoming SYNs, rather than respond with a RST...
(A very unfriendly configuration, BTW... People who do that
annoy me... ;-/) So, that would explain why a client would
hang in connect(): their system is just continually trying to
resend the SYN... But, after a while, it should time out...
(Perhaps a LONG while, though...)

But, anyway, like I say: it sounds like someone setup some
firewall rules on the machine... If you don't have root on the
machine, well you'll have to ask someone who does about it,
I guess...

I agree with Rob. Mostly firewall admins do the SYN dropping to avoid automated scans that search for open ports. It is very annoying because a legitimate user will try to connect to the port and will timeout (2 min aprox), without knowing what is going on (whether the machine is down or the port has been filtered out). The sad part is that most scanning tools (e.g. nmap) provide a list of "open", "closed" and "filtered" ports by checking the response (or absence of) packets to the probing packets. So, this mute packet dropping tells the scanning tools that the firewall has an explicit filter out rule for such ports, which is interesting for attackers.
What I have done (using IPTABLES, not IPCHAINS) is to reply to every blocked port with an RST packet. The scanner won't notice the difference between a closed port in the machine from a filtered out port (I don't know what I get for this, or even if this is safer or less secure, but it never hurts to test different things!!! ;)

But in fact, thinking from the fw admin perspective, RST responses from firewalls might in the future be used for DoS attacks. That could be a possibility, the other could be that the FW doesn't support sending RST packets in behalf of the host or the admin doesn't know how to configure that...

Enough on that subject, and going back to yours:

My suggestions are:

1) Try to pinpoint the location of the problem by using strace (as Rob mentioned). It is quite useful and pretty simple to use (the basics)
2) Put perror() everywhere after the calls, check the errno values, and be patient. In the case of a firewall dropping packets, you will have to wait a long time to get a timeout error.
3) Check the addresses, try connecting using plain-old telnet
4) Try connecting from other clients.

If you want additional help, please post more details on your configuration/programs.

Good luck

[dev]

hi Rob/Loco/all,

well the prob is still there. the prob is strange as u know, as the server code doesnot go below listen, ie it doesnot listen(). no error messages, no warnings, but just hanges on listen. that is the real prob. the clients prob and others can be side effect of server's non listening or rather not going to lines below listen.

so leave the connect() and others, lets try to find whats wrong with listen() of server. the case is :-

- when i had coded the server, it was working fine (going to lines below listen() and all)

- next day, the same code doesnot go to lines after listen(), ( the printf below listen() is not printed)
- i tried fflushing stdout and in, but still no changes.

- no errors,no warnings,nothing other than it just hangs on listen().

so thats it, i am working ipchains and iptables( am new to firewalls and all), so lets see what comes out.

with thanks
dev

[dev]

hi all,

well when i connected the client to the server( which , i thought was not listening!), printed the message that should be printed before accept . i used telnet to connect to server(thnaks to Loco for the advice).

now that i am sure listen is working , but still it doesnot feel good , why the printf after listen which should be printed after listen and before accept, is printed only after accept?

mean while strace of listen() showed "= 0",( i guessed that means listen is working fine).

so why the printf after listen is working in srange way?
i have also fflused stdout before listen().

-dev

[dev]

hi all,

got the prob,
i made the silly mistake of fflushing the stdout before printing!
i fflushed the stdout before printing the line after listen().
yea its foolish of me, shame on me.
sorry all u guys , made u think over the stupid stuff.
still thanks for the help and info on firewall and others
with regerts,
-dev

[Loco]

hi all,

got the prob,
i made the silly mistake of fflushing the stdout before printing!
i fflushed the stdout before printing the line after listen().
yea its foolish of me, shame on me.
sorry all u guys , made u think over the stupid stuff.
still thanks for the help and info on firewall and others
with regerts,
-dev

I'm glad to hear you finally solved the problem. And don't worry, usually the printer doesn't work because it is unplugged - but that's the last thing one usually checks!!! ;)

Regards