From PC Tips

Fixing Wi-Fi upload issues with a Sonic.net ZXV10 W300 modem/router

logo-white-half

I have Sonic.net for my ISP here in Oakland, and I’ve been pretty happy with the speed and consistency of the DSL service they provide. After returning from my latest visit to the East Coast, however, I discovered I had little to no upload bandwidth on my MacBook Pro. Trying various test sites yielded download speeds in the 12-14Mbps range, but the upload timed out on all of them. I was unable to send a test email from Apple Mail. If I plugged my MBP directly into the ZXV10 W300 modem/router combo that Sonic.net uses, everything worked fine, including standard upload speeds of 1Mbps (that’s why I’m only pretty happy with Sonic.net, by the way–I could really go for a slightly faster upload speed). I also noticed that in the Status menu of the router configuration page, there were a lot of Rx and Tx errors under the Wireless tab, which just didn’t seem good.

A few different things I tried didn’t help:

  • Checked and re-configured the modem according to the Sonic.net wiki (I changed the ‘Bridged’ setting to ‘Enabled’ as it was ‘Disabled’, no effect)
  • Restarted the modem
  • Restarted the MBP
  • Changed the channel on the WLAN from ‘Auto’ to 7, 8, and 11 in case someone had a router hard-coded to channel 1 (my auto-selected channel)
  • Put the MBP really, really close to the router

Here’s what did work:

  1. Log in to the router config page (type 192.168.1.1 into your browser URL bar, default username/password are both admin)
  2. Go to Interface Setup -> Wireless
  3. In the Multiple SSIDs Settings section, Authentication Type was set to WPA-PSK/WPA2-PSK
  4. The menu item directly below that, Encryption, was set to TKIP. When I pulled that menu down, the options available were TKIP and AES.
  5. I switched the Authentication Type to Disabled. NB: don’t leave your router set this way, unless you’re in the middle of the woods somewhere
  6. After re-testing the connection, I was able to upload normally.
  7. When I went to re-enable authentication, I re-chose WPA-PSK/WPA2-PSK.
  8. To my surprise, the Encryption pull-down now included the TKIP/AES option, which wasn’t there before. When I chose this option, my connection worked perfectly.

So, what could have caused this? I suspect that somehow the modem configuration got corrupted, or alternately TKIP-only encryption was working fine for a while, but stopped working with my MBP after a recent OS X 10.8 software update (I applied one while out of town). Either way, I don’t really care what broke, as long as I know how to fix it. If it happens again, that’ll point to the router as the culprit for sure, though.

Active Directory / Open Directory group nesting fixed in Snow Leopard

There was a bug in Mac OS X 10.5 “Leopard” that prevented proper application of MCX settings to an Active Directory group nested inside an Open Directory group. This problem has been corrected in 10.6 “Snow Leopard,” but it’s important to note that this is a client-side issue as well that requires you to upgrade all machines to Snow Leopard in order to have the settings properly apply.

The problem evidences itself in the following way: under Apple’s Magic Triangle guidelines, the proper method for access management on the desktop is to “nest” AD users and groups within OD groups, and then to apply settings to those OD groups. This allows for user management of AD users on any Macs they log into, while avoiding the risk of extending the AD schema itself. For the most part, this worked correctly in Leopard, except on AD groups nested in OD groups when applied to Computer groups within the OD. For example, placing a user AD\joeuser into an OD group called banned_users and then denying the banned_users group login access to the LabComputers OD group would block Joe from logging in, but adding AD\alumni into the same OD group would not prevent login access.

Thankfully, this nesting behavior now works correctly in 10.6. As long as you upgrade your clients as well, you should be able to manage Computer settings just like you’d expect.

Internal Error 2739 while installing Adobe Creative Suite 3

[simage=107,320,y,right]I ran into this Windows Installer error today while trying to add Adobe CS3 to our computer lab image. The solution is simple. Launch a command prompt (in Vista, you will need an administrative cmd prompt, which you can get by typing ‘cmd’ into the Start menu box and then right-clicking on the cmd icon and choosing “Run as administrator”). Now enter the following two separate commands:

regsvr32 vbscript.dll
regsvr32 jscript.dll

You should be all set.

Internal Error 2738 while installing QuickCam software in Vista

[simage=105,320,y,left]Recently, while trying to set up some Logitech QuickCam Messengers in one of our public computer labs, I ran into an Internal Error 2738 displayed by InstallShield during the installation process. A quick Google search turned up some information that indicated the error is caused by VBScript not being enabled on the computer. This may be because it was turned of for security (in Windows XP), or because it comes disabled for security by default in Windows Vista. To enable it, simply launch a command prompt (in Vista, you will need an administrative cmd prompt, which you can get by typing ‘cmd’ into the Start menu box and then right-clicking on the cmd icon and choosing “Run as administrator”). Type the following into the prompt:

regsvr32 /u vbscript.dll

That should allow you to re-run the installer successfully. You might want to disable VBScript again afterwards (no idea if it is necessary to run the app) for security. To do that, type the following:

regsvr32 vbscript.dll

Repair missing Wireless 355 Bluetooth on Dell Inspiron with Windows 7

After upgrading my wife’s Dell Inspiron 1525 to Windows 7 this weekend, I discovered that the Bluetooth had stopped working. Downloading the driver from the Dell site did nothing, which was not too surprising considering that nothing was showing up in Device Manager.

