I was asked to investigate a weird issue with an Apple Mac Book-laptop, which was loosing connectivity to the dd-wrt network. After some investigation I found that iPhone 4 (and 5) had a known issue with loosing connectivty with dd-wrt routers. The fix however was to tweak 3 settings. Under advanced settings:

Beacon Interval should be lowered to 50 ms from 100 ms.

Fragmentation Threshold should be lowered to 2304 from 2346.

RTS/CTS Threshold should be lowered to 2305 from 2347.

These tweaks solved the issue – and now the apple products are all happy on the WDS-wifi-network.


I have during the last few years been deploying quite a few Ubiquiti antennas – which has been performing really great over 1 km and has been really satisfiering. The two radios I have been deploying are Ubiquiti Pico-station M2 (with external antennas) and Ubiquiti Nano-station M5. The radios are performing okey – which means that the M2-chain is performing with around 40 mbit duplex (1×1 chain – which means a max of 150 mbit half duplex). And the Nano-Station are performing with 90 mbit full duplex (could run 150/150 – but I decided to decrease bandwidth to 90/90 mbit in order to achive less jitter and more stability). Anyway the jitter part has been the biggest problem – especially with video-streaming. I therefore went to ubiquiti’s webpage http://ubnt.com – where I noticed some new AC-products which sounds really promising.

The one of the upgrades was the new Rocket AC. The old rocket was a 2×2 radio with 2 external-antenna terminals. The radio has never been in my interrest – mostly because the only external antenna setup I have been running is 2.4 ghz. The primary upgrade going from the Rocket to the Rocket AC is the fact that the AC standard now makes the radios capable of 450 mbit half duplex.

The second of the upgrades was the new Nanobeam AC – which is more interresting to me. Mostly because I have noticed way better performance with radios with integrated directoral antennas. And these antennas would therefore upgrade my existing setups. But as written above my biggest concern isn’t bandwith – more stability and quality. Therefor its really interresting that Ubiquiti now have released new chip-technology named AirPrism. Ubiquity claim that AirPrism improves latency and noise-immunity. The only reason I’m a bit sceptical about AirPrism is that I faced some troubles with AirMax some other Ubitquiti-technology, which actually just added latency to my point2point setup. Later on I figured out that AirMax made most sense if you deployed more radios on same frequency in the same tower, which wasn’t my scenario. Anyway – the new AC technology sounds compealing – and I might in future deploy some of these new nanobeam “motherfuckers” 🙂

The AirFibre-products also have been upgraded, but sadly these units are too expensive for my budget – and too big to deploy on a regular house. They are however nice indeed (1.4 gbit) – and if I never go’ to buy a Ferrari – then the money might be well spend. 😉 Read more about the new awesome products on Ubiquiti’s webpage: http://www.ubnt.com/airmax/airmax-ac/


A new awesome networktuner is soon shipping from Silicondust. The tuner is a part of a new series of tuners, which have tc instead of hr in the modelnumber. Where HR was stranding for high resolution, the TC stands for transcode. The new modelnumber of the HdHomerun Plus is therefore HDTC-2EU for the European market and HDTC-2US for the US market. The awesome thing about this tuner compared to earlyer models is the transcoding. Where older models only had the mpeg2 stream to send to recievers the new tc- models are able to transcode the mpeg2 stream into mpeg4 h264. The high compression on h264 makes the tuner much better in wireless environments, since the design of h264 – which is less prone to packet jitter etc. This should make it possible to stream tv through dlna in wireless point2point setups, which is known to cause problems with the mpeg2 streams. I have already preordered mine.. – And can’t await the pick-up. Maybe you also should preorder yours 🙂



Maybe you have been facing the same problem as me, when trying to install teamviewer 9 on you Arch Linux distribution. The problem was quite weird. I installed teamviewer9 via Yaourt. Fixed some dependencys and reinstalled. After this I could open teamviewer 9, but I wouldn’t be able to login – and an error message in the bottom was saying: “No connection available – check connectivity”. I have been googling about it – and a dude said that he fixed some problems in Suse-linux by chmod 770 some files. This indicated a permission problem and I decided to download the tar.gz from teamviewer.com

I extracted the files in my home-dir and ran the ./tv-setup –checkdeps – everything was fine.

I then executed the teamviewer by ./teamviewer – and fun enough everything worked.

I then decided to copy everything from my home-folder/teamviever9-folder to /opt/teamviewer9 – expecting that everything now would work – since it worked in my home-folder. Apparently this made no difference. So I finally chown’ed the folder /opt/teamviewer9 to my home-user. And Woila – everything worked. It has been quite frustrating not having the possibility to run teamviewer9 for a few months – so I hope everyone reading this will benefit from reading my findings.



Normalt plejer jeg ikke at kommentere pĂ„ bugs, der bliver fundet i software, men alligevel er jeg nĂždt til at kommentere pĂ„ det OpenSSL bug, der igĂ„r d. 7 april blev publiceret af et sikkerhedshold (Riku, Antti og Matti) i firmaet Codenomicon og af Neel Mehta fra firmaet Google Security. Bug’et, som har fĂ„et navnet CVE-2014-0160 er et af tidens nok vĂŠrste bugs. Mange protokoller og applikationer afhĂŠnger af OpenSSL, som generelt set har vĂŠret berĂžmmet som en sikker certifikat-applikation. SĂ„ledes er OpenSSL implementeret ikke blot pĂ„ webservere som Apache og IIS – men ogsĂ„ pĂ„ sikkerhedsprodukter som f.eks. OpenVPN.

Hvorfor er bugget sĂ„ katastrofalt at bl.a. jeg vĂŠlger at skrive om det? Det er fordi at bug’et gĂžr det muligt for en ondsindet person at tĂžmme hukommelsen ud af systemet, der bruger OpenSSL. Det gĂžr at man med en enhver OpenSSL-baseret autentifikation rent faktisk kan dumpe hukommelsen – og udpakke f.eks. certifikater, koder etc. af det binĂŠre dump.

LĂŠs mere om bug’et pÄ http://heartbleed.com/ – her kan du ogsĂ„ finde links til testere, sĂ„ du kan se om din HTTPS-hjemmeside er ramt af bug’et – og om du har lĂžst problemet efter opdatering af dit system.



Nyhed: Nu har Version2 publiceret en artikel, hvor de anbefaler alle at Êndre koder: http://www.version2.dk/artikel/ekspert-efter-omfattende-ssl-saarbarhed-derfor-skal-du-skifte-alle-dine-kodeord-57246

Mit rÄd er ikke at opdatere din kode, fÞr du har vished for at dine sites er opdateret med nyeste version af OpenSSL. Der er nemlig stÞrre chance for at dumpet vil indeholde dumpet, hvis du laver aktivitet et SSL-site som endnu ikke er beskyttet.