Chování getaddrinfo() a podivnosti v RFC

Pavel Šimerda na fedora.cz píše o problémech s funkcí getaddrinfo(). Implementace podle RFC by způsobila nefunkčnost localhostu v případě, že počítač není připojen do sítě.

21.11.2012 08:36 | Jendа | Zajímavý článek

Komentáře

[Luboš Doležel (Doli)]

To AI_ADDRCONFIG musel navrhovat vůl. Nejpřímočařejším řešením je IMO zkoumat, jestli lokální systém má kudy routovat adresu, u které se rozhoduje jestli ji vrátit, nebo ne. Pak není potřeba obskurností jako jestli zkoumat, nebo nezkoumat loopback.

[Michal Kubeček]

Vůbec ne. "Vůl" (pokud už se rozhodneme používat takové výrazy) je spíš ten, kdo použije flag AI_ADDRCONFIG při dotazu na adresu v číselném formátu, kde nemá nejmenší smysl. Smysl tohoto flagu je v tom, že ptám-li se na jméno, nebude mi getaddrinfo() vracet IPv6 adresy, pokud sám žádnou (kromě automatických link-local a localhostu) nemám a pokus navázat spojení na takovou adresu by mne jen zbytečně zdržel (a časem samozřejmě i naopak). To byl totiž dříve poměrně častý problém.

[Luboš Doležel (Doli)]

Principiálně zakazovat loopback a podobné je ptákovina, to nemá technické opodstatnění. Pokud by se stanovilo pravidlo tak, že místní systém má/nemá pakety na takovou IP jak routovat, mělo by to aspoň hlavu a patu a problém by nemusel být.

[Michal Kubeček]

Nikdo žádný loopback nezakazuje, to je jen vaše dezinterpretace.

Ta idea s testem na routovatelnost se mi moc nelíbí, spíš by stačilo, kdyby se i při použití AI_ADDRCONFIG vždy vracely lokální adresy hosta (funkce si stejně přes netlink získává jejich seznam). Patch by ani nebyl nijak složitý, ale vzhledem k tomu, že vím nejméně o dvou skutečných chybách v resolveru, které jsou nahlášené v upstreamové bugzille i s patchem a nikdo si jich nevšímá, pochybuji, že by takový enhancement dopadl lépe.

On by vůbec celý kód resolveru potřeboval zahodit a napsat znovu…

[Luboš Doležel (Doli)]

If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be returned only if an IPv4 address is configured on the local system, and IPv6 addresses shall be returned only if an IPv6 address is configured on the local system. The loopback address is not considered for this case as valid as a configured address.

Tohle je ta zvrácenost. Dostupnost IPv4/IPv6 je hodnocena podle nějakých přiřazených adres, nikoliv podle routovatelnosti, navíc se specificky vyřazují z vyhodnocování adresy loopbacku.

[Michal Kubeček]

Kdyby se nevyhazovaly, neměl by ten flag smysl vůbec, protože ty máte vždy.

[j]

To neni samozrejme pravda, looback nemusi pricipielne vubec bezet, navic muzu looback volat jmenem, ze, vubec nemluve o tom, ze jak je v clanecku receno, i loopback muze mit globalni IP adresu.

Problem ty definice je v tom, ze pokud mam v systemu pouze ten looback, tak mi to nema vratit nic, coz je hovadina.

Nehlede na to, ze cela podobna detekce je stejne nanic. Klido muzu mit sytem, kterej ma IPcek "jak nasrano" a 80% znich je nepouzitelnejch, protoze nemaj routu ... => tak jako tak si to musim osefovat nekde dal => je naprostej nesmysl nejaky adresy vracet nebo nevracet podle toho, jaky adresy mam kde nastaveny.

[Michal Kubeček]

Test na existenci routy toho ve skutečnosti neřeší o moc víc, protože většinou se nedostupnost projeví až o hop (nebo víc) dál. On vůbec ten článeček moc nerozlišuje mezi "nemám IPv{4,6} adresu" a "nemám IPv{4,6} konektivitu", což spolu často vůbec nesouvisí. Flag AI_ADDRCONFIG nebyl navržen pro řešení dynamicky se měnícího stavu "mám/nemám konektivitu", ale spíš pro filtraci odpovědí na systémech, kde se IPv6 (nebo teoreticky IPv4) nepoužívá vůbec. A tak je potřeba ho chápat a neočekávat od něj něco, co nemůže splnit.

