Downloadsnelheid veel lager via HTTP dan HTTPS

[Kevin-de-Groot]

Korte versie:
Het lijkt erop dat ik langzamer download over HTTP dan over HTTPS. Ik heb dit getest door een testbestandje van 2 GB te downloaden (via Google Chome) over HTTP en HTTPS en daar zag ik verschil.

Wat langere versie:
Ik heb vanavond Windows 10 opnieuw geïnstalleerd en sindsdien download ik erg langzaam. Ik heb Glas 600 (600 Mbit/s up- en download) van Caiway. Ik wilde vanavond Warzone en Rocket League installeren, Warzone via Battlenet en Rocket League via Steam. Beide games downloaden met maximaal 25 MB/s (dus 200 Mbit/s). Niet tegelijk, maar één voor één. Beide games tegelijk downloaden is helemaal drama.

Goed, ik dus een speedtest gedaan en dat gaf me afgerond 633 Mbit/s download en 626 Mbit/s upload. Met WiFi (5Ghz) kwam ik gemiddeld op 460 Mbit/s download en 460 Mbit/s upload. Dat lijkt me dus niet het probleem. Ik heb tevens met Caiway gebeld en zij zagen geen problemen.

"Nou, dat moet dan wel aan de servers liggen" dacht ik. Dus ik heb andere games gedownload via Steam, maar met hetzelfde resultaat. Ik heb geen idee of de games op dezelfde servers staan, maar goed.

Toen heb ik zo'n .bin-bestand van 2 GB gedownload via deze website van XS4ALL. Normaal gebruik ik een andere website, maar die was alleen beschikbaar via HTTPS en niet via HTTP.
Als ik het bestandje (genaamd "2gb.bin") download via de genoemde website (dus over HTTPS), dan zit ik vrijwel de hele tijd op 60+ MB/s (== 480 Mbit/s). Nog geen 600 Mbit/s, maar al veel beter.
Als ik hetzelfde bestandje download via HTTP (door de URL aan te passen) dan kom ik op maximaal 25 MB/s (== 200 Mbit/s), hetzelfde "limiet" als bij het downloaden van de games, zo lijkt het.
Het lijkt er dus op alsof het downloaden via Battlenet en Steam ook over HTTP gaan, ofzo. Ik heb verder geen tools als Wireshark gedownload om dit te bevestigen.

Overigens kwam ik erachter dat het downloaden van iCue ook met maximaal 25 MB/s ging, want ik zag dat dat via HTTP ging.
Het downloaden van bijvoorbeeld mijn chipset driver ging weer met 60+ MB/s omdat dat over HTTPS ging.
Overigens gebruik ik Google Chrome, maar ik heb het ook getest in (vergeef me) Edge, maar dat gaf hetzelfde resultaat.

Ik heb gedacht aan een defecte SSD. Ik heb nog geen uitgebreide test/check gedaan, maar de snelheden waren in ieder geval acceptabel (via Samsung Magician en AS SSD).

Hardware:

• Moederbord: Asus Maximus Ranger VIII met een Intel I219V netwerkcontroller
• Processor: Intel i7-6700K (niet overclocked)
• Werkgeheugen: Corsair 32GB (4x 8GB) 3.600 MT/s (maar momenteel op 3.200 MT/s)
• SSD: Samsung 970 EVO 1TB
• Netwerk: Modem > Netgear R7000 (router) > Switch (unmanaged) > Switch (unmanaged) > PC
• Bekabeling: CAT5e en een enkele CAT6

Note 1: twee switches achter elkaar is misschien niet het meest ideale, maar dit is nooit een probleem geweest. Op andere apparaten (na die tweede switch) doet dit probleem zich niet voor.

Note 2: Achter die tweede switch hebben we overigens nóg een Netgear R7000 die dienst doet als AP. Overigens is deze AP vrij recent (6 augustus) toegevoegd aan ons netwerk.

Bevindingen en informatie dusver:

