Socket doesn't get EOF

Socket doesn't get EOF

[K-sPecial]

Hey, i've got an irc bot of over 3000 lines of perl. I test for EOF on 
occasion and do a reconnect if eof is detected. This works greatly for 
instances as when the socket times out or is disconnected in most 
manors. It doesn't although register an eof when pppd dies. I realy 
don't know if this might be specific to perl or if even in C this is an 
issue.

--K-sPecial

[ http://xzziroz.freeshell.org
   irc://xzziroz.dtdns.net       ]

Re: Socket doesn't get EOF

[carlsonj]

K-sPecial writes:
> Hey, i've got an irc bot of over 3000 lines of perl. I test for EOF on 
> occasion and do a reconnect if eof is detected. This works greatly for 
> instances as when the socket times out or is disconnected in most 
> manors. It doesn't although register an eof when pppd dies. I realy 
> don't know if this might be specific to perl or if even in C this is an 
> issue.

This is a frequently-asked question about TCP/IP.

No, you won't get EOF.  No, it's not a bug.  It's a feature, and it's
by design.  The TCP layer sees IP as a connectionless datagram
service, and tries its best to deliver the data the application
provides.  IP sees the datalink layers as unrelated to any particular
transport, so when a datalink layer goes down, the transport (such as
TCP) isn't involved.  If IP can route around the problem, it does so.
If it can't, it drops the packets and hopes that either (A) the link
comes back 'soon' or (B) the transport gives up eventually.

If you want a shorter timeout, set a timer in your application.

-- 
James Carlson                                 <carlsonj@workingcode.com>

Re: Socket doesn't get EOF

[K-sPecial]

carlsonj@workingcode.com wrote:
> K-sPecial writes:
> 
>>Hey, i've got an irc bot of over 3000 lines of perl. I test for EOF on 
>>occasion and do a reconnect if eof is detected. This works greatly for 
>>instances as when the socket times out or is disconnected in most 
>>manors. It doesn't although register an eof when pppd dies. I realy 
>>don't know if this might be specific to perl or if even in C this is an 
>>issue.
> 
> 
> This is a frequently-asked question about TCP/IP.
> 
> No, you won't get EOF.  No, it's not a bug.  It's a feature, and it's
> by design.  The TCP layer sees IP as a connectionless datagram
> service, and tries its best to deliver the data the application
> provides.  IP sees the datalink layers as unrelated to any particular
> transport, so when a datalink layer goes down, the transport (such as
> TCP) isn't involved.  If IP can route around the problem, it does so.
> If it can't, it drops the packets and hopes that either (A) the link
> comes back 'soon' or (B) the transport gives up eventually.
> 
> If you want a shorter timeout, set a timer in your application.
> 

Thanks, that was very informative, it made sense and I much appreciate 
the prompt response. I have added a timeout on the socket and will get a 
glimpse of what happens next time pppd dies.

--K-sPecial

Re: Socket doesn't get EOF

[carlsonj]

K-sPecial writes:
> Thanks, that was very informative, it made sense and I much appreciate 
> the prompt response. I have added a timeout on the socket and will get a 
> glimpse of what happens next time pppd dies.

You can also have pppd clobber the application via the
/etc/ppp/ip-down script.  I'd suggest that doing so is a mistake.  If
the link comes back (it was just a short glitch), then the application
fails for no reason.  If the network is designed with multiple paths,
then there's really no good way to know when (or if) to kill the
application.

Moreover, you'd have no way to know if some intermediate router
failed, and you'd likely want to have the application "notified" in
some way if that were to happen for the same reason that you want pppd
to kill the application.  If you can't detect router failure in
practice, is there much additional value to detecting local interface
failure?

-- 
James Carlson                                 <carlsonj@workingcode.com>

Re: Socket doesn't get EOF

[K-sPecial]

carlsonj@workingcode.com wrote:
> K-sPecial writes:
> 
>>Thanks, that was very informative, it made sense and I much appreciate 
>>the prompt response. I have added a timeout on the socket and will get a 
>>glimpse of what happens next time pppd dies.
> 
> 
> You can also have pppd clobber the application via the
> /etc/ppp/ip-down script.  I'd suggest that doing so is a mistake.  If
> the link comes back (it was just a short glitch), then the application
> fails for no reason.  If the network is designed with multiple paths,
> then there's really no good way to know when (or if) to kill the
> application.
> 
> Moreover, you'd have no way to know if some intermediate router
> failed, and you'd likely want to have the application "notified" in
> some way if that were to happen for the same reason that you want pppd
> to kill the application.  If you can't detect router failure in
> practice, is there much additional value to detecting local interface
> failure?
> 

Well, yes and no. In the way of the bot, not drasticly. Although the 
other day I was programming some perl that needed to know when the 
computer was online and when it wasn't. I realy didn't give it as much 
thought as I could have, but resorted to the resolution of a popular 
name server, such as internic.net. This of course can also have problems 

when your DNS server(s) happens to not cooperate. Honestly i'm sure this 
isn't the correct manor to go about such a thing, but for what I needed 
it for, it should suffice. I was going to test for interfaces being up, 
which would work in the case of pppd, just not in the case of say DSL 
where your interface can obviously still be up yet your modem isn't online.

But as to your question, I would say there is, when you just need to 
know, period, if you can successfuly access a remote node via the 
Internet, and don't actualy need the support of an exact cause.

--K-sPecial

[ http://xzziroz.freeshell.org
   irc://xzziroz.dtdns.net       ]

Re: Socket doesn't get EOF

[James Carlson]

K-sPecial writes:
> Well, yes and no. In the way of the bot, not drasticly. Although the 
> other day I was programming some perl that needed to know when the 
> computer was online and when it wasn't. I realy didn't give it as much 
> thought as I could have, but resorted to the resolution of a popular 
> name server, such as internic.net. This of course can also have problems 
> 
> when your DNS server(s) happens to not cooperate. Honestly i'm sure this 
> isn't the correct manor to go about such a thing, but for what I needed 
> it for, it should suffice. I was going to test for interfaces being up, 
> which would work in the case of pppd, just not in the case of say DSL 
> where your interface can obviously still be up yet your modem isn't online.

SIOCGIFCONF can tell you if you have interfaces available.

Even if the interfaces are up and the modem is "on line," that doesn't
mean that any particular host is actually reachable.  That sort of
global knowledge just isn't knowable, except in retrospect: if the
connection times out, then that host obviously can't be reached.

> But as to your question, I would say there is, when you just need to 
> know, period, if you can successfuly access a remote node via the 
> Internet, and don't actualy need the support of an exact cause.

That's what timeouts are for.  You can use the existing default
timeout provided by TCP, or (if that's too long) you can set up your
own timer with alarm() or similar functions.

-- 
James Carlson                                 <carlsonj@workingcode.com>

Re: Socket doesn't get EOF

[K-sPecial]

> Even if the interfaces are up and the modem is "on line," that doesn't
> mean that any particular host is actually reachable.  That sort of
> global knowledge just isn't knowable, except in retrospect: if the
> connection times out, then that host obviously can't be reached.

Well there the problem lies within, the script was meant to to check if 
a port was open every so often, if it's down, check if your online, then 
possibly wait again to see if it opens back up, say 10 minutes (maybe 
the computer rebooted, maybe crontab will restart it), check again if 
online, then point the hostname to a different ip and start checking if 
the old host is back up again (so I can change it back). So just 
checking if I could access the host is what I was *double* checking, of 
course I couldn't rely on just the fact that I can't reach the port, 
before updating it to a new ip.

 > That's what timeouts are for.  You can use the existing default
 > timeout provided by TCP, or (if that's too long) you can set up your
 > own timer with alarm() or similar functions.

Yup, i'm not sure but it seems the timeout optino that IO::Socket uses 
is just a connect timeout, it didn't seem to register when pppd died, 
could be wrong.

--K-sPecial

[ http://xzziroz.freeshell.org
   irc://xzziroz.dtdns.net       ]

Re: Socket doesn't get EOF

[James Carlson]

K-sPecial writes:
> > Even if the interfaces are up and the modem is "on line," that doesn't
> > mean that any particular host is actually reachable.  That sort of
> > global knowledge just isn't knowable, except in retrospect: if the
> > connection times out, then that host obviously can't be reached.
> 
> Well there the problem lies within, the script was meant to to check if 
> a port was open every so often, if it's down, check if your online, then 
> possibly wait again to see if it opens back up, say 10 minutes (maybe 
> the computer rebooted, maybe crontab will restart it), check again if 
> online, then point the hostname to a different ip and start checking if 
> the old host is back up again (so I can change it back). So just 
> checking if I could access the host is what I was *double* checking, of 
> course I couldn't rely on just the fact that I can't reach the port, 
> before updating it to a new ip.

What's the point?

If the system is isolated from the world, then periodically noticing
that the 'port' still isn't reachable, and switching to a different IP
address should make no difference at all.

Why condition the logic on local interface status?

>  > That's what timeouts are for.  You can use the existing default
>  > timeout provided by TCP, or (if that's too long) you can set up your
>  > own timer with alarm() or similar functions.
> 
> Yup, i'm not sure but it seems the timeout optino that IO::Socket uses 
> is just a connect timeout, it didn't seem to register when pppd died, 
> could be wrong.

Again, that's not a bug.  It's a design feature of TCP/IP.  Links
going up and down intentionally do _not_ cause connections to fail.

If you care about particular interfaces for some reason, then use
SIOCGIFCONF to read the kernel's interface table or open a routing
socket (PF_ROUTE) and listen for interface add/delete messages.

-- 
James Carlson                                 <carlsonj@workingcode.com>

Re: Socket doesn't get EOF

[K-sPecial]

> What's the point?
> 
> If the system is isolated from the world, then periodically noticing
> that the 'port' still isn't reachable, and switching to a different IP
> address should make no difference at all.

No, I think we are confusing each other, the port is open to begin with, 
the script changes it's ip so when the service goes unavailable it can 
be redirected to another computer running the same service. Basicly for 
when you don't have enough control of the computer the service is 
initialy running on to implment this from there.

> Again, that's not a bug.  It's a design feature of TCP/IP.  Links
> going up and down intentionally do _not_ cause connections to fail.
> 
> If you care about particular interfaces for some reason, then use
> SIOCGIFCONF to read the kernel's interface table or open a routing
> socket (PF_ROUTE) and listen for interface add/delete messages.
> 

Well, I don't care about the interface, since as I earlier stated, an 
interface can be up yet the internet still not accessable such as when 
your router is connected to you via ethernet.

--K-sPecial

Re: Socket doesn't get EOF

[James Carlson]

K-sPecial writes:
> > If the system is isolated from the world, then periodically noticing
> > that the 'port' still isn't reachable, and switching to a different IP
> > address should make no difference at all.
> 
> No, I think we are confusing each other, the port is open to begin with, 
> the script changes it's ip so when the service goes unavailable it can 
> be redirected to another computer running the same service. Basicly for 
> when you don't have enough control of the computer the service is 
> initialy running on to implment this from there.

Sure ... but why does it hurt to change the IP address when "the link"
is down?

> > If you care about particular interfaces for some reason, then use
> > SIOCGIFCONF to read the kernel's interface table or open a routing
> > socket (PF_ROUTE) and listen for interface add/delete messages.
> > 
> 
> Well, I don't care about the interface, since as I earlier stated, an 
> interface can be up yet the internet still not accessable such as when 
> your router is connected to you via ethernet.

That's precisely the point.

The thing that makes a host unreachable might be zero, one, or many
hops away.  Worrying about the local interface(s) or about one
particular local router is just useless.

Anway, as I've said multiple times now, you can determine precisely
whether PPP is up or down (and get notifications when it goes up and
down) by using any of SIOCGIFCONF, PF_ROUTE, or /etc/ppp/ip-{up,down}.
You do not need to have the socket connection aborted with an error in
order to find out this information.

-- 
James Carlson                                 <carlsonj@workingcode.com>

Re: Socket doesn't get EOF

[K-sPecial]

> Sure ... but why does it hurt to change the IP address when "the link"
> is down?
> 

Because I don't want the script to go into the loop of checking if it's 
back up again if it wasn't down in the first place. I guess it wouldn't 
hurt because all that would happen is it would update the hostname with 
the ip it's already at (the "old" ip) and things would be gravy. But 
remember at the time I said it waits 10 minutes or whatever is specified 
before updating if it thinks it's down (connect() doesn't succeed on the 
port), what if in these 10 minutes your Internet came available, then 
unless it checks if it's online, the ip would be changed to the ip to 
change to when the service on the port can't be reached because of that 
services computer.

> That's precisely the point.
> The thing that makes a host unreachable might be zero, one, or many
> hops away.  Worrying about the local interface(s) or about one
> particular local router is just useless.

Yay! We *do* agree.

> Anway, as I've said multiple times now, you can determine precisely
> whether PPP is up or down (and get notifications when it goes up and
> down) by using any of SIOCGIFCONF, PF_ROUTE, or /etc/ppp/ip-{up,down}.
> You do not need to have the socket connection aborted with an error in
> order to find out this information.

Yes, for ppp that is great, thanks, thanks alot.

--K-sPecial

[ http://xzziroz.freeshell.org
   irc://xzziroz.dtdns.net       ]

Re: Socket doesn't get EOF

[K-sPecial]

But also, in the case of 'that' script, you are correct, even an 
interface not being up in the case off ppp, none the less would provide 
me with the information that need be obtained (if I can successfuly 
access a standard remote node), for example as i'm sure you're well 
aware of, a ddos attack.