Ik heb hier iets vreemds aan de gang op geen van mijn computers in het netwerk werkt duckduckgo niet meer
sinds vandaag.
Ik kan wel pingen en traceroute werkt 30 hops maar geen verbinding naar duckduckgo.
Dus het lijkt mij geen firewall probleem.
Krijg alleen maar The connection has timed out.
Met een tor-browser werkt het wel.
Verder werkt alles gewoon.
Er is gisteren wel onderhoud aan mijn verbinding geweest, maar lijkt me sterk dat dat er iets mee te maken heeft.
De weg is wel korter geworden.
Zit nu op 15 hops in het laatste stuk.
De rest is gelijk aan @Noci
14 * * * Request timed out.
15 19 ms 19 ms 19 ms 52.142.124.215
Als je 30 hops hebt gehad, was er iets stuk in een laatste deel van de route, denk ik.
Als je niet in een paar hops bij Freedom bent, is het in Nederland wat mis gegaan.
Probeer’s op de commandline : curl -v duckduckgo.com
Puur om te zien of & waar dat - inhoudelijk - op uitkomt en eventuele upper-layers (browsers) te negeren.
Maak je ms gebruik van een proxy server en/of firewall ?
Los daarvan, code 35 duidt doorgaans op een (verouderde) cURL versie die - in geval van https - al of niet verkeerde certificaten hanteert en dan wordt gecanceld.
Wat ik zelf in deze situatie(s) doe is een maagdelijk Linux (Live Ubuntu boot bv) gebruiken om mogelijk zelf veroorzaakte issues uit te schakelen.
TTL/hopcount wordt hier uitgebreid uitgelegd: Time to live - Wikipedia
traceroute en tcptraouceroute op poort 80 of 443 zijn heel verschillend werkende
varianten, traceroute hetzij ICMP (windows) of UDP (unix) gebruikt terwijl tcptraceroute TCP/SYN pakketen gebruikt.
Moderne omgevingen routeren packet verschillend op poort niveau. naast IP adres.
cURL gebruikt in de kern de systeem certificaten.maar kan andere gebruiken.
Zijn de certificaten nog up to date is de openssl Stack nog bij de tijd.
TLS 1.2 is nu minimum, binnen afzienbare tijd zal TLS v1.3 het minimum worden. (ook voor duckduckgo).
(curl --tls-max 1.2 https://duckduckgo.com …)
curl -v https://www.duckduckgo.com > /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:–:-- --:–:-- --:–:-- 0* Trying 52.142.124.215:443…
Kernfout blijft zitten in die error-code (35) die zou duiden dat het uitwisselen van certificaten niet goed/gaat.
kweet niet of dat al is gezegd/getest, maar krijg je dat op ook op (totaal) andere systemen in je netwerk ?
Zet/start bvk ergens Live-CD aan om dat te checken.
NB: Hierna , mits je weet hoe, kan je overwegen om met die Live-CD, rechtstreeks een PPPoE verbinding proberen te leggen om zo alles wat bij jouzelf zit als oorzaak uit te zetten. Denk je eigen media/router, die je eventueel als test kunt factory resetten.
Verder popt bij mij de vraag op wat voor media/router je gebruikt omdat je TOR-browser - dat via andere poorten gaat - nl. wel zou werken. Niet ondenkbaar is dat in die “router” een bit is gaan hangen.
Dat snijdt geen hout.
Het modem kan niet selectief duckduckgo sessies mollen. (onder normale omstandigheden).
Als het modem defect is waarom werken andere sessies nog wel.
wat is de datum van /etc/ssl/certs/ca-certificates.crt
(of eigenlijk van elk van de certificten die er in staan…)
Er zijn de afgelopen 2 jaar een hoop certificaten van CA’s vervallen en vervangen. (voor exemplaren met een latere datum).
Ook zijn er enkele CA’s definitief afgevoerd en andere nieuwe erbij gekomen. (letsencrypt heeft een andere keten van certificering bv.).
2 minuut 30 is een rare periode. 2 minuten zou TCP connect tijd zijn,
Zijn je eigen libraries op orde voor TLS v1.3, het wordt steeds breder ingevoerd, en TLS 1.2 zal langzamerhand ook verdwijnen.
(Redhat 7 en afgeleiden doen niet aan TLS v1.3), daarvoor is RH 8 e.v. nodig.
@mario
Zou dit een MTU issue kunnen zijn?
Kijkend naar je curl output dan stuur je wel je client hello uit, maar krijg je nooit een server response. De eerste response is meestal groot (cipher lists, certificaten, enz) die de volledige MTU gebruikt. Van pppoe is ook bekend dat het vaak dit soort dingen veroorzaakt. Zelf had ik daar ook last van toen ik van mijn vorige modem met pptp tunnel naar mijn huidige vigor 130 met pppoe ging.
Als dit het is kan je dit simpel testen door tijdelijk even de mtu van je pc naar beneden te zetten, doe maar even vrij grof nar 1400 ofzo. Als het dan wel werkt is het bingo,
De meest gebruikte workaround is om dan op de router een feature te gebruiken die de MSS van tcp aanpast naar de MTU, vaak mss-clamping genoemd. Als je die aanzet zou het automagisch goed moeten komen zonder aanpassingen op je PC.
@mario,
op glasvezel kabels (en mogelijk ook DSL) zou je kunnen proberen om de MTU op de WAN poort op 1508 (mini-jumbo) frames te zetten.
Dan is er ruimte voor ppp headers op het WAN zonder de MTU1500 van je LAN aan te hoeven passen. (MSS clamping maakt alle TCP packetten 8 bytes korter), dat is beter dan fragmentatie maar als iedereeen 1500 aankan is dat wel zo makkelijk.
Freedom staat je hier niet in de weg, alleen een mogelijke bekabelaar.