Slow to access websites, but not always....

[Shabakthanai]

The grep reply was as follows:

steven@YESHUAH-desktop:~$ grep -i "regulatory domain" /var/log/syslog
steven@YESHUAH-desktop:~$

And yes it is that big honking desktop, but I have a wireless router connected to it, and it communicates wirelessly with my wireless printer and laptop, when the laptop is in use.

Nonetheless, when I have the lagging problem opening websites and the freeze problems, they are described the same a when they happened on the laptop. I hope I have not been confusing the issue.

Since it is happening more and more often, and because it requires a hard-restart to continue using the computer, am I damaging anything with all the hard-restarts?

Uh, wait...is this your big honking desktop we're talking about, which presumably doesn't have wi-fi? Or a laptop with wi-fi?

[Shabakthanai]

It is not from the 'grep' command. I opened Dolphin>Root>/var/log/syslog.1, highlighted the file and copy and pasted it to an odt file. I did that with /var/log/syslog, /syslog.1, and /syslog.2.gz, and saved them to my documents folder.

Wait. How, exactly, did you get the contents into the ODT file? Your mention of red text makes me curious, because Kubuntu automatically color-highlights the output of grep. Red indicates a match of the searched-for string. Did you run the grep command, and then copy-paste the output into an ODT file? I'd rather that you just copy-paste the output here on the forum.


None of these are relevant to the specific troubleshooting step I've asked you to take. At this point in the process, all we need to know is the specific number of lines containing "regulatory domain." In your perusal of syslog you've found a number of things that you apparently don't understand. While it's useful to ask questions, it's not useful to begin performing any kind of repair attempt based on what you think you might need to do. Case in point:


The first time I read this, I couldn't possibly imagine what would cause such a window to pop up. Then it finally dawned on me: I suspect you opened the actual file /var/log/syslog in your word processor. While that window was open, some process on the system added information to the file. Your word processor received a file change notice, and offered to display the new, changed file or continue to display the (now out-of-date) version of the file on the screen. Did you, in fact, open the actual file this way?

Yes. Not understanding what the 'grep' search was about, when it did not yield any information, just returned to the prompt "steven@YESHUAH-desktop:$" in the console, I searched for the location of the file and found it in those entries located at /var/log/. I did not knowingly change anything in those files, I just highlighted all the data and copied it to an odt. I now understand that the changes that were made during the time I had the file open were normal, but at the time I wanted to close those files, I was given options to save with changes that were made by something or someone else and I selected to save them, I believe, as I found them. Did that action screw things up more?

Not here, yet. But sometimes I think you dive into attempts to fix things without fully understanding what you're doing, and something else breaks as a result. As a general suggestion, the best way for us to help you when you run into trouble is to describe the problem succinctly, then perform exactly the steps we ask and nothing more. There are reasons why we provide the specific guidance we do. If you don't understand our request or want to know the reasons behind it, that's fine -- just ask. But please don't deviate from the suggestion, because that just makes it all the more difficult for everyone.

I guess I did not understand. I will try not to interfere with the process. In this case, it did not seem reasonable that you would ask to see data and the computer's reply would be just to return to the prompt. And when I looked through the /syslog file and no red print appeared, then read through the /syslog.1 file and several instances of the red print appeared throughout the log file, I thought I stumbled upon perhaps what you were looking for when you gave me the 'grep' command. I then copied all three syslog files and placed them into my documents file so that I would have them, in case you needed them.

It is difficult for me to know what to do sometimes. I have 2 posts that have been read several times and no one seems to recognize or have an idea how to help solve the problems. Eventually they get pushed down the line until I suspect no one looks anymore.

I don't know how to abandon problems that no one has input on, and I don't know whether continued waiting is the proper procedure, or to bite the bullet and fix by reinstalling the OS.

