Re: [ULOGD PATCH] rework, fill MAC address in ULOG for ethernet.

[Patrick McHardy <kaber@trash.net>]

Eric Leblond wrote:
> Hello,
> 
> On Friday, 2008 July 11 at 16:08:50 +0200, Patrick McHardy wrote:
>>>> This comment made me believe that it would break header
>>>> printing for non-ethernet packets. If that is not true,
>>>> I have no objections.
>>> Hmm, you're right but user using non-ethernet packets can upgrade to
>>> NFLOG ;)
>> I assume thats not meant seriously :) But we should integrate
>> new features into the new things, not break old things and
>> expect users to upgrade :)
> 
> Well, we still have a problem here:
>  * ULOG logs raw hardware header
>  * NFLOG logs source hardware address only
>  * SQL output module only support real MAC address (at least for PGSQL which
>  has a dedicated type)
> 
> I'm not able to find a clean and easy way to fix this.
> 
> Here's some possible solutions:
>  * Modify mac type in database to support everything:
>   * Performance impact
>   * Different datatypes in same field :(

It seems we already have a problem here since we can't put
other link layer headers in the database.

>  * NFLOG modification to log full hardware header:
>   * Will revert to a non parsable field :(

How about extending nfnetlink_log to include the full MAC header
and link layer type? That will make it a superset of ULOG.

>  * ULOG header parsing:
>   * Incomplete and untrustable by design
>   * May be able to retrieve source HW address info in most cases
>   * ULOG could output fields raw.mac and raw.mac.saddr to ensure
>   compatibility with older applications

Why don't you do something similar to your previous patch,
but instead of refusing unknown header lengths, treat
them as before?

> IMHO last solution is the less worst one. If it seems ok for you, I will
> provide a patchset implementing this solution.

I don't think I understand the problem well enough yet
to make that decision. Generally, I'm fine with anything
that doesn't break existing features and doesn't stand
in the way of correctly handling non-ethernet headers.