Date: Mon, 13 Jul 1998 12:18:19 +0200 From: Eivind Eklund <eivind@yes.no> To: "Larry S. Lile" <lile@stdio.com>, hackers@FreeBSD.ORG Subject: Re: Still having problems with my driver :( Message-ID: <19980713121819.08980@follo.net> In-Reply-To: <Pine.SUN.3.91.980711153811.23884C-101000@heathers.stdio.com>; from Larry S. Lile on Sat, Jul 11, 1998 at 03:47:07PM -0400 References: <Pine.SUN.3.91.980711153811.23884C-101000@heathers.stdio.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I limited this to -hackers only, as it isn't really a tokenring
problem.
On Sat, Jul 11, 1998 at 03:47:07PM -0400, Larry S. Lile wrote:
>
> I still cannot get the upper network layers to respond to incoming
> packets. I even hacked tcpdump to make sure that I was no wrecking
> the packets as I took them off the wire.
>
> 15:29:58.698564 arp who-has anatok tell blastok (0:0:83:2d:9f:35)
> hardware #6
> 15:29:59.588735 cyntok > anatok: icmp: echo request
> 15:30:00.590438 cyntok > anatok: icmp: echo request
> tcpdump: WARNING: compensating for unaligned libpcap packets
> (^- anybody know how to fix this?)
> 15:30:03.499586 cyntok.1054 > anatok.telnet: S 3037285377:3037285377(0)
> win 16384 <mss 1452>
> 15:30:09.271262 cyntok.1054 > anatok.telnet: S 3037285377:3037285377(0)
> win 16384 <mss 1452>
> 15:30:09.702343 arp who-has anatok tell blastok (0:0:83:2d:9f:35)
> hardware #6
>
> The only messages I got indicating anything at all is wrong were
> these when I ifconfig the card up for the first time after a
> reboot.
>
> Jul 10 22:21:33 anarchy routed[69]: ignore RTM_ADD without gateway
> Jul 10 22:21:33 anarchy routed[69]: Send bcast sendto(tok0,
> 10.0.0.255.520): No buffer space available
> Jul 10 22:21:33 anarchy routed[69]: write(rt_sock) RTM_ADD 10.0.0.0/24
> --> 10.0.0.1: File exists
>
> Any ideas what might be wrong, or could someone please look at my
> code and help me figure this out.
If ping -f gives the same "no buffer space available", it probably
originate here (around line 333 in netinet/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;
}
If this is the case, it is due to your driver not pulling packets off
the output queue (or not doing it fast enough). What to do about it
depend on the internals of your driver.
The 'file exists' comes from an already existing route being
overwritten - that part of it shouldn't be a problem, I think.
Eivind.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980713121819.08980>