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: | Nate Williams (na...@sri.MT.net) | |
| Date: | Jun 20, 1996 11:45:59 am | |
| 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.
Nate