[Luboš Doležel (Doli)]

Jako systém, kde se IPv4/6 nepoužívá bych ale bral právě ten, kde není žádná taková routa. Stav mám/nemám konektivitu se logicky kryje s používáním.

Snažit se šarlatánsky dedukovat, jestli ji opravdu nikdy nemá, to podle mě nemá v takovém API co dělat.

[Michal Kubeček]

Jako systém, kde se IPv4/6 nepoužívá bych ale bral právě ten, kde není žádná taková routa.

Vy ano, já ne. Autoři RFC ne. Autoři implementace v glibc ne.

Stav mám/nemám konektivitu se logicky kryje s používáním.

To, že teď zrovna routa v tabulce není, vůbec neznamená, že IPv6 nepoužívám.

Váš problém je, že místo snahy pochopit, jak flag funguje a k čemu slouží, se do něj snažíte projektovat svou vizi úplně jiné featury, která by byla bezesporu zajímavá a pro leckoho užitečná, ale byla by IMHO poměrně obtížně implementovatelná (přesněji: v plné obecnosti neimplementovatelná), v RFC popsána není a v glibc není implementována. Můžete zkusit navrhnout referenční implementaci a pokusit se ji prosadit, víc se k tomu říct nedá.

[Luboš Doležel (Doli)]

A já se vám zase snažím vysvětlit, že principiálně není možné ověřovat, jestli se na daném systému obecně IPv6 používá, proto se na výstup funkce naprosto nelze spolehnout. Proto je lepší zjišťovat to, co navrhuju já, protože to má alespoň nějakou užitečnost.

Zjevně je to házení hrachu na zeď.

[Michal Kubeček]

Spolehnout se na něj lze, pokud vezmete na vědomí, co ten flag opravdu znamená. Pak dělá přesně to, co je popsáno. Pokud vám to nevyhovuje, nepoužívejte ho. Pokud potřebujete něco jiného, naimplementujte si to.

[pavlix]

Spolehnout se na něj lze, pokud vezmete na vědomí, co ten flag opravdu znamená.

Ten flag znamená „nic neřeš, ale pár věcí rozbij“. Bohužel to není napsáno v dokumentaci.

Pak dělá přesně to, co je popsáno.

Dokonce ani nedělá to, co je napsáno v manuálové stránce.

Pokud vám to nevyhovuje, nepoužívejte ho.

Tak to je opravdu hraběcí rada. Pravdou je, že to pro mě byla poslední kapka pro nainstalování Gentoo, kde se mnohem lépe patchuje systém, aby správně fungoval.

Zpravidla totiž tento flag dělá problémy uživatelům software a správcům systémů. A ti si ho zpravidla bez patchování a rekompilace nevypnou.

[pavlix]

Vy ano, já ne. Autoři RFC ne. Autoři implementace v glibc ne.

Věřím tomu, že po pečlivém přečtení článku je zřejmé, že:

1) AI_ADDRCONFIG podle POSIX1-2008 nedělá to, kvůli čemu byl tento flag navržen

2) AI_ADDRCONFIG podle RFC 3493 nedělá to, kvůli čemu byl tento flag navržen a navíc může rozbít node-local konektivitu a to jak na IPv4, tak na IPv6

3) AI_ADDRCONFIG podle obsolete RFC 2553 nedělá to, kvůli čemu byl tento flag navržen, ale nic nerozbíjí

4) Drobná úprava obsolete RFC 2553 by mohla vést na to, že by AI_ADDRCONFIG dělal to, na co byl navržen, a nic by nerozbíjel

Můžete zkusit navrhnout referenční implementaci a pokusit se ji prosadit, víc se k tomu říct nedá.

Vzhledem k tomu, že ani jeden z uvedených standardů funkci AI_ADDRCONFIG nedefinuje tak, aby dělala to, kvůli čemu byla navržená, nemá smysl ani nikoho dalšího kritizovat za to, že nezvádl to, co nezvládli ani návrháři standardů.

Nicméně, společně s Torem Andersonem jsme popsali řešení, které je stále ještě založené na adresách a fungovalo by. A nemysli si, že ten Lubošův nápad s default routou nepadl a rozhodně si nemyslím, že by byl v době absence funkčního řešení nějak méněcenný.

[Franta]

