> > kernel interfaces, but discovered the the kernel's higher-level network
> > code had changed such that only one application at a time could open a
> > SOCK_PACKET for any specific socket type, which prevented the whole scheme
> > from working.
>
> It isnt supposed to have been. Are you sure about this ?
>
> > Has this behaviour of SOCK_PACKET changed since circa 1.3.70? If so,
> > dosnet.c could be modified to work with new kernels. (Of course, if
> > somebody's already done this I may be flapping my jaw needlessly. :)
>
> Its changed a bit in that you can bind() them and pass protocol id hints
> when you want (eg for PPP)
Okay I started reading some kernel code in 2.0.29 and I came across this
section, which appears to be identical in 2.1.27, btw.
>From net/core/dev.c, about line 650, in net_bh():
/*
* We got a packet ID. Now loop over the "known protocols"
* list. There are two lists. The ptype_all list of taps (normally empty)
* and the main protocol list which is hashed perfectly for normal protocols.
*/
pt_prev = NULL;
for (ptype = ptype_all; ptype!=NULL; ptype=ptype->next)
{
if(pt_prev)
{
struct sk_buff *skb2=skb_clone(skb, GFP_ATOMIC);
if(skb2)
pt_prev->func(skb2,skb->dev, pt_prev);
}
pt_prev=ptype;
}
Either this is a bug or my brain isn't functioning properly. (The latter
is a distinct possibility as it's almost midnight. :)
The problem I see is with the pt_prev variable. Why is it even there? It
looks like this loop will never process the last entry in the ptype_all
list.
+-----------------------+---------------------------------------+
| Nathan Bryant | Unsolicited commercial e-mail WILL be |
| nathan@burgessinc.com | charged an $80/hr proofreading fee. |
+-----------------------+---------------------------------------+