Ciao a tutti,
ho di recente spolverato il mio timhub a cui si era bruciata l'antenna 2.4GHz per usarlo come ATA VoIP con a monte il mio firewall con PFsense plus.
Dopo aver avuto non pochi problemi nella configurazione del VoIP con PFsense (avevo snort installato che bloccava la registrazione del telefono) son riuscito a farlo andare. Il problema è che va a singhiozzo, nel senso in uscita funziona sempre, in ingresso a volte non riceve la chiamata e quando succede noto che nel log di PFsense mi spunta questo messaggio: Jun 23 16:52:28 kernel arp: 192.168.1.7 moved from xx:xx:xx:xx:xx:7b to xx:xx:xx:xx:xx:5c on re0 e fino a che non torna con l'altro MAC non funziona. Il problema è che il MAC del timhub è quello che finisce con 5c (segnato sia nella ansuel GUI che nell'etichetta dietro). Da dove salta fuori l'altro MAC ed eventualmente come posso risolvere? Premetto che non ho impostato alcuno spoof del MAC e il tiimhub è impostato in modalità bridge con indirizzo IP statico, dite di impostarlo in DHCP? Eventualmente ho accesso anche a LuCi se può servire.
Timhub con 2 MAC address
[cancellato]
Perchè bridge? Se è solo per il VOiP basta che si prenda un IP dalla LAN sulla sua interfaccia.
[cancellato] lo uso anche come switch in cui c'è collegato in cascata un altro timhub che uso come AP per il piano di sotto.
Lo metto in IP statico invece di bridge?
[cancellato]
Non conosco in dettaglio la configurazione del TIM hub ma fra bridge e switch c'è una differenza. Non ha una modalità AP dove disabilita il routing e si comporta solo da AP/ATA?
[cancellato] la modalità bridge fa quello da quanto ne so. Altrimenti le funzionalità di routing son sempre abilitate mi pare
Giann se vedi quel messaggio significa che hai due schede di rete con lo stesso IP.
Prova ad inserire il mac qui: https://macvendors.com/ dovrebbe aiutarti a capire a chi appartiene l'altro mac
handymenny da not found. Ma sospetto sia il timhub perché anche con l'altro ora che guardo da lo stesso errore. Solo che con quello usandolo solo come AP non me ne sono accorto.
Invece quello suo giusto da technicolor.
Giann allora sarà un macaddress generato, sicuro di non aver nessun dispositivo in casa con ip statico?
handymenny sisi, gli unici dispositivi con IP statico impostato sono i due timhub e il NAS, il resto è tutta roba in DHCP e non ho mai visto altri dispositivi che prendevano quell'IP oltre al timhub
[cancellato]
Tanto per essere sicuri, quell'IP è escluso dal range assegnato dal server DHCP?
- Modificato
[cancellato] sisi.
Indagando un po' con SSH e LuCi quel MAC address non sembra assegnato a nessuna interfaccia...
Giann fai una cosa, spegni il tim hub e prova a dare un ping verso quell'IP
- Modificato
handymenny host non raggiungibile
PING 192.168.1.7 (192.168.1.7) 56(84) bytes of data.
From 192.168.1.101 icmp_seq=1 Destination Host Unreachable
From 192.168.1.101 icmp_seq=2 Destination Host Unreachable
From 192.168.1.101 icmp_seq=3 Destination Host Unreachable
From 192.168.1.101 icmp_seq=4 Destination Host Unreachable
From 192.168.1.101 icmp_seq=5 Destination Host Unreachable
From 192.168.1.101 icmp_seq=6 Destination Host Unreachable
From 192.168.1.101 icmp_seq=7 Destination Host Unreachable
From 192.168.1.101 icmp_seq=8 Destination Host Unreachable
From 192.168.1.101 icmp_seq=9 Destination Host Unreachable
From 192.168.1.101 icmp_seq=10 Destination Host Unreachable
From 192.168.1.101 icmp_seq=11 Destination Host Unreachable
From 192.168.1.101 icmp_seq=12 Destination Host Unreachable
From 192.168.1.101 icmp_seq=13 Destination Host Unreachable
From 192.168.1.101 icmp_seq=14 Destination Host Unreachable
From 192.168.1.101 icmp_seq=15 Destination Host Unreachable
From 192.168.1.101 icmp_seq=16 Destination Host Unreachable
^C
--- 192.168.1.7 ping statistics ---
19 packets transmitted, 0 received, +16 errors, 100% packet loss, time 18386ms
pipe 4la parte che hai nascosto (inutilmente) degli indirizzi mac è identica per i due indirizzi? oppure parliamo di indirizzi completamente diversi, non solo nell'ultimo blocco?
e allora hai due attrezzi che usano lo stesso ip; devi fare pulizia in casa.
quando ti succede il flip-flop, aspetti che la situazione ritorni normale, oppure pulisci la cache arp per forzare il broadcast e ricollegarti all'apparecchio "giusto"?
- Modificato
damir13 più che spegnere il timhub e pingare il suo IP che diventa non raggiungibile da spento non so che fare, altri dispositivi che prendono il suo IP son sicuro al 100% non ce ne siano, anche perché l'altro timhub fa lo stesso comportamento.
Questo è quello che da per il 2o timhub di cui il MAC poco mi importa: arp: 192.168.1.2 moved from a6:91:b1:18:65:65 to a4:91:b1:44:0d:72 on re0 e a cui il primo timhub quando "cambia MAC" ne genera uno quasi identico a questo a6:91:b1:18:65:65 cambiando solo le ultime 2 cifre.
- Modificato
Giann mandaresti i mac "ufficiali" dei due tim hub? oppure ci dici quante cifre combaciano con quelli che su macvendor dicono "not found"?
handymenny a4:91:b1:18:65:5c e a4:91:b1:44:0d:72
Nel frattempo ho pulito la cache ARP di PFsense.
- Modificato
Giann ecco, i due tim hub si stanno scambiando di posto tipo...
quel a6:... è un mac di un ssid o comunque un'interfaccia secondaria dell'altro tim hub
handymenny in che senso?
Qua comunque i messaggi di errore con i MAC se fanno chiarezza:
arp: 192.168.1.2 moved from a6:91:b1:18:65:65 to a4:91:b1:44:0d:72 on re0
arp: 192.168.1.2 moved from a4:91:b1:44:0d:72 to a6:91:b1:18:65:65 on re0
arp: 192.168.1.7 moved from a4:91:b1:18:65:5c to a6:91:b1:44:0d:7b on re0
arp: 192.168.1.7 moved from a6:91:b1:44:0d:7b to a4:91:b1:18:65:5c on re0
Giann in che senso?
mi viene difficile da spiegare, ma probabilmente hai un loop nella tua lan e a un certo punto tim hub1 pensa che tim hub2 sia lui stesso e tim hub2 pensa che tim hub1 sia lui stesso
Sicuramente qualcuno di più esperto ti saprà spiegare meglio
handymenny eh il problema è che non so da dove vengano fuori quei MAC A6, anche facendo ifconfig -a da terminale quei MAC non mi vengon fuori, non capisco come possano andare in loop
- Modificato
quando dici che il tim hub è configurato in bridge, vuol dire che hai in un unico bridge sia le porte ethernet che le antenne wifi?
e come ti colleghi al bridge? via cavo o via wifi? (magari lo hai scritto, ma non ho voglia di rileggere tutto, scusa)
e se rendi statica l'accoppiata arp/ip (non ho idea come si faccia su pfsense), il problema persiste, oppure si risolve?
- Modificato
damir13 allora a monte di tutto c'è PFsense che fa da firewall e tutto, dal firewall va nel keenetic speedster che uso come AP per il piano di sopra, poi nel timhub1(usato solo come ATA voip e switch) messo in bridge e con il WiFi disattivato (lo fa già meglio il keenetic e tanto l'antenna 2.4GHz mi ha abbandanato) e da timhub1 poi si va nel th2 che in bridge fa da AP per il piano di sotto, tutto via cavo ovviamente
se rendo l'accoppiata arp/ip col mac a6 non cambia nulla se non addirittura peggiora (mi è capitato di chiudermi fuori da timhub 1 a cui ho dovuto resettare e reinstallare la ansuel gui)
Provo a riassumere in uno schema L2 la tua rete… vediamo se ho capito. Qui non se ne viene fuori altrimenti 
Giann PFsense che fa da firewall e tutto
WAN -> PfSense —> LAN (bridge): keenetic, timhub1, timhub2
Questo è come dovrebbe essere L2.
Ti direi che se hai problemi sono nelle configurazioni dei bridge dei timhub.
Mi ricapitoli un attimo i collegamenti L1 che hai fatto?
- Modificato
gandalf2016 se ho compreso bene L1 (sono ignorante) la WAN arriva dall'antenna Eolo.
Se può essere utile qua c'è l'ifconfig del timhub 1:
Premi per mostrare Premi per nascondere
bcmsw Link encap:Ethernet HWaddr A4:91:B1:18:65:5C
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:299026 errors:0 dropped:0 overruns:0 frame:0
TX packets:401913 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:85850184 (81.8 MiB) TX bytes:161995016 (154.4 MiB)
Base address:0xffff
br-lan Link encap:Ethernet HWaddr A4:91:B1:18:65:5C
inet addr:192.168.1.7 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::a691:b1ff:fe18:655c/64 Scope:Link
inet6 addr: 2a02:29e1/64 Scope:Global
inet6 addr: 2a02:29e1:/128 Scope:Global
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:222710 errors:0 dropped:817 overruns:0 frame:0
TX packets:22164 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:76202869 (72.6 MiB) TX bytes:3180127 (3.0 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:18:65:5C
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1673596 errors:0 dropped:8 overruns:0 frame:0
TX packets:511052 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1883862734 (1.7 GiB) TX bytes:86514439 (82.5 MiB)
eth1 Link encap:Ethernet HWaddr A4:91:B1:18:65:5C
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:496526 errors:0 dropped:0 overruns:0 frame:0
TX packets:1669048 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:83664090 (79.7 MiB) TX bytes:1882249006 (1.7 GiB)
eth2 Link encap:Ethernet HWaddr A4:91:B1:18:65:5C
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)
eth3 Link encap:Ethernet HWaddr A4:91:B1:18:65:5C
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:18:65:5C
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:18:65:5C
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:81080 errors:0 dropped:10 overruns:0 frame:0
TX packets:248012 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6199300 (5.9 MiB) TX bytes:84920027 (80.9 MiB)
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 4E:31:29:84:7F:47
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 A2:CA:DF:2F:DB:2D
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:129942 errors:0 dropped:0 overruns:0 frame:0
TX packets:129942 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:14580046 (13.9 MiB) TX bytes:14580046 (13.9 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:18:65:5D
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)
Interrupt:92
wl0_1 Link encap:Ethernet HWaddr A4:91:B1:18:65:5D
inet addr:192.168.168.1 Bcast:192.168.168.127 Mask:255.255.255.128
inet6 addr: fe80::a691:b1ff:fe18:655d/64 Scope:Link
UP BROADCAST RUNNING 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)
wl1_1 Link encap:Ethernet HWaddr A4:91:B1:18:65:5C
inet addr:192.168.168.129 Bcast:192.168.168.255 Mask:255.255.255.128
inet6 addr: fe80::a691:b1ff:fe18:655c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:125 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:18358 (17.9 KiB)```!<- Modificato
Giann non conosco i tim hub, ma per l'assegnamento statico dell'indirizzo arp dovresti usare il mac "reale", quindi quello presente sull'etichetta, direi.
e comunque dovrebbe essere sufficiente pulire nuovamente la cache arp, perché le comunicazioni riprendano (magari devi aspettare 5 minuti che si pulisca la cache anche sul tim hub).
Giann grazie, poi mandare anche la config del tim 2?
gandalf2016 grazie, stavo per chiedere la stessa cosa.
mi sembra siamo tutti d'accordo che ci deve essere un loop nel broadcast L2,ma via cavo, o sfruttando anche il rientro attraverso i due AP ?
Giann
ecco qui il mac address con a6:
fe80::a691:b1ff:fe18:655c
qualcuno si ricorda la teoria ip6 per creare gli indirizzi fe80::?
che succede se disabiliti ip6 in entrambi i tim?
una curiosità: gli indirizzi ip6 di PF che si vedono nell'interfaccia br-lan, li hai editati tu, oppure sono quelli che effettivamente il tim riceve?
Giann mah... finché la cache è dinamica e hai il loop nel broadcast non risolvi nulla, pulendo la cache, prima o poi il problema ritorna.
mi sembra strano che tu non riesca a rendere statico l'indirizzo arp, dovrebbe essere una operazione abbastanza basilare (e funzionare). hai provato a rendere statico l'indirizzo arp da entrambe le parti (sul pfsense e sui tim hub)?
alla peggio puoi forzarlo con:
lancia un ping dal pfsense al tim hub e verifica che ti risponda usando l'indirizzo arp corretto, altrimenti cancella l'indirizzo ip dalla cache (mentre il ping è attivo).
una volta che ip/arp sono quelli giusti, lascia andare il ping all'infinito, cosi l'indirizzo arp in cache non dovrebbe cambiare (si spera). ammetto che sia una soluzione un po' alla canna del gas, ma almeno il telefono risponde finché non trovi come risolvere definitivamente la cosa.
- Modificato
damir13 finché la cache è dinamica e hai il loop nel broadcast non risolvi nulla, pulendo la cache, prima o poi il problema ritorna
si infatti stanotte ha spammato messaggi arp.
damir13 hai provato a rendere statico l'indirizzo arp da entrambe le parti (sul pfsense e sui tim hub)?
Si, attualmente è così: IP statico impostato su PFsense e anche sul timhub perché deve per forza sapere quale sia il suo IP.
Se può tornare utile ho scoperto che quel MAC fa richiesta in DHCP
Jun 25 07:07:08 dhcpd 29212 DHCPACK on 192.168.1.7 to a6:91:b1:44:0d:7b via re0
Jun 25 07:07:08 dhcpd 29212 DHCPREQUEST for 192.168.1.7 from a6:91:b1:44:0d:7b via re0
Intanto faccio una prova mettendo il timhub invece che in bridge IP statico in bridge DHCP e vedo se così lascia gestire tutto al firewall.
Mentre ora il voip si è pure deregistrato e non riusciva più a registrarsi ho provato a fare un packet capture e dentro ho trovato questo:
08:26:10.230866 ARP, Request who-has 192.168.1.7 tell 192.168.1.2, length 46
08:26:21.821962 ARP, Request who-has 192.168.1.2 tell 192.168.1.7, length 46
08:26:34.109921 ARP, Request who-has 192.168.1.1 tell 192.168.1.7, length 46
EDIT: in un rapsus violento di rabbia e frustrazione ho defenestrato telefono e timhub1.
Per un capriccio non vale la pena farsi venire tutti sti mal di testa, più avanti magari compro un ATA voip (un cisco SPA122 o un telefono IP) giusto però rimane comunque interessante scoprire perché si comportano così i timhub.
[cancellato]
Però se quell'IP è fuori dal range assegnabile dal DHCP, come fa a dargli l'ACK?
[cancellato] bella domanda è quello che vorrei capire pure io, magari il fatto di aver messo in bridge con IP statico lato Timhub gli fa tirare fuori quel mac finto e si prende l'IP.
[cancellato]
Ma il server DHCP deve rifiutare una richiesta per un IP che non è nel range assegnabile e offrirgliene un altro. Anche ci fosse una reservation è associata al MAC, non deve associarla ad un MAC diverso. O il server DHCP ha un bug, o c'è qualcosa che non va.
Controlla i lease dei DHCP, spegni i TimHub, e altri dispositivi in DHCP, elimina i lease degli IP sbagliati, controlla le impostazioni e riavvia il server DHCP.
[cancellato] Ma il server DHCP deve rifiutare una richiesta per un IP che non è nel range assegnabile e offrirgliene un altro. Anche ci fosse una reservation è associata al MAC, non deve associarla ad un MAC diverso. O il server DHCP ha un bug, o c'è qualcosa che non va.
Assolutamente d'accordo, però il server DHCP si è comportato così solo coi timhub.
[cancellato] Controlla i lease dei DHCP, spegni i TimHub, e altri dispositivi in DHCP, elimina i lease degli IP sbagliati, controlla le impostazioni e riavvia il server DHCP.
Fatto, tolto tutti i lease e riavviato il server DHCP, Timhub 1 comunque l'ho tolto proprio per ora nel rapsus di rabbia e frustrazione di poco fa. Però rimane comunque timhub2 che vedrò se manda ancora MAC strani.
[cancellato]
Perché probabilmente gli ha chiesto quello specifico IP. Che però il server DHCP non gli avrebbe dovuto rilasciare. Prima della request c'è una offer del server DHCP per quell'ip? E la discovery? Lì chiede uno specifico IP? Tra l'altro il client dovrebbe fare un arp per assicurarsi che l'ip non sia in uso.
Giann no, io parlavo di rendere statico il record arp tramite "arp -s ...." (o simile), non di rendere statico l'ip. a rendere statico l'ip non cambi nulla.
ma come ti hanno già fatto notare, se il server dhcp gli fornisce il .7, allora vuol dire che non hai configurato il servizio dhcp come pensi di aver fatto.
aggiungi nel pool dhcp l'opzione per rifiutare la risposta a indirizzi mac sconosciuti e l'elenco di tutti gli indirizzi mac che vengono usati dai dispositivi "regolari", in questo modo il server dhcp risponde solo a richieste "lecite".
su linux si fa con qualcosa simile a questo (solo un estratto a cui devi aggiungere tutto il resto, ovviamente):
class "laptops" {
match hardware;
}
subclass "laptops" 1:c8:5b:76:fb:c0:a0; # lenovo
pool {
deny dynamic bootp clients;
allow members of "laptops";
range 192.168.1.x 192.168.1.y;
}
[cancellato] allora si, sembra che il timhub si comporti così quando viene messo in bridge IP statico, in bridge DHCP per ora non vedo alcun messaggio ARP strano.
Attualmente il DHCP è impostato così:
Ma sinceramente non credo che valga lo sbattimento star li a reimpostare manualmente tutto il DHCP per un timhub, al max mi compro l'ATA giusto e bon
damir13 mi sembra siamo tutti d'accordo che ci deve essere un loop nel broadcast L2,ma via cavo, o sfruttando anche il rientro attraverso i due AP ?
Si, penso anche io a naso.
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?