• Downloaden via HTTPS gaat sneller dan via HTTP
• Andere browser heeft geen effect
• Andere apparaten hebben hier geen last van
• Via WiFi heb ik dit probleem niet
• Het probleem doet zich voor na een herinstallatie van (legaal) geactiveerde Windows 10 Pro, vóór de herinstallatie nooit problemen gehad
• Twee (of meer) downloads over HTTP kan niet, de bandbreedte (ca. 200 Mbit) wordt als het ware "verdeeld"
• Modem, router of PC herstarten heeft geen effect
• Ik heb verder geen software en drivers geïnstalleerd, het betreft een nagenoeg schone installatie
• Ik heb de firewall en Windows Defender uitgeschakeld, maar dit had geen effect
• Ik heb geen antivirus (en dergelijke) software geīnstalleerd
• Soms stopt de download van het .bin-bestand ook (met als melding "Netwerkfout")
• Ik heb hetzelfde geprobeerd in veilige modus met netwerkmogelijkheden, geen effect
• Ik heb alle (niet-optionele) Windows updates geïnstalleerd, geen effect
• Ik heb de driver voor de netwerkcontroller geïnstalleerd, geen effect
• Mijn provider (Caiway) zag geen problemen in de verbinding
• De PC aansluiten op de eerste switch (dus de tweede switch niet gebruiken) heeft geen effect

Wat ik nog ga proberen:

• Kijken of de SSD (deels) defect is
• Kijken of het werkgeheugen (deels) defect is
• Kijken of het probleem zich voordoet als ik de PC rechtstreeks op de router aansluit

Alvast bedankt voor het lezen/meedenken

Edit: irrelevante informatie verwijderd, opmaak aangepast zodat het bericht duidelijker is en makkelijker leest en extra bevindingen/informatie toegevoegd.

[ Voor 21% gewijzigd door Kevin-de-Groot op 11-08-2020 11:54 ]

[Nilltris]

Heb je antivirus software of een firewall draaien? Zou je voor de grap je Windows firewall eens uit kunnen zetten om te testen?

[Ben(V)]

Vrees dat het op een onleesbaar verhaal weinig hulp krijgt.
Nog nooit gemerkt dat een stuk tekst zonder nieuwe regels onleesbaar wordt?

[boyette]

Heb je hier al eens naar gekeken?

https://support.steampowe...le.php?ref=4166-TYSC-9690

[Mijzelf]

Het lijkt me dat er ergens Deep Packet Inspection plaatsvind. Als jouw PC het enige apparaat in het netwerk is die daar last van heeft, moet het op die PC plaatsvinden. Je zou eens kunnen kijken of je kunt zien dat een proces bij HTTP download meer CPU doet dan bij HTTPS.

[Kevin-de-Groot]

@Nilltris Ik heb geen antivirus draaien en de firewall had ik ook al eens uitgeschakeld. Na jouw reactie nog maar eens geprobeerd, maar nog steeds geen effect (dit heb ik tevens aan het bericht toegevoegd).

@Ben(V) Bedankt voor je kritische opmerking. Ik heb het bericht aangepast waardoor het hopelijk wat makkelijker wegleest. Ik heb het bericht even snel getypt en niet veel aandacht aan de opmaak gegeven. Het is een lang bericht, maar puur omdat ik wil vermelden wat ik wél (en niet) heb getest en wat mijn bevindingen dusver zijn. Zo kunnen we hopelijk veel "dubbele" opmerkingen, tips én vragen voorkomen.

@boyette Vóór jouw reactie heb ik er nog niet naar gekeken, simpelweg omdat dit nooit een probleem is geweest. Ik vermoed dat dat het probleem niet verhelpt, omdat het probleem zich ook voordoet in Battlenet en o.a. Google Chrome. Ik zal dit zometeen (binnen 30 minuten) even testen.

@Mijzelf Daar heb ik nog niet van gehoord. Ik zal dit zometeen (binnen 30 minuten) even testen.

Ik ga zo even Steam installeren (want die had ik niet meer geīnstalleerd), de instellingen nakijken en even kijken naar het CPU gebruik bij het downloaden via HTTP en HTTPS. Ik zal mijn bevindingen zometeen hier plaatsen.

Bedankt voor het meedenken

Edit: dat met Steam heeft geen effect. Ik heb gekeken naar het CPU gebruik en ik zag dat het CPU gebruik bij HTTPS juist hoger ligt dan bij HTTP.

Idle: 2% (met af en toe een piek van 3%)
Download over HTTP: ca. 10% (met af en toe een piek van 11%)
Download over HTTPS: ca. 15% (met af en toe een piek van 17%)

