CONFIG_FILTER error on arm

[Mukund Deshpande]

Thanks a lot for the reply Bjørn.

I was thinking the error was being thrown because  of some missing
option in my kernel configuration.

Config_packet is enabled and as you say config_filter is enabled by
default. there should be some other reason possibly one among the
three you have pointed..

I will customize the printfs so that we can know where actually it fails..


Thanks.
Mukund


On Fri, Nov 25, 2011 at 6:44 PM, Bjørn Mork <bjorn at mork.no> wrote:
> Mukund Deshpande <sai.mukund.sagar at gmail.com> writes:
>
>> Can no one help me with this error? :(
>> I have been stuck with this error since last 4 days...Have enabled all
>> netfilter options..
>>
>> Still dhcp daemon gives same error. CONFIG_PACKET or CONFIG_FILTER
>> should be enabled in kernel configuration :|
>
> The error message is very misleading.  CONFIG_FILTER hasn't existed in
> ages. It doesn't have anything to do with NETFILTER. The functionality
> which previously required CONFIG_FILTER is unconditionally enabled in
> Linux 2.6.
>
> And if you look through common/lpf.c you'll notice that the exact same
> message is printed for not less than three(!) non-related errors.
> Unless you have Token Ring enabled, which adds a fourth...  They even
> all use "socket" as prefix.  This makes it much harder to tell exactly
> which call failed.  But at least the print the returned error code:
> "Invalid argument".  So we can look at the three calls and see which one
> is likely to cause that:
>
> 1) socket(PF_PACKET, SOCK_PACKET, htons((short)ETH_P_ALL)
>
>  Yup, could be it if you didn't enable CONFIG_PACKET
>
> 2) bind (sock, &sa, sizeof sa)
>
>  Yup, could be it if there is an bug in the ifindex detection?
>
> 3) setsockopt (info -> rfdesc, SOL_SOCKET, SO_ATTACH_FILTER, &p, sizeof p)
>
>  Yup, could be a bug in the filter.  You say you cross compiled
>  this. I'm wondering if that might cause endianness problems when
>  building the filter?  Don't know - just guessing possible causes....
>
> The first thing I would do, was verifying that I actually had
> CONFIG_PACKET enabled in the running kernel.  Then I would locate these
> three calls in common/lpf.c and add enough debug output to them to find
> out exactly which one failed.  The path from there depends on the result
> of that.
>
>
>
> Bjørn
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users



-- 
Regards,
Mukund