promiscuous mode w/ hook

promiscuous mode w/ hook

[Richard Gopaul]

Hi,

I'm trying to put my ethernet interface into promiscuous mode and have all traffic sent to the netfilter prerouting hook.  I've read documentation on line and in the source that says that traffic doesn't make it to netfilter until after foreign promiscuous packets are dropped though, which makes me think this will be a bit of a challenge.  Any ideas?

Thanks,
Richard ;

Re: promiscuous mode w/ hook

[Aleksandar Milivojevic]

Richard Gopaul wrote:
> Hi, 
> 
> I'm trying to put my ethernet interface into promiscuous mode and have all traffic sent to the netfilter prerouting hook.  I've read documentation on line and in the source that says that traffic doesn't make it to netfilter until after foreign promiscuous packets are dropped though, which makes me think this will be a bit of a challenge.  Any ideas?  

Either I'm missing what you want to do, or the question doesn't make any 
sense.  It doesn't matter if interface is in promiscuous mode or not. 
If apropriate Netfilter modules are loaded, packets will end up in 
prerouting chain (unless something in kernel drops them earlier, such as 
rp_filter).

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: promiscuous mode w/ hook

[Nick Drage]

On Fri, Oct 22, 2004 at 08:55:18AM -0500, Aleksandar Milivojevic wrote:
> Richard Gopaul wrote:

> >I'm trying to put my ethernet interface into promiscuous mode and
> >have all traffic sent to the netfilter prerouting hook.  I've read
> >documentation on line and in the source that says that traffic
> >doesn't make it to netfilter until after foreign promiscuous packets
> >are dropped though, which makes me think this will be a bit of a
> >challenge.  Any ideas?  
> 
> Either I'm missing what you want to do, or the question doesn't make
> any sense.  It doesn't matter if interface is in promiscuous mode or
> not.  If apropriate Netfilter modules are loaded, packets will end up
> in prerouting chain (unless something in kernel drops them earlier,
> such as rp_filter).

I *think* you're missing what Richard is trying to do.  I'm presuming
that all packets picked up by the ethernet inferface in promiscuous
mode, so irrespective of whether they're meant for the host or not,
should be sent to the prerouting table.

I would be surprised if this can be done without a great deal of hacking
around... but most interesting of all, why do you want to do this
Richard?

-- 
We are the Willing, led by the Unknowing,
Are doing the Impossible, for the Ungrateful.
We have done so much, for so long, with so little,
We are now qualified to do anything with nothing.

Re: promiscuous mode w/ hook

[Aleksandar Milivojevic]

Nick Drage wrote:
> I *think* you're missing what Richard is trying to do.  I'm presuming
> that all packets picked up by the ethernet inferface in promiscuous
> mode, so irrespective of whether they're meant for the host or not,
> should be sent to the prerouting table.
> 
> I would be surprised if this can be done without a great deal of hacking
> around... but most interesting of all, why do you want to do this
> Richard?

Yup, that would make sense.  I too don't see any simple way how to do 
it.  Maybe by creating virtual interface (such as tun or tap, depending 
on the Richards needs) and feeding the packet into it from userspace.

The packet would go through all Netfilter chains, and kernel would do 
the routing.  Both Netfilter and routing parts of kernel will see this 
packet as comming from tun/tap device (not from original physical 
network device).  It is quite possible that the packet will be routed 
back onto the physical interface it was received from (creating a loop 
and causing havoc on the network, unless userspace application and 
Netfilter rules are very carefully crafted to prevent this).  One way of 
avoiding this would be to use firewall marks, so that such packets can 
be identified later on by remaining chains and routing parts of the 
kernel.  However, still, a single typo could bring Richard's network down.

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7