Ik heb bij het testen alleen de taskmanager en Google Chrome geopend (3 tabbladen).

Ook heb ik even getest op een oude laptop die ik hier heb liggen. Deze laptop heb ik bedraad aangesloten op de tweede switch, net als mijn PC. Downloaden via HTTP ging met maximaal 28 MB/s en via HTTPS werd maximaal 57 MB/s gehaald. Ook op die laptop lag het CPU gebruik van het downloaden via HTTPS hoger dan bij het downloaden via HTTP.

Daarna heb ik de PC rechtstreeks aangesloten op de eerste switch (dus de tweede switch zat er niet meer tussen), maar dit had geen effect.

[ Voor 25% gewijzigd door Kevin-de-Groot op 11-08-2020 11:53 ]

[Ben(V)]

Ik heb even een testje gedaan met dezelfde XS4ALL locatie en kon geen verschil in snelheid waarnemen tussen http en https downloaden.
Het ligt dus niet aan de server kant.

Heb je in chrome "enable parallel downloading" aan staan?

Probeer eens een test uit te voeren op je lan tussen twee PC bijvoorbeeld.

[Kevin-de-Groot]

Ben(V) schreef op dinsdag 11 augustus 2020 @ 11:52:
Ik heb even een testje gedaan met dezelfde XS4ALL locatie en kon geen verschil in snelheid waarnemen tussen http en https downloaden.
Het ligt dus niet aan de server kant.

Heb je in chrome "enable parallel downloading" aan staan?

Probeer eens een test uit te voeren op je lan tussen twee PC bijvoorbeeld.

Stond in de flags op "Default". Dit heb ik aangepast naar "Enabled", de browser opnieuw gestart, maar helaas geen effect.

Ik zag nog wel dat ik de LAN drivers heb geïnstalleerd (die ik van Asus heb gedownload). Normaal gesproken doe ik dat niet, maar ik moest toch wat testen. Die driver geeft me wat meer opties en informatie via apparaatbeheer (rechtermuisknop op het apparaat en dan "Eigenschappen"). Zie:



Bij de test results staat het volgende:

✔️ Cable Length Status : Passed
Cable Length: 18 meters

✔️ Cable polarity Status : Passed
Cable polarity normal.

✔️ Local Receiver Status : Passed

✔️ Remote Receiver Status : Passed

✔️ Cable Quality Status : Passed
Cable quality is excellent.

✔️ Cable Integrity Status : Passed
No cable problems detected.

✔️ Connection Status : Passed
Successfully pinged Gateway address 10.0.0.1

✔️ Cable Link Status : Passed
This adapter is running at full speed.

Ik denk dat ik die driver maar weer verwijder en gewoon de standaard Windows driver ga gebruiken, dat heeft het altijd gedaan. Ik las laatst ook iets over MSI moederborden, of eigenlijk de software ervoor. Daar zit iets in wat je downloadsnelheid drastisch omlaag gooit. Voor wat ik er mee doe lijkt software voor de netwerkcontroller mij overkill.

Een test op mijn LAN tussen twee PC's, bedoel je daarmee gewoon iets van data overzetten? Pingen naar mijn werk-laptop (MacBook Pro) geeft:

code:

Reply from 10.0.0.xx: bytes=32 time=172ms TTL=64
Reply from 10.0.0.xx: bytes=32 time=193ms TTL=64
Reply from 10.0.0.xx: bytes=32 time=1ms TTL=64
Reply from 10.0.0.xx: bytes=32 time=18ms TTL=64

Pingen naar die oudere laptop geeft:

code:

Reply from 10.0.0.xx: bytes=32 time<1ms TTL=64
Reply from 10.0.0.xx: bytes=32 time<1ms TTL=64
Reply from 10.0.0.xx: bytes=32 time<1ms TTL=64
Reply from 10.0.0.xx: bytes=32 time<1ms TTL=64

Pingen naar mijn NAS geeft:

code:

Reply from 10.0.0.xx: bytes=32 time<1ms TTL=64
Reply from 10.0.0.xx: bytes=32 time<1ms TTL=64
Reply from 10.0.0.xx: bytes=32 time<1ms TTL=64
Reply from 10.0.0.xx: bytes=32 time<1ms TTL=64

