Re: network problems

>>
>> The problems are similar to 
>> http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010287.html
>>
>
>  That was a configuration issue.
>
>>
>> When I try to ping the address the machine panics!
>> (something with sin_family and in_lltable_lookup)
>> http://denisy.dyndns.org/panic.jpg
>>
>
>  After a quick cursory read over the code, this issue appears to be a 
> problem
>  in the flow-table handling logic in ip_output() function.
>
>  Two problems seem to exist in the flow-table logic.
>
>  1. In flowtable_lookup() where it searches for the destination in the
>     routing table, the code does not check for the rt_ifp type once a
>     route entry is found. In the case of "if_tun", the flow-table
>     must not try to cache any entry whose "rt_ifp->if_flag & 
> IFF_POINTOPOINT"
>     is true. Right now it does, and I think this will trigger the crash
>     later.
>
>  2. The flowtable_lookup() seems to alway assume a valid entry
>     will be returned as long as a route entry exists for the
>     destination. In other words, if a route exists for the destination,
>     then either flow-table already have a cache, or a new entry
>     is created.  This does not work due to (1.) above.
>     flowtable_lookup() should allow a "bypass flow-table" return, not
>     just success/failure result.   This is especially true for
>     tunneling interfaces "if_tun, if_gre" etc. where ip_output()
>     will be called multiple times (nested). Only at the final invocation
>     of ip_output() (where the rt->rt_ifp points to a physical NIC)
>     should a flow-table entry be created.
>
>  So for now, as a possible temporary workaround, disable FLOWTABLE in your
>  kernel configuration file and see if that fixes the problem.
>
>  -- Qing

Qing,

yes, disabling the flowtable (sysctl net.inet.flowtable.enable=0) fix the 
problem (no more IPv4 is not on the network). But here, everything is 
working fine, even with that annoying message (no crashes).

Thanks,
Luiz