If you prefer Linux drivers, use the link above and download the driver (RTL819xCU_USB_linux_ v3.3.2_3192.zip)
Righ click the zip archive and select "Extract Here". The zip archive will be extracted to a folder called "RTL8188C_8192C_8192D_USB_linux_v3.3.2_3192.20120103"
Right click this folder and select "Open in Terminal"
Now in Terminal, type the commands below to run the installation script:
- Code: Select all
chmod +x install.sh
You'll be asked what your card is:
- Code: Select all
Please select card type(1/2):
Type "1" (without quotes), and press Enter key.
[SOLVED VMware Kernels Errors] - First you need to download the Patch 3.8 file download here
Download it into you " /home/username/Download " then you have move the terminal to the directory
and run the tar command as super user
The runn all these commands
After get this done, do " sudo -i " on terminal to become super user. right after do ..
After all that done you need to run the following command on terminal " sudo vmware-modconfig --console --install-all " then the magic will start happening.
At end you should be able to see a the terminal getting into this stage;
Meaning the VMware workstation will be able to work as normal ... :-)
========================================================================== Ubuntu Security Notice USN-1949-1 September 10, 2013 imagemagick vulnerability ========================================================================== A security issue affects these releases of Ubuntu and its derivatives: - Ubuntu 13.04 - Ubuntu 12.10 Summary: ImageMagick could be made to crash or run programs as your login if it opened a specially crafted file. Software Description: - imagemagick: Image manipulation programs and library Details: It was discovered that ImageMagick incorrectly handled decoding GIF image comments. If a user or automated system using ImageMagick were tricked into opening a specially crafted GIF image, an attacker could exploit this to cause a denial of service or possibly execute code with the privileges of the user invoking the program. Update instructions: The problem can be corrected by updating your system to the following package versions: Ubuntu 13.04: libmagick++5 8:184.108.40.206-5ubuntu2.1 libmagickcore5 8:220.127.116.11-5ubuntu2.1 Ubuntu 12.10: libmagick++5 8:18.104.22.168-2ubuntu4.1 libmagickcore5 8:22.214.171.124-2ubuntu4.1 In general, a standard system update will make all the necessary changes. References: http://www.ubuntu.com/usn/usn-1949-1 CVE-2013-4298 Package Information: https://launchpad.net/ubuntu/+source/imagemagick/8:126.96.36.199-5ubuntu2.1 https://launchpad.net/ubuntu/+source/imagemagick/8:188.8.131.52-2ubuntu4.1
Howto use an encrypted container under Windows XP/7 and LinuxUSB sticks become increasingly common to carry around. When one keeps confidential data on such an USB medium, it should be protected against loss (and it should also be possible to use it for transferring files to and from an untrusted machine, just for convenience). An encrypted container that is usable under Windows XP, (Vista, ) Windows 7, and Linux as a virtual drive is a good way to do that. There are many uses for such a container, I use it to carry high-resolution scans of my most important documents with me on my USB stick, so that a potential loss/theft of my physical passport will not leave me stuck somewhere abroad. Any Windows XP or recent Linux machine should be enough to access those data. Am I worried about identity theft when I lose my USB stick or when somebody copies the container file when I lend them my USB stick? No, I am not that paranoid - if somebody wants to try to brute-force the AES-256 encryption, then be it....One central requirement for such an encrypted volume is of course that it is secure; therefore, the old ZIP file encryption and other weak methods should not be used. But fortunately, an encrypted volume that can be mounted as a virtual drive can be accomplished in a cross-platform manner with open source software.
LinuxUnder Linux, LUKS is, at the time of this writing, one of the best options for creating secure containers. This works very much like I described it for encrypted home directories, and creating such a volume (with 20MB for this example) is simple:
- dd if=/dev/urandom of=/tmp/container.bin bs=1024 count=20000
- sudo losetup /dev/loop2 /tmp/container.bin
- sudo cryptsetup -c aes -s 256 --verify-passphrase luksFormat /dev/loop2
- sudo cryptsetup luksOpen /dev/loop2 container
- sudo mkdosfs /dev/mapper/container
- sudo mount /dev/mapper/container /mnt/ (optional, just to verify that mounting works)
- sudo umount /mnt/ (optional)
- sudo cryptsetup luksClose container
- sudo losetup -d /dev/loop2Here I assume that /dev/loop2 is a free loopback device. The next free one can be found with losetup -f. Of course, if you are logged in as root (which is not recommended), sudo will not be needed - I have added it to the above list to illustrate where root privileges are required. The only catch is that only "-c aes" is supported by FreeOTFE (under Windows) at the moment, but that the more secure ESSIV is not (yet). After the above steps have been executed, /tmp/container.bin can be copied to any location, e.g. to a USB stick. For mounting and using it, I have written a smallshell script that takes care of the necessary steps. It will find the next free loopback device and figure out the location of the container.bin file automatically as long as the shell script is kept in the same directory. After mounting the encrypted container to a temporary directory (and obviously asking for the necessary passphrase in that process), it will wait for a key press and the unmount it again. Therefore, it should be kept running as long as the encrypted container is accessed, and then a key should be pressed to let the script perform the unmount. Here is an example:
rene@styx:/tmp$ sh /media/sda1/documents/mountit.shNot executed as root, re-executing myself with sudo....Enter LUKS passphrase:key slot 0 unlocked.-------------------------------------------Encrypted container mounted at /tmp/tmp.6oBzy6Press any key to unmount-------------------------------------------done
In this case, I explicitly call a shell to execute the script, because my USB stick is (by default, as described here) mounted with noexec, preventing the direct execution of the script.
Windows XP / Windows 7Under Windows XP, (Vista, ) and Windows 7, the fabulous tool FreeOTFE provides virtual drives for encrypted containers and is, in recent versions, compatible with the LUKS container format that was created by the above steps under Linux. In its "portable mode", it does not require any installation at all, but can be used directly from the USB stick to access the encrypted container. I use it in conjunction with SecureTrayUtil, but this is not strictly necessary. It is sufficient to just extract the FreeOTFE archive to the portable medium and execute the freeotfe.exe file. Then select "Tools" - "Use portable mode drivers" to temporarily install the virtual file system drivers (administrator privileges necessary) and "File" - "Linux volume" - "Mount file" to open the container. Attention: Just using "File" - "Mount file" will not work, you need to use "Linux volume" (yes, it is obvious after blindly trying the icon for opening a file for half an hour....).
Loading the drivers on Windows 7Windows Vista and Windows 7, especially for the 64 Bit versions, enforce driver signing. That is, FreeOTFE can no longer load its own drivers, which are not signed by Microsoft at this time. The simple fix is to enable "test signing" mode under Windows 7 to enable loading unsigned drivers. This is documented widely and requires using the bcdedit tool in an administrative shell. However, I kept getting this error, whose solution is certainly not as widely documented:
C:\Windows\system32>bcdedit.exe -set TESTSIGNING ON The boot configuration data store could not be opened. The system cannot find the file specified.
The reason seems to be that my systems are typically dual-boot, running Linux (>95% of their time) and Windows (currently Windows 7 64 Bit, <5 of their time).bcdedit then (for some reason I don't know) needs another parameter to find the location of its BCD data:
C:\Windows\system32>bcdedit.exe /store c:\boot\bcd /set TESTSIGNING ON The operation completed successfully.