how to use promiscuous mode without receiving the packages from localhost?

Hi, I want to use the promiscuous mode to meet some requirement. However, to reduce the load, I'm not like to receive the packages form localhost. Does anybody know how to do it? Thx.

Best wishes, Lrj

Reply to
Lrj
Loading thread data ...

????

AFAIK, the meaning of promiscuous mode is exactly that: the software gets all packets received by the hardware/driver.

-Michael

Reply to
Michael Schnell

Promiscious mode, by definition, is where the NIC receives and passes on to the network stack /all/ packets that it detects. This includes packets originating from the local host. You can't have promiscious mode and /not/ have these packets.

Reply to
Lew Pitcher

But if you have a full-duplex connection then outgoing messages aren't on the same wires as incoming, so you ought to be able to isolate them, don't you think?

Peter

Reply to
Peter Dickerson

Dont spawn processes that use localhost services... by definition those are located in the same machine performing the promiscuous mode stuff.

Salud Rene

Lrj wrote:

Reply to
rTrenado

[top posting fixed]

I took the issue to be how to avoid outgoing packets rather than incoming (addresses to the local machine). If the problem is incoming then hardware doesn't provide this function, so filtering in software is the only option other than making sure that nothing should be directed to the local machine.

Peter

Reply to
Peter Dickerson

To me this makes sense only if you want to reduce the load to your application. The load on the interface (network card) cannot be reduced (see other posts).

That's obvious, that you're only interested in packets from outside. So you want to separate packets depending on the incoming interface.

iptables: just create two different chains, one receiving all packets from eth0 (if this is the interface you're interested in), while all other packets go to another. Either you combine both queues afterwards, such that other applications aren't influenced, or you may drop the other packets. Create a special log file, etc...

However, I wonder how you receive the packets in your application. Usually you have the information from which interface the packets come, so you should be able to select them, anyhow.

Bernhard

Reply to
Bernhard Holzmayer

Thanks for all above.

First, I'd like to give a description more clearly. I mean: I just don't want to receive the packets outgoing from the localhost, not incoming. And my project is a embedded system.

I used to try the iptables/netfilter. However, I found that in the function ip_rcv(), all the packets whos destination is not the local will be dropped. And the first HOOK of netfilter, NF_IP_PRE_ROUTING, is just in the last part of the ip_rcv(). So in my opinion, the iptables/netfilter will have no effect on those packets, am I right?

And, in my opinion, when the promiscuous mode is activated, all the packets hardware received will raise an interrupt to alert the software. My question is that, when the outcoming packets from the localhost was received by the local in promiscuous mode, if they go through the hardware or not? I think that they will not go through the hardware, am I right? And if they don't go through the hardware, there will must be a software mechanism to receive the outgoing packets directly from the IP layer instead of the physical layer. So where is this mechanism in the kernel source? I want to modify it to meet my reqiurements.

thx.

Best wishes, Lrj

Reply to
Lrj

Typically, traffic sourced by the system goes past the "taps" _before_ it gets to the NIC. If the NIC does offer to give to the host its own traffic, either the host tells it to not do that, or filters it. Otherwise, combined with things like interrupt avoidance you could end-up with:

ICMP Echo Reply N ICMP Echo Request N

It could very well be driver-specific because it is NIC-specific as to whether or not the NIC hardware gives-back frames with the local MAC as the source MAC.

rick jones

--
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
these opinions are mine, all mine; HP might not want them anyway... :)
 Click to see the full signature
Reply to
Rick Jones

"Rick Jones wrote:"

Sorry, I don't quite understand the last sentence, es. the "> ICMP Echo Reply N > ICMP Echo Request N" to avoid the interrupt. And, what's your meaning by "the taps"?

You mean, I should modify the driver of my NIC to drop the frames from the local MAC? I will try, thx.

Best wishes, Lrj

Reply to
Lrj

I meant that there is a chance of reordering the traffic in the promiscuous stream such that it does not match what happened on the network, and that being why "the taps" - as in "wiretaps" as in where in the code the packets are sent to the promiscuous stream - are where they are.

Might be best to check some other NIC drivers to see what they do before accepting the word of a psueudo-random person on the net... :)

At one point in HP-UX of years gone by, "promiscuous mode" only showed what came-in via the NIC - so that would be broadcast/multicast/stuff to our local MAC and wouldn't show outbound traffic. Now it will show both, and I found myself once wishing there were (in DLPIspeak) DL_PROMISC_PHYS_IN and DL_PROMISC_PHYS_OUT instead of just DL_PROMISC_PHYS - ie finer grain on the promiscuous request. No idea if "Linux" has anything like that these days or not - i'd think the bridging guys might want that...

rick jones

--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
 Click to see the full signature
Reply to
Rick Jones

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.