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]

        • Messaggio #32

        Giann

        Però se quell'IP è fuori dal range assegnabile dal DHCP, come fa a dargli l'ACK?

        • Giann ha risposto a questo messaggio

            [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]

                • Messaggio #34

                Giann

                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.

                • Giann ha risposto a questo messaggio

                    [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]

                          • Messaggio #36

                          Giann

                          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 ha risposto a questo messaggio

                              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;
                              }

                              • Giann ha risposto a questo messaggio

                                  damir13

                                  [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?

                                          • Giann ha risposto a questo messaggio

                                              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]

                                                • Messaggio #42

                                                Giann

                                                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.

                                                • Giann ha risposto a questo messaggio

                                                    [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]

                                                          • Messaggio #44

                                                          Giann

                                                          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.

                                                          • Giann ha risposto a questo messaggio

                                                              [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?

                                                                  • Giann ha risposto a questo messaggio

                                                                    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.

                                                                    • damir13 ha risposto a questo messaggio

                                                                        • [cancellato]

                                                                        • Messaggio #48

                                                                        Giann

                                                                        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

                                                                        • Giann ha risposto a questo messaggio

                                                                            Giann tutti questi cambiamenti a livello arp (e i tempi di risposta che riferisci adesso) mi lasciano notevolmente perplesso. La rete, come l'hai descritta, dovrebbe essere piuttosto lineare. Non è che hai un qualche servizio di proxyarp attivo sui Tim hub o su qualche altro dispositivo?

                                                                            • Giann ha risposto a questo messaggio

                                                                                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) !<

                                                                                      Informativa privacy - Informativa cookie - Termini e condizioni - Regolamento - Disclaimer - 🏳️‍🌈
                                                                                      P.I. IT16712091004 - info@fibraclick.it

                                                                                      ♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile