status (Thursday soon)

[Dave Taht]

While patching the kernel to handle a new message seems straightforward,
all messages are discarded that do not match a predefined type.

Secondly, iptables would need to be patched too.

I am not interested in rebuilding all of our kernels on all of our
boxes (laptops and cpe) at this late date.

from:

linux-2.6/net/ipv4/icmp.c

        ICMPMSGIN_INC_STATS_BH(net, icmph->type);
        /*
         *      18 is the highest 'known' ICMP type. Anything else is a mystery
         *
         *      RFC 1122: 3.2.2  Unknown ICMP messages types MUST be silently
         *                discarded.
         */
        if (icmph->type > NR_ICMP_TYPES)
                goto error;


        /*
         *      Parse the ICMP message
         */

... snip snip...

        [9] = {
                .handler = icmp_discard,
                .error = 1,
        },
        [10] = {
                .handler = icmp_discard,
                .error = 1,
        },
        [ICMP_TIME_EXCEEDED] = {
                .handler = icmp_unreach,
                .error = 1,
        },


On Thu, Mar 22, 2012 at 11:56 AM, Dave Taht <dave.taht at gmail.com> wrote:
> On Thu, Mar 22, 2012 at 11:49 AM, Francisco Obispo <fobispo at isc.org> wrote:
>> After re-reading draft-penno-softwire-sdnat-01 and 02, I think I can understand what's happening.
>>
>>
>> Draft 02 imposes a new ICMP message type (with type yet to be defined), and sends back a response that includes the port range that should be used.
>>
>> Draft 01, on the other hand, just rejects with an ICMP type 13 message.
>>
>> So I believe the intersection could be, to send a message as in Draft-02, with the type set to 13.
>>
>> However, I'm now sure how the CPE is supposed to alter in real-time all of live NAT entries, to accommodate for the change. So I'm suspecting the sanest way to deal with this, is to configure the new port range within the SD-B4 and reboot the box :-(
>
> No need to reboot. iptables -t nat -F, regen the rules. less than < 1
> second overhead...
>
>
> and totally devestating to all connections in use. But if that's what
> the spec needs? who needs ssh, or movies, to keep working?
>
>
>
>> Am I right with this analysis?
>>
>>
>>
>>
>>
>> On Mar 22, 2012, at 8:54 AM, Francis Dupont wrote:
>>
>>>> So I just chatted with Alain.
>>>>
>>>> His top priorities for the demo are:
>>>>
>>>>      1) draft-penno-softwire-sdnat-02
>>>
>>> => 01 is compatible with 02, the problem is in the other way.
>>>
>>>>      2) ICMP message with Min, Max port range reset
>>>
>>> => this won't be in the demo and IMHO it won't work (i.e.,
>>> deeply broken)
>>>
>>>> Preferably running on both HW and VirtualBox VMs (he says VirtualBox
>>>> supports IPv6 just fine)
>>>
>>> => we don't have the hardware to run it and VirtualBox doesn't provide
>>> what we need for this demo.
>>>
>>>> Francis, in one of your previous emails you said
>>>>
>>>>      => yes (BTW the setup is more 02 but the code support 01)
>>>>
>>>> Does this mean "you implemented 02 which is backwardly compatible with 01",
>>>> or something else..
>>>
>>> => I implemented the 01 and setup the demo in the intersection of 01
>>> and 02 (by accident: it was just the simplest, good for a demo but
>>> not for the real world but this is another debate :-).
>>>
>>> Regards
>>>
>>> Francis Dupont <fdupont at isc.org>
>>> _______________________________________________
>>> sdcpe-devel mailing list
>>> sdcpe-devel at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/sdcpe-devel
>>
>> Francisco Obispo
>> email: fobispo at isc.org
>> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
>> PGP KeyID = B38DB1BE
>>
>> _______________________________________________
>> sdcpe-devel mailing list
>> sdcpe-devel at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/sdcpe-devel
>
>
>
> --
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://www.bufferbloat.net



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net