Unitymedia Technicolor TC4400 Docsis 3.1 Modem Info Thread

[JPDribbler]

Hallo zusammen,

jetzt hat es mich auch erwischt und Unitymedia hat hier einen OFDM-Kanal aufgeschaltet. Seitdem komme ich nicht mehr ins Internet.

Was schon gemacht wurde:
- Störung gemeldet. Techniker war da und wollte mir nicht glauben, dass der OFDM-Kanal da ist bis ich ihm den auf der Statusseite gezeigt habe. Hat dann einen Auftrag an NE3 geschrieben, da das Signal schon "schief" am HÜP ankommt.
- Nächster Techniker hat alles untersucht und einen Bauauftrag geschrieben, Abzweiger vorm Haus sollte getauscht werden. Das ging auch sehr schnell.
- Danach wieder Techniker-Besuch. Der hatte den Auftrag, mein Anschluß online zu bringen. Nichts von eigenem Modem oder OFDM wurde ihm gesagt und so ist auch wieder unverrichteter Dinge weg gefahren. Unitymedia hat das Ticket als erledigt geschlossen.

In Eigenregie hab ich mir einen Sperrfilter LPF-774 short besorgt. Hat nichts gebracht, damit habe ich gar keine Verbindung mehr.
Auch das snmp set Kommando hat nicht funktiniert, trotz Firmware .20

Ich weiß nicht mehr, was ich noch machen soll. Niemand (und das ärgert mich im Moment tierisch) will das Problem verstehen.

Hier noch meine Werte:

Anhang anzeigen 3986
Anhang anzeigen 3987
Anhang anzeigen 3988

Ich bekomme zwar eine öffentliche IP, aber das Internet ist komplett tot, kein Ping, kein Trace Route nichts funktioniert.

Kann mir jemand noch einen Tip geben, was ich noch tun kann?

Gruß
spatze

Techniker anfordern. Oder mal via Twitter / Facebook nerven, komischwerweise reagieren die da eher...

 

[ajunity]

Kleines Update: Am Montag ließ sich zeitnah ein Techniker organisieren, der Mittags eintrudelte. Als erstes hat er sich (nach anklemmen von zwei Messgeräten an der Modem-Dose), wie von UHeinz13 vorhergesagt, auf den Upstream PowerLevel eingeschossen: am Verstärker im Nachbarhaus hat er einen Stecker "0" gegen "10" getauscht um den von ~32 dBmV auf ~42 dBmV zu reduzieren (er sagte ein höherer Wert steht für einen niedrigeren PowerLevel; der solle zwischen 38 und 45 liegen und 32 sei schlichtweg "zu viel des guten"). Sein Tablet meldete danach drei Modems aus der Siedlung als "OK" (zuvor waren neben meinem zwei weitere "NOK"), aber online kam mein Modem von alleine nicht (auch wenn er am Tablet nun auch die Werte von meinem Modem sehen konnte). Da die beiden Nachbar-Modems vorher online waren, scheint ein zu starker Upstream PowerLevel vom TC4400 vergleichsweise schlecht weg gesteckt zu werden!?
Seltsam war, dass selbst nach einem Powercycle meines TC4400 kein surfen/pingen möglich war (wobei der nachgelagerter OpenWrt Router schon die public IPv4 und auch IPv6 bekommen hat und das deutlich fixer als am Wochenende). Nach 5-10 Minuten ging plötzlich doch alles - so als hätte das Modem noch ein anderes Problem verdauen müssen. Über die nächsten 20-40 Minuten wechselte das 2-3 Mal - ein paar Minuten funktionierte es, dann für ein paar Minuten wieder garnichts, usw. Die public IP Adressen blieben dabei allerdings unverändert - ist mir schleierhaft was da von statten ging. Hat hier jetzt dann der OFDM zugeschlagen/negative Wirkung gezeigt!?
Jedenfalls hat es sich spätestens nach einer Stunde eingekriegt gehabt; seitdem funktioniert der Internetzugriff ohne spürbare / messbare Unterbrechnung (ThinkBroadBand-Monitor zeigt keinerlei rot mehr und VPN Verbindungen sind stabil).

