> Bosko and I were discussing my problem offline a couple of weeks ago,
you see, a couple of weeks ago the whole bridging-related
code had all sort of race conditions involving pointers to memory
areas about to be freed. I think/hope to have fixed most of them
now so it is probably worthwhile concentrating on the one problem
with recent code.
> > Can you by chance find out what is the "len" value passed
> > to ed_get_packet? The printout in line #10 below is par-
> > tially deleted by some error message.
>
> Sure. I did "up 10", followed by "print len", and the value of this
> parameter was reported as 10.
interesting enough, because this 10 cannot be a valid packet.
The min ethernet header is 14 bytes, so even if this calls refers
to the packet after the header extraction (and it is probably not
the case), you still should have 50 bytes for a valid packet.
Try the following patch: near line 2209 of if_ed.c
* we have a length that will fit into one mbuf cluster or less;
* the upper layer protocols can then figure out the length from
* their own length field(s).
*/
- if ((len > sizeof(struct ed_ring)) &&
+ if ((len > ETHER_HDR_LEN + sizeof(struct ed_ring)) &&
(len <= MCLBYTES) &&
so that at least we avoid passing around mbufs with negative length,
and other odd things.
cheers
luigi
----------------------------------+-----------------------------------------
Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa)
http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704
Phone: (510) 666 2927
----------------------------------+-----------------------------------------
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
