Automatic channel selection of WiFi router

I normally have 30 Mbps connection to the Internet via WiFi and VDSL modem.  In the past three days, the speed dropped to less than 0.5 Mbps.  I used a WiFi scanner to scan what channels had been used by my own router and other routers in the neighborhood. Pretty good, due to automatic channel selection, my WiFI router picked channel 9 which was less used.  As things did not improve, I decided to manual assign the WiFi channel.  Channel 6 was selected despite one or two routers nearby were using it.  After rebooting the router, speeds came back to normal.  I suspected that there might be strong interference to Channel 9 due to other devices like Microwave Oven, Bluetooth, Cordless Phone or toys.  The fact is there is no way to make a complaint or seek help since the whole WiFi band is unprotected, free to use by any people and any devices.  Picking the most reliable channel in the junk 2.4 GHz band depends on luck.  Having said that, I am inclined to switch to 5GHz 802.11a band for router and client device provided that the prices drop to average user affordable level.

神舟五號返回艙

神舟五號返回艙，現安放在太古城中心展出。單看外型和艙面金屬嚴重燒焦，已知強國航天技術嚴重落後。算把啦，倒不如將研究經費改善民生吧！

802.11n or Powerline Ethernet Adaptor

I note that powerline ethernet adpators which some body call them as homeplug can now support 500 Mbps and 1000 Mbps.  This is much better than 802.11n WiFi connection. The best I can get from 802.11n at home is always below 30 Mbps though the specification states the client can have a maximum speed of 300 Mbps.  If the throughput of ethernet adpators is reduced to half due to cable length or noise, the offered speed of 250 Mbps - 500 Mbps is still far superior than the best WiFi devices. It is now the right time to consider replacing 802.11n by powerline ethernet.  

IPv6 Router Advertizement Attack

I heard the IPv6 router advertizement attack almost a year ago but did not jot it down in writing. Here it is. A single Windows 7 machine can make all Windows machines in a local area network not workable by flooding bogus RA messages with many bogus source addresses.  Only about 20 seconds of flooding is capable of doing great harm. The CPU usage of all machines are approaching 100 % and then hang up

http://samsclass.info/ipv6/proj/flood-router6a.htm

Microsoft has indicated that no patches will be released to rectify this bug but Windows 8 will have this problem removed.  In other words, there is no cure from the OS side. Shame on Microsoft.

For those organisations that need to use IPv6 RA for address assignment, they should use an Ethernet switch with RA guard.

Good luck to those who allow RA in their internal network.

Interactions of ntpdate with DNS round robin

To follow up on my last post of ntpdate interactions with DNS round robin,  I wanted to find if the shortest path fails, whether ntpdate will take the second path as backup.  The answer is affirmative. I have tested it with firewall blocking the reachability of the shortest path. Some captures are given below for reference.

Test : 118.143.17.82 is blocked by firewall to stimulate the shortest path failure

# ntpdate -4 time.hko.hk
13 Jun 08:53:48 ntpdate[3578]: sendto(118.143.17.82): Operation not permitted
13 Jun 08:53:49 ntpdate[3578]: sendto(118.143.17.82): Operation not permitted
13 Jun 08:53:50 ntpdate[3578]: sendto(118.143.17.82): Operation not permitted
13 Jun 08:53:51 ntpdate[3578]: sendto(118.143.17.82): Operation not permitted
13 Jun 08:53:52 ntpdate[3578]: adjust time server 223.255.185.2 offset -0.000177 sec

More details by :

#ntpdate -4 -d time.hko.hk
13 Jun 09:01:15 ntpdate[3699]: ntpdate 4.2.4p5@1.1541-o Wed Oct  8 11:22:55 UTC 2008 (1)
Looking for host time.hko.hk and service ntp
host found : 118.143.17.82
transmit(118.143.17.82)
13 Jun 09:01:15 ntpdate[3699]: sendto(118.143.17.82): Operation not permitted
transmit(223.255.185.2)
receive(223.255.185.2)
transmit(223.255.185.2)
receive(223.255.185.2)
transmit(223.255.185.2)
receive(223.255.185.2)
transmit(223.255.185.2)
receive(223.255.185.2)
transmit(223.255.185.2)
transmit(118.143.17.82)
13 Jun 09:01:16 ntpdate[3699]: sendto(118.143.17.82): Operation not permitted
transmit(118.143.17.82)
13 Jun 09:01:17 ntpdate[3699]: sendto(118.143.17.82): Operation not permitted
transmit(118.143.17.82)
13 Jun 09:01:18 ntpdate[3699]: sendto(118.143.17.82): Operation not permitted
transmit(118.143.17.82)
118.143.17.82: Server dropped: no data
server 118.143.17.82, port 123
stratum 0, precision 0, leap 00, trust 000
refid [118.143.17.82], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036 14:28:16.000
originate timestamp: 00000000.00000000  Thu, Feb  7 2036 14:28:16.000
transmit timestamp:  d38264de.bd2b5c2c  Wed, Jun 13 2012  9:01:18.738
filter delay:  0.00000  0.00000  0.00000  0.00000
         0.00000  0.00000  0.00000  0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
         0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