Aktuell scheint es, als bräuchte ich garkeinen LTE-Sperrfilter einbauen um den OFDM auszublenden. Nach Mr.Goodcat's Info zum LPF-766-Short hatte ich allerdings am Montag Morgen den LPF-774-short bestellt, der heute eingetroffen ist. Der wird jetzt allerdings bis zu den nächsten Problemen auf seinen Einsatz warten müssen... (Wobei spatze76's Erfahrung ja kein gutes Zeichen für den 774 ist. Verdammt, hätte doch ein paar Downstream-Kanäle opfern und den 766 nehmen sollen. )

Apropos: Nachdem ich wieder online war, hat der Techniker sich dennoch dem OFDM-Kanal angenommen und am HÜP (also am Anfang der C-Linie) nachgemessen was dort reinkommt. Nach etwas experimentieren fing er an den Zustand zu dokumentieren und verließ mich schlussendlich mit der Aussage er würde ein NE3-Ticket wegen dem OFDM öffnen - vor Ort wäre an dem miserablen Input von der Straßen nichts sinnvoll zu retten.

 

[shm0]

Hi!
Hat sonst wer noch das "Problem", wenn man das TC auf der internen Addresse (192.168.0.1) pingt,
die Latenz schlecht ist und Ping Pakete doppelt versendet werden?

PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: seq=0 ttl=64 time=4.038 ms
64 bytes from 192.168.0.1: seq=0 ttl=64 time=4.324 ms (DUP!)
64 bytes from 192.168.0.1: seq=1 ttl=64 time=2.633 ms
64 bytes from 192.168.0.1: seq=1 ttl=64 time=2.960 ms (DUP!)
64 bytes from 192.168.0.1: seq=2 ttl=64 time=2.508 ms
64 bytes from 192.168.0.1: seq=2 ttl=64 time=2.551 ms (DUP!)
64 bytes from 192.168.0.1: seq=3 ttl=64 time=2.616 ms
64 bytes from 192.168.0.1: seq=3 ttl=64 time=2.655 ms (DUP!)
64 bytes from 192.168.0.1: seq=4 ttl=64 time=2.799 ms
64 bytes from 192.168.0.1: seq=4 ttl=64 time=2.836 ms (DUP!)
64 bytes from 192.168.0.1: seq=5 ttl=64 time=2.722 ms
64 bytes from 192.168.0.1: seq=5 ttl=64 time=2.761 ms (DUP!)
64 bytes from 192.168.0.1: seq=6 ttl=64 time=2.771 ms
64 bytes from 192.168.0.1: seq=7 ttl=64 time=2.603 ms
64 bytes from 192.168.0.1: seq=8 ttl=64 time=2.736 ms
64 bytes from 192.168.0.1: seq=9 ttl=64 time=2.591 ms

 

[sparkie]

den Test kann du mit beliebigen anderen Adressen aus dem 192.168.0.0/16 Netz auch machen. Die Antworten kommen nicht vom Modem sondern von irgendeinem Gateway deines Providers

 

[rv112]

Normal sollte bei der IP gar keine Antwort kommen?

 

[sparkie]

kommt wohl auf den Provider an. Bei mir kommt sowas zurueck:

08:15:13.663816 IP 10.120.33.1 > 46.124.33.128: ICMP host 192.168.0.1 unreachable - admin prohibited filter, length 36
08:15:18.750592 IP 10.120.33.1 > 46.124.33.128: ICMP host 192.168.0.1 unreachable - admin prohibited filter, length 36
08:15:21.791111 IP 10.120.33.1 > 46.124.33.128: ICMP host 192.168.0.1 unreachable - admin prohibited filter, length 36

 

[shm0]

?
192.168.0.1 ist die IP vom Modem.

 

[UHeinz13]

also bei mir ist es die 192.168.100.1 ...

 

[spatze76]

Was mich wundert, ajunity hat ziemlich identische Werte wie ich, auch die alte .20 Firmware und trotzdem Verbindung.

Hat jemand daür eine Erklärung?

Morgen kommt wieder ein Techniker von Telcotek - gibt es irgendwas was ich ihm sagen muss?

 

[MaXX]

