|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
If you follow me on Google+, you'll know that I'm a big Android fan but am starting to get annoyed with the constant OS bugs that plague platforms running vanilla Android (eg, Google's Nexus line of devices).
One of my recent posts had me wondering if I should ditch Android and switch to the iPhone. Ultimately, I'd lose too much (IPv6 on T-Mobile, certain apps, etc.), so I'm probably not going this route.
Anyway, here's a list of some recent bugs that continue to plague vanilla Android (more or less - I'm using the M2 build of CyanogenMod 10.1) running on my Nexus 4 along with the fixes or workarounds that I've found.
This is documented in issue 40996 and happens maybe once a week to me. All applications that use the camera freeze and require a kill.
I haven't really confirmed this yet, but the supposed fix is to switch to video mode and then switch back.
This only happens to me once a month so I haven't really been able to research it too much. Even though mobile data is enabled, a GNU/Linux interface (rmnet0, p2p1, etc.) is not created in the OS so applications cannot access the Internet. If the PDP context is just IPv4 or just IPv6, the behavior is a little bit different; the data connection connects for 3-4 seconds and then disconnects. It does this every 20-30 seconds or so. Most of the time bad network conditions (no service, very poor signal, etc.) trigger this condition.
The fix that I've found is to enter the testing screen (*#*#4636#*#*), go to Phone information, and select the "Select radio band" in the menu. The application crashes but then mobile data starts working again. It's weird.
Sometimes after switching Bluetooth on or off or enabling or disabling airplane mode, the Bluetooth subsystem stops working. I took a video of this behavior:
This is documented in issue 42255. This one is frustrating because Google fixed this in 4.2.1 but it came back in 4.2.2.
The only workaround I know of is to never disable Bluetooth and never use airplane mode (turn off the wireless radio in the Phone information screen after using *#*#4636#*#*).
After almost two years of not seeing any snow here in Charlotte, we finally got a good snowfall last night. I took a few photos at night and the next day. Strangely enough, even though it snowed for a few hours, the majority of the accumulation happened over a three minute period. I have a few time lapses of driving home and at my condo that I might put up on YouTube, later today.
In other non-news, people really don't know how to drive in the snow, down here. Shocker, I know!
It's January 26, 2013. This means that, among other things, it's now illegal in the United States to unlock a carrier-locked UE (ie, phone, tablet, etc.) without the provider's consent. See accurate coverage here and here.
Unfortunately, lots of people and online news sources seem to be spreading misinformation about this. They say incorrectly that "jailbreaking and unlocking is illegal on Jan. 26." Wrong! jailbreaking of iOS devices is completely separate from unlocking, although one often leads individuals to do the other. It is still legal to jailbreak or root your UE, although this may void the warranty of the specific device.
This law is, of course, thanks to the DMCA.
Let the flogging begin! Yep, I'm using IPv6 NAT+PAT on GNU/Linux.
Sure, for awhile it's been possible to do this in other operating systems (Junos, ScreenOS, IOS, FreeBSD, OpenBSD, etc.).. but not GNU/Linux.
The ip6tables MASQUERADE target was introduced in kernel 3.7 as ip6t_MASQUERADE.ko. Since I have a setup at home that involves using a Verizon Wireless LTE USB stick for backup Internet access (see this and this on the struggles I had to undertake to get it to work with GNU/Linux), this is a requirement for me if I want my IPv6 Internet traffic to use the connection as well. Verizon Wireless has supported native IPv6 on their LTE network since it launched, back in December of 2010.
I had to roll a vanilla kernel from kernel.org and use the deb-pkg target since the latest kernel in Debian is based on 3.2. I also had to grab iptables 1.4.17, build it, and install it from scratch, too. The three configuration options I enabled in the kernel were the following:
CONFIG_NF_NAT_IPV6=m CONFIG_IP6_NF_TARGET_MASQUERADE=m CONFIG_IP6_NF_TARGET_NPT=m
I'm not using NPTv6, yet, but I might try that out in the future. Once built and installed, I added the following familiar line to my iptables configuration script to enable MASQUERADE functionality for IPv6 on the upstream interface:
ip6tables -t nat -A POSTROUTING -s $VOXELV6 -o $EXT -j MASQUERADE
Since my internal network is numbered out of my IPv6 block from Voxel dot net (now Internap) that is usually tunneled to a server I have with them, $VOXELV6 is defined as 2001:48c8:1:100::/56. $EXT is wwan0, which is the USB stick. A very simplified diagram of this setup is shown below:
Normally, IPv6 traffic flows through the tunnel between starfire and dax. When the Road Runner connection fails or is otherwise manually depreferenced on starfire (this will also bring down the OpenVPN tunnel to dax), IBGP moves IPv4 and IPv6 connectivity over to evolution where formerly only IPv4 NAT took place.
Now, both IPv4 and IPv6 NAT+PAT is done on evolution. It works fairly well:
(evolution:17:44)% sudo ip6tables -t nat -S POSTROUTING -P POSTROUTING ACCEPT -A POSTROUTING -s 2001:48c8:1:100::/56 -o wwan0 -j MASQUERADE (destiny:17:30)% mtr --report --report-cycles=32 -w 2001:4860:4860::8888 HOST: destiny Loss% Snt Last Avg Best Wrst StDev 1.|-- et3.starfire.prolixium.net 0.0% 32 0.2 0.3 0.2 0.4 0.0 2.|-- et0.evolution.prolixium.net 0.0% 32 0.5 0.5 0.5 0.6 0.0 3.|-- 2600:1004:b01d:66b7:0:4a:d1a7:7f40 0.0% 32 34.7 44.7 32.1 68.8 8.0 4.|-- 2001:4888:0:1000:201:200:: 0.0% 32 49.0 45.3 31.4 100.3 12.5 5.|-- 2001:4888:20:2010:201:25:: 0.0% 32 83.2 47.3 32.9 83.2 12.5 6.|-- 2001:4888:20:2000:201:1:0:1 3.1% 32 56.9 47.1 36.1 62.7 6.6 7.|-- 2001:4888:20:1002:201:24:: 0.0% 32 52.5 43.9 32.1 61.8 8.2 8.|-- 2600:804:21f::1 0.0% 32 52.9 56.5 40.7 82.0 9.1 9.|-- Loopback0.GW1.MIA19.ALTER.NET 0.0% 32 62.1 75.5 54.9 137.5 18.4 10.|-- 2600:804:80f::a 0.0% 32 115.0 123.5 108.4 159.1 12.0 11.|-- 2001:4860::1:0:245c 0.0% 32 80.3 80.3 62.1 159.9 21.0 12.|-- 2001:4860::8:0:464f 0.0% 32 75.5 87.9 65.1 160.6 18.6 13.|-- 2001:4860::2:0:a7 0.0% 32 99.7 84.7 69.5 126.2 13.0 14.|-- ??? 100.0 32 0.0 0.0 0.0 0.0 0.0 15.|-- google-public-dns-a.google.com 3.1% 32 94.0 84.1 71.6 102.7 8.2
It's been stable for about an hour, now, so that's good enough for me. Since I'm not using a tunnel with this connection, I can also get a full 1500 byte MTU:
(destiny:18:23)% ping6 -c 4 -M do -s 1452 he.net. PING he.net.(he.net) 1452 data bytes 1460 bytes from he.net: icmp_seq=1 ttl=54 time=140 ms 1460 bytes from he.net: icmp_seq=2 ttl=54 time=167 ms 1460 bytes from he.net: icmp_seq=3 ttl=54 time=136 ms 1460 bytes from he.net: icmp_seq=4 ttl=54 time=134 ms --- he.net. ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3003ms rtt min/avg/max/mdev = 134.451/144.745/167.546/13.340 ms
So, what about the flogging? That's because lots of people will say this is the wrong way of doing things. They say I should call up Verizon Wireless and petition them to support DHCPv6-PD, in addition to the 3GPP-mandated /64 assigned to the cellular interface (see section 1.5.3 of RFC 3314). They also say NAT is evil.
Sure, I could do that, but it won't help me now. Even though NAT does suck in general, I say IPv6 NAT+PAT works fine in certain circumstances like this. It's just a tool, it can be used for good and as well as evil. To be honest, I don't find NAT or this use of it inherently evil.
If you want, read some of my other blog entries on the topic of IPv6 NAT+PAT.
It looks like MIT's domain, mit.edu., got pwn3d:
(destiny:13:02)% whois mit.edu This Registry database contains ONLY .EDU domains. The data in the EDUCAUSE Whois database is provided by EDUCAUSE for information purposes in order to assist in the process of obtaining information about or related to .edu domain registration records. The EDUCAUSE Whois database is authoritative for the .EDU domain. A Web interface for the .EDU EDUCAUSE Whois Server is available at: http://whois.educause.net By submitting a Whois query, you agree that this information will not be used to allow, enable, or otherwise support the transmission of unsolicited commercial advertising or solicitations via e-mail. The use of electronic processes to harvest information from this server is generally prohibited except as reasonably necessary to register or modify .edu domain names. You may use "%" as a wildcard in your search. For further information regarding the use of this WHOIS server, please type: help -------------------------- Domain Name: MIT.EDU Registrant: Massachusetts Institute of Technology Cambridge, MA 02139 UNITED STATES Administrative Contact: I got owned Massachusetts Institute of Technology MIT Room W92-167, 77 Massachusetts Avenue Cambridge, MA 02139-4307 UNITED STATES (617) 324-1337 cunt@mit.edu Technical Contact: OWNED NETWORK OPERATIONS ROOT US DESTROYED, MA 02139-4307 UNITED STATES (617) 253-1337 owned@mit.edu Name Servers: FRED.NS.CLOUDFLARE.COM KATE.NS.CLOUDFLARE.COM Domain record activated: 23-May-1985 Domain record last updated: 22-Jan-2013 Domain expires: 31-Jul-2013 (destiny:13:02)% dig +short @FRED.NS.CLOUDFLARE.COM. mit.edu. A 141.101.117.213 141.101.116.213
Whoops! Here is more information.
I picked up a GoPro HERO3: Black Edition camera a few weeks ago. I like to do silly things with time lapses and HD video, so I figured this camera would be a good fit for my creative side.
The camera's got a nice wide-angle lens. This makes it easy to see at least 170°, which usually includes enough context for the scene to make it enjoyable.
The resolution and frame rate on the camera is great. I usually shoot things in 720p at 60 FPS since the 1080p mode chews up the MicroSD card too quickly. The modes that I use to shoot have the following bitrate, according to MPlayer on GNU/Linux:
The encoding is variable bit rate (VBR), so the averages might be slightly different. This page on Wikipedia shows published bit rates. The camera also supports a few 4K modes, but at lower frame rates. It'll also do 848 x 480 at a whopping 240 FPS. I need to do something creative with this!
A Wi-Fi remote control is included, which is handy when unattended operation of the camera is required. The small LCD display on the camera is duplicated on the Wi-Fi remote control, too, so no features are lost during remote operation. That being said, using the remote adds a considerable amount of lag for button presses.
Unlike many newer consumer electronics that don't have removable batteries (I'm looking at you, Apple!), the GoPro cameras all seem to have removable batteries. Among other things, this allows one to swap out the battery during shooting (although this has some implications that I'll disuss in the next section).
The included water-proof enclosure is nifty. It works well under water to 200 meters (I haven't tried this) and appears to be fairly shock-absorbant, too. Unfortunately, audio doesn't penetrate it very well, which is to be expected. All three buttons are still available when in the enclosure, but to replace the battery and connect USB or HDMI, the camera must be completely removed.
Let's start out with the worst feature: the HERO3 will overwrite files if you restart the camera. As far as I can tell, if you turn on the camera, take video or photos, turn off the camera, then turn it back on, it'll immediately start overwriting the previous files regardless of how much free space is on the MicroSD card.
Normally, the HERO3 will write files to the directory DCIM/100GOPRO files with a format of GOPRxxxx.yyy where xxxx is the file numbers (0001 to 9999) and yyy is the extension (LRV, THM, MP4, or JPG). This format will switch to Gxxxxxxx.yyy when the number of files hit 10,000, which happens often during the time lapse mode. Most cameras do something like this, it's nothing out of the odrinary. However, the difference is that when most cameras are powered off and then powered back on, the file numbering starts off with the last file written (usually the highest numbered one). The HERO3 just resets the counter and starts writing over prior files. This can even be seen from the number on the LCD display.
There's a configuration knob labeled "loop" that, according to the manual, causes the camera to treat the MicroSD card as a sort of circular buffer and start to overwrite earlier files when the MicroSD card reaches capacity. This is disabled by default and seems to have no direct relation to this behavior.
As a result, I lost several videos and time lapse sequences before discovering this behavior. In my opinion, this makes the software on the HERO3 fundamentally "broken" and not fit for sale. I probably could have said the same thing about the early releases of JUNOS-ES on Juniper's line of SRX firewalls and J-series routers, though. They just don't make stuff like they used to. Hopefully this will be fixed in a software update. I opened up a support ticket with GoPro about this just to be sure they're aware of it. If they're not.. ugg.
On December 14, 2012, GoPro released a firmware update (HD3.03.02.00) for the HERO3 that allows it to work with the GoPro iOS application. This allows for a live view and the ability to control the camera and its various settings from an iPad, iPod, or iPhone. This sounds neat but.. it just doesn't work for me.
The application works by connecting to the camera over Wi-Fi. The camera itself becomes an access point (the SSID and pre-shared key are set when you download the firmware, but it's really just a text file) and the iOS device is supposed to connect to it. The IPv4 network used is 10.5.5.0/24 and addresses are handed out via DHCPv4. This method is used by other things (like the Brookestone Rover) and is fairly annoying since it prevents iOS device from simultaneously accessing the Internet while connected to whatever specific device is being used. Anyway, once the iOS device is connected to the camera's Wi-Fi SSID the application will "find" the camera by just connecting to the default gateway. This is all well and good but, for me, the camera constantly disassociates my iPad after the GoPro application is open for maybe 15 to 30 seconds. At first I thought it was our Wi-Fi IPS system at work that sometimes misbehaves since that was the first place I tried it. However, it did the same thing for me at home. I am betting the bug is in the HERO3 firmware since the Wi-Fi connectivity on iOS isn't handled at all by the GoPro application.
In the time lapse mode, white balance seems to be evaluated only when the sequence is started. If the lighting conditions change dramatically into the sequence, the subsequent images will often either look too bright or too dark. I searched around for a setting to fix this but found nothing. I opened up a support ticket about this.
When shooting on & off at 720p or 1080p, the battery will last about 90 minutes, then die. I suppose the camera is made for activities that don't last for several hours. Things like scuba diving, skiing, and surfing come to mind. Still, it's annoying. I assume if the video FPS could be dropped to 30 for 720p this would increase the battery life considerably. Unfortunately (as seen in the above Wikipedia link), there doesn't seem to be any video format that is "easy" on the encoding process. Everything is at least 20 Mbps. This lack of flexibility is a bad move on GoPro's part, in my opinion.
The camera and battery both heat up tremendously when shooting video. I suspect this is due to the encoding processing required that heats up the CPU and simultaneously drains the battery very quickly. It becomes uncomfortable to hold at times and probably decreases the overall life of the battery.
Sometimes the MicroSD card becomes unreadable by the camera. Although this happened just once it was a large pain in the butt because I had to reformat the MicroSD card after backing up everything, first. I still don't know what was wrong with the MicroSD card since connecting it to a USB reader on GNU/Linux worked fine. The camera would lock up when starting up, requiring the battery to be pulled.
The HDMI connection is quirky. I tested this on a Vizio TV (W32L A20, 1366x768) and a Samsung computer monitor(S20B350, 1600x900). The Samsung monitor worked but the Vizio TV never detected a signal, possibly due to a handshake failure. Furthermore, when I went to play the videos that were stored on the MicroSD card in my HERO3, none were listed. After taking a short video when still connected to the monitor I went to play it back and the HERO3 complained that the video format was unsupported. So, the HDMI feature seems useless unless you want to.. well, just see live video from the camera or change settings on a big screen.
The camera came in a fairly annoying package. It took some considerable work to break it and the Wi-Fi remote free due to some tight and thick wires. The camera actually sits on a removable plastic base that, upon first glance, is just part of the packaging. However, I'm not so sure of this, since it is very useful and works great when placing the camera on a smooth or semi-smooth surface. The rubber "feet" on the base were originally connected to the packaging but still contain some stickiness that serves to keep the base still when placed on, oh.. the dashboard of a moving vehicle:
I can't seem to find a similar base on the accessory list, so I'm holding onto this thing! I'll probably have to replace the feet eventually, when the stickness wears off. I suspect double-sided tape will serve as a decent replacement.
There are some odd "LRV" video files that are created along side of the MP4 files. Apparently these files are the "Low Resolution Version" of the matching MP4 files. They're used for quick previews, apparently. Unfortunately, they eat up some space on the MicroSD card and there's no way to turn them off.
The HERO3 actually runs Linux 2.6.38.8, apparently:
(orion:10:51)% strings HD3.03-firmware.bin|grep Linux.version Linux version 2.6.38.8 (rlim@ubuntu) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #1 PREEMPT Thu Dec 13 00:05:05 PST 2012 Linux version
The boot loader is apparently some "Amboot" loader that starts the Linux kernel. I'm wondering if we're going to see some alternate (less buggy!) firmwares for the HERO3 in the future. BusyBox httpd 1.19.3, PHP 5.x, and hostapd all are present in the firmware, from what I can see.
The HERO3 is a nice rugged video camera that probably shouldn't have been released until the software was ready. At this point, it's too buggy to use seriously because of the file overwriting issue. That being said, I am still having some fun with it:
I keep telling people that I'm going to get the head mounting kit and swim a few laps in the aquatic center. Hopefully the software will be improved by the time I do that!
I finally put up my Christmas tree, today. Although I skipped last year, I usually setup my camera (or webcam) and do a time-lapse of the whole thing. Here it is:
I used my Canon 60D with manual focus and auto mode along with an intervalometer. I used MPlayer on GNU/Linux to combine the images into a video. The interval between shots is 15 seconds and I encoded the video at 24000/1001 (film) FPS.
Also, no Christmas tree is complete without some Star Trek ornaments. I've got the USS Reliant and USS Enterprise (NCC-1701-D from an alternate universe):
Also, I had to replace 30+ bulbs, today:
I suppose next year I'll have to get a new tree. Hopefully, the LED trees won't be so blue and I'll be able to pick up one of those.
I've been using the Cisco AnyConnect client for quite awhile as a supported method of extending IPv6 connectivity to my iPad. It's also come in handy when using unencrypted Wi-Fi networks to prevent snooping. It's worked flawlessly, except for the last few releases of the AnyConnect client.
Unfortunately, with version 3.1 on Mac OS X and 3.0 on Android, the client just stopped working. The client tries to connect, then times out after a minute or so. Previous versions of the client kept working just fine, though. After digging quite a bit on both the client-side and ASA-side logs, I found absolutely nothing to indicate why the client failed to connect. For instance, the logs on the server show nothing interesting:
%ASA-6-302013: Built inbound TCP connection 1174 for outside:208.54.87.209/25076 \ (208.54.87.209/25076) to identity:192.0.2.149/443 (192.0.2.149/443) %ASA-6-725001: Starting SSL handshake with client outside:208.54.87.209/25076 for TLSv1 session. %ASA-6-725002: Device completed SSL handshake with client outside:208.54.87.209/25076 [... wait a minute or so ...] %ASA-6-725007: SSL session with client outside:208.54.87.209/64512 terminated. %ASA-6-302014: Teardown TCP connection 1177 for outside:208.54.87.209/64512 \ to identity:192.0.2.149/443 duration 0:00:26 bytes 130 TCP Reset-I
On the client side (Android, for instance), we have a bunch of generic timeout messages (abridged):
11-24 13:56:36.854 I/vpnandroid(26414): ConnectionActivity: user initiated connection to Example 11-24 13:56:36.870 I/vpnapi (26414): An SSL VPN connection to vpn.example.com has been requested by the user. [... removed ...] 11-24 13:56:38.963 D/vpnandroid(26505): CertificateManager: Certificate #0 11-24 13:56:38.963 D/vpnandroid(26505): CertificateManager: Subject : CN=*.[... removed ...] 11-24 13:56:38.963 D/vpnandroid(26505): CertificateManager: Issuer : CN=RapidSSL CA, O="GeoTrust, Inc.", C=US 11-24 13:56:38.963 D/vpnandroid(26505): CertificateManager: Certificate #1 11-24 13:56:38.963 D/vpnandroid(26505): CertificateManager: Subject : CN=RapidSSL CA, O="GeoTrust, Inc.", C=US 11-24 13:56:38.963 D/vpnandroid(26505): CertificateManager: Issuer : CN=GeoTrust Global CA, O=GeoTrust Inc., C=US 11-24 13:56:38.979 I/vpnapi (26414): Function: VerifyServerCertificate File: AndroidSNAKCert.cpp Line: \ 286 client received response with GOOD [... removed ...] 11-24 13:57:30.924 E/vpnapi (26414): Function: SendRequest File: CTransportCurlStatic.cpp Line: \ 1695 Invoked Function: curl_easy_perform Return Code: -29949906 (0xFE37002E) Description: CTRANSPORT_ERROR_TIMEOUT 28 : Error 11-24 13:57:30.924 E/vpnapi (26414): Function: sendRequest File: ConnectIfc.cpp Line: 3126 Invoked Function: \ CTransport::SendRequest Return Code: -29949906 (0xFE37002E) Description: CTRANSPORT_ERROR_TIMEOUT 11-24 13:57:30.924 E/vpnapi (26414): Function: connect File: ConnectIfc.cpp Line: \ 468 Invoked Function: ConnectIfc::sendRequest Return Code: -29949906 (0xFE37002E) Description: CTRANSPORT_ERROR_TIMEOUT 11-24 13:57:30.924 E/vpnapi (26414): Function: TranslateStatusCode File: ConnectIfc.cpp Line: \ 2950 Invoked Function: TranslateStatusCode Return Code: -29949906 (0xFE37002E) Description: CTRANSPORT_ERROR_TIMEOUT \ Connection attempt has timed out. Please verify Internet connectivity. 11-24 13:57:30.924 E/vpnapi (26414): Function: doConnectIfcConnect File: ConnectMgr.cpp Line: \ 2075 Invoked Function: ConnectIfc::connect Return Code: -29949906 (0xFE37002E) Description: CTRANSPORT_ERROR_TIMEOUT 11-24 13:57:30.924 I/vpnapi (26414): Message type warning sent to the user: Connection attempt has failed.
From the above, there was nothing to conclude. The ASA didn't respond correctly. I ran all of the webvpn debugs possible on the ASA and didn't come up with squat. I then captured amd decoded the SSL traffic, which showed no response to the HTTP POST:
POST / HTTP/1.1 User-Agent: AnyConnect Android 3.0.09073 Host: vpn.example.com Accept: */* Accept-Encoding: identity X-Transcend-Version: 1 X-Transcend-Version: 1 X-AnyConnect-Identifier-ClientVersion: 3.0.09073 X-AnyConnect-Identifier-Platform: android X-AnyConnect-Identifier-PlatformVersion: 4.1.1 X-AnyConnect-Identifier-DeviceType: Samsung Galaxy Nexus X-AnyConnect-Identifier-Device-UniqueID: 12DFB4098FFBD9D09952C95C50C3E31017B807E7 X-Aggregate-Auth: 1 Connection: close Content-Length: 334 Content-Type: application/x-www-form-urlencoded <?xml version="1.0" encoding="UTF-8"?> <config-auth client="vpn" type="init"> <device-id platform-version="4.1.1" device-type="Samsung Galaxy Nexus" \ unique-id="12DFB4098FFBD9D09952C95C50C3E31017B807E7">android</device-id> <version who="vpn">3.0.09073</version> <group-access>https://vpn.example.com</group-access> </config-auth>
Oddly enough, the client that still worked, version 2.5 for iOS, showed a GET instead of a POST:
GET / HTTP/1.1 User-Agent: AnyConnect AppleSSLVPN_Darwin_ARM (iPad) 2.5.5130 Host: vpn.example.com Accept: */* Accept-Encoding: identity X-Transcend-Version: 1 X-AnyConnect-Identifier-ClientVersion: 2.5.5130 X-AnyConnect-Identifier-Platform: apple-ios X-AnyConnect-Identifier-PlatformVersion: 5.1.1 X-AnyConnect-Identifier-DeviceType: iPad3,3 X-AnyConnect-Identifier-Device-UniqueID: fa14141ac8f11d5bcce13a2b2014fe98c786b109 Connection: close
The iOS client above got data back from the server, I just didn't reproduce it here. Anyway, I couldn't make heads or tails on this, so I upgraded my ASA from 8.4(2) to 8.4(4)5. This didn't do jack, so I rolled back. Since I have access to another ASA (running 8.2, I believe), I tested all of the clients against this version. They all worked! This indicated that I had a problem in my configuration, somehow.
I tore apart the configuration and went so far as to rebuild the configuration from scratch, testing the clients' connectivity after each step. They all worked until, and here it is, I added this configuration line:
ssl encryption 3des-sha1 aes128-sha1 aes256-sha1
After that line was added, the newer clients wouldn't connect and did their standard "hang" of death. Apparently, this was the problem (although I don't see why). However, by removing the line, I was left with the RC4 stream cipher:
icarus# show run | i ^ssl.enc icarus# show ssl Accept connections using SSLv2, SSLv3 or TLSv1 and negotiate to SSLv3 or TLSv1 Start connections using SSLv3 and negotiate to SSLv3 or TLSv1 Enabled cipher order: rc4-sha1 aes128-sha1 aes256-sha1 3des-sha1 Disabled ciphers: des-sha1 rc4-md5 null-sha1 SSL trust-points: inside interface: ASDM_TrustPoint0 outside interface: ASDM_TrustPoint0 Certificate authentication is not enabled
I then tried a different configuration:
ssl encryption 3des-sha1 aes128-sha1
No dice on this, either. In fact, I tried a few different combinations and the only ones that worked were ones that had RC4 listed first. Apparently there is some bug or issue with the encryption types that don't bother affecting the SSL or TLS connection, yet cause the whole WebVPN subsystem to hang!
Anyway, I suppose I'm happy with RC4, for now, since it works. It's not like I have any super-secret stuff to hide, I'd probably be fine with DES encryption!
Hopefully this will help someone out there fighting with the newer AnyConnect client versions. I didn't find anything using Google or Bing that related to this type of issue.
Displaying page 8 of 121 of 965 results
     |
This HTML for this page was generated in 0.004 seconds. |