Rispondo #2:No.
Quando ottiene un indirizzo IP, il demone dhcp crea un socket raw per l'interfaccia di rete e gestisce il protocollo UDP stesso. Così i pacchetti UDP non passano mai attraverso iptables.
Il motivo per cui il demone dhcp deve implementare UDP è che il kernel può gestire solo UDP (in effetti tutta la suite TCP/IP) quando l'interfaccia ha un indirizzo IP. In precedenza i demoni dhcp assegnavano prima a un'interfaccia l'indirizzo IP 0.0.0.0, ma non funziona più.
Aggiunta
$IPT -I INPUT -i $INTIF -p udp --dport 67:68 --sport 67:68 -j ACCEPT
renderà l'aggiornamento DHCPD più veloce :) Funzionerà su entrambi i lati INPUT e OUTPUT. Puoi DROP dhcpd con ebtables, non con iptables. DHCPD in ascolto su 0.0.0.0, non all'interno di IP
La mia recente osservazione, su OpenWRT Kamikaze 7.09 =2.4.34 e udhcpc da busybox 1.4.2 :
Ho una politica "ACCEPT" nella catena OUTPUT e nella direzione INPUT, inizialmente mi sono affidato a questa classica regola onnicomprensiva:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
per consentire le risposte DHCP (al mio udhcpc) sull'interfaccia WAN. Cioè, qui è dove il server DHCP upstream del mio ISP mi assegna un indirizzo IP.
Fai attenzione alla differenza tra uno scambio DHCP iniziale (discover, offer, request, ack) e un rinnovo del lease DHCP (request, ack).
Dopo l'avvio, udhcpc inizia con lo scambio iniziale completo. Quello scambio avrà successo. E anche un altro o due rinnovi avrebbero avuto successo:solo una richiesta e un riconoscimento. Il server DHCP del mio ISP in genere richiede un tempo di rinnovo da circa un'ora a un'ora e mezza, quindi il mio client DHCP richiede un rinnovo ogni 30-45 minuti (questo comportamento è basato sulla RFC).
Ma, verso il terzo o quarto rinnovo, inizierebbe a diventare interessante. TCPdump mostrerebbe circa tre tentativi di rinnovo, seguiti da uno scambio iniziale completo, entro un periodo di pochi minuti o addirittura secondi. Come se a udhcpc non piacesse quello che riceveva in cambio :-( e alla fine si accontentasse dello scambio completo. Dopodiché, un altro rinnovo in mezz'ora sarebbe riuscito... e la storia si ripeterebbe di nuovo.
Ho capito che forse è il tracciamento della connessione nel kernel che ha qualcosa che non va. Come se la voce conntrack scadesse dopo circa due ore e i successivi rinnovi DHCP fallissero perché l'ACK dal server non arriva effettivamente a udhcpc in ascolto sul socket. Si noti che tcpdump (libpcap) è in ascolto sull'interfaccia raw e può vedere tutti i pacchetti in arrivo, prima che siano soggetti a iptables. Una volta che udhcpc rinuncia ai rinnovi e, disperato, tenta di ricominciare da capo utilizzando uno scambio completo (a partire da DISCOVER), il kernel stabilisce una nuova voce conntrack e può comprendere i pacchetti correlati per un altro po' di tempo...
Abbastanza sicuro, una volta ho aggiunto qualcosa come:
iptables -A INPUT -i $OUT_IF -p udp --sport 67 --dport 68 -j ACCEPT
i rinnovi sembrano funzionare per sempre.
Potresti trovare utili i seguenti argomenti della cmdline di tcpdump:
tcpdump -vv -s 1500 -i eth0.1 port 67 or port 68
Nota:il -vv richiede l'output dettagliato del dissettore. eth0.1 è la mia porta WAN (anche un'interfaccia "NAT outside").
Un attributo interessante nei pacchetti ACK è il campo LT:=tempo di lease suggerito / massimo concesso in secondi. Le richieste DHCP vengono inviate dalla porta 68 alla porta 67. Le risposte arrivano dalla porta 67 alla porta 68.