Giann Assolutamente d'accordo, però il server DHCP si è comportato così solo coi timhub.
sicuro di non avere più server dhcp? riesci a capire quale apparato ha dato quella risposta?
Timhub con 2 MAC address
handymenny si sono sicuro che solo il firewall ha il DHCP attivo, i timhub è la prima cosa che spengo appena metto la ansuel. L'unica altra cosa che può fare da DHCP sarebbe il pihole ma anche quello non è impostato e ne sono certo. La risposta in DHCP da quanto ho visto è PFsense che la da e ne vedo il log.
[cancellato]
La configurazione pare corretta (ma il pfSense ha una sola interfaccia di rete?). Non dovrebbe assegnare un indirizzo fuori da quel range. Il log immagino fosse quello del pfSense. Bisognerebbe vedere se quel lease appariva in Status > DHCP leases. Li si vedrebbe se c'è qualche casino fra MAC e client id. Però io uso pfSense essenzialmente come router/fw, non so se ci sono problemi noti con DHCP. Ho visto che nella 2.7 che rilasciano fra pochi giorni hanno risolto problemi con Unbound e DHCP, ma non so se possono essere relativi al tuo caso.
- Modificato
[cancellato] no ha 2 porte una WAN intel e la LAN realtek.
In DHCP leases semplicemente mi dava offline il vero MAC del timhub e dava online l'altro MAC con un indirizzo preso dal pool DHCP. Ora lo si vede offline perché è spento
Ovviamente se mettevo quell'IP il timhub non era raggiungibile...
[cancellato] Però io uso pfSense essenzialmente come router/fw, non so se ci sono problemi noti con DHCP. Ho visto che nella 2.7 che rilasciano fra pochi giorni hanno risolto problemi con Unbound e DHCP, ma non so se possono essere relativi al tuo caso.
Io uso PFsense plus non so quando uscirà per quello la nuova versione.
[cancellato]
Se il TimHub ha IP statico non doveva nemmeno apparire nella tabella dei lease. E non dovrebbe fare richieste DHCP se non ha altre interfacce configurate per farlo, e il DHCP client non è attivo.
Nella lista delle interfacce vedo cose un po' strane, come le due wl con i loro range IP, ma conosco molto poco OpenWRT e derivati e non so se sia normale. Magari se non servono sarebbero da metter in down.
[cancellato] beh no appariva nella lista dei lease all'inizio in mezzo a quelli statici.
Comunque si sembra che timhub 1 andasse in conflitto col MAC di timhub 2 per qualche motivo ancora a me sconosciuto, Timhub 1 è spento e messo nella scatola e questo:
ora è online ed è quello che prima scambiava il mac con quello vero di timhub1. Timhub2 è online
quindi, riassumendo: i due tim hub, per un qualche motivo, in origine erano entrambi configurati con lo stesso ip. se anche hai spostato la configurazione dell'ip da statica a dinamica su uno dei due (o entrambi), i tim hub richiedevano al server dhcp di avere sempre lo stesso ip funzionante in precedenza (192.168.1.7), come è normale che sia, e il server dhcp lo forniva tranquillamente a entrambi, perché non trovava impedimenti (il tim hub che già lo aveva in dinamico o statico non rispondeva al ping di controllo fatto dal server dhcp?).
adesso con un solo tim hub presente in rete, il problema è scomparso.
sono nel circa giusto, fino a qui?
giusto per curiosità, visto che ora il tim hub sopravvissuto al raptus ha beccato l'p 44, che succede, se rimetti in esercizio l'altro tim hub? si prende l'ip 7 (statico o dhcp), oppure vuole anche lui il 44?
- Modificato
damir13 i due timhub non hanno mai avuto lo stesso IP se non subito dopo il reset avendo quello di default in 192.168.1.1 poi subito cambiato.
Poi appena ho tempo oggi o domani faccio altre prove ma penso che il problema stia o in timhub2 o in qualche dispositivo ad esso collegato ma che si annuncia come modem tim (magari solo perché è collegato al TH2), se pingo il .44 ha un ping di 30-40ms quindi mi fa presumere qualcosa collegato in WiFi, se spengo il WiFi di TH2 il ping a .44 diventa 1ms, quindi qualcosa collegato con cavo, il che mi fa presumere che sia o la smartTV (che però ha il WiFi spento) oppure il timhub2 stesso che ha qualche altra interfaccia senza che compaia in ifconfig -a.
TH2 è normalmente raggiungibile con il suo IP 192.168.1.2, il .44 non ha una GUI accessibile e non fa nemmeno richieste al DNS.
[cancellato]
Può apparire lì come static solo se hai fatto un mapping per il server DHCP, e L'Hub fa query DHCP, non se è impostato staticamente direttamente sull'Hub nel qqual caso non deve fare query DHCP e quindi essere invisibile al server DHCP.
Leggi per, https://docs.netgate.com/pfsense/en/latest/services/dhcp/mappings-in-pools.html
Io per srvizi critici che devono sempre essere accessibili allo stesso IP senza dipendere da altri servizi preferisco impostare direttamente l'IP sul dispositivo
- Modificato
damir13 no nessun proxyarp impostato.
[cancellato] boh ho sempre reputato il firewall capace di gestirsi degli IP statici
EDIT: ho fatto delle prove e alla fine è timhub 2 che si prende quell'IP e quel MAC. Ho provato a isolare dispositivo per dispositivo e se scollego TH2 il .44 non è pingabile, se scollego la TV e spengo il WiFi rimane pingabile quindi deve essere qualcosa nel TH2 ma non saprei cosa.
Dato che risponde ai ping non penso nemmeno sia qualche idiosincrasia di PFsense...
Qua l'ifconfig -a del TH2
Premi per mostrare Premi per nascondere
bcmsw Link encap:Ethernet HWaddr A4:91:B1:44:0D:72
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:83079282 errors:0 dropped:0 overruns:0 frame:0
TX packets:116860934 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:62145366117 (57.8 GiB) TX bytes:35191613524 (32.7 GiB)
Base address:0xffff
br-lan Link encap:Ethernet HWaddr A4:91:B1:44:0D:72
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::a691:b1ff:fe44:d72/64 Scope:Link
inet6 addr: 2a02:29e1:x/128 Scope:Global
inet6 addr: 2a02:29e1:x/64 Scope:Global
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:170624 errors:0 dropped:657 overruns:0 frame:0
TX packets:17112 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:60430236 (57.6 MiB) TX bytes:6504020 (6.2 MiB)
dsl0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
[NO FLAGS] MTU:0 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth0 Link encap:Ethernet HWaddr A4:91:B1:44:0D:72
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:391257392 errors:0 dropped:347823 overruns:0 frame:0
TX packets:132063821 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:494376850160 (460.4 GiB) TX bytes:19623575604 (18.2 GiB)
eth1 Link encap:Ethernet HWaddr A4:91:B1:44:0D:72
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:60568852 errors:0 dropped:0 overruns:0 frame:0
TX packets:183328356 errors:0 dropped:341877 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6000170749 (5.5 GiB) TX bytes:232423189168 (216.4 GiB)
eth2 Link encap:Ethernet HWaddr A4:91:B1:44:0D:72
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:233958 errors:0 dropped:1 overruns:0 frame:0
TX packets:426444 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16493166 (15.7 MiB) TX bytes:579822834 (552.9 MiB)
eth3 Link encap:Ethernet HWaddr A4:91:B1:44:0D:72
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth4 Link encap:Ethernet HWaddr A4:91:B1:44:0D:72
inet addr:192.168.2.2 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth5 Link encap:Ethernet HWaddr A4:91:B1:44:0D:72
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:24653673 errors:0 dropped:11 overruns:0 frame:0
TX packets:84684179 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3994332262 (3.7 GiB) TX bytes:71508062314 (66.5 GiB)
gre0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-66-00-00-00-00-00-00-00-00
NOARP MTU:1476 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
gretap0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
BROADCAST MULTICAST MTU:1462 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
ifb0 Link encap:Ethernet HWaddr 76:D9:D3:34:FF:35
BROADCAST NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
ifb1 Link encap:Ethernet HWaddr 46:7C:F1:01:8A:83
BROADCAST NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
ip6gre0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
NOARP MTU:1448 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
ip6tnl0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
NOARP MTU:1452 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:9565424 errors:0 dropped:0 overruns:0 frame:0
TX packets:9565424 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:715419377 (682.2 MiB) TX bytes:715419377 (682.2 MiB)
sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
tunl0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-66-00-00-00-00-00-00-00-00
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
wl0 Link encap:Ethernet HWaddr A4:91:B1:44:0D:73
inet6 addr: fe80::a691:b1ff:fe44:d73/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:59021256 errors:0 dropped:1 overruns:0 frame:28940270
TX packets:192308755 errors:30421 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:10281044479 (9.5 GiB) TX bytes:215221759344 (200.4 GiB)
Interrupt:92
wl0_1 Link encap:Ethernet HWaddr A4:91:B1:44:0D:73
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:28940270
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0B) !<[cancellato]
Giann boh ho sempre reputato il firewall capace di gestirsi degli IP statici
Qui il firewall non c'entra nulla - è l'assegnazione degli indirizzi IP, dove hai tre scelte:
- IP statico impostato sul dispositivo (il server DHCP non fa nulla e non sa nulla) e DHCP client non attivo. Non va in alcun modo inserito nel server DHCP, deve essere fuori dal range e basta.
- IP dinamico con prenotazione sul server DHCP per riottenere lo stesso IP (ma vedi l'avvertimento con ISC-DHCP usato da pfSense sopra). Come configurarli e in quale range dipende dal server DHCP.
- IP dinamico senza prenotazione per ottenere il primo indirizzo libero deciso dal server DHCP.
Solo nel caso 2 e 3 il server DHCP conosce i lease. Nellì'altro modo al massimo può verificare gli IP via ARP, ma di solito questi non sono listati nei lease perché non sono sotto il suo controllo. Se mischi le cose un po' malamente c'è il rischio che qualcosa faccia casino.
Giann eth4 Link encap:Ethernet HWaddr A4:91:B1:44:0D:72
inet addr:192.168.2.2 Bcast:192.168.2.255 Mask:255.255.255.0
Quante subnet hai attive? Qui se ne vede un'altra diversa (anche se non fa traffico). Sopra si vedevano anche della 192.168.168.x/25
[cancellato] Quante subnet hai attive? Qui se ne vede un'altra diversa (anche se non fa traffico). Sopra si vedevano anche della 192.168.168.x/25
nessuna, il 192.168.2.2 è l'indirizzo di un teorico SFP di default del timhub.
il caso 1 non è fattibile avendo gente pressoché digitalmente analfabeta in casa e non avendo voglia di impostare manualmente oltre una trentina di dispositivi in giro per casa di cui alcuni non sono nemmeno configurabili manualmente.
I casi 2 e 3 poi me li studio ma penso di puntare sul 3 avendo pensionato di nuovo il timhub e il sirio, avendo appena comprato uno snom710 per sostituirli assieme a uno switch.
[cancellato]
Nulla vieta di fare un mix fra i tre, anzi, si fa comunemente, purché sia opportunamente pianificato. Io ho modem, router/fw, switch, AP e ATA con IP statici. Questi devono essere sempre per me raggiungibili via IP direttamente in caso di problemi. È anche più facile fare regole di firewall dedicate, e altre configurazioni (DHCP relay, ad esempio)
Poi ovviamente il Pi con DHCP, DNS e RADIUS. NAS e stampanti sono in reservation. Tutti gli altri dispositivi client in DHCP semplice. Ci sono tre blocchi dedicati in ogni subnet per evitare problemi. Blocchi logici, gli IP statci sono ovviamente esclusi completamente dagli scope DHCP.
la mia conclusione è che il problema in realtà non esiste:
innanzitutto "il problema" non è a livello ip (3), ma a livello mac (2), quindi concentrarsi su come il server dhcp fornisce gli ip non serve, il server dhcp fa il suo lavoro e lo fa (sembra) correttamente. ovviamente parto dal presupposto che nella configuraizone della rete non ci siano errori macroscopici.
quello che manda il palla tutta la teoria è perché ci sono, qui, indirizzi mac che non dovrebbero esistere:
mi sono finalmente ricordato (pedalare aiuta, evidentemente) che ho visto la stessa cosa succedere con un vecchio repeater/ap netgear: tutti i client che si connettono alla rete attraverso il netgear impostato in modalità AP, lo fanno con un mac address spippolato dal netgear.
non ho idea del perché, la mia ipotesi è per evitare degli accavallamenti tra collegamenti wifi e via cavo in realtà dove non c'è controllo su come gli ip vengono assegnati (tipiche situazioni casalinghe), o per altre ragioni, a me sconosciute.
sta di fatto che quello che nota Giann, non è un episodio casuale.
ci sarebbe da capire perché il tim hub sembra non solo cambiare gli indirizzi mac dei client wifi che passano attraverso lui, ma anche perché sembra lui stesso usare degli indirizzi mac aleatori.
probabilmente la ragione può essere spiegata dalla configurazione bridge/hostapd di quel router, ma non conosco luci/openwrt, e non posso dare delle opinioni definitive senza "averlo in mano".
Giann metti il tim hub con una configurazione IP statica, se ancora vedi richieste dhcp arrivare con indirizzi mac che "sembrano" appartenere al tim hub, sicuramente sono richieste provenienti da apparecchi che si collegano alla rete attraverso l'AP del tim hub. configura il server dhcp adeguatamente e il "problema" sparisce.
damir13 metti il tim hub con una configurazione IP statica, se ancora vedi richieste dhcp arrivare con indirizzi mac che "sembrano" appartenere al tim hub, sicuramente sono richieste provenienti da apparecchi che si collegano alla rete attraverso l'AP del tim hub. configura il server dhcp adeguatamente e il "problema" sparisce
Eh il problema però non è che poi avrei problemi di doppio NAT no?
Poi comunque ormai ho comprato un telefono IP e uno switch in modo da non dover usare il timhub.
Magari farò qualche prova per vedere perché mi incuriosisce questa faccenda.
Continuo a pensare che sia il timhub2 perché scollegando tutti i dispositivi a lui collegati il ping verso il .44 riesce, appena lo scollego non riesce più.
[cancellato]
damir13 il server dhcp fa il suo lavoro e lo fa (sembra) correttamente.
No, se assegna IP fuori dal range ammesso 