Test na existenci routy toho ve skutečnosti neřeší o moc víc…

jj, ono každé hádání a věštění je problematické. Řešení je AFAIK v /etc/gai.conf – zejména pro neobvykle nakonfigurované počítače nebo neobvyklé požadavky.

[pavlix]

Kdyby se nevyhazovaly, neměl by ten flag smysl vůbec, protože ty máte vždy.

Vzhledem k tomu, že typicky kernel sám nakonfiguruje link-local adresy, tak je výsledný efekt zcela totožný. Tedy flag v jeho současné implementaci nemá vůbec smysl. O tom je odkazovaný článek.

[Michal Kubeček]

Formulace "an IPv6 address is configured on the local system" IMHO nevylučuje výklad, který nezahrnuje ani automatické link local adresy. Dokonce by takový výklad byl i logičtější. Ano, vím, že se implementace v glibc tak nechová, ale to by asi stálo za diskusi - bohužel podle všeho momentálně není s kým.

Abych zbytečně nepsal víc odpovědí, tak přidám ještě jednu společnou reakci na všechny ty "kdyby sis přečetl odkazovaný článek": článek jsem si přečetl, ale to neznamená, že musím souhlasit se vším, co se v něm píše.

[pavlix]

Formulace "an IPv6 address is configured on the local system" IMHO nevylučuje výklad, který nezahrnuje ani automatické link local adresy.

To je ovšem hodně svérázný výklad. Ale ano, ten standard je napsaný špatně a jeho vágnost to jen umocňuje. Dokonce po krátkou dobu takový patch ve Fedoře byl, čímž pádem ve stejné situaci, kdy nefungoval localhost, nefungovaly ani link-local adresy.

Dokonce to byl ten moment, kdy jsem já osobně problém zaregistroval, protože mi přestalo chodit SSH do virtuálu po linkových adresách.

Dokonce by takový výklad byl i logičtější.

Ono je vcelku jedno, jaký výklad se zvolí. Ve chvíli, kdy se to aplikuje na resolvování non-DNS adres, je celý ten nápad špatný.

Abych zbytečně nepsal víc odpovědí, tak přidám ještě jednu společnou reakci na všechny ty "kdyby sis přečetl odkazovaný článek": článek jsem si přečetl, ale to neznamená, že musím souhlasit se vším, co se v něm píše.

Budu rád, když budeš smysluplně rozporovat cokoli z článku, ať už to budou zjištěná fakta, návrhy řešení, nebo osobní hodnocení situace. To poslední je samozřejmě nejméně důležité a slouží spíše jako zpestření.

[Michal Kubeček]

Ono ani tak nejde o rozpor, spíš o odlišný pohled na problém. Podle mne byl flag AI_ADDRCONFIG nástrojem, který v určité době řešil určitý problém. Můžeme se sice bavit o tom, jak dobře a účinně ho řešil, ale podle mne ta debata nemá smysl, protože (1) ta doba pomalu končí a (2) jsou jiné (lepší) způsoby, jak ho řešit. Ze stejného důvodu IMHO tím spíš nemá smysl řešit, jak by se měla sémantika AI_ADDRCONFIG upravit, aby se odstranily konkrétní problémy. V POSIXu i v glibc je spousta jiných rozhraní, funkcí a flagů, které časem ztratily význam (a některé ho ani nikdy neměly), je tam dokonce nejméně jedna funkce (gets()), která se v podstatě ani nedá použít tak, aby z toho nebyla bezpečnostní díra jako vrata od stodoly.

Mimochodem, původně jsem nereagoval na článek jako takový (to bych reagoval pod ním), ale na zdejší komentáře Luboše Doležela.

[pavlix]

Podle mne byl flag AI_ADDRCONFIG nástrojem, který v určité době řešil určitý problém.

Zde jsou v rozporu naše zjištěná fakta. Já jsem zatím nenarazil na informaci, která by byť jen naznačovala, že někdy v historii AI_ADDRCONFIG nějaký problém skutečně řešil. Mé dosavadní informace spíše naznačují, že se tento nástroj selhával od začátku.

(1) ta doba pomalu končí

Na to mám stejný názor, nicméně to vypadá, že budu muset vyhovět těm, kteří stále považují tento nástroj za potřebný.

(2) jsou jiné (lepší) způsoby, jak ho řešit

