9 messages in org.freebsd.freebsd-hackersRe: IP question: who should return EN...| From | Sent On | Attachments |
|---|---|---|
| Greg Lehey | Jun 20, 1996 11:03 am | |
| Nate Williams | Jun 20, 1996 11:45 am | |
| Dennis | Jun 20, 1996 2:06 pm | |
| David Greenman | Jun 20, 1996 2:43 pm | |
| Greg Lehey | Jun 21, 1996 12:50 am | |
| Greg Lehey | Jun 21, 1996 6:36 am | |
| Oleg N Panashchenko | Jun 21, 1996 10:03 am | |
| Greg Lehey | Jun 22, 1996 4:16 am | |
| David Greenman | Jun 22, 1996 5:33 pm |
| Subject: | Re: IP question: who should return ENOBUFS? | |
|---|---|---|
| From: | Dennis (den...@etinc.com) | |
| Date: | Jun 20, 1996 2:06:48 pm | |
| List: | org.freebsd.freebsd-hackers | |
I Cc'd David on this since I'm not sure he reads hackers, and he's responsible for the piece of code in question.
I've just spent a fair amount of time trying to figure out why our ISDN software jams up if it can't establish a connection. The symptoms are that if you can't establish a connection before a certain number of packets have been sent, the whole interface just returns:
=== root@freebie (/dev/ttyp0) /sys/netinet 11 -> ping 192.109.197.38 PING 192.109.197.38 (192.109.197.38): 56 data bytes ping: sendto: No buffer space available ping: wrote 192.109.197.38 64 chars, ret=-1 ping: sendto: No buffer space available
....
. After a bit more investigation, I found this code in
ip_output.c:
/* * Verify that we have any chance at all of being able to queue * the packet or packet fragments */ if ((ifp->if_snd.ifq_len + ip->ip_len / ifp->if_mtu + 1) >= ifp->if_snd.ifq_maxlen) { error = ENOBUFS; goto bad; }
I think this is bogus. It's not present in the BSD/OS version, so I assume it was added in FreeBSD. The problem is, it gives you no possibility of recovery: the queue is full and stays that way. Can anybody give me an idea of why it's there, when the interface is perfectly capable of looking after itself?
Here's the log messages when David made the change.
---------------------------- revision 1.3 date: 1994/08/01 12:01:45; author: davidg; state: Exp; lines: +10 -0 fixed bug where large amounts of unidirectional UDP traffic would fill the interface output queue and further udp packets would be fragmented and only partially sent - keeping the output queue full and jamming the network, but not actually getting any real work done (because you can't send just 'part' of a udp packet - if you fragment it, you must send the whole thing). The fix involves adding a check to make sure that the output queue has sufficient space for all of the fragments.
ENOBUFS causes a QUENCH to be sent, which is arguably correct if the problem is truly a queue overload. This should not "break" the connection unless the source is broken. ICMP ignores the return value from ip_output, so it should not matter what is returned.
Another problem is that you need queue management based on the available bandwidth of the interface. You can't have the same management scheme or thresholds for a 10Mbs interface as you do for a 56kbs one.
This is precisely why we have the interface manage the queue depth. Additionally, queue managment should be based on queue size in bits (or bytes), not number of packets. 100 60 byte packets is not backup... 100 1000 byte packets is. Using packet counts is simply wrong.
Dennis
---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com
Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 for BSD/OS, FreeBSD and LINUX