Re: --arpreply-mac AUTO and Mac Masquerading

First of all. I wrote the previous mail like 6am without sleeping so the
text was confusing at some points. Can't even understand it completly
myself when I'm reading it ;) sorry about that...

Really short summary, and hopefully more understandable:
The customers could have 1 or more IPs. The customers don't have static
IPs. The customers macaddress could be anything. IP addresses should never
change.

IP1 ---- eth0 - br0 - eth1.101 ---- IP2(customer)
                      eth1.102 ---- IP3,IP4(customer with 2 IPs)

<-IP = iptables mangle, mark with incoming vlannumber, ebtables snat
markvalue with predefined macaddress(one mac for each customer).
->IP = ebtables redirect-target
<-ARPrequest = Bridge need to answer from arpcache if possible.
Otherwise(or always) snat the packet and let it through. ebtables
redirect-target the arpreply and bridge will install in arpcache.
->ARPrequest = Bridge need to answer from cache if possible. Otherwise(or
always) let the packet through. ebtables redirect-target the arpreply and
bridge will install in arpcache.

>
> Sorry, I don't quite see why you need to snat their traffic...
>

Why I would like to snat their traffic is because when you have lots of
customers it's really great if you could easily be sure of who the true
source is. Otherwise it's really timeconsuming to hunt down a single user
that's spamming the network with useless data.
And I also read some other old thread about "Dynamic source MAC-NAT?"
which seems to be the same thing as I'm talking about.

>>
>> So in conclusion, the only thing that needs to be done for this whole
>> thing to work. That's to make the --arpreply-mac AUTO check in the
>> bridge
>> fdb for an entry. Read about some timer issues in the old thread. But is
>> that really necessary. Doesn't the bridge fdb take care of all that?
>
> I was probably thinking that the arp entries would be cached by the
> arpreply target. That way you don't need the arp code. But you can add a
> new entry into the arp cache without having to actually redirect the
> packet (something like that would then best be put in a watcher module,
> so the user can decide which arp packets can be used to fill the arp
> cache).

A watcher module seems like a good idea. It shouldn't matter if the arp
request continues all the way to the target, even though the bridge
already has(if entry exist) answered the sender from the cache.

Another solution I'm thinking of is to use some modified arpd/farpd. What
do you think is the preferred method?

/Regards Oscar



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642