arptables and the generic xtables issues

arptables and the generic xtables issues

[Pablo Neira Ayuso]

Hi,

Currently, we have tagged quite a lot of targets and matches with
AF_UNSPEC as they are generic for the netfilter supported protocols.
This is fine if we only think of ebtables, iptables and ip6tables but
not for arptables, I doubt that all those target and matches can work
with arptables - even if we still need the userspace support, of course.

I think that we should fix those, right?

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers

Re: arptables and the generic xtables issues

[Jan Engelhardt]

On Wednesday 2008-10-15 21:43, Pablo Neira Ayuso wrote:
>
>Currently, we have tagged quite a lot of targets and matches with
>AF_UNSPEC as they are generic for the netfilter supported protocols.
>This is fine if we only think of ebtables, iptables and ip6tables but
>not for arptables, I doubt that all those target and matches can work
>with arptables - even if we still need the userspace support, of course.
>
>I think that we should fix those, right?

That would be a tremendous amount of work, given that arptables (and
ebtables too) is not quite the same codebase as iptables anymore.
Most of the iptables development just went by arp and ebtables due
to the nature of all these semiforks.

I think we should rather focus on a truly family-independent table
in the very near future. In fact I have ideas floating around that,
but am stuck with how I'd exactly funnel it into reviewable patch
chunks.

Re: arptables and the generic xtables issues

[Patrick McHardy]

Pablo Neira Ayuso wrote:
> Hi,
> 
> Currently, we have tagged quite a lot of targets and matches with
> AF_UNSPEC as they are generic for the netfilter supported protocols.
> This is fine if we only think of ebtables, iptables and ip6tables but
> not for arptables, I doubt that all those target and matches can work
> with arptables - even if we still need the userspace support, of course.
> 
> I think that we should fix those, right?

Looking through the list (targets only, arp_tables doesn't support
matches):

- CLASSIFY: OK
- comment: OK
- CONNMARK/CONNSECMARK: no effect
- MARK: OK
- NFLOG: OK
- NOTRACK: no effect
- RATEEST: should be OK
- SECMARK: OK
- TRACE: OK, but currently no effect

So I don't think there really is a problem.

Re: arptables and the generic xtables issues

[Patrick McHardy]

Jan Engelhardt wrote:
> On Wednesday 2008-10-15 21:43, Pablo Neira Ayuso wrote:
>> Currently, we have tagged quite a lot of targets and matches with
>> AF_UNSPEC as they are generic for the netfilter supported protocols.
>> This is fine if we only think of ebtables, iptables and ip6tables but
>> not for arptables, I doubt that all those target and matches can work
>> with arptables - even if we still need the userspace support, of course.
>>
>> I think that we should fix those, right?
> 
> That would be a tremendous amount of work, given that arptables (and
> ebtables too) is not quite the same codebase as iptables anymore.
> Most of the iptables development just went by arp and ebtables due
> to the nature of all these semiforks.
> 
> I think we should rather focus on a truly family-independent table
> in the very near future. In fact I have ideas floating around that,
> but am stuck with how I'd exactly funnel it into reviewable patch
> chunks.

I think we should finish the unification/resyncing efforts before
adding new features in this area. There's still *a lot* of old
cruft that could probably be removed.

Re: arptables and the generic xtables issues

[Jan Engelhardt]

On Thursday 2008-10-16 09:23, Patrick McHardy wrote:
> Jan Engelhardt wrote:
>> On Wednesday 2008-10-15 21:43, Pablo Neira Ayuso wrote:
>> > Currently, we have tagged quite a lot of targets and matches with
>> > AF_UNSPEC as they are generic for the netfilter supported protocols.
>> > This is fine if we only think of ebtables, iptables and ip6tables but
>> > not for arptables, I doubt that all those target and matches can work
>> > with arptables - even if we still need the userspace support, of course.
>> >
>> > I think that we should fix those, right?
>> 
>> That would be a tremendous amount of work, given that arptables (and
>> ebtables too) is not quite the same codebase as iptables anymore.
>> Most of the iptables development just went by arp and ebtables due
>> to the nature of all these semiforks.
>> 
>> I think we should rather focus on a truly family-independent table
>> in the very near future. In fact I have ideas floating around that,
>> but am stuck with how I'd exactly funnel it into reviewable patch
>> chunks.
>
> I think we should finish the unification/resyncing efforts before

Yesyesyes, but I think we reached a point where the next step in
Improving It™ requires a big lockstep change with userspace OR
adding a new interface, just because of the "keeping compat" fun.

> adding new features in this area. There's still *a lot* of old
> cruft that could probably be removed.

Modules ripe for removal is just the smaller piece.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html