Problem s modulem pf.ko

[Dan Lukes]

Petr Rehor wrote:
>>No, ono to tady za celou dobu nepadlo, ale v teto chvili je vadne pouze
>>"pf" (nebo je jedine o kterem vim). A pokud zrovna tehle filter
>>nepouzivate a pouzivate neco jineho (coz je muj pripad) nebo zadny
>>filtr, tak na zmineny problem proste nenarazite.

> (abych pravdu rekl tak netusim jestli se vubec
> informace v konfiguraci kernelu pouzivaji pri prekladu modulu, ale
> rekl bych ze spis ne) 

	V zasade ano. Globalne se pouzivaji ty, ktere maji kategorii "global" 
(tedy skonci v opt_global.h). To jsou napriklad I?86_CPU, SMP, PAE a 
takove podobne.

	Jine se mohou pouzivat, pokud je to explicitne uvedeno (#include) v 
jejich kodu.

	Napriklad takove ipfw includuje kernelove optiony tridy 
ipfw,ipdn,ipdivert,inet a ipsec

	Problem s modulem 'pf' je, ze nejde o nativni modul pro FreeBSD.  Je to 
'third-party' modul pochazejici nativne z OpenBSD (coz je ostatne 
vyjadreno jeho pozici v 'contrib' vetvi.

	Tam je, bohuzel, nutne ocekavat, ze spoluprace s FreeBSD muze byt 
nikoli tak hladka jak jsme zvykli od nativnich modulu.

	Na druhou stranu, letmym nahlednutim do kodu modulu (nestudoval jsem to 
peclive) se zda, ze modul je v tom tentokrat nevinne. On sam by, podle 
vseho, kernelove optiony prevzal spravne. Je to zvlastni, ale Makefile 
(ktery je nativne z FreBSD) je ten, kdo pri nepritomnosti NO_INET6 mezi 
kernelove optiony ten INET6 dopise. No pak je pochopitelne, proc 
INET6-ready modul nelze pouzit s non-INET6 jadrem.

	Proc to ale onen Makefile takhle dela, to ja nevim.

	Je mozne, ze userland aplikace, ktere se pro komunikaci s pf pouzivaji 
nejsou schopny zdetekovat zda kernel (a pf) INET6 podporuji ci nikoliv 
(a userland aplikace na nastaveni kernelovych optionu kaslou - na druhou 
stranu - naprota vetsina z nich je schopna si (ne)pritomnost zajimavych 
feature v kernelu detekovat) a format predavanych dat na teto informaci 
zalezi. Pak by nebylo lze vyloucit, ze prave neschopnost autodetekce ze 
stranu userland aplikace (a z toho duvodu vynucena pritomnost INET6 kodu 
v pripade, ze je pritomen v userlandu) je cena za 'third-party' kod ...

> ale musi se jeste definovat symbol NOINET6. To

	BTW, v pristi release se podle vseho ten symbol bude jmenovat NO_INET6

> protoze se s jeho pomoci odstrani IPv6 i z
> user space cimz se odstrani zbytek problemu zbusobenych neexistenci
> IPv6 v kernelu. 

	Smel bych se, skutecne jen ze zvedavosti, zeptat na nejaky problem, se 
ktery jste se v teto souvislosti setkal ? Ja mam kernel typicky bez IPv6 
(krome tech par serveru v sitich, kde IPv6 skutecne je) a zatim jsem 
nemel tu cest (ne, ze bych si stezoval). Tak abych mel predstavu, co by 
me tak mohlo potkat ...

						Dan