Dan Lukes wrote on 2019/04/28 22:36:
To "send_packet: Permission denied" to naopak osvetluje naprosto jasne.
A uvahu, jejimz vysledkem je zaver "by to nemelo vadit" bych si docela
rad precetl.
To jsem si to jenom ja spatne vylozil. Kdyz jsem to ted cetl znovu, tak
uz to chapu jinak :(
https://lists.freebsd.org/pipermail/freebsd-questions/2005-January/071188.html
Podle vseho dhclient neni schopen prodlouzit "pronajem" adresy, protoze
odeslani pozadavku nedovoluje firewall (to je ten "EPERM" vysledek
pokusu o odeslani paketu). Teprve kdyz doba zcela vyprsi a adresa je z
interface odstranena, dhclient je schopen domluvit "novy pronajem".
Zbyva otazka jak se lisi pozadavek na "novy pronajem" od pozadavku na
"prodlouzeni najmu". Tech rozdilu je vic, ale kvalifikovany odhad
priciny je tento:
kdyz interface adresu nema, odchazi pozadavek z 0.0.0.0 na 255.255.255.255
kdyz ji ma, tak odchazi z te, kterou ma primo na adresu DHCP serveru,
ktery minule adresu pridelil
To je pravdepodobny rezim prace DHCP klienta, prestoze jsou mozne i jine
varianty.
No a firewall propousti jen ty prvni pakety ...
Na firewallu nemam zadne pravidlo, ktere by jmenovite povolovalo cokoliv
na DHCP portech 67 a 68. I tak to adresu dostane.
Predpokladam, ze je to na zaklade pravidla, ktere povoluje odchozi UDP s
keep state:
pass out on bge0 inet proto udp all keep state
Zkusmo jsem pridal jmenovita pravidla, povolujici obousmerny provoz mezi
porty 67 a 68
pass in quick on bge0 proto udp from any port = 67 to any port = 68 keep
state
pass out quick on bge0 proto udp from any port = 68 to any port = 67
keep state
Ale v logu se mi zase objevilo dhclient[40538]: send_packet: Permission
denied.
Takze co by melo byt povoleno?
Mirek
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