To jsem chtěl slyšet. Sem s nimi, jestli máš nějaký v zásobě a jsi ochotný se o něj podělit.

Ze stejného důvodu IMHO tím spíš nemá smysl řešit, jak by se měla sémantika AI_ADDRCONFIG upravit, aby se odstranily konkrétní problémy.

S tím, že by se měly problémy s node-local komunikací ponechat, rozhodně nesouhlasím. Dokud tento flag bude fungovat jako kurvítko a nebude tak popsán ve své dokumentaci, budou ho lidé chtít používat. Při zadání NULL namísto hints se dokonce tento flag použije automaticky.

V POSIXu i v glibc je spousta jiných rozhraní, funkcí a flagů, které časem ztratily význam (a některé ho ani nikdy neměly) (gets()), která se v podstatě ani nedá použít tak, aby z toho nebyla bezpečnostní díra jako vrata od stodoly.

Tím mě jenom utvrzuješ v tom, že bývá zvykem to řešit. U funkce gets() je v manuálu zřetelně popsáno, proč se nemá používat. Oproti tomu AI_ADDRCONFIG se použije „by default“ a v manuálu není upozorněno na to, že funguje zcela špatně.

Mimochodem, původně jsem nereagoval na článek jako takový (to bych reagoval pod ním), ale na zdejší komentáře Luboše Doležela.

Mimochodem, Luboš reagoval na zprávičku týkající se článku a v mnoha věcech měl buď naprostou pravdu nebo přinejmenším dobrý nápad.

[Michal Kubeček]

Zde jsou v rozporu naše zjištěná fakta. Já jsem zatím nenarazil na informaci, která by byť jen naznačovala, že někdy v historii AI_ADDRCONFIG nějaký problém skutečně řešil. Mé dosavadní informace spíše naznačují, že se tento nástroj selhával od začátku.

Na systémech, kde ten, kdo IPv6 nepoužíval, neměl na rozhraních IPv6 adresy (kromě ::1), to fungovalo podle očekávání. Svět se změnil, dnes je obvyklé mít defaultně všude automatické link-local adresy bez ohledu na to, jestli o ně uživatel stojí a má pro ně využití. To ale těžko vyčítat tomu, kdo to rozhraní navrhoval v době, kdy to tak ještě nebylo.

Hlavní rozdíl mezi námi je IMHO v tom, že já si nemyslím, že je dobrý nápad sémantiku AI_ADDRCONFIG nějak výrazně upravovat (opravovat). Ze zkušenosti vím, jak jsou uživatelé citliví na změny chování rozhraní i v případech, kdy jde o čistě empirické zkušenosti. Měnit zásadním způsobem zdokumentované chování, s tím jsou většinou jen problémy. To už bych radši viděl zavedení nového flagu s novou sémantikou; ale protože nemám pocit, že by se dal vymyslet takový, který by vždy pomáhal a nedal by se najít use case "ze života", kde by škodil, tak ani tahle cesta mi nijak neimponuje.

Já bych prostě dnes ve svém programu AI_ADDRCONFIG nepoužil a pokud ho nějaká aplikace používá a způsobuje to problémy, považuji to za chybu té aplikace, která by měla být řešena tak, že se buď AI_ADDRCONFIG používat nebude nebo půjde jeho použití aspoň vypnout v konfiguraci.

To jsem chtěl slyšet. Sem s nimi, jestli máš nějaký v zásobě a jsi ochotný se o něj podělit.

Třeba gai.conf, případně i specifikace AF_INET v hintech (podle konfigurace). A v neposlední řadě samozřejmě získání IPv6 konektivity.

U funkce gets() je v manuálu zřetelně popsáno, proč se nemá používat. Oproti tomu AI_ADDRCONFIG se použije „by default“ a v manuálu není upozorněno na to, že funguje zcela špatně.

Zdokumentování, že je tento flag obsolete a že většinou stejně nedělá to, co by od něj uživatel očekával, bych považoval za rozumný krok, stejně tak přehodnocení toho, že je defaultně nastaven.

[pavlix]

Na systémech, kde ten, kdo IPv6 nepoužíval, neměl na rozhraních IPv6 adresy (kromě ::1), to fungovalo podle očekávání.

Já vidím, že se fakt snažíš a díky za to. Ale taky vidím problém v tom, že nespecifikuješ, co se schovává za to. Můžu si tedy domýšlet, že je to implementace getaddrinfo() podle POSIX1-2008, podle RFC 3493 (2003), podle RFC 2553 (1999).

