On 12 Aug 1999, Andi Kleen wrote:

> > Would it then be neccesary use ipchains program in (l)user space so that
> > ALL net traffic would go trough this module?
> No, ipchains only configures the ipchains firewall module. If you register
> your own it is independent.
Ok this would be good

> > back,etc) and in a way that it'd work in 2.0 and 2.2 (hopefully 2.4 no
> > major net changes there?).
> 2.4 will have netfilter (means register_firewall will be gone and you'll
> need to use netfilter API)
Ok this is not nice :(

I'd have to write this module foobar for all version 2.0, 2.2, 2.4 *sigh*
------------------

On Thu, 12 Aug 1999, Tom Gallagher wrote:

> > been doing (except modifying IP destinations (skb->data[26-33]) to
> > something weird ;) ) it would seem that I'd have to try this ipchains
>
> The IP address will only be at 26-33 in the case of Ethernet.  If you
> ever use your program on Token-Ring, PPP, SLIP etc etc it won't work
> if you hard code offsets into it.
I know this but it would be somewhat easy to check which protocol is
coming ie.
---
if((skb->data[12] == 8) && (skb->data[13] == 0))
    {
      DEBUG(3,("*Internet Protocol packet* from:%d.%d.%d.%d to:%d.%d.%d.%d\n",
           skb->data[26],
           skb->data[27],
           skb->data[28],
           skb->data[29],
           skb->data[30],
           skb->data[31],
           skb->data[32],
           skb->data[33]));
    }
else if ((skb->data[12] == 8) && (skb->data[13] == 6))
    {
      DEBUG(3,("*Arp protocol*\n"));
    }
------------------

So the dev_add_pack() is not "the way (tm)" to do the thing?
Sad thing is that it seems to be most "portable" way in linux 2.0&2.2 (I'd
think it will be in 2.4 also) versions without having to hack the kernel
sources.

dev_queue_xmit_nit() && net_bh() seem to be functions that do the cloning
and send clones onwards to protocol list (net_bh() in particular). However
if I'll choose way of "kernel source hacking" I might as well do some more
major changes... :(

I also tried to modify lenght of packages to 0 which would make kernel to
discard them later on however this did not work either. 
I tried skb->len && skb->truesize.

I'd seem that in this "protocol" of mine I could change only skb->data
area so that it'd be noticed later on by kernel.

-- 
Janne

-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]

Reply via email to