In learning how to use Kubuntu, I have never had anyone to talk with about what or how to do things. Most of the time, I have to work just to understand what is being talked about. Nevertheless, when the computer just sits there and doesn't work, and a post does not draw interest, I assume that it is my lack of knowledge and inability to describe my problem that is what is at fault. Then I have to make a decision of whether to re-install as the hopeful fix of the problem or just wait.

At times like this, I am explaining stuff that you probably don't want or need to know. I feel the need to explain, but fear it is an abuse of your time. I hope I am not losing your willingness to continue to help. Respectfully. Steven

[SteveRiley]

I will try not to interfere with the process. In this case, it did not seem reasonable that you would ask to see data and the computer's reply would be just to return to the prompt.

Don't try to anticipate what you think seems reasonable. Some troubleshooting steps are not intuitive. In the case here, running grep and seeing no output would tell me that the next step is to check syslog.1. I didn't want to put too many steps into a single post.

And when I looked through the /syslog file and no red print appeared, then read through the /syslog.1 file and several instances of the red print appeared throughout the log file, I thought I stumbled upon perhaps what you were looking for when you gave me the 'grep' command. I then copied all three syslog files and placed them into my documents file so that I would have them, in case you needed them.

What red print? grep will highlight the searched-for terms in red. Take a look:



Note that syslog has rotated and I haven't used wireless since then, so I searched syslog.1. It appears that your situation is similar. So what output do you get when you do the same thing I did?

Also, I ask about your red text because your explanation indicates that you had red text before you ran grep. What did you do to get red text? I know my question might seem silly, but this is why it's important to follow guidance exactly, or ask first before you think that an alternate procedure might be better. Now we're chasing something that's probably irrelevant to the issue at hand, but I don't know enough to be certain of that.

It is difficult for me to know what to do sometimes. I have 2 posts that have been read several times and no one seems to recognize or have an idea how to help solve the problems. Eventually they get pushed down the line until I suspect no one looks anymore.

It could be that the problem is unfamiliar to us.

[Shabakthanai]

My reply apparently did not post. Yes, I am talking about my "big honkin desktop". Having a devil of a time getting it configured and working stably. I communicate via router to my laptop and wireless printer. Have become totally lost in this one. What should I do, abandon, re-install (that is what this is)?

Uh, wait...is this your big honking desktop we're talking about, which presumably doesn't have wi-fi? Or a laptop with wi-fi?

[jollyjack]

Guys, sorry for not replying sooner, but the auto-reply notification was caught in my junk filter, for some reason.

I don't think my problem lies with wifi. (A) I'm connected to the router by ethernet (B) my laptop is a Dell with Broadcom wireless, not Atheros (C) there is no mention in any of the systemlogs of "regulatory domain". (BTW, my syslogs are very small - around 40-50 lines covering a two period. Is this unusual?)

Thanks

[GreyGeek]

An UPDATE:
Repeated updates of the 3.8 kernel and other software has rendered BOTH my AR8151 eth and AR5BWB222 wifi chips essentially useless. I time out on most websites and barely get over 250Kb/s downlink speed. The ethernet link is fast for only 3 or 4 seconds after I plug it in, then my "ping google.com" speed rises from 25ms to 2000 ms, or doesn't respond at all. nm-tool remains blissfully ignorant. DNS doesn't appear to be the problem.

I am surprised that the AR8151 ethernet chip is is erratic and unreliable now. I am mulling over my options and neither sounds good: revert to the 3.2 or earlier kernel, which would probably wreak havoc on my system, or switch to my Win7 side until these problems in the ath9k driver are resolved.

UPDATE2:
I've determined that my loss of connectivity is because DNS initally works for a short period of time, then begins workingintermittantly, and after a short period of time stops working altogether. This is verified by pinging an IP address, which works, but pinging the domain name hangs the ping command. After a few minutes, or less, even the ping of the ip address fails. The /etc/resolv.conf file remains unchanged, containing the DNS ip addresses entered in when the interface is configured with the NetworkManager.

Contents of /etc/resolv.conf symlink:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.254.254
nameserver 8.8.8.8
nameserver 8.8.4.4
search Home