De tests die ik heb gedaan op een "oude laptop die ik had liggen" heb ik dus niet gedaan op de MacBook Pro, want deze heeft enkel WiFi.

Edit: tevens hier wat informatie over mijn netwerkadapter:

Naam: Ethernet
Beschrijving: Intel(R) Ethernet Connection (2) I219-V
Fysiek adres (MAC): -irrelevant-
Status: Operationeel
Maximale verzendeenheid: 1500
Snelheid van de verbinding (ontvangen/verzenden): 1000/1000 (Mbps)
DHCP ingeschakeld: Ja
DHCP-servers: 10.0.0.1
DHCP-lease verkregen op: dinsdag ‎11 ‎augustus ‎2020 12:08:00
DHCP-lease loopt af op: woensdag ‎12 ‎augustus ‎2020 12:08:00
IPv4-adres: 10.0.0.34/24
IPv6-adres: fe80::bd63:aecd:357e:fbfe%4/64
Standaardgateway: 10.0.0.1
DNS-servers: 10.0.0.1
DNS-domeinnaam: -
Achtervoegsel DNS-verbinding: -
Lijst met DNS-zoekachtervoegsels: -
Netwerknaam: Netwerk
Netwerkcategorie: Privé
Connectiviteit (IPv4/IPv6): Verbonden met Internet / Verbonden met lokaal netwerk

[ Voor 11% gewijzigd door Kevin-de-Groot op 11-08-2020 12:35 ]

[Ben(V)]

Drivers en netwerk optimalisaties zal je niets opleveren,op dat nivo werken ze voor http en https precies hetzelfde.

Misschien moet je even ipv6 uitzetten op die PC een dual stack wil nog wel eens problemen opleveren.

Wat ik bedoelde is op een andere PC in je lan een bestandje beschikbaar stellen via http en via https en die dan downloaden naar jouw PC.

Je moet dan wel een webserver opzetten dus effe doen is er niet bij als je die niet heb
Maar hier heb je dan wel wat aan.
https://developer.mozilla...up_a_local_testing_server

[Kevin-de-Groot]

Ben(V) schreef op dinsdag 11 augustus 2020 @ 12:50:
Drivers en netwerk optimalisaties zal je niets opleveren,op dat nivo werken ze voor http en https precies hetzelfde.

Misschien moet je even ipv6 uitzetten op die PC een dual stack wil nog wel eens problemen opleveren.

Wat ik bedoelde is op een andere PC in je lan een bestandje beschikbaar stellen via http en via https en die dan downloaden naar jouw PC.

Je moet dan wel een webserver opzetten dus effe doen is er niet bij als je die niet heb
Maar hier heb je dan wel wat aan.
https://developer.mozilla...up_a_local_testing_server

Ik heb enigszins goed nieuws, denk ik

Ik was toch even wat eten beneden en het leek me een goed idee om de PC maar eens naar beneden te sjouwen (vanaf zolder) om deze rechtstreeks op de router aan te sluiten. Het is een vervelende klus, maar wel het eenvoudigst om oorzaken uit te sluiten.

Even ter verfrissing: Modem > Netgear R7000 (router) > Switch 1 > Switch 2 > PC.

• Ik heb de PC net op Switch 1 aangesloten, zelfde probleem
• Daarna heb ik de PC op de router aangesloten, zelfde probleem
• Om alles uit te sluiten heb ik de PC daarna rechtstreeks op het modem aangesloten en toen deed het probleem zich niet meer voor

Dus we kunnen concluderen dat het probleem in de router zit. Ik heb e.e.a. anders ingesteld dan standaard, zoals de DHCP range, WiFi instellingen en volgens mij niet veel meer.

Ik zie in de logs (van de router en van de NAS) dat heel vaak wordt geprobeerd verbinding te maken met mijn NAS. Maar dat zal vast geen problemen veroorzaken, toch?
Verder zie ik in de log van de router ook deze regel: [DoS attack: FIN Scan] (1) attack packets in last 20 sec from ip [172.217.xx.xxx], Tuesday, Aug 11,2020 11:59:08, maar dan met een geldig IP-adres.

Ik ga eerst even in de router kijken wat ik even terug kan zetten. Mocht het niet baten, dan reset ik 'm wel gewoon. Bevindingen plaats ik hier z.s.m.

