mazhar, david, nivedita,
thanks for your replys:
>You should probably drop the packets using netfiler if you can (look at
> NF_DROP).
this is one thing i've tried by using a handler function (packet_type.func)
like this:
int packet_handler(struct sk_buff *skb ...)
{
return NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL, dev, dummy);
}
where dummy just returns. netfilter now sees all the outgoing packets :) but
when i try to drop them i get lots of wonderful flashing keyboard lights and
a long fschk... ;)
> No matter what you do in your packet handler, other devices will
> still see the packet, as will packet sniffers.
i suspect the crashes have something to do with this (or that i'm not
registering the hook properly/nf hooks can't drop stuff if registered in the
ptype_all list?), as all i ever get is a clone of the packet.
is there really no way of stopping the packet as it traverses the ptype_all
list (apart from e.g. changing its ttl or blanking its destination address as
it goes thru my handler!!)? could i somehow get a pointer to the original
sk_buff and do something with that?.
dropping's also important as i'm also implementing a delay mechanism (instead
of dropping) for outgoing packets. i'd envisioned a two part thing with the
handler parsing the packets it gets and if necessary pushing them onto its
own stack (and dropping them), then a timer driven routine which periodically
pops stuff off the stack + sends its out.
> Also, this is the input path, and you said you were interested in
> trapping packets in the output stream. (?)
hum, i fear this is where the glass house that's my conception of the linux
network stack takes a bit of damage :) my major problem is that i'm dealing
with packets to and from vmware vm's running on my linux box (to emulate a
virtual network). the vm's need to be in bridged mode, which means using the
(closed-source - the _real_ problem) vmware bridged-networking driver. this
is a module which gets inserted at the bottom of the ptype_all list. i think
this is the reason why none of the 5 netfilter hooks see any of the traffic
(in or out) from the vm's. so, what i'd imaged happen in the network stack is
(simplifying):
incoming packets come out of the device driver and move up thru the ptype_all
list then into the ptype_base hash. at any point in this journey a handler
may stop and claim a packet + send it off to an application (like vmware
does). upper handers in the list/hash don't see it (explains why not seen by
nf hooks)
outgoing packets can enter the list/hash at any point and move downwards then
out to the device driver (hence the vm packets not being seen even by
NF_IP_POST_ROUTING - called in ip_finish_output() - above the vm driver).
what's the damage?? ;)
thanks once again for your help,
jamie
On Wednesday 16 October 2002 2:08 am, Mazhar Memon wrote:
> > hi,
> >
> > i'm writing a kernel module (2.4.19) which sits in the network stack and
> > listens for outgoing tcp-syn packets and drops them if they start coming
> > too fast (e.g. when someone is doing a tcp-syn scan from your box).
>
> Most of the ways that people figure out how to drop packets at this level
> are usually tacky. One way is to replace the hard_start_xmit pointer (of
> the necessary device) with your own...again tacky. A lot of people seem to
> have a need to have this feature implemented for various projects
> (hint...hint...).
>
> You should probably drop the packets using netfiler if you can (look at
> NF_DROP).
>
> Regards,
> Mazhar Memon
> -
> : send the line "unsubscribe linux-net" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
