Re: l2tp/ipsec
On 02/21/11 03:51, Čiernik Tomáš: Klient hlasi "Server negotiation failed. The server may not agree with your encryption option." Zial z tejto odozvy neviem vycitat, ci je problem na strane klienta alebo serveru. Androida jsem nikdy nedrzel v ruce, to ti bude muset pomoct nekdo jiny, presto bych rekl, ze podstatnejsi nez ta chybova hlaska, kterou uvadis je jina cast: message_type_avp: message type 4 (Stop-Control-Connection-Notification) assigned_tunnel_avp: using peer's tunnel 19914 result_code_avp: avp is incorrect size. 8 < 10 handle_avps: Bad exit status handling attribute 1 (Result Code) on mandatory packet. call_close : Connection 19914 closed to 192.168.20.231, port 46816 (Result Code: expected at least 10, got 8) Oni si nerozumi na urovni L2TP protokolu, a to kvuli chybne naformatovane StopCCN zprave. StopCCN ma dvojbajtovou hlavicku - jestli jeden ze systemu spatne pochopil zda se do udane delky (ne)zapocitava i delka teto hlavicky je vysvetleni dvoubajtoveho rozdilu na svete. Idealni by bylo tu spravu zachytit a podivat se. Nicmene, pokdu to nedokazes, tak hledej nekoho, kdo se potkal prave s timto problemem - a pokud zpravy posila blbe Android, nemusel se problem vyskytovat jen proti FreeBSD a tak muzes "dotaz pro Google" rozsirit. Zvysis sanci, ze nekoho najdes. Takhle "naslepo" dokazu poradit jediny work-around, sahnout do zdrojaku funkce result_code_avp, do mista, kde se kontroluje spravna delka, a ten test pozmenit nebo uplne odstrelit. Vzhledem k tomu, ze pocinaje tretim byte zpravy StopCCN jde o "human readable" retezec, nemela by pripadna ztrata dvou poslednich znaku mit vazne nasledky. Podotykam, ze (jako casto) drze radim o protokolu, ktery jsem sam nikdy nepouzil a doporucuju jako mozna reseni upravy zdrojaku, ktere jsem dokonce ani neotevrel. Takze se muze stat, ze se treba ta funkce vubec result_code_avp() nejmenuje. Nicmene, mela by byt k nalezeni snadno - je to proste ta funkce v okoli te chybove hlasky ... Samozrejme, lepsi nez workaround by bylo najit skutecny duvod dvoubytove diference a na te ci one strane provest skutecnou opravu ... Dan -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: l2tp/ipsec
Jeste ted jsem se kouknul o odstavec niz v RFC2661 a nasel jsem kousek, ktery stoji za ocitovani: - The Length is 8 if there is no Error Code or Message, 10 if there is an Error Code and no Error Message or 10 + the length of the Error Message if there is an Error Code and Message. - Jestlize FreeBSD "expected at least 10" naznacovalo by to, ze je chyba na strane FreeBSD, ktere "prazdnou" StopCCN vubec neocekava. Pak ta pripadna "workaround" uprava, kterou jsem zminil muze byt opravou skutecneho problemu - jen to bude malinko slozitejsi, protoze FreeBSD prijaty paket jiste dale zpracovava a vytahuje z nej Result Code a Error Code. Pokud akceptujeme paket v delce 8B tak v nem ale R/E kody vubec nejsou - je tedy treba dat pozor aby se nam nevyextrahovaly nahodne hodnoty z pameti "za paketem" a v pripade osmibitove odpovedi je patrne bude nutne nastavit na konstantu. Odhaduju, ze nula by mohla byt dobra. Stale plati, ze opravuju kod, ktery jsem vubec nevidel - muze to cele byt totalni blabol. Rekneme, ze je ale nenulova sance, ze by to blabol byt nemusel. Takze se rozhodni sam, pripadne to zkus, kdyz to pomuze, mas opravu obecneho problemu. Kdyby to nahodou vyslo, nezapomen chybu a opravu odreportovat autorum kodu, at to muzou opravit "pro vsechny". Dan -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: rtld i386 versus amd64
Dne 19.2.2011 13:24, Dan Lukes napsal(a): ... Vypada to, ze problemy jsou dva - nejak spatne se nam chova ldconfig - to bdue v lepsim pripade problem s jeho volanim, v horsim pripade problem s jeho vnitrni logikou. A nejake napady jak z toho vybruslit jsem popsal nahore. Zmena logiky dynamickeho linkovani nam problem spis nevyresi. Druhy problem je komunikace pres routing-socket, kde se predavaji binarni data a asi jsou spatne interpretovana - to je trochu horsi. Lepsi varianta je, ze to je nezamysleny bug - bud' ta data nemaji byt architekturne zavisla (a chyba je, ze jsou), nebo zavisla byt mohou a kernel je ma zavisle interpretovat (a chyba je v teto logice). V takovem pripade je treba chybu najit, odreportovat - oni ji do nekolika let do kodu vlozi. Do te doby to ja mohu mit jako lokalni "vlastni" patch. Takove patche me tolik netrapi. Horsi je, pokud se commiteri rozhodnou, z enebylo zamerem dosahnou tohoto typu kompatibility a tudiz nejde o bug, ale "by design". ... Ja sam se ted nebudu pokouset to zkouset a doladit do finalne pouziteneho stavu ... ... ale jsem ochoten se tomu jeste venovat a jestli me Ty nebo nekdo dalsi popostrci, pokusim se k tomu pouzitelnemu stavu dostat. To je spoluprace, ktera mi momentalne vyhovuje. Ja fakt nemam cas si s tim ted hrat. Pokud ty cas a naladu mas, zkus se podivat co po tom startu vlastne vyrobil ten ldconfig - zda vyrobil jen /var/run/ld-elf.so.hints nebo i /var/run/ld-elf32.so.hints - a co do nich vlastne dal. To je vec, ktera se na "normalnim" systemu spatrit neda. Na "route" se podivat muzu - na to nemusim "zparchantet" zadnou masinu, to si proste i386/route nakopiruju domu a zkusim to, to zadne velke mnozstvi casu nevyzaduje. Dik za komentare. Ted se mi ale taky trochu pokrivil cas a nevim, jestli a kdy si v nejblizsich dnech utrhnu par hodin na hrani :-( U toho "route" me trochu znervoznuje, ze takovych nefunkcnich programu muze byt vic a ja si jich akorat zatim nevsiml. Zkratka pocet prekazek cestou jeste muze rust. Co kdybychom si zjednodusili zadani a mohli vyuzit swap? Odpojit, nahrat na nej mfsBSD Martina Matusky, "nejak" (ted hned nevim jak) prinutit loader, aby po rebootu natahl msfBSD. Reboot, z mfsBSD jednoduse prerazit puvodni system, zase prenastavit loader a mohlo by byt vyhrano. Snad :-) Oli -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