[lier]

Dus je werkt met dubbele NAT? Of krijgt je pc als deze met het modem verbonden is een publiek IP adres?

[laurens0619]

helemaal eens met @Mijzelf dit klinkt als DPI/QoS en dat zit meestal op het niveau van je router. JE laatste post doet dit ook bevestigen.

Ik zat even te lezen in de handleiding van je router en probeer het volgende eens uit te zetten:
- Circle Smart Parental Controls - Manage content and time online
- Dynamic QoS—Prioritizes network traffic by application & device
- Advanced features for lag-free gaming
- NETGEAR Armor™ - Advanced cyber threat protection for your home and all your devices
- Double firewall protection (SPI and NAT)
- Denial-of-service (DoS) attack prevention

Het liefst 1 voor 1 dat je kunt kijken waar het verschil maakt. Ik gok echter op QoS

Dat klinkt namelijk allemaal als zaken die een connectie door de CPU laten lopen. HTTPS kan een router niet in kijken dus dat verkeer negeert vaak al deze "security/optimalsiatie" protocols. HTTP kunnen ze wel in kijken maar als je CPU te zwak is dan zakt je snelheid in.

Kan overigens niets met de herinstallatie te maken hebben, misschien is het gewoon toeval dat het nu pas opvalt.

edit:
ik lees hier dat het ook te maken kan hebben met een firmware versie.
https://community.netgear...am-downloads/td-p/1836836

The most stable firmware version for the R7000 is .42

[ Voor 14% gewijzigd door laurens0619 op 11-08-2020 15:00 ]

[Ben(V)]

Dubbele Nat doet er eigenlijk niet toe.
Mijn mening over Netgear spullen waarschijnlijk ook niet.

Ook dat ik vind dat een eigen router zelden iets toevoegt en als dat zo zou zijn je dan eerder een (semi-)professionele router/firewall moet nemen en geen consumentenspul die over het algemeen van mindere kwaliteit is dan wat de providers leveren.

90% heeft ofwel Ziggo ofwel KPN en zowel de Connectbox als de Experiabox zijn prima modem/routers en van betere kwaliteit dan de gemiddelde consumenten spullen.
Plus dat ze support leveren bij problemen.

Verder helemaal eens met @laurens0619

[dion_b]

Een goede om uit te vogelen waar het aan zit: draai een webserver met afwijkende poortnummers:
80 voor HTTPS, 443 voor HTTP.

Als het probleem is DPI, dan volgt het verkeerstype ongeacht poort, is het probleem niet DPI dan zie je het gekoppeld blijven aan poort ongeacht verkeerstype.

De R7000 heeft een Broadcom router chip. Ik heb ooit op het werk een issue gehad met een BCM-based router uit vergelijkbare tijd (~2014) dat hardware acceleration per default uitgeschakeld stond voor poorten 80 en 8080. Alle verkeer op die poorten ging dus over de CPU ipv op line speed door dedicated hw, waardoor het significant trager was. Het schijnt iets te zijn dat in dagen van inbelmodems zinnig was (al heeft nog nooit iemand mij weten uit te leggen waarom...) en nooit verwijderd is, al is het ronduit contraproductief op een moderne verbinding.

[laurens0619]

Bovenbestaanden hebben wel een punt. Tenzij je een goede reden hebt om die netgear als router te draaien, zet dat ding in accesspoint modus (je weet al hoe getuigende je 2e netgear) en gebruik alleen de router van je provider. Scheelt een hoop gedoe (alhoewel oorzaak achterhalen via bv test van dion leuker is maar dat is mijn persoonlijke mening )

[ Voor 3% gewijzigd door laurens0619 op 11-08-2020 15:09 ]

[Kevin-de-Groot]

Excuses voor de wat late reactie, ben de hele tijd druk geweest. Ik heb onder andere weer gebeld met Caiway. Ze konden me nog steeds niet verder helpen.

@lier Ik heb een laptop rechtstreeks op het modem aangesloten en toen kreeg ik een intern IP-adres toegewezen. Althans, dat denk ik. Het was een 69.xx.xx.xx IP-adres. Sorry, ik heb het niet genoteerd, maar het was geen geen 169.254.xx.xx IP-adres. Op het modem(/router) staat dat ik kan verbinden met http://router, maar dat werkt dus ook helemaal niet. Ik ben toen naar het "Default Gateway IP-adres" gegaan, maar die deed het ook niet. Alsof deze functionaliteit bij ons is uitgeschakeld.