Was mich wundert, ajunity hat ziemlich identische Werte wie ich, auch die alte .20 Firmware und trotzdem Verbindung.

Hat jemand daür eine Erklärung?

Morgen kommt wieder ein Techniker von Telcotek - gibt es irgendwas was ich ihm sagen muss?

Erklärung: Modem kaputt, wie bei mir.

https://www.unitymediaforum.de/threads/36248/page-285#post-450401

 

[rv112]

Das würde ich so pauschal nicht sagen.

 

[shm0]

10.000+ verworfene ARP Pakete pro Minute. Soll für DocSIS ja normal sein... bis zu einem bestimmten Grad... ARP Filter einrichten? So vllt?
Ich frage mich ob dadurch die ~3 ms Verzögerung entsteht?

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1.2, link-type EN10MB (Ethernet), capture size 262144 bytes
05:58:40.586071 ARP, Request who-has ip-5-147-94-33.unitymediagroup.de tell ip-5-147-88-1.unitymediagroup.de, length 46
05:58:40.590381 ARP, Request who-has ip-176-198-68-210.hsi05.unitymediagroup.de tell ip-176-198-68-1.hsi05.unitymediagroup.de, length 46
05:58:40.590421 ARP, Request who-has ip-5-147-95-59.unitymediagroup.de tell ip-5-147-88-1.unitymediagroup.de, length 46
05:58:40.595968 ARP, Request who-has ip-5-147-88-38.unitymediagroup.de tell ip-5-147-88-1.unitymediagroup.de, length 46
05:58:40.601292 ARP, Request who-has ip-95-222-203-152.hsi15.unitymediagroup.de tell ip-95-222-200-1.hsi15.unitymediagroup.de, length 46
05:58:40.602643 ARP, Request who-has ip-5-147-94-138.unitymediagroup.de tell ip-5-147-88-1.unitymediagroup.de, length 46
05:58:40.606291 ARP, Request who-has ip-95-222-203-156.hsi15.unitymediagroup.de tell ip-95-222-200-1.hsi15.unitymediagroup.de, length 46
05:58:40.618936 ARP, Request who-has aftr-88-152-191-243.unity-media.net tell aftr-88-152-190-1.unity-media.net, length 46
05:58:40.631662 ARP, Request who-has ip-5-147-93-100.unitymediagroup.de tell ip-5-147-88-1.unitymediagroup.de, length 46
05:58:40.641840 ARP, Request who-has ip-88-152-23-254.hsi03.unitymediagroup.de tell ip-88-152-20-1.hsi03.unitymediagroup.de, length 46
05:58:40.644964 ARP, Request who-has ip-95-222-175-38.hsi15.unitymediagroup.de tell ip-95-222-172-1.hsi15.unitymediagroup.de, length 46
05:58:40.653276 ARP, Request who-has ip-5-147-93-221.unitymediagroup.de tell ip-5-147-88-1.unitymediagroup.de, length 46
05:58:40.654777 ARP, Request who-has ip-88-152-27-228.hsi03.unitymediagroup.de tell ip-88-152-24-1.hsi03.unitymediagroup.de, length 46
05:58:40.664011 ARP, Request who-has ip-95-222-171-181.hsi15.unitymediagroup.de tell ip-95-222-170-1.hsi15.unitymediagroup.de, length 46
^C05:58:40.665645 ARP, Request who-has ip-178-200-230-212.hsi07.unitymediagroup.de tell ip-178-200-228-1.hsi07.unitymediagroup.de, length 46
...........

Wieso antwortet der DHCP Server nicht auf unicast renew anfragen?

udhcpc: sending renew to 10.130.*.*
udhcpc: sending renew to 10.130.*.*
udhcpc: sending renew to 10.130.*.*
udhcpc: sending renew to 10.130.*.*
udhcpc: sending renew to 10.130.*.*
udhcpc: sending renew to 0.0.0.0
udhcpc: lease of 95.222.*.* obtained, lease time 7200
tcpdump
09:46:40.236976 IP 95.222.*.* > 10.130.*.*: ICMP 95.222.*.* udp port 68 unreachable, length 336

 

[rv112]