I renamed the resolv.conf symlink file and created a real resolv.conf text file and put my nameserver and namesearch data in it. Then I restarted the NetworkManager. That did not resolve the problem so I restored the resolv.conf symlink to put NetworkManager back in control of DNS.

My planned fix, recycle the networking to restart the DNS, is a "fix" that works for only a few minutes, sometimes less than one.

So, I issue
sudo service network-manager restart

and the network starts working for a while. You can see in the ping log below the points where the pign travel time jumps up as connection slows down.

Right after restarting the NetworkManager I ping Google:
ping google.com
......
64 bytes from google.com (74.125.227.73): icmp_req=88 ttl=56 time=29.3 ms
64 bytes from google.com (74.125.227.73): icmp_req=89 ttl=56 time=27.8 ms
64 bytes from google.com (74.125.227.73): icmp_req=90 ttl=56 time=26.5 ms
64 bytes from google.com (74.125.227.73): icmp_req=91 ttl=56 time=25.1 ms
64 bytes from google.com (74.125.227.73): icmp_req=92 ttl=56 time=46.7 ms <----
64 bytes from google.com (74.125.227.73): icmp_req=93 ttl=56 time=42.5 ms
64 bytes from google.com (74.125.227.73): icmp_req=94 ttl=56 time=62.3 ms
64 bytes from google.com (74.125.227.73): icmp_req=95 ttl=56 time=81.3 ms
64 bytes from google.com (74.125.227.73): icmp_req=96 ttl=56 time=76.2 ms
64 bytes from google.com (74.125.227.73): icmp_req=97 ttl=56 time=75.1 ms
64 bytes from google.com (74.125.227.73): icmp_req=98 ttl=56 time=70.1 ms
64 bytes from google.com (74.125.227.73): icmp_req=99 ttl=56 time=69.6 ms
64 bytes from google.com (74.125.227.73): icmp_req=100 ttl=56 time=67.4 ms
64 bytes from google.com (74.125.227.73): icmp_req=101 ttl=56 time=69.5 ms
64 bytes from google.com (74.125.227.73): icmp_req=102 ttl=56 time=69.3 ms
64 bytes from google.com (74.125.227.73): icmp_req=103 ttl=56 time=73.6 ms
64 bytes from google.com (74.125.227.73): icmp_req=104 ttl=56 time=69.6 ms
64 bytes from google.com (74.125.227.73): icmp_req=105 ttl=56 time=33.0 ms
64 bytes from google.com (74.125.227.73): icmp_req=106 ttl=56 time=508 ms <----
64 bytes from google.com (74.125.227.73): icmp_req=107 ttl=56 time=1017 ms
64 bytes from google.com (74.125.227.73): icmp_req=108 ttl=56 time=1142 ms
64 bytes from google.com (74.125.227.73): icmp_req=109 ttl=56 time=436 ms
64 bytes from google.com (74.125.227.73): icmp_req=110 ttl=56 time=543 ms
64 bytes from google.com (74.125.227.73): icmp_req=111 ttl=56 time=1095 ms
64 bytes from google.com (74.125.227.73): icmp_req=112 ttl=56 time=1154 ms
64 bytes from google.com (74.125.227.73): icmp_req=113 ttl=56 time=454 ms
64 bytes from google.com (74.125.227.73): icmp_req=114 ttl=56 time=837 ms
64 bytes from google.com (74.125.227.73): icmp_req=115 ttl=56 time=1202 ms
64 bytes from google.com (74.125.227.73): icmp_req=116 ttl=56 time=1424 ms
64 bytes from google.com (74.125.227.73): icmp_req=117 ttl=56 time=1217 ms
64 bytes from google.com (74.125.227.73): icmp_req=118 ttl=56 time=445 ms
^C64 bytes from dfw06s07-in-f9.1e100.net (74.125.227.73): icmp_req=119 ttl=56 time=625 ms