@laurens0619 Ik heb die functies nagekeken en de meeste had ik al niet eens ingeschakeld.
De optie "Poortscan en DoS-bescherming uitschakelen" (checkbox) is niet aangevinkt, dus dat kan ik nog proberen.
Bij de optie "NAT-filters" kan ik kiezen voor "Beveiligd" en "Open" en momenteel is "Beveiligd" nog geselecteerd. Dus dat kan ik ook nog proberen.
De optie "SIP ALG uitschakelen" is ook nog niet aangevinkt, dus dat kan ik ook nog proberen.
Ik heb eerder problemen gehad met firmware en heb toen bewust een hele lange tijd geen firmware upgrade gedaan. Dat heb ik vrij recent (minder dan 1 maand geleden) gedaan, maar toen is me niets opgevallen. Maar goed, toen hoefde ik ook niets te downloaden. Ik ga downgraden.

@Ben(V) Ik heb er nooit bij stilgestaan, eerlijk gezegd. Ik wist niet eens dat we mogelijk een modem+router hadden. Na veel testen en bellen met Caiway is het eigenlijk alleen maar onduidelijker geworden. Ik heb een laptop rechtstreeks op het modem aangesloten en dan zou ik verbinding kunnen maken met http://router, maar dat werkt dus niet.

@dion_b Ik zal een webservertje opzetten en dan eens testen met die poorten. Kan wel interessant zijn om te testen.

Oh ja, Caiway gaf aan dat ze een dubbele MAC-adres zagen. Kloont de AP-functionaliteit van Netgear het MAC-adres van de router? Volgens Caiway is dat vaak de oorzaak van dergelijke internetproblemen.

Ik heb met Caiway afgesproken dat er een monteur langskomt. Ik ben benieuwd, wat deze te zeggen heeft. We hebben in het verleden problemen gehad met de stroomvoorziening van het modem. We hebben toen een nieuwe adapter gekregen en toen werkte alles weer goed. Misschien is het weer zoiets.

In ieder geval bedankt voor de reacties. Ik ga nog even wat dingen testen en houd jullie op de hoogte.

[d22wth]

Ik heb zelf ook caiway en heb hier het nieuwste model Genexis Titanium modem, en heb hier achter een EdgeRouter X zitten waarmee ik gewoon de volledige snelheid behaal.
Ik gok dat deze modems uit de fabriek ook een router en WiFi functionaliteit hebben (want er is een WiFi symbool aanwezig op het modem) maar dat deze door caiway is uitgezet (en dus in bridge draait)

[laurens0619]

@Kevin-de-Groot ah dan lijk je in deze modus toch de router nodig te hebben. Je firmware upgrade van minder dan een maand geleden is dan wel een goede verdachte, benieuwd of de downgrade verschil gaat maken

[Kevin-de-Groot]

@d22wth Dat symbooltje heb ik ook gezien in de handleiding, maar die hebben wij er helaas niet op staan. Wij hebben een Genexis Hybrid Live! Titanium-22 (versie 1.1).

@laurens0619 Ja, ik denk dat een downgrade het meest logisch is. Ik ga dat sowieso vanavond niet meer doen, ik moet morgen gewoon weer vanuit huis werken (via het internet dus). Ik heb eventueel nog een oude WDR-4300 (als back-up), dus ik zou het morgen eventueel kunnen proberen.

Ik heb overigens steeds geprobeerd om het internet maar weer aan de praat te krijgen, dan maar langzaam downloaden. Want we hebben ook een IP camera op de kinderkamer. Maar ook dat lukte steeds niet. Ik heb de router verwijderd en de AP aangesloten (die is nu dus gepromoveerd tot router). Dat heeft even geduurd, maar ik heb weer internet. Langzaam, maar ik ben online.
Het zette me wel aan het denken.. Het probleem doet zich dus ook voor met de andere router (maar van hetzelfde merk en model). Dus het is waarschijnlijk geen hardware fout. Het moet dus eigenlijk wel aan de firmware (of een instelling) van de router óf aan Caiway liggen, toch?