Ist normal weil Broadcast. Mein Modem antwortet stabil mit 1ms aber ich erreiche es auch nur auf seiner IP. Wer es via 192.168.0.1 erreicht, hat irgendeine statische Route oder sonst was drin.
Der Renew ist eher ein Bug von pfSense. Dazu gibts auch einen fix. Suche es heute Abend mal raus.

 

[shm0]

Ist normal weil Broadcast.

Ja soll normal sein. Müsste man wohl die Endgeräte modifizieren um das etwas einzudämmen? Aber warum senden die ganzen Geräte ARP Requests ?
Wird ein ARP Requests(Broadcast) nicht erst getriggert wenn eine Verbindung aufgebaut werden soll und kein Eintrag im ARP Cache vorhanden ist?
Warum sollte ein Endgerät versuchen eine Verbindungen zu einem anderen Gerät auf zu bauen?

Mein Modem antwortet stabil mit 1ms aber ich erreiche es auch nur auf seiner IP. Wer es via 192.168.0.1 erreicht, hat irgendeine statische Route oder sonst was drin.

Das Inteface hat eine statische IP konfiguriert. (192.168.0.2/30) um das Modem Web-Interface erreichen zu können + DHCPv4/6 für Internet.
Welche IP das Modem hat, kommt anscheinend drauf an welche Firmware und ob es online ist oder nicht. (192.168.100.1 / 192.168.0.1)
Benutzt dein Modem den OFDM Kanal?
Ist mein Modem Defekt?

Der Renew ist eher ein Bug von pfSense. Dazu gibts auch einen fix. Suche es heute Abend mal raus.

Danke!

 

[rv112]

Jedes Kabelmodem hat die 192.168.100.1 als IP. Deine Konstellation ist vermutlich das „Problem“.

Die CMTS und Modem aller Kunden im Segment, fragen sich regelmäßig ab. Die CMTS ist dabei nur ein DHCP Relay, das Gateway steht meist wo anders.

Ja ich nutze den OFDM.

 

[shm0]

Jedes Kabelmodem hat die 192.168.100.1 als IP. Deine Konstellation ist vermutlich das „Problem“.

Bei mir nur wenn das Modem nicht online ist.

Deine Konstellation ist vermutlich das „Problem“.

Denke nicht.

Modem aller Kunden im Segment

Warum sollte Modem A nach Modem B fragen?

Die CMTS ist dabei nur ein DHCP Relay, das Gateway steht meist wo anders.

Hmm...

RFC 2131 4.3.2

In this situation, the client is completely
configured, and is trying to extend its lease. This message will
be unicast, so no relay agents will be involved in its
transmission. Because 'giaddr' is therefore not filled in, the
DHCP server will trust the value in 'ciaddr', and use it when
replying to the client.

09:03:31.585452 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 381) 10.130.252.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 353, hops 1, xid 0x6e05fc76, Flags [Broadcast] (0x8000) Client-IP 95.222.171.* Your-IP 95.222.171.* Server-IP 81.210.129.* Gateway-IP 10.130.252.1 Client-Ethernet-Address 34:31:c4:8e:1c:50 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 10.130.252.1 Lease-Time Option 51, length 4: 7200 Subnet-Mask Option 1, length 4: 255.255.254.0 Default-Gateway Option 3, length 4: 95.222.170.* Domain-Name-Server Option 6, length 8: 80.69.96.12,81.210.129.4 MTU Option 26, length 2: 1500

Ich gehe davon aus das 10.130.252.1 der Relay ist? Sollte Server-ID Option 54 dann nicht die IP vom eigentlichen DHCP Server haben? (81.210.129.* ? muss dann natürlich auch erreichbar sein...)

 

[rv112]

Die 10er IP ist die interne Modem IP. Die 39.xxx... ist in BW Nord das Gateway. Die 172.xxx war bisher die CMTS DHCP Relay wurde nun durch eine Public IP ersetzt.

Die Modem fragen nach ihrer IP für sich. Du bekommst es nur auch mitgeteilt da Broadcast. Völlig unbedenklich.

 

[shm0]

Völlig unbedenklich.

Mag sein, generiert aber auch unnötigen Traffic.