Nicméně i tak tě musím upozornit, že stále ještě pracuješ s nesprávnými fakty. Pokud je ::1 při posuzování ignorováno, nastává problém s localhostem, což rozhodně není podle očekávání. Pokud je ::1 do posuzování počítáno, AI_ADDRCONFIG pro změnu nefunguje vůbec.

Já mám dojem, že v době, kdy ty problémové standardy přišly, tak už byly link-local adresy považovány za samozřejmost. Řešení #3 je vlastně návratem k RFC 2553 obohaceným o link-local adresy:

3) Only process AI_ADDRCONFIG in the nsswitch DNS plugin. This requires implementing getaddrinfo() in nsswitch which is required for zeroconf networking anyway. Use solution (1) as a temporary fix. Locally assigned addresses looked up through local DNS would still fail.

Je otázka, zda má cenu řešit umělý corner case s node-local DNS serverem poskytujícím lokálně přiřazenou adresu. Prozatím mám za to, že by tento corner case šel ignorovat a o jiném nevím. AI_ADDRCONFIG by pak mohlo plnit svůj účel jak na IPv4-only, tak na IPv6-only. Nebo ne?

Hlavní rozdíl mezi námi je IMHO v tom, že já si nemyslím, že je dobrý nápad sémantiku AI_ADDRCONFIG nějak výrazně upravovat (opravovat).

Já vycházím z toho, že Tore, David a mnoho dalších lidí považuje AI_ADDRCONFIG za potřebné a oprava tak vychází jako přirozený, krok, který ušetří předělávání všech aplikací.

Měnit zásadním způsobem zdokumentované chování, s tím jsou většinou jen problémy.

To chování je navíc momentálně zdokumentováno v několika standardech a v manuálové stránce. Bohužel se getaddrinfo() nechová dle žádné z těchto různých dokumentací. Tudíž to těžko lze považovat za zavedené API.

Pokud tě téma ještě neotrávilo, doporučuju prostudovat komentáře v kódu, který AI_ADDRCONFIG používá:

https://fedoraproject.org/wiki/Networking/NameResolution#Examples_of_software_using_AI_ADDRINFO

Já bych prostě dnes ve svém programu AI_ADDRCONFIG nepoužil a pokud ho nějaká aplikace používá a způsobuje to problémy, považuji to za chybu té aplikace, která by měla být řešena tak, že se buď AI_ADDRCONFIG používat nebude nebo půjde jeho použití aspoň vypnout v konfiguraci.

Vývojáři aplikací potřebují jednoduché, jednoznačné a zdokumentované API. V tomto případě postupují podle dokumentace, která přinejmenším naznačuje, že AI_ADDRCONFIG vyřeší některé problémy s konektivitou.

Třeba gai.conf, případně i specifikace AF_INET v hintech (podle konfigurace). A v neposlední řadě samozřejmě získání IPv6 konektivity.

Specifikace AF_INET/AF_INET6 vyřadí adresy jedné rodiny bezpodmínečně, tedy ne podle toho, zda jsou v systému dostupné. A nemyslím si, že by bylo vhodné, aby aplikace toto jednotlivě zjišťovaly.

Zdokumentování, že je tento flag obsolete a že většinou stejně nedělá to, co by od něj uživatel očekával, bych považoval za rozumný krok, stejně tak přehodnocení toho, že je defaultně nastaven.

To rozhodně. Ale dokud nemám jasno v tom, jaké řešení je vhodné a přijatelné, tak se do úprav manuálu. Dobrovolnosti jiných se samozřejmě meze nekladou. Prozatím dokumentuju bokem a podrobněji.

Fajn, teď snad mám od tebe něco, co jde aspoň trochu použít. Přesto budu rád, když budeš reagovat na položené dotazy a především specifikuješ, který ten standard definuje getaddrinfo() podle očekávání a bez rozbití localhosta pro ty dávné doby, kdy nebyly link-local adresy.

[Michal Kubeček]

Test na routovatelnost je problematický i z toho důvodu, že výsledek může záviset na informacích, které getaddrinfo() k dispozici nemá. Navíc se pro seznam používá cache, zatímco dotaz na routovatelnost by se přes netlink musel provádět pokaždé znovu.

[Luboš Doležel (Doli)]

