On (03/03/09 00:43), Kacheong Poon wrote:
>>>> - icmp_bsd_compat: sounds like something that should
>>>>   be a setsockopt, if we want something other than the
>>>>   default. Does anyone actually alter the default here?
>>
>> this one is defined as "if 1 (default) the length field in the IP
>> header of received datagrams is adjusted to exclude the length of the
>> IP header. This is compatible with Berkeley derived implementations and
>> is for applications reading raw IP or raw ICMP packets. If 0, the
>> length is not changed." 
>>
>> But if the admin sets this to 0, all the existing raw-socket apps that 
>> look at the length would be broken! How does it help to have
>> a big button for the whole machine in this case? 
>
>
> So I guess this one is for bug compatibility with old BSD.
> I'm wondering if the current *BSD still behaves like this.
> If no, it means that some sys admin may actually turn this
> off to make those new apps work.  Have you checked this out?

not from looking at netbsd (http://tinyurl.com/be9kdv)
rip_input() has:

        /*
         * XXX Compatibility: programs using raw IP expect ip_len
         * XXX to have the header length subtracted, and in host order.
         * XXX ip_off is also expected to be host order.
         */
        hlen = ip->ip_hl << 2;
        ip->ip_len = ntohs(ip->ip_len) - hlen;
        NTOHS(ip->ip_off);

The problem with having icmp_bsd_compat as an ndd tunable is
that we now need to have *all* apps running in bsd compat mode,
or all apps running in the non-compat mode.

>>>> - [ip, tcp, icmp, udp]_wroff_extra- who modifies these
>>>>   from defaults? The stack should self-tune these based
>>>>   on the ill_phys_addr_length it learns through DLPI.
  :
> I suspect that this is for historical reason since all the
> transports, IP and drivers are different STREAMS modules.
> And I guess there was no such communication on exactly
> this info.
>
> One interesting question to think about is whether using
> ill_phys_addr_length is good enough.  All the _wroff_extra
> params have values bigger than most MAC header length.  One
> use of this I can think of is for interesting alignment.
> Then using ill_phys_addr_length is properly not OK.  I don't
> know if it actually matters.  But I'd suggest you to check
> it out before removing them and change the code to use
> ill_phys_addr_length.

I don't think "interesting alignment" is something we should
throw on the admin's shoulder to figure out. But what I was
thinking was to have the *_wroff_extra set to the larger
of (32,  ill_phys_addr_length) with the appropriate rounding
off to the beat alignment boundary. 

And looking through sunsolve etc. did not produce any hits
for modifications to this one, at least.

--Sowmini


Reply via email to