Recently the wireless access-point decided that I should not have access to the management interface. I even tried both the IPv4 address I assigned and the default IPv4 address it gets. And the last days I noticed strange delays, which may have been caused by channel overlaps. So I wanted access to the management interface to check the channel settings. I noticed the management interface decided to respond again on the IPv4 address I assigned, and I saw new firmware available which should also help with some stability issues. Firmware upgraded, and after the upgrade and automatic reboot my access was gone again. Time for the suggested factory reset to get everything back to normal. Done, and I was able to set it up again from scratch with the right configuration. Maybe I should start running some kind of wiki or something to keep internal documentation of my home network. I had a hard time remembering several details of my own setup recently.
For the first time I brought my new personal laptop to a place where I could use eduroam wireless network. This gave some trouble, eduroam did not work out of the box. I had to set the authentication method to 'Protected EAP (PEAP)' and set the inner authentication correct. And I had to set the CA-Certificate to check. If you don't set it, network manager settings will ask if you are sure, but if you say you are sure the net result in the background is that the request for a valid certificate is set but there is no certificate set to check against, resulting in the connection not working.
The wireless card of the weather station computer in the shed is dual-band but with only a 2.4 GHz capable antenna. Since the house access-point is configured to support both 2.4 GHz and 5 GHz channels the system sometimes selects the 5 GHz access and keeps having serious packet loss. I looked at ways to convince the driver to select 2.4 GHz channels only but found none, but then I found out wpa_supplicant can do this. But I configure wpa_supplicant through wpa-* options in /etc/network/interfaces so I had to find out how to configure it using those. The manpages for the interfaces file is very limited on the wpa-* options, but I found an explanation that a lot of wpa_supplicant options are supported, including the one to select frequencies. The sneaky part is that the option in wpa_supplicant.conf is freq_list and the option in /etc/network/interfaces is wpa-freq-list. A rather complete list can be found at Where can I find a full list of wpa-* options for the interfaces file? - superuser.com. So now I have in /etc/network/interfaces:auto wlan0 iface wlan0 inet dhcp wpa-ssid default wpa-psk VerySecret wpa-freq-list 2412 2417 2422 2427 2432 2437 2442 2452 2457 2462 2467 2472The ideal solution is to order a dual-band (2.4 GHz and 5 GHz) antenna. Update: Noticeable absent are channels 12 and 13 which are available for regulatory domain NL but are not listed when I ask the driver for available channels:koos@ritchie:~$ /sbin/iwlist wlan0 chann wlan0 19 channels in total; available frequencies : Channel 01 : 2.412 GHz Channel 02 : 2.417 GHz Channel 03 : 2.422 GHz Channel 04 : 2.427 GHz Channel 05 : 2.432 GHz Channel 06 : 2.437 GHz Channel 07 : 2.442 GHz Channel 08 : 2.447 GHz Channel 09 : 2.452 GHz Channel 10 : 2.457 GHz Channel 11 : 2.462 GHz Channel 36 : 5.18 GHz Channel 40 : 5.2 GHz Channel 44 : 5.22 GHz Channel 48 : 5.24 GHz Channel 52 : 5.26 GHz Channel 56 : 5.28 GHz Channel 60 : 5.3 GHz Channel 64 : 5.32 GHz Current Frequency:2.462 GHz (Channel 11)And now I wonder why those are missing.
For an upcoming demonstration about security I plan to play with sniffing insecure wireless networks. I currently have a 'WiFi Pineapple' to play with which makes this quite easy. I created an open wireless network with the SSID of a very popular open network which should be 'attractive' to the visitors of the demonstration and I play with tools to show what can be found in the passing datastream. First of all dsniff for decoding usernames/passwords in a lot of open protocols, like:dsniff: listening on ----------------- 01/21/16 21:54:47 tcp xx.yy.zz.60683 -> ftp3.xs4all.net.21 (ftp) USER ftp PASS koos@ ----------------- 01/21/16 22:05:49 tcp xx.yy.zz.35913 -> pop.xs4all.nl.110 (pop3) USER bestaatniet PASS weetiknietIt took me a while to get dsniff working: it does not 'see' connections that originate on the system it is running on, which was my 'preferred' way to test it. And a more visual one: driftnet for picking out all images from passing traffic. It's a strong visual thing when you see the images from a site you visit popping up in another screen.
New messages in the wifi system logs, probably caused by the new TP-Link TL-WDR4300 access point:[339796.577998] wlan0: associated [339796.578154] cfg80211: Calling CRDA for country: NL [339796.614689] cfg80211: Regulatory domain changed to country: NL [339796.614711] cfg80211: DFS Master region: ETSI [339796.614722] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [339796.614739] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm) [339796.614754] cfg80211: (5170000 KHz - 5330000 KHz @ 80000 KHz), (N/A, 2000 mBm) [339796.614769] cfg80211: (5490000 KHz - 5710000 KHz @ 80000 KHz), (N/A, 2700 mBm) [339796.614785] cfg80211: (57240000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 4000 mBm) [339796.795070] wlan0: Limiting TX power to 23 (23 - 0) dBm as advertised by ..:..:..:..:..:..
Oh and another interesting thing about the new TP-Link TL-WDR4300. It does IPv6. If I read the docs correctly it can do DHCP6 with prefix delegation or tunnels. It even gives itself an IPv6 address on the LAN side when that side runs address advertising. But ...$ telnet -6 ap 80 Trying 2001:980:14ca:2:ea94:f6ff:fe91:21b3... telnet: Unable to connect to remote host: Connection refusedthe webinterface isn't available via IPv6. Nothing in the device is available via IPv6 according to nmap.
I am used to new access-points showing up at home which make us change the channel from time to time, but after getting hickups in youtube video on a tablet for the second time in a week I decided it was time to go dual-band and higher speeds. Good advice was to look at the TP-Link TL-WDR4300 which is dual-radio dual-band with 802.11n support with mimo. The advertised 750 megabit is when you add 802.11n at 300 megabit on 2.4 GHz and 802.11n at 450 megabit on 5 GHz. I'm not setting up extra wide channels on 2.4 GHz since it is busy enough, so I won't be seeing 300 megabit on 2.4 GHz anyway. I set up the network SSID and security on 5 GHz exactly the same as on 2.4 GHz so devices can switch automatically. The weather station computer in the shed also measures wifi signal strength, the difference is clear so the TP-Link also has a stronger signal on 2.4 GHz. The wireless card in the weather station computer can do 5 GHz, but its antenna is tuned for 2.4 GHz and there are multiple walls between the access-point and that antenna.
An interesting new message showing for the wireless config:[2668364.843138] cfg80211: Calling CRDA to update world regulatory domain [2668365.630995] cfg80211: World regulatory domain updated: [2668365.631018] cfg80211: DFS Master region: unset [2668365.631029] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [2668365.631046] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm) [2668365.631062] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm) [2668365.631078] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm) [2668365.631093] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 2000 mBm) [2668365.631109] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm) [2668365.631124] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm) [2668365.632073] cfg80211: Calling CRDA for country: NL [2668365.661681] cfg80211: Regulatory domain changed to country: NL [2668365.661703] cfg80211: DFS Master region: unset [2668365.661715] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [2668365.661731] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm) [2668365.661747] cfg80211: (5170000 KHz - 5330000 KHz @ 80000 KHz), (N/A, 2000 mBm) [2668365.661763] cfg80211: (5490000 KHz - 5710000 KHz @ 80000 KHz), (N/A, 2700 mBm) [2668365.661778] cfg80211: (57240000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 4000 mBm)The message about DFS Master region is new to me, compared to the crda messages I saw last february.
I noticed in the logs of the weather station computer ritchie:[770336.506717] cfg80211: Calling CRDA to update world regulatory domain [770336.906545] cfg80211: World regulatory domain updated: [770336.906567] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [770336.906585] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [770336.906602] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [770336.906619] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) [770336.906635] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [770336.906652] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)But I'm in a specific country (the Netherlands) although the access-point is old enough to not transmit the regulatory domain information. I found out I can update the default in the client using:root@ritchie:~# iw reg get country 00: DFS-UNSET (2402 - 2472 @ 40), (3, 20) (2457 - 2482 @ 40), (3, 20), NO-IR (2474 - 2494 @ 20), (3, 20), NO-OFDM, NO-IR (5170 - 5250 @ 40), (3, 20), NO-IR (5735 - 5835 @ 40), (3, 20), NO-IR root@ritchie:~# iw reg set NL root@ritchie:~# iw reg get country NL: DFS-UNSET (2402 - 2482 @ 40), (N/A, 20) (5170 - 5250 @ 40), (N/A, 20), NO-OUTDOOR (5250 - 5330 @ 40), (N/A, 20), NO-OUTDOOR, DFS (5490 - 5710 @ 40), (N/A, 27), DFS (57240 - 65880 @ 2160), (N/A, 40), NO-OUTDOORThis changes maximum power, bandwidth and frequency ranges. And indeed in dmesg:[770977.623611] cfg80211: Calling CRDA for country: NL [770977.715887] cfg80211: Regulatory domain changed to country: NL [770977.715909] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [770977.715926] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm) [770977.715941] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm) [770977.715957] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm) [770977.715972] cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm) [770977.715988] cfg80211: (57240000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 4000 mBm)Now I wonder about the flags... NO-IR = no initiating radiation the device may not transmit on a frequency until it has received beacons on the frequency. DFS = Dynamic Frequency Selection which is mainly avoiding collision on the 5 GHz wireless band with weather radars. More information about this subject at Regulatory - Linux Wireless.
Ik vroeg me recent af wat het aanbod is in access-points voor thuis met dual-radio support, dus tegelijkertijd actief op 2.4 GHz en 5 GHz. Op de 5 GHz band is minder storing maar niet alle apparaten die wifi gebruiken ondersteunen 5 GHz. En 802.11n op 2.4 GHz doen is volgens mij asociaal omdat je dan helemaal andere netwerken in de buurt stoort. Toevallig blijkt het agentschap telecom het met me eens te zijn: Met een combi-router ben je goed voorbereid op de Wi-Fi van de toekomst - Agentschap Telecom. Dus liefst heb ik een access-point met dual-radio, 802.11n ondersteuning alleen op 5 GHz, WPA2 en niet te veel stroomgebruik. Het lijkt soms dat 2 access-points met verschillende settings wel eens goedkoper in aanschaf kunnen zijn dan eentje met al deze opties, alleen dan vast in stroomgebruik niet.
Gelijk na het bijwerken naar UTF-8 codering liep ik weer eens door het document Draadloos netwerk uitleg en installatie. Sommige links waren niet meer geldig en ik kon nog wat tekst verbeteren.
Sophos the security company went warbiking in central London and found very high numbers of wireless networks, with parts still without any security or with bad wireless security. All explained with a nice youtube video which presents the results in a format even your neighbour who still relies on WEP can understand. The Sophos warbiking project. Found via Warbiking: WiFi hacken op de fiets - security.nl although I would avoid using the term 'hacking' for purely passive measurements.
A practical demo of the latest attack on WiFi security: Hands-on: hacking WiFi Protected Setup with Reaver - Ars Technica shows that it is quite easy to attack WiFi access-points which use WiFi Protected Setup (WPS). The idea behind WPS is that good WPA2 keys are difficult to remember and difficult to reliably copy from the access-point to the client system. WPS uses a PIN hard-coded in the access-point and a client which understands WPS can access the WPA2 key when it has the WPS pin. But a vulnerability in the WPS system allows malicious clients to find the WPS pin (which cannot be changed..) which allows access to the current WPA2 key. So even if you change the WPA2 key, the WPS pin will still allow access to it. WiFi security seems to be a constant arms race. And keeping the balance between security and accessibility is also important.
In the news-alerts for Camp Wireless I noticed a few interesting news items. One was Nature and the Internet: Idaho state parks have campsites, campfires and Wi-Fi - the Bellingham Herald so I updated the listings of campsites with wireless Internet access in Idaho, USA. The other was Gratis wifi voor gasten Kempense campings (Dutch) .. resulting in some extra listings of campsites with wireless Internet access in Belgium.
Don't mix christmas lights and wifi, according to What can get in Wi-Fi's way? - PC Pro:Every holiday season, ISPs receive a spike in complaints that internet connections aren’t working. The culprit: that festive, sparkly, lit-up tree in the living room.Via What's Killing Your Wi-Fi? - Slashdot
TalkTalk said Christmas tree lighting and other household lights can reduce Wi-Fi performance by 25%, and interference is at its worst when the lights are blinking.
The UU has changed certain settings of the Eduroam wireless network. And this change causes a problem with my Nokia E71. The change to the network includes a change in the certificate which has a different root certificate. I tried installing the AddTrust External CA Root certificate in the phone. It took me a while to find what the correct form of a certificate is: it has to be a DER format certificate and mime-type application/x-x509-ca-cert. To convert the certificate from the usual pem form I had to use:openssl x509 -in AddTrust_External_CA_Root.pem -outform der -out AddTrust_External_CA_Root.crtAnd download that .crt into the phone using the system browser. But even when I select that certificate for verifying the Eduroam network it fails at the moment.
Update 2011-03-23: Support had one look at the phone and decided to update the firmware first before trying to get eduroam running.
Update 2011-03-25: Updated firmware now gives me a working connection.
Glenn Fleishman (wireless network expert) has taken the time to completely read and analyze the class-action suit against google for collecting public data from wi-fi networks and tears it to pieces:You're broadcasting data in an unlicensed band. You have no reasonable expectation of privacy over openly broadcast data.In my opinion google should not have collected this data. It still sounds like installing kismet and forgetting to configure it completely. Google should wipe this data immediately. Not hand it over to any law enforcement because law enforcement should not have this data either, it should be wiped thoroughly. But starting a stupid lawsuit with falsehoods and lies like:9. In 2006, Google generated programming code that sampled and decoded all categories of publicly broadcast WiFi data. This type or class of program is commonly called a packet analyzer, also known as a network analyzer, protocol analyzer or packet sniffer, or for particular types of networks, an Ethernet sniffer or wireless sniffer ("wireless sniffer"). As data streams flow across the wireless network, the sniffer secretly captures each packet (or discreet package) of information, then decrypts / decodes and analyzes its content according to the appropriate specifications.I get worked up just having to point out the lies and false acquisations in this part. I really hope this suit by Vicki van Valin and Neil Mertz backfires on them.
10. To view data secretly captured by a wireless sniffer in readable or viewable form, after being captured and stored on digital media, it must then be decoded using crypto-analysis or similar programming or technology. Because the data "as captured" by the wireless sniffer is typically not readable by the public absent sophisticated decoding or processing, it is reasonably considered and understood to be private, protected information by users and operators of home- based WiFi systems.
Running kismet from a wardriver-CD will yield you the same data unless kismet was configured (not the default!) to not save that data. So the above statements are false.
I'm in Paris at the Alcatel-Lucent Enterprise Forum. Lots of presentations about the future of IP telephony, how to save money with IP telephony in the current financial climate and lots of future visions involving UC (Unified Communications). Even realistic ones where people want to look at the organization first before deciding wheather UC is a good idea to spend money on.
Last year I was at the 2008 edition and an analyst told that TDM (digital intracompany telephony) had no future left. This year it isn't even mentioned anymore. IP telephony is the future and there is a move from proprietary protocols to SIP. One standard, pick the SIP PBX that does best what you want and pick the SIP phones that do what you want. For standard features (calling and being called) any standard SIP phone is good enough.
The conference center has wireless network for the forum guests with limited access: only port 80 and 443 seem to work. Good thing xs4all runs sshd on port 80 on the shell servers so I can still get somewhere and use my screens. My tip now for Internet access for road-warriors: bring a 2 meter UTP cable too. Wifi may be everywhere, but our hotel (Hotel California in Paris, makes me wonder how hard it will be to leave) offers free Internet access when you bring your own utp cable.
I'm typing this while sitting in the Thalys high-speed train between Antwerp and Brussels (so no 300 km/h yet). The first class has free wi-fi Internet access. I had to lower the mtu of the wireless interface to be able to use ssh and screen to access my normal home environment, so path mtu discovery is probably b0rken somewhere. I appear from a Belgian IP, no idea how they do the uplink from the train.
Update 2009-03-06: Found on the Thalys website: WiFi - Internet access for everyone! with an explanation how satellite Internet and UMTS/GPRS are used to tunnel the Internet to the train. The whole tunneling thing is probably what is causing the mtu problem.
For the next meeting of the hcc pc!gg netwerkgroep I wanted wired Internet access. But the location where it will be is so advanced it only has wireless Internet access. Time for a fix.
First option was a Linksys WAP54G (borrowed from work). The page in the setup where it can be configured as a wireless client already mentioned that it doesn't want to connect to other brands of networks. Too big a risk that this will not work on location.
Second option was getting a wireless - wired bridge running in Linux. The server I use for experiments with the netwerkgroep has a pci to pcmcia interface and a prism2 based pcmcia wireless card. After a bit of finding sources and getting the hostap drivers working again I set up the bridge and built a test network. First the normal iwconfig commands failed to produce results until I found that the right order is to first ifconfig wlan0 up and then iwconfig wlan0 essid 2marken.ifconfig wlan0 up iwconfig wlan0 essid 2markenAs a simple wireless client it works. Now to make it a bridge:ifconfig wlan0 0 up ifconfig eth1 0 up brctl addbr br0 brctl addif br0 eth1 brctl addif br0 wlan0Disabling ip on wlan0 and eth1 to take them out of normal ip routing and traffic. The bridge was working, the bridging machine was able to see the wireless network and get an IP via DHCP on the bridge interface using dhclient br0. A client machine connected to the wired connection of the bridge did not get an IP. With lots of tcpdumps running it showed that the bridge did forward the DHCP request out of the wireless interface but it never showed up on the server. Later running of another tcpdump on the same wireless network also showed no packets passing.
The one reason I can think of this happening is spanning tree doing something weird. The main ethernet switch in our house does spanning tree. Configuring that switch to force itself to be the spanning tree root also did not fix things. Or maybe the prism card does not like transmitting ethernet frames with a different source address. The Linux bridging documentation suggests this can be a problem.
Eventually I gave up and just went the standard way of masquerading from eth1 to wlan0 and setting up the standard stuff (dhcp server, nameserver). That does mean double NAT (yuck) but at least it gives connectivity.