Samsung Vibrant and 802.1x WEP…

If there is an easier or non-root required method to what I’ve outlined here, please I’m ALL EARS.


I pretty much hate Samsung or Android, not sure where to direct my h8, but whatever.  I wasn’t going to let it beat me.  Essentially I needed to connect to an AP that uses 802.1x WEP, PEAP, and MSCHAPv2 radius authentication to get access.  Not that difficult on my iPhone w/ the use of profiles, but Android/Samsung wasn’t as easy.  Here it is in a nutshell:

Nitty Gritty:

  1. Follow the instructions on how to root your Vibrant.
  2. Once your vibrant has been rooted, you need to download and install the SDK.
  3. Turn off your phone’s Wifi, and turn USB debugging on (Settings –> Applications –> Development).
  4. This is where it gets interesting (Windows method):
    1. Open a command prompt, go to where you installed the SDK, tools folder. (My case was where I downloaded it which was the desktop)
    2. Type adb shell
    3. This brings you to the Android shell prompt, which starts w/ a $ symbol, now type su
      1. Your phone, if rooted properly, should pop-up w/ a permission request, touch accept or ok, can’t remember how it pops up.
    4. Once in your root the prompt should now show the # symbol.  Now type busybox cp /data/wifi/bcm_supp.conf /sdcard
      1. This copies your current WiFi config file to an area that you can pull from the phone w/o root creds.
    5. Now hit Ctrl-C to get out of the shell prompt.
    6. Type adb pull /sdcard/bcm_supp.conf C:\
      1. This places the bcm_supp.conf file on the root of your C drive.  Feel free to place it elsewhere.
    7. Open the file w/ your text editor of choice (notepad is built in, but I prefer notepad++) 
    8. If you’ve attempted configuring an 802.1x connection, you should see an entry like something below:
      1. network={
        key_mgmt=WPA-EAP IEEE8021X

    9. The above entry is configured for 802.1x WPA, some lines need to change as highlighted below:

      1. network={
        group=WEP104 WEP40
        auth_alg=OPEN SHARED

    10. Once you’ve made your changes, save the file.  Now we need to place this modified file back in the mix.

    11. In the command prompt, type adb push C:\bcm_supp.conf /sdcard

      1. The path will be different if you place the bcm_supp.conf file elsewhere.  We can’t directly copy because adb can’t run as root yet.

    12. Now type: adb shell.  Then type: su (to get into root mode).

    13. Now to apply the conf file type: busybox mv /sdcard/bcm_supp.conf /data/wifi/bcm_supp.conf

    14. Now simply hit CTRL-C to exit the console.  If everything was done correctly, you should be able to turn on your Wifi on the phone and get a successful connection to your 802.1x WEP secured AP.


Usually domain networks require you to change your password, so you may have to do this exercise every time you change your password.  Hopefully Android fixes this.

ScsiCore: 1181: Sync CR


One VM out of several thousands became inaccessible via network and vCenter console access (sample pictured below).  Other symptoms included:

vCenterConsole issue


“Trespass” or “Failover” the LUN w/ the questionable VM to another storage processor (SP).  This immediately stopped all errors and all unaffected VM’s on that LUN continued to run while releasing whatever lock was placed on the LUN causing these ‘wonky’ issues.

Other related reading from VMWare:

VMWare View 4.0.1 no desktop resources exist, but admin console shows VM’s in Ready status…


Essentially the title sums it up.  A user tries to connect to a pool, but they get an error stating that no desktop resources are available to them.  A look @ the admin console shows either the VM is in “Ready” or “Disconnected” status.

Possible Resolutions:

  1. Reset the “VMWare View Agent” service on all or a specific VM in a pool.
  2. Reset the VM from the vCenter management console.
  3. Check your DHCP pools, make sure all addresses are not reserved already.

I believe the View admin console lacks the code to display something like ‘offline’ when it loses communication w/ a VM’s View Agent.  It’s interesting because the View broker is aware that a VM’s View Agent is offline based on it’s debug logs (Usually found under C:\Documents and Settings\All Users\Application Data\VMWare\VDM\logs), but you would never be the wiser because the admin console shows everything to be fine.  It seems that status is only updated when it ‘expects’ something back from the Agent like after initial deployment (error/timeout or ready) and user connection status change (agent initiated).

The debug logs look something like “debug-yyyy-mm-dd-######.txt”.  In it, search for the term ‘offline’.  I’ll probably open a ticket w/ VMWare.