Hab nen kleinen Patch geschrieben für udhcpc, so dass immer ein Broadcast benutzt wird.

udhcpc: started, v1.31.1
udhcpc: sending discover
udhcpc: sending select for 95.222.*.*
udhcpc: lease of 95.222.*.* obtained, lease time 4469
udhcpc: sending renew to broadcast
udhcpc: lease of 95.222.*.* obtained, lease time 7200

Sieht gut aus. Ist zwar nicht RFC konform aber naja.

 

[rv112]

Der Traffic (200-300 kbit/s) schlägt ja nur am WAN auf und wird verworfen. Klar, unschön.

 

[shm0]

Hab mal testweise ein anderes Gerät angeschlossen,
Latenz auch erhöht um 2-5 ms, schon eigenartig.

 

[rv112]

Häng doch das Modem mal direkt an einen Client und pinge die 192.168.100.1.

 

[shm0]

Hab ich probiert, hab aber die 192.168.0.1 IP getestet.
Teste nachher mal die 192.168.100.1.

Hab grad gelesen, unter Linux werden ARP Einträge 15 bis 45 sek gecached. Hab ich mal auf 30 min erhöht.
Gibt wohl die DHCP Option "35" (ARP Cache Timeout), aber keine Ahnung inwiefern die Clients das nutzen.

 

[shm0]

Die 192.168.100.1 bekomme ich nicht erreicht wenn das Modem eine Verbindung aufgebaut hat.
Ohne Verbindung ist die 192.168.100.1 erreichbar, aber auch hier ist die Latenz leicht erhöht.

root@cerberus:~# ping -c 10 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
64 bytes from 192.168.100.1: seq=0 ttl=64 time=1.797 ms
64 bytes from 192.168.100.1: seq=1 ttl=64 time=1.716 ms
64 bytes from 192.168.100.1: seq=2 ttl=64 time=1.697 ms
64 bytes from 192.168.100.1: seq=3 ttl=64 time=1.724 ms
64 bytes from 192.168.100.1: seq=4 ttl=64 time=1.717 ms
64 bytes from 192.168.100.1: seq=5 ttl=64 time=1.724 ms
64 bytes from 192.168.100.1: seq=6 ttl=64 time=1.658 ms
64 bytes from 192.168.100.1: seq=7 ttl=64 time=1.621 ms
64 bytes from 192.168.100.1: seq=8 ttl=64 time=1.637 ms
64 bytes from 192.168.100.1: seq=9 ttl=64 time=1.644 ms
--- 192.168.100.1 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 1.621/1.693/1.797 ms

Springt dann auch mal auf 3 oder 5 ms.

Die Sache bei DHCP ist halt, dass ist so nicht standardkonform.
Der Client versucht so lange per Unicast zu erneuern (T1, nach 50%, immer wieder) bis er irgendwann in den Rebind Status fällt. (T2 Timer, 87.5% der Lease Time.)
Keine Ahnung ob man die Relay Server so konfigurieren könnte, dass diese auch Unicasts weiterleiten,
falls es aus irgendwelchen Gründen für die Clients nicht möglich ist, den DHCP Server direkt zu erreichen.
Der Sinn eines Relays ist eigentlich nur, den Clients zu ermöglichen eine IP zu bekommen, wenn der eigentliche DHCP Server sich nicht im gleichen Segment befindet.
Hat der Client seine IP bekommen, sollte es ihm möglich sein, den DHCP auch direkt per Unicast zu erreichen.

Beim ARP Traffic kommt schon bisschen was zusammen...
10000 ARP Packets pro Minute à 46 Byte (wird auf 64 Byte erweitert, da Ethernet eine minimale Packet Größe von 64 Byte vorschreibt? )
= 640000 Byte / ~ 0,61 Mbyte
* 60 * 24 *30 / 1024
= ~ 25 Gbyte im Monat

