UmbertoZ.
Il 04/dic/2015 10:29, "Stefano Bianchi" <bianchi.ste@xxxxxxxxx> ha scritto:
>
> Il 2 dicembre 2015 01:37, Daniele Palumbo <daniele@xxxxxxxxxxxx> ha scritto:
> > Il giorno 01/dic/2015, alle ore 11:58, Stefano Bianchi <bianchi.ste@xxxxxxxxx> ha scritto:
> >> - Il log del firewall di un esempio di questo tipo dice
> >> Dec 1 11:38:44 dhcpd DHCPOFFER on 192.168.1.66 to 34:15:9e:8e:f9:5d
> >> (MacBookcaMolari) via br0
> >
> >
> > così è veramente pochino per fare debug :)
> Hehe lo so...
>
> >
> > serve, secondo me, un bel trace (dhcpdump è un comodo tool tipo tcpdump, specializzato).
> > va preso il dump mentre fai una renew su entrambe le interfacce, separatamente.
> >
> > inoltre allega i log (non solo la offer, tutta la catena).
> >
> > e dhcpd.conf (rimuovi le informazioni sensibili, e direi che non ha senso avere tutte le lease statiche, ma solo alcune giusto come esempio)
> >
> > domanda che deriva da quella di matteo:
> > quanti dhcp sono attivi sulla rete?
> > Se spegni il dhcp sull'endian e chiedi un ip sulla br2, cosa succede? (ancora, dhcpdump è una buona risorsa)
> >
> >
> >> nelle impostazioni se clicco semplicemente su riottieni indirizzo DHCP
> >> mi torna quello sbagliato, ma se entro in manuale, lo cambio (ho usato
> >> 172.16.3.21), poi torno in automatico ottengo
> >>
> >> Dec 1 11:38:45 dhcpd DHCPOFFER on 172.16.1.203 to 34:15:9e:8e:f9:5d
> >> (MacBookcaMolari) via br2
> >
> > si ma non hai rimosso il lease del "pc", questo è un test non efficace :)
> > step:
> > 1) stop del servizio
> > 2) rimozione delle entry nel file dei lease
> > 3) start del servizio
> >
> > potrebbe essere anche un problema di routing/tagging.
> >
> > potresti verificarlo ad esempio togliendo il tag della vlan attestata su br0, e chiedere un ip dalla rete br2.
> > il server funzionerà nello stesso modo, quindi se è un problema di routing farà uscire i pacchetti su br0 (che non funzionerà).
> > questo ovviamente nel caso in cui la dhcpoffer esca solo da una nic e non da entrambe.
> >
> > come vedi i problemi possono essere N, ed è necessario che tu faccia decisamente tanti test, condividendo i risultati in maniera puntuale :)
> >
> > ciao,
> > d.
>
> Prima di tutto sono veramente contento di "sentirti" Daniele, spero di
> cuore che tu stia alla grandissima e quando vuoi venirci a trovare sei
> sempre il benvenuto.
>
> Poi, se sapessi fare la metà delle cose che mi hai chiesto forse non
> avrei mai postato il problema :), però ho fatto questo ieri sera
> quando a scuola non c'era nessuno.
>
> Sul firewall ho disabilitato il server DHCP su br2. Ho attivato il
> wifi dal cellulare e lui, una pausa un pelino più lunga del normare ha
> preso un indirizzo da br0 (192.168. ...). Ovviamente sbagliando.
> Poi ho disabilitato anche il DHCP su br0; ho riavviato wifi sul
> cellulare e stavolta non ha avuto nessun indirizzo.
>
> Così per sfizio ho fatto anche l'ultima casistica e cioè ho
> disattivato il DHCP solo su br0 riattivandolo su br2 e riaccendendo il
> wifi sul cellulare ho ottenuto subito l'IP corretto (172.16. ...)
>
> So che è ancora pochino, quando avrò più tempo (e conoscenze) farò
> altri tentativi
Da quanto descrivi potrebbe sembrare a prima vista che venga fatto un relay del dhcp sull'altra interfaccia quando un dhcp sull'interfaccia corretta non risponde o non sia disponibile.
Da quanto ricordo, però, un dhcp offre un indizzo ip alla richiesta di un broadcast che viene limitato alla singola sottorete.
Sui router cisco c'è un opzione (helper-address) per eseguire un relay verso un dhcp centralizzato che, però risponde con un ip conguente con la sottorete che genera la richiesta di avere un ip.
Non vorrei che, invece, sia abilitato un forward del broadcast fra le due sottoreti.
In questa ipotesi quando un apparato (pc, telefonino, tablet,...) richiede un indirizzo, il broadcast viene passato anche sull'altra interfaccia e il dhcp che risponde per primo è quello che assegna l'ip al dispositivo che ne fa richiesta.
>
>
> Grazie ancora
> --
> ---------------------------------
> Stefano Bianchi
> bianchi.ste@xxxxxxxxx
>
> ---------------------------------------------------------------------
> Per cancellarsi, scrivi a: riminilug-general-unsubscribe@xxxxxxxxxxxx
> Se vuoi conoscere altri comandi, scrivi a: riminilug-general-help@xxxxxxxxxxxx
>