raw sockets and blocking

[Paul Jakma]

Hi,

I'm curious, is it good for raw sockets to block for writes because a 
cable of one interface has been pulled? 

We're seeing a problem with ospfd (www.zebra.org/www.quagga.net) 
which uses a single raw, AF_INET/OSPF socket and manages it's own IP 
headers, to send/receive OSPF packets to/from a number of interfaces.

The problem we see is that:

- a cable is pulled from an interface
- the application tests the file descriptor to see if it ready for 
  writing, and finds it is.
- the application constructs a packet to send out that interface
  and sends it with sendmsg(), no error is posted.
- the file descriptor never becomes available for writing again
- hence, all OSPF adjacencies are lost, because we can no longer 
write out packets to the file descriptor.

we havnt yet tested if it becomes writeable again if we put cable
back in, however if we detect absence of IFF_RUNNING and hence
manually avoid constructing packets to be sent via link-down
interfaces, we avoid this problem. However, this leaves us with a
race.

Is this proper behaviour? I'm guessing the driver or network layer is 
blocking the socket because it is waiting for the link to come back, 
however would it not be better to discard the packet, especially a 
raw packet?

(if it is "proper" behaviour that's fine, we can work with that, we 
were just surprised sendmsg() is trying to be /that/ reliable :) .)

regards,
-- 
Paul Jakma	paul@xxxxxxxx	paul@xxxxxxxxx	Key ID: 64A2FF6A
	warning: do not ever send email to spam@xxxxxxxxxx
Fortune:
How much net work could a network work, if a network could net work?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/