Irgendwie ist seit dem Update der Wurm drin...
Gefühlt dauert der Aufruf von Websites viel länger und vor allem in Social Media Videos wird ständig gebuffert und auch Youtube hat wahnsinnig Probleme mit scrollen durch Videos.
Total seltsam...
Habt ihr Tipps wie ich das am besten troubleshoote?
Erstmal im Dashboard die CPU- und Netzwerkgraphen begutachten, dann in der Firewall-Liveansicht nach ungewöhnlich vielem Rot suchen. Traceroute, dann iperf3 durch die Firewall schicken, Letzteres ist so ne Sache, weil man eine Gegenstelle braucht. Bandbreitentesttools/-Seiten probieren. Simples ping sollte ungewöhnlich hohe Latenzen offenbaren.
"Lahm" könnte auch von DNS kommen, gerade die beknackten asozialen Netzwerke seuchen mit Fremdservern=DNS lookups rum als gäb's nen Preis dafür. Ist ja auch klar, die zwingen Deinen Rechner ja, mit jedem Tracker der Welt Kontakt aufzunehmen, bevor auch nur das erste Nutzbyte gesendet wird. Und jeder davon macht erstmal den kompletten HTTPS-Handshake, allein dadurch wird's langsam. Hat aber alles nichts mit der Version zu tun, also kann allenfalls ein Startpunkt für weitere Tests sein.
Quote from: drosophila on March 12, 2026, 03:48:15 AMErstmal im Dashboard die CPU- und Netzwerkgraphen begutachten, dann in der Firewall-Liveansicht nach ungewöhnlich vielem Rot suchen. Traceroute, dann iperf3 durch die Firewall schicken, Letzteres ist so ne Sache, weil man eine Gegenstelle braucht. Bandbreitentesttools/-Seiten probieren. Simples ping sollte ungewöhnlich hohe Latenzen offenbaren.
Danke schon mal.
Das Dashboard sieht unaufgeregt aus, alles langweilt sich.
Traceroute spuckt mir das hier aus:
traceroute.jpg
Ich finde irgendwie keinen Server der beim iperf3 funktioniert....
Bufferbloat hab ich noch getestet:
https://www.waveform.com/tools/bufferbloat?test-id=5d7e4e7a-8044-4850-b83c-83f7154ea856
"Lahm" könnte auch von DNS kommen, gerade die beknackten asozialen Netzwerke seuchen mit Fremdservern=DNS lookups rum als gäb's nen Preis dafür. Ist ja auch klar, die zwingen Deinen Rechner ja, mit jedem Tracker der Welt Kontakt aufzunehmen, bevor auch nur das erste Nutzbyte gesendet wird. Und jeder davon macht erstmal den kompletten HTTPS-Handshake, allein dadurch wird's langsam. Hat aber alles nichts mit der Version zu tun, also kann allenfalls ein Startpunkt für weitere Tests sein.
[/quote]
hm naja das problem hatte ich ja vorher nicht und ich habe an meinen adguard einstellungen nichts verändert. DNS nutze ich übrigens standard o2
Ah was noch sein könnte, ich habe ipv6 deaktiviert, da das irgendwie immer meine logs vollgespammt hat und ich es nicht wirklich brauche?!
Bin aber der Meinung das habe ich bereits vor dem Update auf 26.1 gemacht und es lief alles normal...
Ganz generell: IPv6 deaktivieren wenn der Provider es halbwegs vernünftig liefert, ist eine Scheißidee. IPv6 ist das Internet. IPv4 ist "legacy" - Altlast. Je eher du dich daran gewöhnst, desto besser für deine Performance. IPv6 ist bei den berühmten "Ping Zeiten" immer vorne.
Da ist was dran und ich habs wieder aktiviert... War nichts weiter als unter System Configuration das Prefer IPv4 wegzuhaken und ich bin jetzt auf dem LAN Interface wieder auf Track Interface und dort aufs WAN gegangen.
Jetzt hab ich wieder v6 Adressen auf den Endgeräten, passt.
Nur noch ein nerviges Log, das spammt jetzt durchgehend
2026-03-12T22:55:39Warningradvdsendmsg: Network is down
2026-03-12T22:55:38Noticedhcp6cSending Solicit on pppoe0
2026-03-12T22:53:30Noticedhcp6cSending Solicit on pppoe0
2026-03-12T22:52:26Noticedhcp6cSending Solicit on pppoe0
2026-03-12T22:51:57Warningradvdsendmsg: Network is down
2026-03-12T22:51:54Noticedhcp6cSending Solicit on pppoe0
2026-03-12T22:51:41Warningradvdsendmsg: Network is down
2026-03-12T22:51:38Noticedhcp6cSending Solicit on pppoe0
edit: das Network is down kam nur von einem Interface in dem kein Kabel steckte.
Das Solicit bleibt, kommt jetzt aber seltener
Ja, IPv4 ist generell langsamer als IPv6, aber das sollte nicht so extrem sein, dass es das Originalproblem wäre. Und weil letztlich IPv4 irgendwann abgedreht werden wird, sollte man sich schon irgendwann mit IPv6 anfreunden, besonders, weil viele Provider nur noch DS-Lite ausspucken und wer sich da was hosten will, tut sich mit IPv6 auf Dauer wohl eher einen Gefallen, als mit Tunneln herumzubasteln. Das mit dem schwatzhaften IPv6 stimmt zwar auch, aber vermutlich wäre das bei IPv4 auch so, wenn das mit DHCP und dem ganzen anderen Autokonfigurationszirkus aufgezogen wird. Mich stören hauptsächlich die autogenerierten Adressen, da sehe ich nicht an der IP, welcher Rechner das war, was bei Logs IMO extrem wichtig ist.
Deine Pingzeiten sind zwar langsam, aber nicht so grottig, dass das allein das Problem sein sollte. Kannst Du den traceroute mal vom Client aus machen? So sieht man ja Deine OPNsense nicht. Die sollte deutlich unter 1ms liegen.
iperf3 bietet AFAIK keiner an, also falls Du nicht selber irgendwo einen Server laufen lassen kannst geht das nur im eigenen Netz. Also z.b. zwischen Client und Deiner Sensebox. Deshalb eher die Bandbreitenmessung machen und sehen, ob zumindest der Rohdurchsatz paßt.
@Patrick
Die Aussage "IPv6 ist das Internet und IPv4 nur noch Altlast" klingt zwar schön pointiert, ist technisch aber ein bisschen zu grob mit der Axt formuliert. In der Praxis läuft das Internet nach wie vor überwiegend im Dual-Stack, also parallel über IPv4 und IPv6. Selbst große Anbieter liefern Inhalte fast immer über beide Protokolle aus, weil ein erheblicher Teil der Netze weiterhin nur IPv4 oder nur eingeschränktes IPv6 hat.
Auch die pauschale Aussage zur Performance ist so nicht haltbar. Weder das eine noch das andere Protokoll ist per se schneller. Unterschiede entstehen fast immer durch die Providerarchitektur. Etwa wenn IPv4 über CGNAT oder DS-Lite läuft und deshalb einen Umweg macht. Dann kann IPv6 tatsächlich niedrigere Latenzen haben. In Netzen mit nativen IPv4-Routen sieht das aber oft genauso schnell aus.
Kurz gesagt: IPv6 ist definitiv die Zukunft und man sollte es sinnvollerweise aktiv nutzen, wenn der Provider es sauber liefert. Aber IPv4 als "Legacy, das eigentlich schon vorbei ist" darzustellen, ist aktuell eher Wunschdenken als technische Realität. :p Das sagt mir auch mein WAN Simulator im Lab.
Und ja, ich fand IPv6 schon damals in den Cisco/PA/... Trainings+Certs sch..... ;) Nebenher war 1981 ein großartiges Jahr. Nicht nur wegen IPv4 *g*
*duck und wech*
Zum Thema:
Wenn du prüfen willst, ob es wirklich langsamer geworden ist, ein paar einfache Checks:
=> Ping vergleichen: ping -4 und ping -6 auf denselben Host, Latenz und Paketverlust vergleichen.
=> Traceroute getrennt testen: traceroute -4 / traceroute -6, um unterschiedliche Routingpfade zu sehen.
=> Browser DevTools (Network-Tab): DNS-Zeit, TLS-Handshake, TTFB und Gesamtladezeit vergleichen.
=> curl Timing: curl -4 und curl -6 mit Timing-Output (-w), um Connect- und Transferzeiten zu sehen.
=> tcpdump auf der Firewall: schauen, ob Retransmits, ungewöhnliche Delays oder Path-MTU-Probleme auftreten.
=> Wireshark am Client: TCP-Retransmissions, Handshake-Zeiten und mögliche Paketverluste analysieren.
=> iperf3 im eigenen Netz: Durchsatz zwischen Client und Firewall bzw. zwei Hosts prüfen.
Also, ipv6 läuft jetzt parallel mit v4, macht soweit keine Probleme, aber an den "Ausfällen" hat sich nichts geändert
hier das Ergebnis von iperf
[ 5] local 10.10.100.39 port 57258 connected to 10.10.100.1 port 13619
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 116 MBytes 965 Mbits/sec
[ 5] 1.01-2.01 sec 113 MBytes 949 Mbits/sec
[ 5] 2.01-3.01 sec 114 MBytes 949 Mbits/sec
[ 5] 3.01-4.01 sec 112 MBytes 950 Mbits/sec
[ 5] 4.01-5.01 sec 114 MBytes 949 Mbits/sec
[ 5] 5.01-6.00 sec 112 MBytes 949 Mbits/sec
[ 5] 6.00-7.00 sec 113 MBytes 949 Mbits/sec
[ 5] 7.00-8.01 sec 114 MBytes 949 Mbits/sec
[ 5] 8.01-9.01 sec 113 MBytes 949 Mbits/sec
[ 5] 9.01-10.01 sec 113 MBytes 949 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.01 sec 1.11 GBytes 951 Mbits/sec sender
[ 5] 0.00-10.02 sec 1.11 GBytes 949 Mbits/sec receiver
iperf Done.
Ping v4
Ping wird ausgeführt für google.de [172.217.168.67] mit 32 Bytes Daten:
Antwort von 172.217.168.67: Bytes=32 Zeit=20ms TTL=115
Antwort von 172.217.168.67: Bytes=32 Zeit=20ms TTL=115
Antwort von 172.217.168.67: Bytes=32 Zeit=20ms TTL=115
Antwort von 172.217.168.67: Bytes=32 Zeit=21ms TTL=115
Ping-Statistik für 172.217.168.67:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 20ms, Maximum = 21ms, Mittelwert = 20ms
Ping v6
Ping wird ausgeführt für google.de [2a00:1450:4001:80a::2003] mit 32 Bytes Daten:
Antwort von 2a00:1450:4001:80a::2003: Zeit=14ms
Antwort von 2a00:1450:4001:80a::2003: Zeit=13ms
Antwort von 2a00:1450:4001:80a::2003: Zeit=14ms
Antwort von 2a00:1450:4001:80a::2003: Zeit=14ms
Ping-Statistik für 2a00:1450:4001:80a::2003:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 13ms, Maximum = 14ms, Mittelwert = 13ms
traceroute to google.de (172.217.168.67), 64 hops max, 40 byte packets
TTL AS# Host Address Probes
1 AS6805 loopback1.0005.acln.01.dus.de.net.telefonica.de 62.52. 7.104 ms
2 AS6805 ae14-0.0001.cord.01.dus.de.net.telefonica.de 62.53.11.48 6.377 ms
3 AS6805 ae12-0.0002.corx.01.dus.de.net.telefonica.de 62.53.0.152 21.192 ms
4 AS6805 bundle-ether14.0006.corx.01.muc.de.net.telefonica.de 62.53.2.58 15.991 ms
5 AS6805 bundle-ether3.0001.cord.02.fra.de.net.telefonica.de 62.53.14.138 12.227 ms
6 AS6805 ae1-0.0001.corp.01.ham.de.net.telefonica.de 62.53.12.35 14.014 ms
7 AS15169 142.251.202.24 142.251.202.24 21.075 ms
8 AS15169 192.178.106.11 192.178.106.11 19.468 ms
9 AS15169 142.250.46.68 142.250.46.68 11.943 ms
10 AS15169 216.239.57.7 216.239.57.7 16.509 ms
12 AS15169 209.85.245.31 209.85.245.31 32.188 ms
13 AS15169 209.85.252.215 209.85.252.215 20.193 ms
14 AS15169 lcfraa-bk-in-f3.1e100.net 172.217.168.67 14.149 ms
traceroute6 to www.google.de (2a00:1450:4001:81c::2003) from 2a02:3100:320b:9d39:6662:66ff:fe2f:f0a, 64 hops max, 28 byte packets
TTL AS# Host Address Probes
1 AS6805 2a02:3001::3c 6.626 ms
3 AS15169 2a00:1450:8463:300::1 9.733 ms
4 AS15169 2a00:1450:8463:300::1 12.089 ms
5 AS15169 2001:4860:0:1::26d6 14.092 ms
7 AS15169 2001:4860::c:4003:364e 10.056 ms
9 AS15169 2001:4860:0:1::8633 13.353 ms
10 AS15169 fra15s17-in-x03.1e100.net 14.406 ms
Mit Browsertools Chrome auf diese Seite
Resource Scheduling
Queueing 0,51ms
connection start
Stalled 0,64ms
DNS Lookup 6µs
Initial Connection 37,4ms
SSL 19,54ms
Request/Response
Request sent 0,25
Waiting for server response 124,28
Content Download 16,78
Gesamt 179,93ms
Curl von windows aus
C:\Users\Cottec>curl -4 -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nPre-transfer: %{time_pretransfer}s\nStart-transfer: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://www.google.de
DNS: 0.004837s
Connect: 0.034893s
Pre-transfer: 0.200168s
Start-transfer: 0.237188s
Total: 0.237502s
C:\Users\Cottec>curl -6 -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nPre-transfer: %{time_pretransfer}s\nStart-transfer: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://www.google.de
DNS: 0.004732s
Connect: 0.016850s
Pre-transfer: 0.042260s
Start-transfer: 0.073919s
Total: 0.074109s
Also diese Kiste "AS6805 loopback1.0005.acln.01.dus.de.net.telefonica.de 62.52. 7.104 ms" ist doch nicht Deine Sensebox, oder doch? Falls ja, ist die extrem langsam, außerdem müßte die eigentlich eine "private" IPv4 auf der Innenseite haben...?
Dein IPv4 Google-Ping ist auch deutlich langsamer als meins:
PING 172.217.168.67 (172.217.168.67): 56 data bytes
64 bytes from 172.217.168.67: icmp_seq=0 ttl=120 time=12.038 ms
64 bytes from 172.217.168.67: icmp_seq=1 ttl=120 time=11.616 ms
64 bytes from 172.217.168.67: icmp_seq=2 ttl=120 time=11.434 ms
64 bytes from 172.217.168.67: icmp_seq=3 ttl=120 time=11.569 ms
64 bytes from 172.217.168.67: icmp_seq=4 ttl=120 time=11.454 ms
64 bytes from 172.217.168.67: icmp_seq=5 ttl=120 time=11.551 ms
64 bytes from 172.217.168.67: icmp_seq=6 ttl=120 time=11.881 ms
Die längeren Pingzeiten könnten ggfs. "Langsamkeit" erklären, aber den Durchsatz bzw. das Puffern sehe ich dadurch nicht gefährdet. Was Du beschreibst klingt fast so, als liefe das ganze durch ein VPN wie TOR, da hat man gerne mal genau diese Effekte. Das wäre dann aber im Client konfiguriert, denn von Deiner Sensebox aus sieht es nicht nach VPN aus.
Schau mal nach, was z.B. https://www.breitbandmessung.de/test sagt, und parallel, wie das Dashboard sich verhält. Irgend einen Grund muß es ja geben, dass das seit dem Update so ist.
Quote from: drosophila on March 13, 2026, 10:27:23 PMAlso diese Kiste "AS6805 loopback1.0005.acln.01.dus.de.net.telefonica.de 62.52. 7.104 ms" ist doch nicht Deine Sensebox, oder doch? Falls ja, ist die extrem langsam, außerdem müßte die eigentlich eine "private" IPv4 auf der Innenseite haben...?
nee da ist ne IP, von meinem gateway,ich hab da hin und her editiert
QuoteDie längeren Pingzeiten könnten ggfs. "Langsamkeit" erklären, aber den Durchsatz bzw. das Puffern sehe ich dadurch nicht gefährdet. Was Du beschreibst klingt fast so, als liefe das ganze durch ein VPN wie TOR, da hat man gerne mal genau diese Effekte. Das wäre dann aber im Client konfiguriert, denn von Deiner Sensebox aus sieht es nicht nach VPN aus.
keine ahnung... ich hab nix geändert. wenn ein download läuft bleibt der auch stabil. nur dieses nachpuffern und social media ist käse.
QuoteSchau mal nach, was z.B. https://www.breitbandmessung.de/test sagt, und parallel, wie das Dashboard sich verhält. Irgend einen Grund muß es ja geben, dass das seit dem Update so ist.
da passiert quasi nix, die cpu last geht von 1 auf 2, keine extra speicherverbrauch
regeln hab ich auch nicht viele...
muss ich die eigentlich auch für v6 nachziehen? ich hab da mal so gar keine Ahnung von...
regeln lag.jpgregeln wan.jpgregeln guest.jpg
Quote from: cottec on March 13, 2026, 11:42:56 PMnee da ist ne IP, von meinem gateway,ich hab da hin und her editiert
Dann mach doch bitte wirklich mal einen vom einem Client aus, das allein wäre aufschlußreich: wenn man schon den Verdacht hat, daß die Box schuld ist, muß man sie wenigstens mittesten. Kannst die IPs auch komplett wegretuschieren, hauptsache, man sieht die Pingzeiten. Also in Windows eine Kommandozeile aufmachen (Ausführen -> cmd), und dann in dem schwarzen Fenster "traceroute www.google.de" eingeben.
Wg. IPv6: klar mußt Du dafür die relevanten Regeln kopieren oder auf IPv4+IPv6 stellen, aber erstmal das Problem loswerden, bevor man neue macht.
Wo ich Deine Regeln sehe: deaktiviere mal das ganze Zeug mit dem DNS. Schnelles DNS ist besonders beim anfänglichen Seitenaufbau entscheidend, und wenn Du im Browser ublock Origin, Noscript, + evtl. Decentraleyes laufen hast, passiert auch ohne Adguard erstmal nichts. Zum Testen muß man ja auch nicht gerade auf youtube oder sowas gehen. ;)
Quote from: drosophila on March 14, 2026, 05:55:21 PM]Dann mach doch bitte wirklich mal einen vom einem Client aus, das allein wäre aufschlußreich: wenn man schon den Verdacht hat, daß die Box schuld ist, muß man sie wenigstens mittesten. Kannst die IPs auch komplett wegretuschieren, hauptsache, man sieht die Pingzeiten. Also in Windows eine Kommandozeile aufmachen (Ausführen -> cmd), und dann in dem schwarzen Fenster "traceroute www.google.de" eingeben.
Ah sorry, das hatte ich falsch verstanden
C:\Users\Cottec>tracert google.de
Routenverfolgung zu google.de [2a00:1450:4005:803::2003]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms dynamic-2a02-3100-3d4c-8f00-6662-66ff-fe2f-0f0c.310.pool.telefonica.de [2a02:3100:3d4c:8f00:6662:66ff:xxxx:xxx]
2 7 ms 6 ms 6 ms 2a02:3001::4a
3 * * * Zeitüberschreitung der Anforderung.
4 11 ms 11 ms 11 ms 2a00:1450:8461:100::1
5 11 ms 11 ms 11 ms 2a00:1450:8461:100::1
6 10 ms 11 ms 11 ms 2001:4860:0:1::5006
7 13 ms 12 ms 13 ms 2001:4860:0:1::5b44
8 18 ms 19 ms 17 ms 2001:4860::c:4003:364f
9 * * * Zeitüberschreitung der Anforderung.
10 18 ms 18 ms 18 ms 2001:4860::c:4002:7868
11 18 ms 18 ms 17 ms 2001:4860::9:4001:ec0
12 17 ms 17 ms 17 ms ham02s15-in-x03.1e100.net [2a00:1450:4005:803::2003]
Ablaufverfolgung beendet.
C:\Users\Cottec>tracert -4 google.de
Routenverfolgung zu google.de [172.217.168.67]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms 10.10.100.1
2 7 ms 6 ms 6 ms loopback1.0001.acln.01.hid.de.net.telefonica.de [62.52.xxx.xxx]
3 7 ms 6 ms 7 ms bundle-ether36.0001.cord.01.hid.de.net.telefonica.de [62.53.11.164]
4 11 ms 11 ms 11 ms ae25-0.0002.corx.01.dus.de.net.telefonica.de [62.53.8.176]
5 15 ms 15 ms 15 ms bundle-ether6.0002.corx.01.off.de.net.telefonica.de [62.53.0.5]
6 12 ms 12 ms 12 ms bundle-ether2.0002.cord.02.fra.de.net.telefonica.de [62.53.28.151]
7 12 ms 12 ms 12 ms bundle-ether2.0001.corp.02.fra.de.net.telefonica.de [62.53.8.189]
8 13 ms 12 ms 12 ms 72.14.213.80
9 15 ms 15 ms 15 ms 142.251.65.75
10 12 ms 12 ms 12 ms 142.250.236.51
11 11 ms 11 ms 11 ms zrh04s15-in-f3.1e100.net [172.217.168.67]
Ablaufverfolgung beendet.QuoteWo ich Deine Regeln sehe: deaktiviere mal das ganze Zeug mit dem DNS. Schnelles DNS ist besonders beim anfänglichen Seitenaufbau entscheidend, und wenn Du im Browser ublock Origin, Noscript, + evtl. Decentraleyes laufen hast, passiert auch ohne Adguard erstmal nichts. Zum Testen muß man ja auch nicht gerade auf youtube oder sowas gehen. ;)
Also du meinst einmal adguard rauswerfen und dann testen oder wie?
Im Browser selber hab ich keine Tools
Ich hab an dem DNS Setup 0,0 geändert seit es lahm geworden ist...
Der Trace sieht einigermaßen normal aus bis darauf, dass der Server auf der Gegenstelle langsam ist, aber vielleicht ist das bei telefonica halt so.
Quote from: cottec on March 14, 2026, 11:27:55 PMAlso du meinst einmal adguard rauswerfen und dann testen oder wie?
Im Browser selber hab ich keine Tools
Ich hab an dem DNS Setup 0,0 geändert seit es lahm geworden ist...
Naja, ich sehe keine offensichtlichen Fehler, und bei irgendwas muß man ja mit Testen anfangen. :) Adguard und die DNS-Umleitung ist zwar nicht komplett ungewöhnlich, aber wenn es ein generelles Problem wäre, wären sicher schon mehr Hilferufe aufgetaucht. Und es mag ja durchaus sein, dass die neue Version anders mit derselben Konfiguration umgeht als die Alte. Es kann auch schlichtweg an sowas liegen, dass z.B. jetzt eine DNS-Anfrage gedroppt und nicht geblockt wird, und der Browser deshalb erst in einen Timeout laufen muß. Da ich derzeit meine Werbeblockierungen komplett clientseitig mache (eben über die o.g. Addons, die meisten anderen Programme werden komplett geblockt), kann ich zu Adguard und Pihole nicht allzuviel sagen. :( Vielleicht kann da aber jemand mit Nutzungserfahrung mal über die Regeln schauen; ohne Adblocker in die asozialen Netzwerke zu gehen ist ja keine gute Idee, aber wenn auch die OPNsense-Seite betroffen ist, kann man ja da testen, das sollte ja halbwegs sicher sein.
Ich endlich mal wieder, sorry, bin derzeit im Umzugsstress und hatte die Probleme hinten angestellt...
Jetzt ist mir allerdings etwas aufgefallen, das seit dem Update gar nicht mehr geht:
Meine Kaffeemaschine kann Bezüge auf die Plattform visualizer.coffee hochladen bzw konnte.
Das geht seit dem Update wohl nicht mehr.
Die Software der Maschine hat ein kleines Plugin (https://github.com/decentespresso/de1app/blob/74cacdcd2106f968c89c3a94c0fbcb615234913a/de1plus/plugins/visualizer_upload/plugin.tcl)zum hochladen.
Wenn ich die Bezugsdaten per Browser direkt auf die Webseite von visualizer hochlade, dann geht das auch. Es scheint also ein Problem in der Art und Weise zu liegen, wie das Plugin kommuniziert.
Wenn ich statt opnsense Wifi einen Hotspot per Handy auf dem Android Tablet der Kaffeemaschine benutze funktioniert alles wunderbar, die Konfig auf dem Tablet scheint also okay.
Ich hab mal testweise Adguard abgeschaltet, ansonsten benutze ich ja nichts...
Hab mal den Traffic mitgeschnitten (siehe Anhang)
Da geht ja irgendwas schief... ist das ein MTU/MSS Problem?
Könnte sein, zudem es anscheinend bei einer Paketlänge von 1466 Bytes auftritt. Wenn Deine Zugangsart PPPoE ist, hast Du nur eine Payload von 1492-40 = 1452 Bytes. Du kannst dann versuchen, entweder die "MSS" (eigentlich MTU-40) auf 1492 zu ändern oder, falls Du keinen Telekom-DSL-Anschluss hast, mittels Mini-Jumbo-Frames die MTU auf 1500 Bytes zu erhöhen (https://forum.opnsense.org/index.php?topic=45658.0).
es ist o2 pppoe DSL...
MSS ist auf den interfaces mit 1492 eingetragen...
Quote from: meyergru on May 14, 2026, 08:14:29 AMfalls Du keinen Telekom-DSL-Anschluss hast, mittels Mini-Jumbo-Frames die MTU auf 1500 Bytes zu erhöhen (https://forum.opnsense.org/index.php?topic=45658.0).
ich hab nen o2 Anschluss über ne Telekom Leitung...
Wo müsste ich das testen?
Beim pppoe device MTU 1500 eintragen und dann aus den Interfaces alles raus?
Ich habe die Anleitung doch verlinkt. Aber wenn es eine Telekom-Leitung ist, geht es nicht, auch das schrieb ich schon.
Quote from: meyergru on May 17, 2026, 08:14:15 PMIch habe die Anleitung doch verlinkt. Aber wenn es eine Telekom-Leitung ist, geht es nicht, auch das schrieb ich schon.
Alles klar, war mir nicht sicher, ob es da um die Leitung oder dann wirklich den Provider geht...
hast du ne Idee was es sonst sein kann?
Das schrieb ich in #15: Prüf, ob die MSS-Einstellung auf 1492 Bytes steht, was bei Deinem PPPoE das Maximum darstellt.
Quote from: meyergru on May 18, 2026, 11:14:16 PMPrüf, ob die MSS-Einstellung auf 1492 Bytes steht
Quote from: cottec on May 14, 2026, 07:46:31 PMMSS ist auf den interfaces mit 1492 eingetragen...
Screenshot 2026-05-19 202029.jpg
Screenshot 2026-05-19 202045.jpg
Fehler bleiben leider bestehen
Screenshot 2026-05-13 223906.jpg
Falls es an der MTU liegt, dann kann es auch sein, dass die Gegenseite nicht mit TCP-Fragmentierung klarkommt oder dass UDP verwendet wird.
Dein Skript läuft ja vermutlich auf irgendeinem Client, nicht auf OpnSense selbst. Kannst Du dort die MTU kleiner machen? Vielleicht funktioniert ja das MSS-Clamping auf OpnSense nicht korrekt. Tatsächlich weiß ich, dass das ganze MTU/MSS-Handling für IPv6 seit einiger Zeit nicht ganz wie erwartet arbeitet. Und visualizer.coffee hat auch IPv6-Adressen, die ggf. bevorzugt genutzt werden. Falls dort die PMTUD kaputt ist, müssen dann die Pakete schon an der Quelle längenbegrenzt werden. Ich würde sicherheitshalber mal mit 1400 Bytes probieren.
okay hab ich jetzt eingestellt mit WAN MTU 1400 und die anderen Interfaces MSS 1400
jetzt kriege ich bei mehr als 1344 ein "message too long"
ist das richtig so?
Screenshot 2026-05-22 234034.jpg
hilft das hier?
und by the way: was sollte man eigentlich schwärzen und was nicht? :D
Screenshot 2026-05-22 234706.jpg
Naja, klar. Wenn die MTU kleiner wird, sind auch weniger Nutzdaten möglich. Hier geht es doch darum, festzustellen, ob der Weg zu den betroffenen Sites eine Limitierung aufweist und Deine Seite darauf einzustellen, auch nicht mehr zu schicken, als möglich ist. Eine MTU von 1400 sollte im Internet jeder können, wenn es also auch nicht funktioniert, wenn Deine Clients nur das nutzen, ist die MTU nicht die Ursache.
Quote from: meyergru on May 23, 2026, 11:18:14 AMist die MTU nicht die Ursache.
Scheint so... Hast du noch ne Idee wo ich forschen könnte?
Normalizing?
NIC Firmware update?
Ist eine Intel I226-V in version 2.13 meine ich
Screenshot 2026-05-23 114630.jpg
Ich kann mir eigentlich nicht vorstellen, dass das das Problem ist. Auf manchen Boxen gibt es Probleme, wenn ASPM aktiv ist, das sollte man im BIOS abschalten. Was bei Dir passiert, sind offensichtlich TCP restarts. Das kann auch so etwas sein wie SACK, Window Scaling, RFC1323 und den verwendeten Algorithmus (CUBIC, NewReno) usw. Windows hat da etliche Parameter, die man setzen kann.
Es gab da früher mal Optimierungstools: https://www.speedguide.net/downloads.php , deren Anwendung ist aber heute nicht mehr zu empfehlen.
Neuere Tools sind da eher zu empfehlen, wobei Windows 11 25H2 schon wieder neue Parameter nutzt: https://www.golem.de/news/tcp-die-versteckte-netzwerkbremse-in-windows-10-und-11-2302-172043.html
Wenn man die Einstellungen unter Windows allerdings vergurkt hat, muss man das eventuell zurücksetzen, denn eigentlich sind neuere Windows-Varianten da schon ab Werk ganz gut.
Quote from: meyergru on May 23, 2026, 12:18:27 PMWindows hat da etliche Parameter
Sorry, wir sprechen hier von einem Android Tablet..
Und ich bin mir ziemlich sicher, dass das Problem eher durch das Update auf die 26.1 gekommen ist.
Vermutlich dann auch eher ne IPv6 Thematik...
Vielleicht das Interface selbst mal aus dem Legacy-Mode holen?
Quote from: trixter on May 28, 2026, 08:08:14 PMVielleicht das Interface selbst mal aus dem Legacy-Mode holen?
Ist das denn so falsch?
Ich scheine ja per DHCP auf dem WAN Adressen zu kriegen...
Hätte eh keine Ahnung wie ich sonst v6 einrichte um ehrlich zu sein...
Quote from: cottec on May 30, 2026, 08:38:29 PMHätte eh keine Ahnung wie ich sonst v6 einrichte um ehrlich zu sein...
Na dann würde ich erst mal Release-Notes lesen, bevor ich anfange zu meckern?
https://forum.opnsense.org/index.php?board=11.0
DHCP hat wenig mit dem Interface zu tun, das ist ein eigener Service..
Quote from: trixter on June 03, 2026, 10:55:04 AMbevor ich anfange zu meckern?
Sorry, wo hab ich denn gemeckert?
In den Release Notes lese ich das hier:
To accommodate the change away from ISC-DCHP defaults the "Track interface" IPv6 mode now has a sibling called "Identity Association" which does the same except it is not automatically starting ISC-DHCPv6 and Radvd router advertisements to allow better interoperability with Kea and Dnsmasq setups.Dann bleibt doch die Frage, was schlecht am automatischen von ISC-DHCPv6 und RA wenn ich noch nicht auf Kea oder Dnsmasg migriert habe?
Nur weil es mit dem Update Legacy wurde sollte man doch meinen, dass es weiterhin funktioniert?
lass mich raten, deine Netzwerkkarten kommen auch noch von Realtek?
Grundsätzlich gibt es zu wenige Infos von Dir, was du da gebaut hast.
Außerdem würde ich jede Legacy Einstellung hinterfragen, denn sonst fällst du beim nächsten Update auf die Nase, wenn aus legacy deprecated wird.
Quote from: trixter on June 05, 2026, 09:18:56 AMlass mich raten, deine Netzwerkkarten kommen auch noch von Realtek?
Grundsätzlich gibt es zu wenige Infos von Dir, was du da gebaut hast.
Außerdem würde ich jede Legacy Einstellung hinterfragen, denn sonst fällst du beim nächsten Update auf die Nase, wenn aus legacy deprecated wird.
Ich habs mir mal in die Signatur geschrieben ;)
Sind Intel I226-V NICs
Ja ich bin da bei dir, ich werde die Migration dann auch bei Zeiten machen, ich weiß nur jetzt schon, dass mich das vermutlich wieder mehrere Stunden und viele graue Haare kostet, das ist mitten im Umzug immer schwierig unterzubringen :)
Dann zieh doch erst mal in Ruhe um, bevor Du noch eine Baustelle aufmachst..
Dann würde evtl versuchen eine aktuelle Sense aufzusetzen und nicht alten Ballast mit zu schleppen.
ICS ist längst abgekündigt - wird Dir also nur Probleme machen.
Quote from: trixter on June 12, 2026, 09:04:49 AMDann zieh doch erst mal in Ruhe um, bevor Du noch eine Baustelle aufmachst..
Ja gut, ich könnte ja mit Snapshots immer wieder auf andere Stände zurückspringen. Muss halt lernen wie ich die Sachen migriere und bestenfalls kommt dann nix mehr :D
Ich muss vielleicht auch mal simpler anfangen und nur v4 checken, ob das auch schon Probleme hat.
Für mein Verständnis müsste doch da reichen, wenn ich unter Generel use V4 only oder wie das heißt aktiviere, oder?!