server 223.255.185.2, port 123
stratum 1, precision -19, leap 00, trust 000
refid [GPS], delay 0.03297, dispersion 0.00114
transmitted 4, in filter 4
reference time:    d38264db.09591159  Wed, Jun 13 2012  9:01:15.036
originate timestamp: d38264db.fb344598  Wed, Jun 13 2012  9:01:15.981
transmit timestamp:  d38264db.fa50e9ce  Wed, Jun 13 2012  9:01:15.977
filter delay:  0.04730  0.03297  0.03494  0.03299
         0.00000  0.00000  0.00000  0.00000
filter offset: 0.006902 -0.00027 0.000801 -0.00029
         0.000000 0.000000 0.000000 0.000000
delay 0.03297, dispersion 0.00114
offset -0.000275

13 Jun 09:01:19 ntpdate[3699]: adjust time server 223.255.185.2 offset -0.000275 sec

***** End of Capture ******

As can be seen, "ntpdate -4 -d time.hko.hk"  will first establish handshakes  with all available IP addresses to determine which one is the best for time sync.  If the best IP address is broken, the other will be taken up.

DNS round robin has no effect on ntpdate

Just found out that if a NTP server has 2 IPaddresses, when clients conduct time sync with the NTP server, the IP address with lower delay will be used.  That is to say, ntpdate has intelligence to  to sync with an IP address with minimal delay.   The effect is that ntpdate overrides DNS round robin rule.  To me, this is a new finding.

Here is the example I used for time.hko.hk.  When doing a ping by hostname, both IP addresses can be selected one by one.  However, when doing ntpdate, only one IP address will be selected.

#ping time.hko.hk
PING time.hko.hk (118.143.17.82) 56(84) bytes of data.
^C
--- time.hko.hk ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1828ms

[warren@dnssec ~]# ping time.hko.hk
PING time.hko.hk (223.255.185.2) 56(84) bytes of data.
^C
--- time.hko.hk ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1137ms

# ntpdate -4 time.hko.hk
12 Jun 13:31:57 ntpdate[24994]: adjust time server 118.143.17.82 offset 0.000340 sec
# ntpdate -4 time.hko.hk
12 Jun 13:31:59 ntpdate[24995]: adjust time server 118.143.17.82 offset -0.000125 sec

Use of gogoCLIENT after 6 June 2012

I like to remind users in Hong Kong who are using gogoCLIENT to access IPv6 and dual-stack websites. After 6 June 2012, GogoCLIENT makes your Windows 7 quite slow in accessing dual-stack websites like Google, Facebook and Yahoo as the nearest tunnel gateway of freenet6.net is in Taiwan. Yes, that is the reality for accessing dual-stack websites but same speed for accessing pure v4 website, still very slow for pure v6 websites. If is up to users to judge if they still want to use gogoCLIENT.

If you have an IPv6 ready router such as D-Link and Linksys, please use router-based 6in4 tunnel with an user account with Hurricane Electric. Since HE has 6in4 gateway in HK with high bandwidth, the v6 speed should be quite OK.

GogoCLIENT is  widely used in Taiwan because all major ISPs there have their TSP tunneling gateway. Taiwan users who want access to v6 network can apply to their ISP for a user account. The v6 speed of course is OK unlike the case of Hong Kong whereby users must connect to Taiwan and then to other parts of the world.

World IPv6 Launch

Today is 6 June 2012 which is named as the World IPv6 Launch by the Internet community.  A new era  has just begun on the Internet starting from 6 June 2012.  Thanks to Google, Yahoo, Facebook, Comcast, Cisco, D-Link and many other companies and organisations that support the new protocol.  Enjoy IPv6.