Ik hoop niet dat de AP het MAC-adres van de router kloont. Caiway gaf aan twee keer hetzelfde MAC-adres te zien. Ik denk dat ik morgen de (voorheen) router aansluit als AP en dan met Caiway bel om te vragen welk MAC-adres dubbel voorkomt. Ik vind een AP toch wel erg prettig. Ik had eerst een WDR-4300 als "AP", maar die zat in een ander DHCP range. Dus apparaten van beneden (letterlijk: woonkamer) konden niet verbinden met de apparaten boven (letterlijk: zolder) en dat vond ik toch wel onhandig.

Morgen weer genoeg te proberen Voor nu wederom bedankt voor het meedenken

[ Voor 8% gewijzigd door Kevin-de-Groot op 11-08-2020 23:24 ]

[Luxicon]

Kevin-de-Groot schreef op dinsdag 11 augustus 2020 @ 23:20:
@d22wth Dat symbooltje heb ik ook gezien in de handleiding, maar die hebben wij er helaas niet op staan. Wij hebben een Genexis Hybrid Live! Titanium-22 (versie 1.1).

@laurens0619 Ja, ik denk dat een downgrade het meest logisch is. Ik ga dat sowieso vanavond niet meer doen, ik moet morgen gewoon weer vanuit huis werken (via het internet dus). Ik heb eventueel nog een oude WDR-4300 (als back-up), dus ik zou het morgen eventueel kunnen proberen.

Ik heb overigens steeds geprobeerd om het internet maar weer aan de praat te krijgen, dan maar langzaam downloaden. Want we hebben ook een IP camera op de kinderkamer. Maar ook dat lukte steeds niet. Ik heb de router verwijderd en de AP aangesloten (die is nu dus gepromoveerd tot router). Dat heeft even geduurd, maar ik heb weer internet. Langzaam, maar ik ben online.
Het zette me wel aan het denken.. Het probleem doet zich dus ook voor met de andere router (maar van hetzelfde merk en model). Dus het is waarschijnlijk geen hardware fout. Het moet dus eigenlijk wel aan de firmware (of een instelling) van de router óf aan Caiway liggen, toch?

Ik hoop niet dat de AP het MAC-adres van de router kloont. Caiway gaf aan twee keer hetzelfde MAC-adres te zien. Ik denk dat ik morgen de (voorheen) router aansluit als AP en dan met Caiway bel om te vragen welk MAC-adres dubbel voorkomt. Ik vind een AP toch wel erg prettig. Ik had eerst een WDR-4300 als "AP", maar die zat in een ander DHCP range. Dus apparaten van beneden (letterlijk: woonkamer) konden niet verbinden met de apparaten boven (letterlijk: zolder) en dat vond ik toch wel onhandig.

Morgen weer genoeg te proberen Voor nu wederom bedankt voor het meedenken

Dan pas je de DHCP range toch aan?

[Kevin-de-Groot]

Luxicon schreef op dinsdag 11 augustus 2020 @ 23:28:
[...]


Dan pas je de DHCP range toch aan?

Ik weet niet of ik de juiste term gebruik, maar de router gaf IP-adressen 10.0.0.x uit. De AP gaf IP-adressen 192.168.0.x adressen uit. Dit wilde ik wel wijzigen, maar dan kreeg ik een foutmelding dat de IP-adressen niet (of juist wel?) in hetzelfde subnet zaten.
Ik wilde graag dat de router bijvoorbeeld 10.0.0.10-10.0.0.99 zou uitdelen en de AP 10.0.0.110-10.0.0.199 en dat kon dus niet.
Toen kocht ik een tweede Netgear R7000 en die heeft een "speciale" AP-modus. Dit was voor ons echt de oplossing, alles werkte perfect. Tot ik Windows ging herinstalleren. Zal wel toeval zijn geweest, maar tot dat moment hebben we geen problemen gehad.

[Luxicon]

Kevin-de-Groot schreef op dinsdag 11 augustus 2020 @ 23:35:
[...]