After a little googling, I managed to stumble upon the solution in a Dell support article. Turns out if the Bluetooth is off during an upgrade, you need to run a small application to re-enable it. I ran the download (only 153KB) and Windows 7 found the Bluetooth and installed it automatically within a couple of seconds. Since I have the RTM earlier than most, I thought I’d share this info in case others have the same problem.

Conficker worm starts to wake up after all

According to various tech sources on the web, the Conficker worm might actually be doing something after all. CNET is reporting that the worm is beginning to replicate itself via P2P file sharing, and is downloading additional encrypted files that experts have yet to decrypt, but suspect are some sort of keylogger. All this is happening a little over a week after the April 1st supposed payload date passed by with little to no incidents. The actual propagation of the worm at this point is taking place gradually, so it may actually be more successful in doing damage than if it had hit all infected computers at once and started to keylog and replicate.

So, bottom line: if you haven’t patched your system, do it now. Then keep doing it.

Configure a Buffalo LinkStation for Active Directory

We recently started deploying Buffalo Network Attached Storage (NAS) devices on our campus to various departments that are looking for additional, non-critical storage in a relatively secure environment. Since we run Active Directory on Windows Server 2008, we chose the Buffalo drives for their ability to interface with AD. The AD bind works well for user management, but I ran into a small problem with the second drive I configured, so I thought I’d share my experience.

The AD configuration screen looks like this, and can be accessed on the drive’s web interface by clicking on Network->Workgroup/Domain:

LinkStation AD

As you can see, there are several fields that need to be populated, but Buffalo’s FAQs are not very specific about what exact info needs to go in them. Here’s what worked for me:

ActiveDirectory Domain Name (NetBIOS Name) – the actual old-school domain name without the .com/.net/.edu part

ActiveDirectory Domain Name (DNS/Realm Name) – the FQDN of the domain, i.e. the same thing as above but with the .com/.net/.edu part

ActiveDirectory Domain controller Name – the machine name of one of your primary domain controller, without the .domain.com part (just the machine name)

Admin user and pass – Domain admin credentials without anything like domain\username

WINS Server IP Address – the IP of your WINS server (usually your PDC)

After I had all this info together, I was still getting a message about authentication failure when joining the AD. I found an article on this problem here, which pointed me to the following troubleshooting steps:

  1. please check the internal Date/Time settings, especially the correct Time-Zone (by default +9 hours). The Timestamps of TS and PDC can only be 5 minutes different, otherwise the PDC will reject the Station. There is a good description of the problem caused by the “Time Difference / LDAP Error 82” located here: Troubleshooting Replication Errors, Microsoft TechNet
  2. The Primary DNS Server IP of the TeraStation network settings must be the IP address of the DNS Server running on the PDC.
  3. The IP address of the Gateway shall be the real gateway/router or the domain controller.In General 1) is the well known point why the Link- or TeraStation still cannot join even if above named things are done properly.
  4. If there is a WINS server given in the ADS-settings test the joining without the WINS IP.
  5. Check if there are some firewalls or Antivirus-Programs up and running that avoid a communication.
  6. If problems still exist please to a “Reset-to-Default” of the Tera/LinkStation by initiate the unit once.

Sure enough, it was the date/time problem for me. I solved this by going into Basic settings, then choosing an NTP server on my domain, then clicking Use Local Time (I think this was what fixed it). Once the time synced up (and it didn’t really look off before I clicked the Use Local Time button), the device joined the domain with no problem and I’m off and running with AD group authentication.

Print jobs sent from wrong user on Vista or Server 2008 computer

At the university I work for, we recently adopted a system called Print Manager Plus to do print accounting for our new, pay-for printing system. A couple of days into production, users started to complain that print jobs were being deducted out of their accounts even though they hadn’t printed them. Since Print Manager Plus runs on our central print server, it simply accounts for each job based on the username sent by the client computer that is printing. I called the folks that make Print Manager Plus, and they mentioned that they had seen similar problems with other Windows Vista clients / Windows Server 2008 server implementations.

The issue, as it turns out, is very much known to Microsoft, and is addressed in KB Article 958741. Basically, the print spooler has a problem releasing a user when he or she logs out of the machine but does not restart it. As a result, subsequent print jobs appear to come from the previously logged-in user, who then “owns” those jobs. Even the KB article addresses the significant security risks this poses in the preamble:

This problem also causes some security-related issues. Because the permission settings for a print job are based on the permission settings of its owner, the first user can manage the print jobs of later users even though the first user did not send these print jobs. Additionally, later users who send print jobs may be unable to manage their own print jobs.

The fix provided on the website is to email Microsoft for a patch, which comes in the form of an time-sensitive, encrypted ZIP file that expands into an .MSU update. A rather secretive and tightly controlled way to distribute something that is in fact a relatively critical update, in my opinion. Of course, Microsoft wants to collect data on how many people find out about and solve this problem now through a single channel of distribution, so that it can figure out how important the problem really is in terms of end-user perception. Supposedly, the fix will be part of Service Pack 2 for Vista and Server 2008. I hope that it is released sooner as a legitimate Windows Update, openly available for all, not just those who navigate the maze that Microsoft has laid out currently.

Disable annoying Java Update notification

If you’re sick of getting prompted to update Java, or if you have some web application like Banner that requires a particular version, you can use a simple registry hack to disable notification of available updates.

  1. Open the Registry Editor by going to the Start button and typing in regedt32.
  2. Navigate through to the following key: HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy
  3. Change the value of EnableAutoUpdateCheck to 0 and the value of EnableJavaUpdate to 0.

Java should no longer prompt you for the annoying updates.