IP-nummer för CG3100 i bryggat läge.

Då jag själv ofta glömmer bort vilket ip-nummer CG3100 från comhem har när man bryggat det tänkte jag att fler kanske drabbas av samma problem. IP i bryggat läge är 192.168.100.1

Säkerhetsproblem med wlan som använder WPS.

WPS, Wi-Fi Protected Setup, är en teknik för att enkelt kunna ansluta sig till WPA2-nätverk. Antingen med hjälp av en pinkod eller genom att man trycker på en knapp på accesspunkten och sedan på sin enhet.

Som vanligt när det gäller säkerhet brukar enklare också betyda osäkrare. Till att börja med använder många routrar samma standardpinkod, vilket gör att du kan komma in i nätverket oavsett vilken WPA-nyckel som används.

Det har också kommit ett verktyg som kan knäcka pinkoden inom ett par timmars tid. Lösningen är att stänga av WPS, men hos vissa tillverkare går funktionen inte att stänga av och ibland fortsätter den att vara aktiverad, fastän den är avstängd.

Bland de drabbade routrarna hittar vi föga förvånande CG3100 från Comhem. Comhems lösning på problemet är att gå in och ändra inställningarna i sina kunders modem och regelbundet bevaka inställningarna i dem. Att detta skulle kunna kännas som ett intrång i kundernas privatliv är inget som bekommer dem.

Källor:
IDG - Comhem: stort säkerhetshål drabbar 140000 kunder.
reaver-wps - Brute force attack against Wifi Protected Setup
Comhem: säkerhetsproblem i ett av våra modem

CG3100 i bridge mode

I mitt föregående inlägg testade att CG3100 i NAT-läge och mätte antal anslutningar samt responstid. Jag har nu även testat med bridge-läget samt använt ytterligare en maskin för att mäta responstiden mot modemet lokalt.

Mätresultaten visar att CG3100 orkar 150 anslutningar i bryggat läge. Lokalt stiger responstiden mot modemet från 1ms till 20-25ms och packet loss ligger på runt 10%. Låt mig upprepa det, 25ms och 10% packet loss lokalt.

För att tillhöra en tjänst som prissätts 400-500kr i månaden är det under all kritik att ha ett modem som inte hanterar fler anslutningar och ger packet loss och hög responstid innan du ens kommit ut mot internet.

Prestanda med Netgear CG3100

CG3100 är ett kabelmodem från Netgear, detta modemet använder Comhem framförallt till sina 100mbit- och 200mbit-tjänster. Jag har länge varit nyfiken på hur många anslutningar CG3100 klarar av pålitligt men även hur modemet fungerar under hög last.

För att mäta detta satte jag upp en testmiljö. Normalt är det inga problem att mäta lokalt, men i och med att det är ett kabelmodem var jag tvungen att sätta upp en mätserver på internet.

Testsystem
CG3100-modemet körs med mjukvara v0028 i NAT-läge. Det som är ändrat från default-inställningarna är att tjänsterna och wlan är avstängt, samt att ett par portar har öppnats för testet.

Min testserver på internet består av en OpenBSD-maskin med gigabitlänk och mot modemet sitter en Linuxmaskin ansluten med 100mbit direkt mot CG3100.

Jag låter OpenBSD-maskinen starta 500 TCP-instanser av iperf och mäter antal anslutningar samt ping mot modemet. Då jag kör 100mbit mellan modemet och testmaskinen kan jag tyvärr inte mäta packet loss tillförlitligt.

Resultat
Vid försök på 500 anslutningar stannar modemet vid exakt 120 anslutningar och håller sig där konstant. Överföringshastigheten är då på 11.5MB/s vid en intern snittping mot modemet på 47ms.

Med v0028 fryser inte modemet som med tidigare firmwares utan klarar sig stabilt i över 1.5 timmar, då jag väljer att avsluta testet.

Sammanfattningsvis kan man säga att modemet håller den utlovade hastigheten, men det är också allt. 120 anslutningar är inte mycket och att gå från ~1ms till ~47ms under last är på tok för mycket.

Testmedotik:
iperf körs i TCP-läge, klienten (maskinen som skickar data) startas med
for i in $(jot 100) ; do iperf -c hostname & done

Servern (maskinen som tar emot data) körs med
iperf -s

Anledningen till att inte -P flaggan används är att den inte fungerar pålitligt nog och inte verkar fungera alls under OpenBSD som testservern kör.

Överföringshastighet mäter jag med programvaran slurm. slurm -i eth0

Antal anslutningar mäter jag med snmp-datan i proc.
cat /proc/net/snmp | tail -5 | head -1 | awk '{print $10}'
Detta kommandot fungerar fint med min konfiguration, men för andra konfigurationer rekommenderar jag att du tittar på hela outputen från cat /proc/net/snmp.

Responstid mäts lokalt med ping mellan Linuxdatorn och modemet, ping 192.168.0.1. Jag lät 500 paket sätta snittvärdet.

Packet loss med Comhem

I dag har jag efter många supportsamtal fått hit en tekniker från Comhem. Har haft problem med packet loss på min 100/10-tjänst samt dålig TV-bild på vissa kanaler i analogutbudet.

Vägguttaget för bredband/TV byttes mot en nyare modell med galvanisk avskiljare. Rent visuellt står uttaget ut mer och kontakterna är vinklade mot golvet istället för att stå rakt ut som på de äldre uttagen.

Efter att uttaget var bytt användes ett mätinstrument som visade att brusnivåerna hade sjunkit. I modemets konfigurationssida kunde man också se bättre signalvärden. Hastigheten med bredbandskollen förblev däremot oförändrad. Huruvida problemet med packet loss är helt löst av uttagsbytet vet jag inte säkert, problemet är intermittent, men nu 8 timmar senare har jag fortfarande inte lyckas mäta upp några tappade paket.

TV-bilden blev också något bättre, men är fortfarande inte bra. Tills vidare var teknikern snäll nog att kontaktera om min kabel bättre och gav mig rådet att gå till en parabolbutik och köpa välskärmad koaxkabel gjord för parabol men att be om att få den kontakterad som antennkabel. Då bilden blivit bättre när jag tidigare bytt till en kortare kabel kan detta mycket väl vara lösningen.

En annan bonus med det nya uttaget är att jag inte längre behöver dra ur antennkabeln för att slippa 50Hz-brus i stereon (TVn är kopplad till stereon). Själv hade jag utgått jag från att det störningen berodde på att min TV jordade sig via kabel-TV-uttaget och detta gav upphov till brus, men teknikern påpekade att det lika gärna kunde komma in brus via antennuttaget från grannarna. Egentligen inte särskilt underligt, men man utgår gärna från att problem är självförvållade innan man börjar skylla på andra.

Comhem skriver själva att galvanisk avskiljning minskar brandrisk på jordade tv-apparater och minskar störningar. Vad jag funderar över är varför deras koaxkabel som följer med modemen inte har galvanisk avskiljare.

Uppdatering:
Vad gäller TV-bilden har jag prövat med två olika TV-apparater och även med olika antennsladdar, bilden är fortfarande dålig på vissa kanaler, så problemet måste ligga hos Comhem.

Comhem har tagit bort sin FAQ kring galvaniska uttag, men jag låter länken ligga kvar som en referens.