netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Renzmann <mrenzmann@web.de>
To: Ben Greear <greearb@candelatech.com>
Cc: netdev@oss.sgi.com
Subject: Re: Deleting incoming network packets / sk_buff
Date: Sun, 15 Aug 2004 20:05:04 +0200	[thread overview]
Message-ID: <411FA5D0.6000004@web.de> (raw)
In-Reply-To: <411E8EE4.70900@candelatech.com>

Hi Ben.

First of all, thanks for your answer.

Ben Greear wrote:
> There is no way that I am aware of to block packets from high-level 
> protocols, but you can disable the higher protocols (ie, set IP to 
 > 0.0.0.0).

Unfortunately this doesn't work for my setup. I have some kind of 
userspace bridge implementation running, which copies frames incoming on 
a physical device (e.g. eth1) to a virtual (tun/tap) device (e.g. tap0) 
and vice versa. When the kernel wants to communicate with the outside 
world it does this by using tap0, and the program "bridges" the packets 
to eth1. In order to avoid to have eth1 running in promiscious mode I 
configure tap0 to have the same MAC address as eth1 - but this has the 
drawback that the kernel sees every incoming packet twice: once when it 
hits eth1, and once when it gets copied by the userspace bridge to tap0.

There is no simple way to have the incoming communication "split" over 
both interfaces without running in serious troubles regarding firewall 
rules or such things as having quagga/zebra dropping incoming OSPF 
announces from eth1 (since it self uses tap0 to communicate with the 
outside world).

Abd yes, it is necessary to have this host only using tap0 for outgoing 
communication (it would be longish to explain the reason, just believe 
me for now ;)).


Bottom line: the easiest way to solve this problem would be to have some 
way for blocking packets on eth1 from being processed (after they have 
been passed to the packet socket - else my userspace program won't be 
able to "bridge" incoming packets to tap0).

> You can also hack net/core/dev.c to stop the packets from going
> up the stack, but it requires more than just a new kernel module,
> you'd have to actually change dev.c.  (Search for BRIDGE).

Hmm, now that you mention it: at least the 2.4.x kernels I use have the 
bridging code enabled. I'll take a look at possible hooks or other 
mechanisms that are used by the bridging code for its job - maybe this 
will help. Thanks for the hint.

Bye, Mike

  reply	other threads:[~2004-08-15 18:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-14 19:12 Deleting incoming network packets / sk_buff Michael Renzmann
2004-08-14 22:15 ` Ben Greear
2004-08-15 18:05   ` Michael Renzmann [this message]
2004-08-15 18:18     ` Ben Greear
2004-08-15 18:57       ` Michael Renzmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=411FA5D0.6000004@web.de \
    --to=mrenzmann@web.de \
    --cc=greearb@candelatech.com \
    --cc=netdev@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).