vnc over ssh with tp-link tl-wn725n causes laptop to freeze

[dborlaug.t at gmail.com]

Dear Mr. Finger,

Thank you kindly for your help and patience.  I'm sure you explain to
write 'uname -r' to many noobs such as myself, your patient instruction
is appreciated; thanks for teaching.

output of 'uname -r':
3.2.0-v-amd64

I will try the v4.1.8_9499 github and report back.  Thank you kindly for
this info. 

>From what I can tell from your email there is an additional in-kernel
driver.  Somehow I missed this.  Before using the install method I
described, I did plug the device in, and i didn't see any pop-ups or get
any notifications after running ifconfig (no wlan0 posted).  Maybe I did
something wrong?  If v4.1.8_9499 github does not solve my problem, can
you kindly guide me to a link showing how to run the in-kernel version
or provide some other form of guidance?

Your assumptions about my prior OS are spot on.  The malware, the need
to restart every few days, among many other reasons is why I made the
switch to linux, and I am supremely enjoying it.  I have found debian to
be quite useful and have already switched my primary workstation and a
number of other machines.  I am definitely seeing better up time and
increased productivity for the simple tasks I run.  Much of this is
thanks to the great community such as yourself and Mr Carpenter, thanks
for helping!

I built the code in an administrator account in /home/<user> using sudo.
I could not get it to build without sudo.  Hopefully this isnt too far
off, but I'm sure there is more to learn about users and security
permissions.  Definitely do not want to boggle my machine.

I will report back regarding my v4.1.8_9499 github progress.

Kind regards,
anon
 

On Wed, 2015-04-22 at 09:52 -0500, Larry Finger wrote:
> On 04/22/2015 02:48 AM, Dan Carpenter wrote:
> > That's Larry Finger's driver and it might be different from the
> > kernel.org driver.  I've added him to the CC list.  If you look in
> > /var/log/messages there may be some useful warning messages from when
> > the driver loaded to when it crashed?
> 
> Actually, that driver is Realtek's. I provide the GitHub repo as a service to 
> users who find faults with the kernel version. As I have no knowledge of the 
> device's internals, my help is essentially limited to fixing crashes when the 
> reporter provides the kernel messages as text or a screen photo, and fixing 
> compilation problems for older kernels. One caveat: Since Ubuntu and RHEL 
> started backporting wireless API changes to older kernels, their users have to 
> fix their own build problems. However, I will ensure that it builds on a vanilla 
> 3.X source.
> 
> @Anon:
> 
> I do need to see the kernel messages, either from the log files or a photo of 
> the logging screen. In subsequent postings, always include your kernel version, 
> which is critical. Open a terminal and enter 'uname -r' to find that info. If 
> your kernel is 3.12 or newer, then you should try the in-kernel version of the 
> driver. If it also has the problem, the priority for fixing the bug is enhanced 
> a lot. You should also switch to the v4.1.8_9499 branch of the GitHub repo and 
> try that version. The master branch, which is what you are likely using, is 
> v4.1.4. Quite a bit has changed.
> 
> Finally, the person who wrote that web page that you linked gave very bad 
> advice. Source code should be kept in the user's file area, not in that of root. 
> The reason is that make files can sometimes have subtle bugs that generate 
> harmless messages when run by an unprivileged user, but do serious damage when 
> run as root. An example was shown very dramatically a few years ago when there 
> was an error in the kernel build system. If you were running as root, it deleted 
> /dev/null. After that, the system did very strange things. Of course, building 
> 8188eu is not very complicated and is unlikely to have any similar bugs, but 
> running everything that you can as an unprivileged user is extremely good 
> practice. I assume that you ran some less secure OS before you changed to Linux. 
> That one probably blurred the distinction between an ordinary user and root, and 
> that OS was likely plagued by malware!
> 
> Larry
>