Pokud už požaduju po getaddrinfo() podobné rozhodování, tak bych měl brát v potaz i to, že získání informace může být náročnější (např. kvůli zkoumání routovacích tabulek přes netlink).

[Michal Kubeček]

Těmi "informacemi, které getaddrinfo() nemá" jsem nemyslel informace, které může získat od jádra, ale spíš informace, které by musel dodat volající, např. jestli bude pevně určená zdrojová adresa (a jaká) nebo jestli se určení zdrojové adresy nechá na systému.

[pavlix]

Jaký je prakticky rozdíl mezi zkoumáním seznamu adres a zkoumáním hlavní směrovací tabulky? Obojí je stejně jenom alchymie, na základě které se mají eliminovat jasné případy, kdy stroj nemá očekávat a především vyžadovat IPv6-friendly DNS server.

[Michal Kubeček]

Především sám termín "hlavní směrovací tabulka" je příliš linux-centrický a i na Linuxu je skutečný algoritmus mnohem složitější, takže by spíš mělo jít o ten test routovatelnosti. A tady vidím dva problémy: jednak nevím, jestli se lze obecně spolehnout na dostupnost této informace z user space, jednak třeba právě v Linuxu není cílová adresa dostatečnou informací a byly by potřeba další informace, které getaddrinfo() k dispozici nemá.

[pavlix]

Především sám termín "hlavní směrovací tabulka" je příliš linux-centrický a i na Linuxu je skutečný algoritmus mnohem složitější, takže by spíš mělo jít o ten test routovatelnosti.

Tento násor chápu, ale nesdílím. A to právě z důvodů, které uvádíš v následujících větách.

[little.owl]

Myslim, ze je mi blizsi interpretace p.Kubecka.

Ono je ostatne blizsi tomu co rikaji MSDN:

If the AI_ADDRCONFIG bit is set, getaddrinfo will resolve only if a global address is configured. If AI_ADDRCONFIG flag is specified, IPv4 addresses shall be returned only if an IPv4 address is configured on the local system, and IPv6 addresses shall be returned only if an IPv6 address is configured on the local system. The IPv4 or IPv6 loopback address is not considered a valid global address.

nebo Apple na OS X:

If the AI_ADDRCONFIG bit is set, IPv4 addresses shall be returned only if an IPv4 address is configured on the local system, and IPv6 addresses shall be returned only if an IPv6 address is configured on the local system.

Zajimave, ze zde se nezminuji o loopbacku.

[Luboš Doležel (Doli)]

Mně ale nejde o interpretaci. Mně jde o to, že tu věc z RFC není dobré používat, protože to považuju za špatný návrh.

Kupříkladu, proč se zvažují jen globální adresy? Já nemám IPv6 konektivitu, ale mám IPv6 služby lokálně včetně DNS serveru, který vrací AAAA záznamy. Aplikace používající AI_ADDRCONFIG se v takové situaci rozhodne IPv6 nepoužít, protože nevidí globální adresu; ta ale není potřeba.

[j]

Presne tak, a dalo by se samo najit tisic a jedna ruzna konfigurace, kdy to nevrati IPv6, presto ze ji system ma a pouziva.

Jednoduse by to melo fungovat tak, ze kdyz !libovolne! rozhrani ma !libovolnou! IPvX adresu, tak ji to vrati. Ta funkce vi kulovy co a jak hodla aplikace pouzivat, tak se do toho nema srat.

Navic pokud budu mit jen lopback, tak to nevrati vubec nic (podle RFC) ... lol => pres loopback nelze komunikovat (podle RFC).

[Michal Kubeček]

Jednoduse by to melo fungovat tak, ze kdyz !libovolne! rozhrani ma !libovolnou! IPvX adresu, tak ji to vrati.

Což je v podstatě totéž, co jsem navrhoval už dnes v 9:43. Ale z důvodů tam uvedených a toho, že mne to osobně nijak netrápí, ten patch psát nehodlám, natož abych se ho (nejspíš marně) snažil tlačit do upstreamu. Tedy aspoň do doby než nebudu mít nic lepšího na práci nebo mi to v práci nepřijde od zákazníka.

Ta funkce vi kulovy co a jak hodla aplikace pouzivat, tak se do toho nema srat.

Pokud volající nastaví flag, který má podle dokumentace určitý význam, pak se má funkce podle něj chovat.

[pavlix]

Pokud volající nastaví flag, který má podle dokumentace určitý význam, pak se má funkce podle něj chovat.

To by opravdu měla. A v tomto případě by být flag opatřen velkým červeným nápisem „nepoužívat“ nebo v lepším případě neutralizován a časem odstraněn.

[pavlix]

Jednoduse by to melo fungovat tak, ze kdyz !libovolne! rozhrani ma !libovolnou! IPvX adresu, tak ji to vrati.

POSIX1-2008, nic neřeší, nic nepokazí.

Navic pokud budu mit jen lopback, tak to nevrati vubec nic (podle RFC) ... lol => pres loopback nelze komunikovat (podle RFC).

Přesně tak.

[little.owl]

Tak existence globalne definovane adresy jako indikator lokalni konektivity je nesmysl, nicmene u techto veci musite brat v uvahu historickou interpretaci a jak to implementuji ostatni, jinak rozmlatite spoustu kodu. Mozna by stacilo zajistit korektni hodnoty pro getaddrinfo(::1), pokud je ::1 v /etc/hosts, existenci local-link pripojeni, nevim.

[little.owl]

I kdyz s tim rozmlacenim kodu to nebude tak horke, staci se podivat, co uz ted musi delat Chromium aby jim to chodilo vsude.

[pavlix]

Mozna by stacilo zajistit korektni hodnoty pro getaddrinfo(::1), pokud je ::1 v /etc/hosts, existenci local-link pripojeni, nevim.

Opravíš jeden special case, uživatelé ti nahlásí druhý. Opravíš druhý, uživatelé ti nahlásí třetí. Opravíš třetí, přestane ti fungovat první.

O podobné lepení už se pokoušeli ve Fedoře.

[pavlix]

If the AI_ADDRCONFIG bit is set, getaddrinfo will resolve only if a global address is configured. If AI_ADDRCONFIG flag is specified, IPv4 addresses shall be returned only if an IPv4 address is configured on the local system, and IPv6 addresses shall be returned only if an IPv6 address is configured on the local system. The IPv4 or IPv6 loopback address is not considered a valid global address.

To vypadá nejpochybněji ze všech definicí, co jsem viděl. A trpí stejným problémem. Nic neřeší a pouze způsobuje problémy, tedy pokud ji Microsoft skutečně takto implementuje.

If the AI_ADDRCONFIG bit is set, IPv4 addresses shall be returned only if an IPv4 address is configured on the local system, and IPv6 addresses shall be returned only if an IPv6 address is configured on the local system.

Tohle je znění jako z POSIX1-2008. Nic neřeší, nic nerozbíjí. Pokud je ta funkce skutečně takto implementována.

[Luboš Doležel (Doli)]

Tohle je znění jako z POSIX1-2008. Nic neřeší, nic nerozbíjí. Pokud je ta funkce skutečně takto implementována.

Chová. Zavolá getifaddrs() a pak jen projde získané a adresy. Když jsou nějaké AF_INET6, tak pak getaddrinfo() vrací i ty, a to samé s IPv4.

[Michal Kubeček]

Zavolá getifaddrs()

Nezavolá. Zavolá __check_pf() a její linuxová verze getifaddrs() nevolá.

[Luboš Doležel (Doli)]

V tomhle případě se řešilo OS X.

[pavlix]

Ta idea s testem na routovatelnost se mi moc nelíbí, spíš by stačilo, kdyby se i při použití AI_ADDRCONFIG vždy vracely lokální adresy hosta (funkce si stejně přes netlink získává jejich seznam).

Rovnák na vohejbák, který stejně nefunguje.

[pavlix]

Vůbec ne. "Vůl" (pokud už se rozhodneme používat takové výrazy) je spíš ten, kdo použije flag AI_ADDRCONFIG při dotazu na adresu v číselném formátu

Michale, tady se naprosto fatálně mýlíš, protože v tomto případě by museli být dva půlvolové. Volbu AI_ADDRCONFIG dává typicky programátor, zatímco hostname dává typicky uživatel prostřednictvím příkazové řádky nebo konfiguračního souboru.

Smysl tohoto flagu je v tom, že ptám-li se na jméno, nebude mi getaddrinfo() vracet IPv6 adresy, pokud sám žádnou (kromě automatických link-local a localhostu) nemám a pokus navázat spojení na takovou adresu by mne jen zbytečně zdržel (a časem samozřejmě i naopak).

Teorie zajímavá, ale kdybysis přečetl odkazovaný článek dozvěděl by ses například, že:

1) AI_ADDRCONFIG nevyfiltruje IPv6 výsledky, jestliže je v systému alespoň jedna link-local IPv6 adresa (což typicky je)

2) AI_ADDRCONFIG rozbíjí nejen číselně zadané adresy, ale i adresy zadané jménem

To byl totiž dříve poměrně častý problém.

A tento problém AI_ADDRCONFIG v jeho současné implementaci neřeší.

[psholty2]

Tak neviem ale tento problem som mal uz v dobe Fedora Core 4. Ked nebol pripojeny pocitac do siete, akykolvek program (napr. xterm) startoval aj 30s. Riesenim bolo do /etc/hosts pridat 127.0.0.1 localhost

[Luboš Doležel (Doli)]

Za tohle nemůže getaddrinfo(), ten localhost by v /etc/hosts měl být.

[AsciiWolf]

+1

[xxx]

Tak ona se vetsina distribuci ponekud rozbije, pokud odstranite lo interface.

[Izak]

Tak ona se vetsina distribuci ponekud rozbije, pokud odstranite lo interface.

Tak na TOTO Windows 8 jednoducho nema

[Zopper]

A Windows se nerozbije? Já to dělat nezkoušel, ale nedivil bych se, kdyby s tím pak měl ten systém taky problémy, případně ve snaze "být chtřejší než uživatel" loopback pro jistotu zase hned vytvořil...

[Luboš Doležel (Doli)]

Windows skutečný loopback device v podstatě nemá. Není to implementováno tak jako na Linuxu. Jádro pouze ví, že pakety mířící na adresy loopbacku nemá nikam posílat a rovnou je předá cílovému procesu.

Proto ani ve Wiresharku na Windows není možné loopback odposlouchávat. Existuje sice jakýsi loopback driver, ten se ale stále neblíží tomu, co by člověk očekával.

[pavlix]

Odlišný problém se stejným symptomem.

[Petr Tomášek]

Další důkaz toho, že IPv6 je zmršenina...

[Franta]

LOL

[Jendа]

Všimni si, že u IPv4 je naprosto, ale opravdu naprosto stejný problém.

[Andrea]

Kto chce IPv6 biť palicu si vždy nájde...

[j]

Dukaz toho, ze i nekdo kdo umi pismenka muze byt negramot.

[pavlix]

Další informace v angličtině na Fedora Wiki. Případné dotazy a připomínky rád zohledním.

[little.owl]

Tak, a jaky je zaver?

[pavlix]

Můj závěr je pořád stejný, ale jestli se ptáš, zda je to vyřešeno, tak si nedělám iluze a bude to na dlouhé lokte. Dostal jsem i nějaký feedback ale spíš formálního charakteru (upřesnění formulací). Tore Anderson mi potvrzoval, že to, co jsem napsal je podle něj v pořádku, vidělo to docela dost dalších lidí.

Zásadní feedback, který by nějak zpochybňoval to, co píšu, nepřišel. Ani Michal Kubeček se zatím nevyjádřil v čem se mnou nesouhlasí :).

[little.owl]

Ja jsem byl v podobne situaci s AVB protokolem, jehoz cast jsem pouzival v nasem zarizeni. Dostat ze standardotvurcu pouzitelnou odpoved v rozumnem case je tezke a tak jsem si to udelal po svem. Nastesti, delame obe strany zarizeni a tak to funguje, nicmene pokud nekdo pripoji neco jineho, ma smulu a fungovat to asi nebude ... aplikace standardu v praxi.

[pavlix]

Dostat ze standardotvurcu pouzitelnou odpoved

Tak já už i použitelnou odpověď mám, bohužel jen svoji a odsouhlasenou pár dalšími lidmi, kteří do tématu vidí. Takže se to taky snažím udělat „po svém“, ale i pro ostatní. Už teď úmyslně porušujeme RFC 6106 v NetworkManageru.

Nastesti, delame obe strany zarizeni a tak to funguje, nicmene pokud nekdo pripoji neco jineho, ma smulu a fungovat to asi nebude ... aplikace standardu v praxi.

Jasně, no. To si dovolit nemůžu.

[pavlix]

Tak mám další úlovek.