Ik weet niet of ik de juiste term gebruik, maar de router gaf IP-adressen 10.0.0.x uit. De AP gaf IP-adressen 192.168.0.x adressen uit. Dit wilde ik wel wijzigen, maar dan kreeg ik een foutmelding dat de IP-adressen niet (of juist wel?) in hetzelfde subnet zaten.
Ik wilde graag dat de router bijvoorbeeld 10.0.0.10-10.0.0.99 zou uitdelen en de AP 10.0.0.100-10.0.0.199 en dat kon dus niet.
Toen kocht ik een tweede Netgear R7000 en die heeft een "speciale" AP-modus. Dit was voor ons echt de oplossing, alles werkte perfect. Tot ik Windows ging herinstalleren. Zal wel toeval zijn geweest, maar tot dat moment hebben we geen problemen gehad.

Heel precies kan ik er niet mee helpen, maar wel een idee geven.
Om een netwerk in orde te krijgen, moet de configuratie matchen. In dit geval 10.0.0.1 - 10.0.0.254. Dat is deze subet mask: 255.255.255.0. Ik denk dat je voor de router / AP verschillende subnet masks had ingesteld.

[laurens0619]

Ik gok dat je de 2e wifi router eerst via de wan poort had aangesloten op de centrale router. Je router krijgt dan op de wan kant een 10.0.0.x subnet wat je dan niet meer kunt instellen aan de lan kant. Dat is logisch, hij wil namelijk routeren tussen 2 subnetten wat niet kan als de subnetten hetzelfde zijn.

De truuk is, je moet stoppen met routeren. Dat kan soms met een speciale AP modus (dan mag de kabel in de wan poort blijven) maar DHCP uitzetten en alles op de lan poorten aansluiten is ook prima.

[HOWTO] Draadloze Router gebruiken als Access Point

[ Voor 43% gewijzigd door laurens0619 op 12-08-2020 09:17 ]

[Kevin-de-Groot]

Ladies and gentlemen... We've got him!

Het probleem lijkt te zijn verholpen. Helaas door iets wat ik véél eerder had moeten proberen: de firmware downgraden

@laurens0619 gaf in deze reactie aan dat de .42 goed zou moeten werken en die heb ik dus geprobeerd. Om precies te zijn (ook voor anderen die dit probleem hebben) draai ik nu versie V1.0.9.42_10.2.44 (de 10.2.44 is volgens mij de taal-versie) en die werkt weer goed.

Ik heb het slechts even getest (maximaal 1 uur), maar het lijkt allemaal in orde Het probleem lijkt me hierbij opgelost. Ik ga vandaag de firmware van de andere router (die dienst gaat doen als AP) downgraden en dan de AP configureren. En daarna kijken of ik de monteur nog kan afzeggen

Iedereen bedankt voor het meedenken

Edit: klein bewijsmateriaal

[ Voor 11% gewijzigd door Kevin-de-Groot op 12-08-2020 10:44 ]

[Kevin-de-Groot]

Oh, en die HOWTO had ik al meerdere malen gelezen voordat ik eraan begon, maar ik liep toch tegen wat problemen aan. Ik heb de kabel eerst in de WAN-poort van de AP gedaan, maar daarna in de eerste LAN-poort. Toch liep ik tegen problemen aan. Echter, dat was met onze oude WDR-4300, misschien gaat het anders bij de R7000. Nu de druk er wat van af is kan ik daar wat meer mee bezig

[laurens0619]

@Kevin-de-Groot mooi dat je het probleem gevonden hebt maar ik zou niet op een oude firmware willen draaien. Ik adviseerde het puur als test om de oorzaak te vinden. Als ik de changelogs bekijk dan zie ik dat ze verschillende security zaken gefixt hebben in nieuwere releases.

Nu je weet dat het de router/firmware is zou ik hem terugzetten naar de laatste versie en gaan klagen bij netgear. Als je daar niets uit haalt, het apparaat vervangen voor iets wat wel netjes blijft werken met de laatste firmware versie

[Luxicon]

Aangezien je nu andere hardware hebt, zal het niet meer uitmaken. Maar voor je oude router is OpenWRT beschikbaar, waardoor je wel een AP functie hebt. Ook is DD-WRT beschikbaar. Wie weet heb je er nog eens wat aan.

Verder eens met @laurens0619. Het is niet handig om te downgraden. Ik snap dat het prettig is, dat alles nu weer naar behoren werkt.

[ Voor 16% gewijzigd door Luxicon op 13-08-2020 18:18 ]