Reakce na ICMP port unreachable (IRIX)

[Matus UHLAR - fantomas]

> Jan Kasprzak wrote:
>>       narazil jsem na zajimavy problem: Je nekde definovano,
>> jak se ma TCP stack a/nebo socketove API chovat pri zavolani connect(),
>> na jehoz SYN packet druha strana odpovi "ICMP port unreachable"?
>> Obvyklejsi je v tomto miste "TCP RST", je-li port neotevreny. ICMP
>> zprava se muze posilat napriklad je-li port nekde filtrovan.
>>
>>       Linux, FreeBSD a Solaris po obdrzeni ICMP port unreachable ihned
>> ukonci connect() s ECONNREFUSED, zatimco IRIX 6.5 zda se tu ICMP zpravu
>> ignoruje a proces visi uvnitr connect() dal (overil jsem tcpdumpem, ze IRIX
>> tu ICMP zpravu vidi).
>>
>>       Nenasel jsem jestli je to chyba IRIXu, nebo jestli jsou legalne
>> mozne oba pristupy, nebo pripadne jestli se toto da nekde IRIXu nastavit.

Ja som sa s tymto problemom tiez stretol, na starsej verzii FreeBSD.
tcpdumpom som zistil ze po 5. syn paketoch pride 5 port unreachable, a potom
connect vytimeoutuje.

Dan Lukes <dan at obluda.cz> wrote:
>        Pripomel bych, ze volani "connect()" neni vyhrazeno jen pro navazovani
> TCP spojeni. A jelikoz seznam moznych IP protokolu neni uzavreny, je
> nepravdepodobne, ze by existovala takova definice, o ktere mluvis.
>
>        IMHO je to implementacni zalezitost - connect by mel zhavarovat, pokud
> je zrejme, ze se spojeni nepodarilo.
>
>        Nicmene, mozna je v tom IRIX preci jen nevinne. Veta "ICMP zprava se
> muze posilat napriklad je-li port nekde filtrovan" totiz je i neni
> pravda - zavisi to na vykladu - a chybny vyklad muze vest ke vzniku
> popsanych problemu.

ak to zavisi na vyklade, potom je spravna, je tam totiz slovicko "moze"

>        Existuje totiz nazor zalozeny na RFC1122, ze PORT UNREACHABLE muze
> zasilat vyhradne cilovy stroj.

to vsak nic nemeni na tom, ze to PORT UNREACHABE moze prist a ked pride,
malo by sa spojenie prerusit.

> Ostatne, pokud je duvodem zaslani ICMP filtr, mela by zasilana zprava byt
> ADMIN PROHIBITED nikoli PORT UNREACHABLE.

konkretne toto som nikde nenasiel.

FreeBSD ipfw option reject posiela defaultne ICMP host unreachable;
linuxovy REJECT posiela standardne icmp port unreachable;
ak systemak teda nastavi tieto "defaultne" moznosti, pride naspat ICMP.

>        Nikoli uplne jasne nasledky ma i vyslovny zakaz pouzit PORT UNREACH v
> pripadech, kdy transportni protokol ma vlastni mechanismus pro totez
> (pricemz TCP RST je vyslovne zmineno jako priklad).

no yo, rfc1122 sekcia 3.2.2.1:

            A transport protocol
            that has its own mechanism for notifying the sender that a
            port is unreachable (e.g., TCP, which sends RST segments)
            MUST nevertheless accept an ICMP Port Unreachable for the
            same purpose.

>        Implementace IRIXu je tedy spravna - patrne dokonce spravnejsi nez
> implementace ostatnich zminenych OS. Je tedy dost dobre mozne, ze zadna
> "oprava" ani "nastaveni" pro zmenu chovani v tomto bode existovat nebude.

spravna? co je spravne na tom, ze ak host dostane informaciu o
nedosiahnutelnosti ciela, NEPRERUSI pokusy o spojenie? Z informativneho
hladiska by to pre neho malo znamenat presne to iste - nejde to, kasli na
to).

tym skor ze vo vami spominanom RFC1122 je napisane (sekcia 4.2.3.9):

            o    Destination Unreachable -- codes 2-4

                 These are hard error conditions, so TCP SHOULD abort
                 the connection.

co znamena dve veci:

1. RFC1122 si v bodoch 3.2.2.1 a 4.2.3.9 protireci
2. IRIX jednoznacne bod 4.2.3.9 porusuje.
3. ak za budeme drzat fundamentalneho pravidla (be liberal in what you
   accept), musi sa bod 4.2.3.9 dodrziavat a 3.2.2.1 nie...

--
Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
Warning: I don't wish to receive e-mail advertising to this address.
Varovanie: Nezelam si na tuto adresu dostavat akukolvek reklamnu postu.
Christian Science Programming: "Let God Debug It!".