Messages in this thread | | | Date | Wed, 18 Feb 2004 01:33:44 +0000 (GMT) | From | Paul Jakma <> | Subject | raw sockets and blocking |
| |
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@clubi.ie paul@jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam@dishone.st 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |