Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi,
For some time I have an issue which finally made me angry enough to get it over. Suddenly, web browsers, curl and wget stop working (I mean refuse to load web-pages), but BitTorrent and ping continue to work. That's why I conclude that TCP doesn't work but UDP do work, please tell me if I'm wrong. In most but not all cases this is accompanied by messages in dmesg:
This happens once or twice in a week, always when my BitTorrent client is on an my laptop left on for longer than a day. For a long time there was only one IP 192.162.164.1, which made me suppose that this is some kind of attack on users of BitTorrent, but this is truly a stab in the dark.
"/etc/init.d/networking restart" doesn't help, as well as reconnecting with NetworkManager. The only thing that I found to be helpful is rebooting my laptop.
I have Internet connection over Wi-Fi router. Other machines connected to my router do not suffer this issue.
If you need any other info to analyse my problem, tell me and I will write it down as soon as this happens again.
My questions are: what is this, how do I secure myself from this, and how to regain Internet connection without rebooting whole system.
The kernel encountered a problem because the remote site changed its advertised window size without any reason. The kernel fixed this all by itself. It's a message of the informational level, not a warning. Watching wireless-tools output and saving packet captures (something like 'tcpdump -i [DEVICE] -s 0 -n -nn -N -w /path/to/file') may (or may not) show clues. To me Wifi always came across as rather fragile.
You simply run into tcp memory pool issues. How much memory you have? 64MiB? You never should run in such problem, it indicates, that memory pool for tcp is exhausted and kernel start aggressively cut TCP connections. Maybe you rise the limits, but be very careful - do not add more then 25% to those limits, as it is stated in pages, not bytes!
You can try to change congestion control to less aggressive one like westwood or illinois
Second command would fail with sudo - you have to be root to do it (redirection would done as normal user, when you would be using sudo)!
Westwood is actually best congestion control for wireless, but it is cutting TCP window more aggressively, then illinois, which is made for wireless as well (but not as target)
P.S. I never have run into such problem. My 2 servers, desktop and laptop are constantly on, there was time, when KTorrent was running on desktop 24/7/365 and I never had even slightest problem.
Last edited by WizadNoNext; 03-30-2012 at 11:46 AM.
unSpawn, thanks! It was my blind guess that those messages point directly to the problem. I'm quite a newbie and all I knew was "dmesg | tail".
WizadNoNext, thank you, too! I will learn about congestion control and tcp pool. That's the kind of answer I wanted to hear -- something to start with. Because I didn't know where to dig. I have relatively modern laptop with 3 GB of RAM. So no lack of memory here. May it be caused by buggy BitTorrent client? I use qBittorrent. Many thanks, again.
I'll not mark this thread as SOLVED yet, untill I definitely know that problem is solved. And surely will post when it happen. Meanwhile any guesses are still welcome.
Then with such big amount of memory, you should get quite fair amount of memory for tcp.
For me it is (tcp_mem):
Code:
48276 64370 96552
The amounts are in pages (4KiB for IA32/AMD64).
Description:
Quote:
tcp_mem - vector of 3 INTEGERs: min, pressure, max
min: below this number of pages TCP is not bothered about its
memory appetite.
pressure: when amount of memory allocated by TCP exceeds this number
of pages, TCP moderates its memory consumption and enters memory
pressure mode, which is exited when memory consumption falls
under "min".
max: number of pages allowed for queueing by all TCP sockets.
Defaults are calculated at boot time from amount of available
memory.
This settings are system wide - for all TCP connections!
You could have it bigger.
Another set of parameters is tcp_wmem (but it shouldn't be a problem in your case). My (automatic) settings are:
IT IS in bytes!
Code:
4096 16384 2059840
And description:
Quote:
tcp_wmem - vector of 3 INTEGERs: min, default, max
min: Amount of memory reserved for send buffers for TCP sockets.
Each TCP socket has rights to use it due to fact of its birth.
Default: 1 page
default: initial size of send buffer used by TCP sockets. This
value overrides net.core.wmem_default used by other protocols.
It is usually lower than net.core.wmem_default.
Default: 16K
max: Maximal amount of memory allowed for automatically tuned
send buffers for TCP sockets. This value does not override
net.core.wmem_max. Calling setsockopt() with SO_SNDBUF disables
automatic tuning of that socket's send buffer size, in which case
this value is ignored.
Default: between 64K and 4MB, depending on RAM size.
This settings are for separate connection (each counted separately.
Settings are unchanged (set by kernel) on 2GiB RAM home server.
unSpawn: it is just guess, but look closely. TCP suddenly dies and won't work any more. If you know any other explanation...
Last edited by WizadNoNext; 03-30-2012 at 05:15 PM.
As far as I am aware computing is binary. This means there should be no reason to "worry", "think" or "guess" as conditions like for instance kernel runtime parameters for the machine ('uname -r; sysctl net.ipv4'), IP statistics ('cat /proc/net/sockstat') and memory object usage ('( grep sharedavail /proc/slabinfo|tr -d '#'; grep -i tcp /proc/slabinfo; grep -i udp /proc/slabinfo ) | column -t;') can be tested to be true or false. As far as I'm aware the tcp_wmem and tcp_rmem settings you refer to do not require tuning unless a distinct need arises. IMHO such a conclusion should be supported by results of proper diagnosis and not "just a guess".
unSpawn
What it could be then? I am actually quite curious about this problem. My guess do not explain problems with unexpected window shrinks, but it could be up to other side of connection due to lost packets.
First of all you should establish a baseline, meaning the OP should provide details about the distribution (kernel), network stack information ('sysctl net.ipv4'), network device configuration (wherever that resides) and an indication if any sysctls were tweaked. Second you observe the OP trying to load web pages and failing so when the situation arises he could first run 'dmesg' to list messages, run 'iwconfig' (or whatever tool in the wireless-tools package exposes the most information) in a loop to list changing network details and start 'tcpdump' to save traffic. With that in place he should then run network diagnostics and since, as he said, 2 out of 3 IP suite protocols seem to work, running 'tcptraceroute' (and not plain traceroute) and retrieving a page with 'curl' could help gather enough information for you to run the packet capture he might share through Wireshark.
# cat /proc/net/sockstat
sockets: used 650
TCP: inuse 40 orphan 5 tw 2 alloc 50 mem 10
UDP: inuse 19 mem 9
And if you're on IPv6 then you want /proc/net/sockstat6 as well or run 'netstat -s' for human readable output.
Quote:
Originally Posted by hnatt
Right now my connection is OK, so sorry if I pasted something that is not useful. I'll remember what I need to do when the failure will happen again.
No, it's OK. Basically what you want is to grab as much information and as quickly as possible related to the network as apparently it's a transient situation: kernel tunables, device configuration, network statistics and traffic captures.
Unfortunately I found out that I didn't have tcpdump package installed at that moment, and I didn't read your last post where you mentioned 'netstat -s', so I could not gather this potentionally useful information this time.
But one more detail now. When I plugged in Ethernet cable and turned off WiFi card, the connection was not regained. The symptoms remained the same as it appeared to me: curl, wget and browsers do not work, and ping, BitTorrent or ICQ client do work. So I wonder if this problem really has something to do with wireless connection. Well, that is again just a blind guess, because there is no reason why WiFi can't cause some problem that could not be solved by simply turning off the WiFi or turning on Ethernet.
Answer is simple - /proc/sys/net/ipv4 is directory, not file! You cannot set directory nor get its value.
For instance
Code:
sysctl net.ipv4.tcp_rmem
If you wish to see all ipv4 values then
Code:
[sysctl -a | grep ipv4
for ease of use (scrolling)
Code:
sysctl -a | grep ipv4 | less
You can even get all net values
Code:
sysctl -a | grep net | less
browsing it without less (or similar program) would be quite awkward.
Actually it seams that TCP is getting overloaded and either it drops everything or it simply stops to work. I was trying to work out, which module is responsible for TCP, but either I was to lazy or it is compiled into kernel. If it is compiled into kernel and would crash, then you have no other choice, then reboot, as there would be no fix.
I just checked Makefile and it is build-in without option to make module. So somehow you TCP stack dies (crashes) and then only option is to reboot. It should never happen!
Maybe try to get linux kernel 3.2.13 or 3.3 and see if it would happen again. BTW what version of kernel you are running, maybe there is some bug and you run into it.
P.S. I have two servers, when I had just one I had all services there. I never had any problem and I can assure you, that from time to time I overloaded both TCP and UDP (FTP, NFS, samba, proxy, DNS, at least 3 SSH connections always running, copying (using FTP, NFS, samba, SSH), sometimes compiling few programs at once (at most 4 kernels with sources on server and compiling process on desktop)) - I never run into such problem - something is terribly wrong with either your usage or your connection or your kernel. It should never happen - kernel should be able to counter-fight such problems, before they would arise to being serious.
Last edited by WizadNoNext; 04-02-2012 at 05:37 AM.
What version of kernel you are running, maybe there is some bug and you run into it.
Code:
# uname -r
2.6.32-5-amd64
It is from default repository of Debian Squeeze (which is the stable branch for now) and I went through several updates of the "linux-image" package with this problem, so I believe it's rather something wrong with my configuration or hardware.
Must confess, one time I was trying to learn traffic analyzing tools like wireshark, but soon ran out of leisure time and gave up. Maybe I broke something while configuring thoughtlessly wireshark, etc.?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.