Bei Cisco IOS Geräten liegt der ARP Cache Timeout bei 4 Stunden...
Aber RFC empfiehlt halt so niedrige ARP Timeouts, macht aber glaub ich nur Sinn bei MultiPath Setups, Umbebungen mit vielen virtuellen Hosts, oder so, denk ich...
Hab das Modem mal über das Webinterface resetet.
Hat gefühlt ewig gedauert bis es neu gesynct hat.
Jetzt lässt sich die 192.168.0.1 nicht mehr pingen, aber das Webinterface ist weiterhin unter dieser IP erreichbar.
Lag nicht am Reset. Sondern an der Netzmaske.
Mit einer /24 Maske ist kein ping möglich, mit einer /30 dagegen schon.

 

[sch4kal]

Beim ARP Traffic kommt schon bisschen was zusammen...
10000 ARP Packets pro Minute à 46 Byte (wird auf 64 Byte erweitert, da Ethernet eine minimale Packet Größe von 64 Byte vorschreibt? )
= 640000 Byte / ~ 0,61 Mbyte
* 60 * 24 *30 / 1024
= ~ 25 Gbyte im Monat

Du siehst da aber halt auch den ganzen ARP-Traffic vom Segment, und ~167 pps sind nicht viel.

 

[shm0]

Schon.
Muss aber nicht sein das der Gateway mit ARP Requests rumspammed oder?
Kann man da nicht was optimieren?
Bei IPv6 sieht es nicht viel anders aus:

tcpdump -i eth1.2 "icmp6 && ip6[40] == 135"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1.2, link-type EN10MB (Ethernet), capture size 262144 bytes
17:57:47.200592 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has fe80::ce35:40ff:fede:f05, length 32
17:57:47.833615 IP6 fe80::201:5cff:fe74:fc46 > ff02::1:ffde:f05: ICMP6, neighbor solicitation, who has fe80::ce35:40ff:fede:f05, length 32
17:57:48.740623 IP6 fe80::201:5cff:fe74:fc46 > ff02::1:ff83:d576: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:f936:57c:c583:d576, length 32
17:57:48.787607 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:65b8:c49d:9cb2:9d14, length 32
17:57:48.787840 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:5c7f:c7de:cd8f:a47d, length 32
17:57:48.788163 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:685d:9edb:aa99:930, length 32
17:57:48.788422 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:5493:b689:9903:83ab, length 32
17:57:48.788700 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:6430:d8ae:4f67:31be, length 32
17:57:48.788962 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:61e2:6fa7:a78b:7c85, length 32
17:57:48.789009 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:6159:79dc:99a5:11b1, length 32
17:57:48.789237 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:685d:9edb:f30c:7754, length 32
17:57:48.791938 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:519a:da17:6040:f30c, length 32
17:57:48.792689 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:648b:6af8:5ae1:9ed2, length 32
17:57:48.792718 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:f5fc:977e:97a1:e1dc, length 32
17:57:48.793074 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:61e2:6fa7:8351:c5a2, length 32
17:57:48.793125 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:65fb:60a0:448e:5312, length 32
17:57:48.793415 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:61c3:653c:1438:a140, length 32
17:57:48.793463 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:5c7f:c7de:9739:1232, length 32
17:57:48.793737 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:6430:d8ae:221f:d7c, length 32
17:57:48.794084 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:61c3:653c:4a8f:3499, length 32
17:57:48.794337 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:6159:79dc:6c5c:ed28, length 32
17:57:48.794822 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:f836:4579:488c:50a, length 32
17:57:48.795094 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:61e2:6fa7:8c60:3328, length 32
17:57:48.795335 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:6d31:e5cc:b87f:73e0, length 32
17:57:48.795647 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:503a:3e12:42a9:aa30, length 32
17:57:48.795995 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:6159:79dc:b4d0:5a2f, length 32
17:57:48.796252 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:59fe:742a:1f11:8154, length 32
17:57:48.796310 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:6159:79dc:abc1:ecc4, length 32
17:57:48.796508 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:6430:d8ae:a9f7:7b9c, length 32
17:57:48.796751 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:6430:d8ae:97da:a064, length 32
17:57:48.796991 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:8ce:8188:7f35:b3f0, length 32
17:57:48.797245 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:61e2:6fa7:5f18:f0b, length 32
17:57:48.797567 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:65fb:60a0:3271:77b1, length 32
17:57:48.797619 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:65b8:c49d:7878:e754, length 32
17:57:48.797935 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:648b:6af8:7f1b:55b3, length 32
17:57:50.560265 IP6 fe80::201:5cff:fe74:fc46 > ff02::1:ff9a:2d69: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:b5fb:dd88:ce9a:2d69, length 32
17:57:51.007005 IP6 fe80::201:5cff:fe74:fc46 > ff02::1:ff9a:2d69: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:b5fb:dd88:ce9a:2d69, length 32
17:57:51.210713 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:503a:3e12:aed3:dfc1, length 32
17:57:51.211409 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:519a:da17:f9b3:4c45, length 32
17:57:51.212679 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:503a:3e12:1ded:385, length 32
17:57:51.218331 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:6159:79dc:9922:20e7, length 32
17:57:51.230385 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:519a:da17:b13f:dec7, length 32
17:57:51.231140 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:58e2:ab66:e360:5a, length 32
17:57:51.231168 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:58e2:ab66:c834:b789, length 32
17:57:51.231697 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:6159:79dc:3583:69eb, length 32
17:57:51.231942 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:59fe:742a:279c:fe44, length 32
17:57:51.232222 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:519a:da17:2059:2a7, length 32
17:57:51.232483 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:503a:3e12:5443:959a, length 32
17:57:51.232734 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:58e2:ab66:76b2:db3e, length 32
17:57:51.232987 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:519a:da17:7ae9:4c29, length 32
17:57:51.233271 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:59fe:742a:42c8:47a6, length 32
17:57:51.233537 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:61c3:653c:2ee0:fac1, length 32
17:57:51.233820 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:4dc4:497c:55:bbbe, length 32
17:57:51.234080 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:519a:da17:8d06:2753, length 32
17:57:51.234130 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:519a:da17:174a:945f, length 32
17:57:51.234355 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:519a:da17:71da:ddf3, length 32
17:57:51.234597 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:5493:b689:e0f4:1d0, length 32
17:57:51.234845 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:4dc4:497c:55:bb6e, length 32
17:57:51.235083 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:503a:3e12:787d:4d1d, length 32
17:57:51.235347 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:4dc4:497c:9a4b:5a5, length 32
17:57:51.289574 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:9925:cbec:7ff6:7ec4, length 32
17:57:51.342557 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:9954:2c43:a908:3370, length 32
17:57:52.561176 IP6 fe80::201:5cff:fe74:fc46 > ff02::1:ff44:8b6d: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:4967:4994:4844:8b6d, length 32
17:57:52.760236 IP6 fe80::201:5cff:fe74:fc46 > ff02::1:ff58:be24: ICMP6, neighbor solicitation, who has fe80::1e3a:deff:fe58:be24, length 32
17:57:53.302033 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has fe80::4632:c8ff:fe42:4feb, length 32
17:57:53.375667 IP6 fe80::201:5cff:fe74:fc46 > ff02::1:ff83:d576: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:f936:57c:c583:d576, length 32
17:57:54.036459 IP6 fe80::201:5cff:fe74:fc46 > ip6-allnodes: ICMP6, neighbor solicitation, who has fe80::4632:c8ff:fe42:4feb, length 32
17:57:54.220268 IP6 fe80::201:5cff:fe74:fc46 > ff02::1:ff44:8b6d: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:4967:4994:4844:8b6d, length 32
17:57:54.361503 IP6 fe80::201:5cff:fe74:fc46 > ff02::1:ff83:d576: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:f936:57c:c583:d576, length 32
17:57:55.052654 IP6 fe80::201:5cff:fe74:fc46 > ff02::1:ff42:4feb: ICMP6, neighbor solicitation, who has fe80::4632:c8ff:fe42:4feb, length 32
17:57:55.776573 IP6 fe80::201:5cff:fe74:fc46 > ff02::1:ff58:be24: ICMP6, neighbor solicitation, who has fe80::1e3a:deff:fe58:be24, length 32
17:57:56.273972 IP6 fe80::201:5cff:fe74:fc46 > ff02::1:ff9a:2d69: ICMP6, neighbor solicitation, who has 2a02:908:a00:3:b5fb:dd88:ce9a:2d69, length 32
^C