Re: Re: ebt_inat

On Monday 15 September 2003 22:40, Grzegorz Borowiak wrote:
> If you like, I'll rename as isnat-target, but IMHO it will be somewhat
> misleading.

You're right.

> In my firewall, I heavily use DROP in nat. And leaving '_' action allows
> to combine indexed NAT with mac-security in one rule, thus saving the CPU.

How about 'D' (or something else descriptive) instead of '_'?

> If nobody needs such features, OK - I will not create them, because I
> don't need them much, too.

Perhaps first concentrate on getting inat finished. We can then see what DaveM 
thinks.

> Yes, this is an unusual situation. But if it happened, and I wrote inat, I
> would like to share this.

OK. I'll put your situation+solution on the ebtables website later, always 
nice to have a story :)

> BTW I have another idea. What about an option --arpreply-mac AUTO, which
> would do the following:
>
> - if we have this IP in the ARP cache, we answer and drop.
>
> - if not, we pass this packet and wait for the reply.
>
> To make this work, however, we would need also an additional target, name
> it arpcache, which would remember all trespassing ARP-reply packets (maybe
> not only ARP-reply packets) to the local ARP cache.

We'll need to add timers so the cache entries don't stay there forever.

> That all would allow to make a very large LANs without risk of being
> flooded by broadcast ARP request packets.
>
> If somebody is interested, I can extend arpreply in this way.

Looks useful to me, but could be quite some work to implement right.

cheers,
Bart



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf