Dotaz: C rozdělení ip rozsahu inet_net_ntop s AF_INET6

[foldy]

Mám problém s rozdělením rozsahu ipv6, potřebuji rozdělit ip rozsahy dle potřeby, s ipv4 mi to funguje v pořádku pomocí :
inet_net_ntop(AF_INET,odkud,24,kam,INET_ADDRSTRLEN); a vše je ok výstup: A.B.C.0/24 apod.

Knihovna arpa/inet.h to ale neumí s AF_INET6, snažil jsem se to nějak implementovat s postgresql databáze s knihovnou inet_net_ntop.c, ale nechci kvůli tomu includovat celý postgresql a tu část svobodné knihovny se mi nepodařilo správně vyvázat a rozchodit.

Potřebuju rozsekat ipv6 dle potřeby např.:
A:B:C:D:E:F:G:H/128 -> A:B:C:D::/64 apod.
Znáte nějakou jinou knihovnu/metodu, (nejlépe aby byla malá a v rámci GPL) jak na to ?
Díky

Odpovědi

[Sten]

Vždyť je to celkem triviální to napsat, ne? Vezmeš adresu, vymaskuješ ji daným počtem bitů a vypíšeš, u IPv6 hexadecimálně v blocích po 16 bitech.

[foldy]

No to si úplně nemyslím, můžou tam být zkráceniny, vynechány kvůli tomu některé bloky a další pravidla pro parsování, které jsou v ipv6 zavedené. Ten alg. z postgre to i zkracuje. Měl by vyrobit i výstup : 2001:ABCD::/64 apod..

[Michal Kubeček]

Zkracování je jen možnost, není to povinné. Např.

  ::
  0000:0000:0000:0000:0000:0000:0000:0000
  0:0:0:0:0:0:0:0
  0:00:000:0000:0000:000:000:0
  0::0

jsou všechno korektní zápisy stejné adresy.

[foldy]

joo to vím, ale to zkracování se mi právě docela hodí, budu to vkládat do DB.

[Michal Kubeček]

Pro potřeby ukládání do databáze by mi přišla vhodnější nativní reprezentace než textová.

[foldy]

Zkracena textova bude právě zabírat méně, proto potřebuji to zkrácení a ten alg. to bude zkracovat stále na stejné dělky, pokud ten rozsah bude stejný. Jde mi také o velikost.

[Michal Kubeček]

Jste si opravdu jistý, že vám to statisticky bude vycházet kratší než 16 B? A pokud ano, bude to o tolik kratší, aby to vyvážilo složitější (a pomalejší) práci s těmi adresami?

[Michal Kubeček]

(Nebo 17 B, pokud se bavíme o adrese a délce prefixu.)

[foldy]

Právě pro sqlite se doporučuje to mít ve stringu.

[Michal Kubeček]

Miluju zdůvodnění typu "se doporučuje"…

[Sten]

„Doporučuje se“ to, jen pokud nad těmi adresami nebudou prováděny žádné operace, takže je není potřeba parsovat a formátovat. Když už jsou naparsované, tak je tam rovnou lze uložit jako čísla.

[foldy]

půjde jen o porovnání strcmp, takže string je akorát a nemusí se to zpětně převádět, pro mě, zbytečná ntop navíc.

[Michal Kubeček]

Tak teď už jsem z toho úplně jelen. Pokud to dostáváte ve formě textové reprezentace a hodláte s tím pracovat výhradně v ní, proč vás vůbec zajímá funkce inet_net_ntop(). Pokud to dostanete v nativní reprezentaci, tak porovnání na rovnost můžete provést i v ní (a bude jednodušší).

[foldy]

Ok, vysvětlím, jen jsem vždy překvapený, že se každý musí ujistit, že to potřebuji.

je to fastcgi webapp v C, kdy chodí requesty do login systemu,ip přijde z getenv jako string, v normálním případě se převede na in6_addr strukturu a pracuje se s ní, vyhodnocuje apod., existuje ale prvotní kontrola, v určitých případech, kdy přijde request rovnou se vezme string z getenv, porovná se string v DB a v případě shody se komunikace zahazuje (typicky obrana před utoky apod)

Proto je důležité zkrácení a převod do /64,56 atd... dle toho co chci zahodit. Čím menší string (i menší data v DB), tím rychleji se odmítne komunikace s něčím s čím nechci komunikovat. Nechci tam mít konverzi na in6_addr, porovnání s intem atd.. zbytečné instrukce navíc pro ten případ.

Ve fázy zpracování (což je jiný případ) v in6_addr potřebuji zkonstruovat ten rozsah a zkrátit ho, proto ten int_net_ntop...

[Sten]

Jak funguje porovnávání hodnoty z getenv s rozsahem /64 bez toho, abyste to musel parsovat?

[foldy]

Parsovat už to nemusím, stačí porovnat, pokud je rozumně zvolená část ip subnetu současně i názvem souboru a dat v ní, pak první sekvenci názvu použijete pro automatický výběr db a druhou část porovnáte binárním algoritmem, do první :: nebo /.

[Sten]

No jestli podle IP adresy volíte databázi, pak už je úplně jedno, co dál to dělá

[foldy]

ok

[Ivan]

Jses si jistej, ze to optimalizujes na spravnym miste? Opravdu je to tak, ze kratsi string => mensi data v DB => rychlejsi zpracovani? Pokud je tam nejaky index tak to bude vice-mene jedno. Dulezita je vyska indexu. A proc nepouzijes nejakou ldbm databazi?

[foldy]

Ten string může být pak i v texťáku, je to jedno, zatím to zkouším s sqlitem. LDBM db neznám.

[Ivan]

dbm je primitivni key-value storage databaze. Poziva ji napriklad openldap jako svuj backend. Ten implementaci je vic - jedna z nich je napriklad sleepycat.

[Sten]

Zkrácenina je maximálně jedna a primitivní implementace to může buď nezkracovat či zkracovat podle zadané masky (např. /56 → posledních 72 bitů lze zkrátit). Problém je parsovat IPv6 adresy, vypsat je ve fungujícím tvaru je opravdu triviální.

[pavlix]

No to si úplně nemyslím, můžou tam být zkráceniny,

Jaké zkráceniny? Maskuje se v binární podobě a to je prostě jenom sekvence 128 bitů, nic víc, nic míň.

[Michal Kubeček]

Manuálová stránka výslovně uvádí

For both functions, af specifies the address family for the conversion; the only supported value is AF_INET.

Ale jak už bylo řečeno, napsat si vlastní implementaci je triviální: odmaskujete příslušný počet nejnižších bitů, převedete na textovou reprezentaci pomocí inet_ntop a na konec přidáte lomítko a délku prefixu. Třeba takhle:

const char *inet6_net_ntop(const struct in6_addr* addr, unsigned bits,
                           char* buff, unsigned len)
{
        struct in6_addr a6 = *addr;
        unsigned char* src = a6.s6_addr;
        const char* bp;
        char* p;
        unsigned i;

        if ((len < INET6_ADDRSTRLEN + 5) || (bits > 128))
                return NULL;

        for (i = (bits + 7) / 8; i < 16; i++)
                src[i] = 0;
        if (bits % 8)
                src[bits / 8] &= ~((1 << (8 - (bits % 8))) - 1);

        bp = inet_ntop(AF_INET6, src, buff, len - 4);
        if (!bp)
                return NULL;

        p = buff;
        while (*p)
                p++;
        *p++ = '/';
        snprintf(p, 4, "%u", bits);

        return buff;
}

[Radek Isa]

Co takhle prevest masku i ipv6 na sitovou reprezentaci (v sitove reprezentaci nemuze byt ta ipv6 skracena) a pak to pomoci operace and vymaskovat a nasledne prevest na reprezentaci řetezcem.

[Michal Kubeček]

Co takhle prevest masku i ipv6 na sitovou reprezentaci

Jak konkrétně se síťová reprezentace liší od toho, co je ve struct in6_addr?

[Michal Kubeček]

Ale fuj...

--- addr.c.orig 2015-11-03 09:58:02.588426088 +0100
+++ addr.c      2015-11-03 09:57:35.660802261 +0100
@@ -11,13 +11,11 @@
        unsigned char* src = a6.s6_addr;
        const char* bp;
        char* p;
-       unsigned i;
 
        if ((len < INET6_ADDRSTRLEN + 5) || (bits > 128))
                return NULL;
 
-       for (i = (bits + 7) / 8; i < 16; i++)
-               src[i] = 0;
+       memset(src + (bits + 7) / 8, 0, 16 - (bits + 7) / 8);
        if (bits % 8)
                src[bits / 8] &= ~((1 << (8 - (bits % 8))) - 1);
 

[foldy]

Tak jsem to našel, použil jsem funkční verzi z Bind 9.5.0.dfsg.P2, kdyby to někdo hledal, v pozdějších verzích už není. Je to s copyrightem ISC, ale dá se použít. Tam je int_net_ntop i pro AF_INET6 i s ořezáním.

[Michal Kubeček]

Že jsem tak zvědavý: co je nefunkčního na té, kterou jsem vám sem před týdnem napsal?

[foldy]

Neobsahuje zkrácení a nevynechává to zbytečné nuly, které tamjsou nepotřebné, asi nejsem tak dobrý programátor abych to dal dohromady a dodělal do toho. Jinak to fungovalo ok. Cíl byl také dostat z toho nejkratší string a to ta implementace z bindu splňuje.Díky za pomoc.

[Michal Kubeček]

Zkusil jste to aspoň? Vypadá to že ne…

[foldy]

Ano zkusil, měl jsem za to, že to zkrácení má udělat : inet_ntop(AF_INET6, src, buff, len - 4); , ale nezkrátilo mi to.

[Michal Kubeček]

Pokud tvrdíte, že ta funkce vrací špatný výsledek, uveďte, prosím, konkrétní příklad, pro jakou adresu a jakou délku prefixu ten špatný výsledek dává.