Thanks, Kenjiro...

My box is working fine now
Thanks for the solution

Heron Gallegos


On Thu, 21 Feb 2002, Kenjiro Cho wrote:

> Date: Thu, 21 Feb 2002 14:24:24 +0900 (JST)
> From: Kenjiro Cho <kjc@csl.sony.co.jp>
> To: list11@sepc.edu.mx
> Cc: current-users@netbsd.org
> Subject: Re: ALTQ: help with altq_etherclassify
>
>
> Lista de NetBSD current <list11@sepc.edu.mx> wrote:
> > I am running -current (Feb 2 2002) i386, my kernel was
> > compiled with the "altq most common options". After to run
> > /etc/rc.d/altqd start, I got a lot of error messages:
> >
> > altq_etherclassify: headers span multiple mbufs: 14 < 34
> > altq_etherclassify: headers span multiple mbufs: 14 < 34
> > altq_etherclassify: headers span multiple mbufs: 14 < 34
> > altq_etherclassify: headers span multiple mbufs: 14 < 34
> >
> > I have compiled the kernel again with NMBCLUSTERS=4096
> > and "make USETOOLS=no depend all", but when I reboot the
> > machine and start altqd, the same messages appears,
> > exactly with the numbers 14 and 34 (a lot of times).
>
> short answer: you can comment out the corresponding printf()
> in altq_etherclassify() in sys/net/if_ethersubr.c.
>
> longer answer:
> major protocols reserve a leading space when they allocate a mbuf so
> that an ethernet header fits into the first mbuf.
> apparently, some types of control protocols don't reserve a leading
> space for an ethernet header.
> I can't tell what protocol causes this for you.  (one I know of is the
> bridge control protocol in OpenBSD.)
>
> when altq_etherclassify() finds the ethernet and ip headers are not in
> the fisrt mbuf, it prints a warning message, just gives up classifying
> the packet and puts the packet into a default class.
> since these protocols are not too important for traffic control,
> just supressing the warning message should be ok, at least for now.
>
> -Kenjiro
>