--- google.com ping statistics ---
119 packets transmitted, 119 received, 0% packet loss, time 118186ms
rtt min/avg/max/mdev = 25.170/130.439/1424.120/292.485 ms, pipe 2

This means that I cannot reliably connect to the repository to fix this problem.


The brain-dead nm-tool sits dumb, fat and happy, reporting everything is A-OK despite the failure of the DNS:

- Device: eth0 [GreyGeekWIRED] ------------------------------------------------
Type: Wired
Driver: atl1c
State: connected
Default: yes
HW Address: xxxxxxx

Capabilities:
Carrier Detect: yes
Speed: 100 Mb/s

Wired Properties
Carrier: on

IPv4 Settings:
Address: 192.168.254.4
Prefix: 24 (255.255.255.0)
Gateway: 192.168.254.254

DNS: 192.168.254.254
DNS: 8.8.8.8
DNS: 8.8.4.4


- Device: wlan0 ----------------------------------------------------------------
Type: 802.11 WiFi
Driver: ath9k
State: disconnected
Default: no


If I activate the wireless network it behaves like eth0 and the wifi connection toggles between 1Mb/s and 54Mb/s and finally settles on 1Mb/s. Ping shows no activity. The NetworkManager is reporting a 1Mb/s wireless speed but the nm-tool says it is 54Mb/s after the DNS failure.

Rebooting restores the the networking and DNS but after a short period of time the whole circus starts all over.

Some have tried to use ndiswrapper to wrap the AR89464 but report failure. I've never heard of an eth0 driver wrapper.

I've had problems in the past with the reliability of the ath9k and atl1c driver, but the network connection was usable. Now, with this DNS problem, it is not.

I've been running the 3.8 kernel for about a year. I'd sure hate to have to revert to a 3.2 kernel.

[GreyGeek]

The saga continues.

When my network connection (wired or wireless) drops my wife's connection continues. She is running 12.04 with KDE 4.8.5. I am running 12.04 with KDE 11.

With either my wireless or wired connection, when I run "sudo service network-manager restart" in a Konsole, the connection resumes and pinging Google.com gives the usual 30 ms response time.
However, within a few seconds or a minute or two at the most, pinging doesn't work and browsing is impossible.
tem
I decided to try another distro. I am currently running Tor's "Tails 0.20" in the Windows XP stealth mode. (It looks EXACTLY like WinXP !! ) and both my wireless and wired connections are stable. (In the stealth mode, however, iceweasle, the tails stealth browser, only allows 2kb/s connection speed, which is ridiculouss. I am currently running their "unsafe browser", which has reasonable access speed.

Anyway, my conclusion to the matter is that since I had a solid connection on this machine while running KDE 4.8.5, and my connection began to give problems with KDE 10, and got worse with 11, the problem lies with NetworkManager.
BUT, I tried replacing NM with wicid, but the problem continued. So, the problem must be deeper in the network system, code common to both wcid and NM. The 3.8 kernel?

What to do .......
I am going to try the 3.2 kernel series. IF that doesn't work, then I will try another distro.

[GreyGeek]

I am now running Kubuntu 13.04 from a LiveUSB stick.
Internet speed is the maxium allowed by my ISP.
Seems stable running the atl1c and ath9k drivers.
Linux kubuntu 3.8.0-19-generic

I may revert to that kernel on my HD install and see what it does.

[GreyGeek]

I was running the 3.8-29 kernel and decided to switch to the kernel that the 13.04 release was using. A while back I had cleaned out the unused kernels and wasn't sure I had that kernel still on my system. Sure enough, it wasn't. But, I noticed that during the last few months several kernel upgrades had been installed but I hadn't switched to them. One was the 3.2.0-52-generic #78-Ubuntu SMP Fri Jul 26 16:21:44 UTC 2013 kernel. It was the most recent. I rebooted and selected it.

That was three hours ago. So far I have not had a single disconnect, or even a slowdown. slowdown. Amazing. Just switching to the most recent kernel. I'm going to give it a couple days and if things continue the way they are I will mark this bad connection episode solved.