From: DEMAINE Benoit-Pierre <benoit@demaine.info>
To: netfilter@vger.kernel.org
Subject: Re: ebtables to perform MAC NAT ?
Date: Wed, 23 Jul 2008 20:54:14 +0200 [thread overview]
Message-ID: <48877E56.90703@demaine.info> (raw)
In-Reply-To: <48860C0C.60504@riverviewtech.net>
Grant Taylor wrote:
> Heh. Sounds like your home network is more of a daisy chain of
> computers with multiple network cars in them or something else equally
> as strange.
This is a very good point of view of my topology. But offtopic.
> That's because it's not a package per say. Proxy ARP is a feature of
> the kernel that has to be enabled, much like routing and IP forwarding.
>
> Rather than me re-typing how to do it, take a look at the write up about
> it in the Linux Advanced Routing and Traffic Control HowTo -
> Pseudo-bridges with Proxy-ARP
> (http://lartc.org/howto/lartc.bridging.proxy-arp.html).
I will read that soon.
[...]
For now, i have tested parprouted (see message dated 22/07/08 18:01
(west Europe)). Fact is: it solves the arp problem at one condition: I
have to shutdown completely the bridge.
parprouted does not work at all with br0; it works properly only for
eth0+wlan0_rename ... and only when br0 is off ("brctl delbr br0");
then, all ARP tables are set up as desired (real mac of the machine
within the segment; IPs of machines from other segments are aliased to
Gluton's MAC). Et the time i do "brctl addbr br0 && brctl addif br0
eth0", arp resolution stops working (after cache expiry, or manual
deletion).
So, my problem is not to get the right arp resolution, and find a way to
bridge interfaces so that it wont prevent arp to work as required. This
is an offtopic problem for now; i have a new path to walk, and i got new
ideas for google keywords to search for. I ll give feedback in few days
(either giving a solution, or with new problems :D ). I have to find why
parprouted and brctl seem incompatible ... or how people do the bridging
when using parprouted around ...
***
I am open minded for changing the software approach, as long as we keep
trying to use my actual hardware.
I now have things to work on my side.
--
>o_/ DEMAINE Benoit-Pierre (aka DoubleHP) http://benoit.demaine.info/
If computing were an exact science, IT engineers would not have work \_o<
"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
next prev parent reply other threads:[~2008-07-23 18:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-21 6:09 ebtables to perform MAC NAT ? DEMAINE Benoit-Pierre
2008-07-21 15:08 ` Grant Taylor
2008-07-21 15:58 ` DEMAINE Benoit-Pierre
2008-07-21 19:37 ` Grant Taylor
2008-07-21 23:09 ` DEMAINE Benoit-Pierre
2008-07-22 16:34 ` Grant Taylor
2008-07-23 18:54 ` DEMAINE Benoit-Pierre [this message]
2008-07-30 14:11 ` DEMAINE Benoit-Pierre
2008-07-22 8:25 ` Oscar N
2008-07-22 16:01 ` DEMAINE Benoit-Pierre
2008-07-23 7:57 ` Oscar N
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=48877E56.90703@demaine.info \
--to=benoit@demaine.info \
--cc=netfilter@vger.kernel.org \
/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