From: Giro on
Hi,

I've written an application using Raw sockets. And sending the
complete Layer2 frame.
sock = socket(PF_PACKET,SOCK_RAW,htons(ETH_P_ALL))

A call like
ret = send(sock, buff, buff_size,0);
should returns the number of trasferred bytes. So far so good. Now, If
I call the same function when the NIC link is down
(cable not plugged) then I receive no error. Instead I receive the
number of bytes trasferred.

Is this is a special case for raw sockets? I guess sockets on higher
layers like IP or TCP should return an error in such a case.

Is there any possibility to register a callback routine for a link
state change event?
I guess I can check with an ioctl call to the driver whether the link
is up or not. But a callback would be better ofcourse.

Thanks for any help.
Giray
From: Gordon Burditt on
>I've written an application using Raw sockets. And sending the
>complete Layer2 frame.
>sock = socket(PF_PACKET,SOCK_RAW,htons(ETH_P_ALL))
>
>A call like
>ret = send(sock, buff, buff_size,0);
>should returns the number of trasferred bytes. So far so good. Now, If
>I call the same function when the NIC link is down
>(cable not plugged) then I receive no error. Instead I receive the
>number of bytes trasferred.
>
>Is this is a special case for raw sockets? I guess sockets on higher
>layers like IP or TCP should return an error in such a case.

A TCP connection shouldn't be aborted just because link state
bounces, especially if nothing was being transmitted at the time.
And in my experience, (the network cable sometimes falls out of my
laptop), it doesn't. I can put it back and resume surfing the web
with only a minor delay. If it's disconnected over about 45 seconds,
then connections start breaking.

The same applies to UDP "connections" where things like DNS lookups
are retried after a timeout, whether link status bounces or not.
*Eventually* they fail if the problem persists.

>Is there any possibility to register a callback routine for a link
>state change event?
>I guess I can check with an ioctl call to the driver whether the link
>is up or not. But a callback would be better ofcourse.

Consider a system where the link state glitches briefly (although
not at the hardware level) whenever DHCP renews. With a particular
brand of DSL modem, that's every 30 seconds, 24x7. I don't think
any packets actually get lost. Are you sure you actually want to
pay attention to that, or should you pay attention to whether you
got an answer to whatever it was you tried to send?

From: Nicolas George on
Gordon Burditt wrote in message
<mNydnRi-Xt6HBmXWnZ2dnUVZ_hWdnZ2d(a)posted.internetamerica>:
> A TCP connection shouldn't be aborted just because link state
> bounces, especially if nothing was being transmitted at the time.
> And in my experience, (the network cable sometimes falls out of my
> laptop), it doesn't.

This is perfectly trye, but...

> I can put it back and resume surfing the web
> with only a minor delay.

.... this does not prove it, as web surfing relies mostly on short
independent connections.
From: Gordon Burditt on
>> A TCP connection shouldn't be aborted just because link state
>> bounces, especially if nothing was being transmitted at the time.
>> And in my experience, (the network cable sometimes falls out of my
>> laptop), it doesn't.
>
>This is perfectly trye, but...
>
>> I can put it back and resume surfing the web
>> with only a minor delay.
>
>... this does not prove it, as web surfing relies mostly on short
>independent connections.

It does if you attempt the connection AFTER the cable falls out, notice
the page isn't coming up, plug in the cable, and the page appears.