Ervaringen topic Ubee EVW3200 WiFi-modemrouter Ziggo (Deel 2)

@ schouwenaarr:
Webteam Jelle zei:
De modem stuurt om de paar seconden een signaal naar onze centrale waarmee het signaal gecontroleerd worden. Vervolgens stuurt de centrale dit ook weer terug naar de modem. Maar lukt dit niet, doordat het signaal niet goed is, en gebeurd dit meerdere keren achterelkaar, dan wordt dit geregistreerd als een T3 time-out. Dit hoeft niet perse een probleem te zijn.

Meer dan een een paar per dag schijnt niet normaal te zijn, maar ook weer niet verontrustend. 1648 x T3 in 6 dagen is veel, maar als er bij jou werkzaamheden geweest zijn, dan kan gedurende die periode de T3 even opgelopen zijn.
 
Ik heb 4 dagen geleden (na zo'n 87 dagen onafgebroken online te zijn geweest) de modem maar eens even een schop gegeven. WLAN was erg onstabiel; apparaten met WLAN konden niet of nauwelijks verbinding krijgen en/of houden en de snelheid was te bedroefd om te beschrijven. De spreekwoordelijke trechter in de winter op Alaska, zullen we maar zeggen.

Vreemd, want als ik bedraad werkte (zoals met mijn iMac) dan was er geen vuiltje aan de lucht en had ik de volle 60Mbit/s om 6Mbit/s. Snelheden over WLAN liggen hier gemiddeld op ongeveer 30/6Mbps. Nu mocht ik over WLAN blij zijn met 1Mbit/s beide kanten op, en de throughput op het lokale subnet lag al niet veel hoger (de via WLAN aangesloten apparaten konden elkaar met zeer veel moeite zien, pingen ging met een horde aan time-outs en zo nog meer van dat soort symptomen. Wijzigen van het kanaal hielp voor zeer korte tijd, evenals het tijdelijk uit en dan weer aanzetten van de WLAN-functie.

Enfin, toen de stekker maar even van de stroom geplukt en na twee minuten (volgens de instructie van Ziggo) weer aangesloten. Na een redelijk lange tijd (vermoedelijk ivm een firmware-update, want ik heb nu ook de ZHS-firmware) kwam de modem op en heb nu wederom de gebruikelijke snelheden. Zowel bedraad (60/6) als over WLAN (~30/6).

Nu ben ik benieuwd of en zo ja wanneer dit zich weer voor zal doen… Ik heb zelf namelijk geen idee waardoor de WLAN interface van de modem zo volkomen verstopt raakte, zowel lokaal alsook naar buiten toe, terwijl de WAN- en de bedrade LAN-interfaces nergens last van hadden. Nu zijn hier weliswaar ongelooflijk veel WLAN-netwerken (kanaal 5 schijnt het minst druk te zijn op 2.4GHz), maar dat verklaart niet waarom het wijzigen van het kanaal werkelijk geen énkele invloed had… Overigens ondersteunt niet al mijn apparatuur de 5GHz-band, waardoor gebruik daarvan vooralsnog geen optie is (reden temeer waarom ik het jammer vind dat de modem niet gelijktijdig op beide frequenties kan zenden).
 
Begin Mei is Ziggo begonnen met de uitrol van firmware versie 9.9.5010. Dit lijkt de vorige versie met als extra een tabblad voor de Hotspots.
(Diverse Ziggo internet handleidingen zijn hier te vinden).

Forwarding

Omdat bij IP-v4 het aantal IP adressen beperkt is, krijgen apparaten achter een router een lokaal IP adres. Dit zijn geen unieke adressen die vanuit het internet opgeroepen worden. Wil je zo een apparaat van buiten je eigen netwerk oproepen, dan gaat dat via port forwarding. Je roept dan het IP adress van je routeer op met erachter het poortnummer dat je wilt gebruiken. In de routeer definieer je dan welke poort naar welk lokaal apparaat moet doorverwijzen.

Eén bepaalde poort kun je dus maar naar één bepaald apparaat doorsturen. Als op het interne netwerk twee apparaten dezelfde poort gebruiken moet je truukjes toepassen. Of je moet het apparaat op een andere poort laten werken, of je moet de poorten in de router omnummeren. Dit omnummeren is een nieuwe feature in de Ubee.

De Forwarding pagina ziet er nu zo uit:

Creating_Forwarding_rules_small_zps94ee4bc0.png


Vroeger waren het 10 fixed regels en een 11e was niet mogelijk. Als je veel forwardings had, ging het mis. Nu begin je met 0 regels en kunt er steeds een toevoegen. Ik heb geen idee wat het maximum is, maar heb er net even zonder problemen 15 gedefinieerd. Dit is in elk geval een verbetering. Als je een nieuwe regel wilt toevoegen, kies je de button "Create IPv4"

Je krijgt dan het volgende invul veld te zien:

Creating_Forwarding_rules_detail_zpsf9f88bdb.png


  • Local IP is het IP adres van je apparaat waar de verbinding naar toe moet.
  • Local Start Port is de eerste poort die je wilt aanspreken.
  • Local End Port is de laatste poort die je wilt aanspreken. Bij één poort zal dit hetzelfde zijn als de start poort.
  • External IP moet je op 0.0.0.0 laten staan. Vul je hier wel een adres in, dan krijg je alleen toegang vanaf dat externe adres.
  • External Start Port is de poort die je voor externe toegang gebruikt en dan doorverbind met de eerste interne poort. Doorgaans zul je intern en extern dezelfde nummers gebruiken, maar het hoeft niet.
  • External End Port zal al voor je ingevuld worden en moet in logische volgorde overeen komen met de interne volgorde.
  • Protocol: kies hier TCP, UDP of beide.
  • Description: Hier mag je alles invullen en dit is alleen een geheugensteuntje voor de gebruiker.
  • Enabled: Aan of uit zetten van deze regel.



Enabled : is dat niet het uit of aan schakelen van de functie.
Zie verschillende voorbeelden waarop hij op Off staat , en dus niet aan volgens mij.
 
Sinds mijn vorige bericht over het moeten herstart van de modem, heb ik deze nog 2x extra moeten herstarten na dezelfde problemen opnieuw te hebben ondervonden. Vóór de tweede herstart toch maar eens de kanaalkeuze voor WLAN teruggezet op Automatisch. Nu lijkt alles goed te gaan, maar echt veel kan ik er nog niet over zeggen: de eerste herstart na mijn vorige post was 12 dagen nadien; de volgende (2e) 5 dagen dáárna. Nu draai ik alweer bijna 9 dagen goed. Maar natuurlijk haalt dat 't nog niet bij de 89 dagen van een tijdje terug.

Let wel: dit ligt zeker níet aan de Ziggo-kant van het Netwerk of aan de internet-verbinding an zich, want zo lang ik geen gebruik maak van WLAN heb ik sowieso nergens last van. Alle bedrade verbindingen zouden dus in feite al sinds 25 maart (!) goed hebben gedraaid. Het inzakken van de snelheid doet zich puur en alleen voor op de WLAN interfaces van de modem; de overigen zijn niet beïnvloed.

Eén verklaring voor het wegvallen van de (snelheid op de) WLAN-interface zou simpelweg het aantal netwerken kunnen zijn dat hier op de 2.4GHz-band uitzendt: Er is werkelijk niet één kanaal echt vrij, met 3 en 5 als echte uitschieters — daar zijn 6 netwerken elk op actief. De overige kanalen hebben ook elk met 2 netten te doen, behalve 6 en 11 (1 net elk). Er is dus geen enkel kanaal waar mijn modem op z'n gemak kan liggen zenden. Dat móet haast wel interferentie teweeg brengen… Heeft er iemand misschien een tip om de overlast van die interferentie te verminderen? Overschakelen naar de 5GHz band zou ik maar wat graag willen, maar kan ik nog niet, omdat er apparaten in huis zijn die niet weten hoe ze daarmee om moeten gaan (en die geen bekabelde aansluiting kunnen hebben)… De 5GHz band zou anders dé ideale oplossing zijn, want daar zou ik zo ongeveer de enige zijn.

Ook zaken zoals folie tussen de modem en de muur hebben weinig zin: ik zit in een flat en bijna íedereen heeft draadloos netwerkoplossingen in gebruik, dus als de storing van één kant zou worden beperkt, komt-ie van andere kanten net zo hard door. Bovendien: het bereik van m'n netwerk is an sich goed; het gaat puur en alleen om onverwacht snelheidsverlies op de WLAN-interface. Oh ja: m'n zendvermogen (TX Power) staat op 100%; anders kom ik helemaal nergens meer…
 
Ik kwam er gister achter dat de Ubee nieuwe firmware heeft: versie 9.9.5011

In de menu's zag ik geen verschillen, dus zullen het alleen bugfixes zijn en geen nieuwe features. Tot nu toe heb ik één verbetering gevonden en wel in de firewall die de uitgaande mail blokkeerde. Nu worden beide beveiligde poorten ook in de hoogste firewall instelling doorgelaten.

SMTP 25 25 TCP
SMTP-S 465 465 TCP
SMTP-T 587 587 TCP

De bug met wifi inlog problemen als de Ubee geen dhcp verzorgt is er nog steeds. Ik zag wel iets anders vreemds. Ik heb dus gisteravond via de Ubee wifi proberen in te loggen met de nieuwe firmware. Toen dat nog steeds problematisch ging, ben ik weer terug gegaan naar mijn airport. Maar wie schetst mijn verbazing als ik op de eerste Ubee pagina mijn laptop zie staan als zijnde verbonden met Wifi? Ik ben echt voor het laatst 12 uur eerder maar een paar seconden ingelogd geweest. :cry:
 
ik heb die 9.9.0.5011 versie nu ook. wat mogelijk nog een "verbetering" is, is dat de semi-bridge mode die ik geconfigureerd had in een veel oudere fw het heeft overleefd, zelfs nu ik een geactiveerd wifi-spot heb. ik kan de semi-bridge instelling niet veranderen, de desbetreffende pagina is al gewijzigd in fw 9.9.0.5010 of eerder.
 
Ik kwam er gister achter dat de Ubee nieuwe firmware heeft: versie 9.9.5011
Dat viel me vrijdag ook op, ik heb vrijdagvan de monteur een nieuwe 3200 gekregen ipv de 3210 en toen zag ik meteen dat het 5011 was, terwijl de buren nog 5010 op hun 3200 hadden.

Gelukkig heeft 5011 niet dezelfde problemen geïntroduceerd als de nieuwe firmwares op de Cisco en de 3210 :mrgreen:
 
De enige cosmetische verbetering die ik gezien heb is dat de developers hebben geluisterd naar het marketing-team: Ziggo Hotspots heet nu keurig Ziggo WifiSpots. Overigens had ik op 11 Juli al een mailtje in m'n mailbox dat de dienst was geactiveerd (en ik heb ook een U/N en Pass ontvangen). Het werkt ook allemaal bij mij. Dit terwijl Ziggo aangeeft dat het in mijn woonplaats pas op 15 juli geactiveerd zou zijn. Volgens mij ben ik zelf trouwens ook nog (zo goed als) de enige geactiveerde gebruiker, want ik zie in de stad talloze ZiggoXXXX-netwerken, maar nergens het 'Ziggo'-netwerk (behalve bij mij in de wijk — mijn eigen modem en de modem van m'n buurman… Als ik vaker het 'Ziggo'-netwerk zie, zal het vast en zeker werken. Maar vooralsnog is het te vroeg om dat met zekerheid te kunnen zeggen…
 
Ik heb sinds een week of twee, drie ook de versie met hotspots en alles werkte
naar behoren, maar sinds een dag of twee lijkt het alsof uitgaande UDP berichten
niet meer werken/aankomen.

Op afstand (ergens op het internet) probeer ik de SQL Server van mijn werk
te benaderen vanaf huis, maar dat lukt ineens niet meer.
Ik zie de UDP connect-packets wel voorbij komen op mijn LAN, maar er wordt
vervolgens geen verbinding opgezet.

Lokaal of binnen mijn LAN een verbinding met een SQL-server instance opzetten
lukt nog wel gewoon.

Klinkt iemand dit bekend in de oren?

Groeten,

Peter.
 
Terug
Bovenaan