On Mon, 29 Nov 2004, Thomas Spatzier wrote:
Has there been any outcome on the discussion about whether or not a
device driver should drop packets when the cable is disconnected?
It seems that from the zebra point of view, as Paul wrote, it would
be better to not block sockets by queueing up packets when there is
no cable connection.
I'd prefer either to get ENOBUFS or to have kernel drop the packet -
we're privileged apps writing to raw sockets and/or with IP_HDRINCL,
the kernel should assume we know what we're doing (cause if we dont,
there's far /worse/ we could do than send packets to an
I do also think that it does not make sense to keep packets in the
queue and then send those packets when the cable is plugged in
again after a possibly long time.
Well, if the kernel is going to queue these packets without notifying
us, we absolutely *must* have some way to flush those queues. Sending
stale packets many minutes after the application generated them could
have serious consequences for routing (eg, think sending RIP, IPv4
IRDP or v6 RAs which are no longer valid - client receives them and
installs routes which are long invalid and loses connectivity to some
part of the network).
So even if we moved to socket/interface, we still need some way to
tell kernel to flush a socket when we receive link-down over netlink
Not trying to queue on sockets where app has no expectation of
reliability in first place would be even better ;)
There are protocols like TCP that handle packet loss anyway.
I'd be very interested to hear advice from the kernel gurus (eg "god,
dont be so stupid, do xyz in your application instead"). We can
accomodate whatever kernel wants as long as its workable.
Paul Jakma paul@xxxxxxxx paul@xxxxxxxxx Key ID: 64A2FF6A
You will pay for your sins. If you have already paid, please disregard