I am using "netstat -s -P tcp" to calculate retransmission. The output shows that tcpRetransBytes is more than tcpOutDataBytes. Three servers show this-- all are up for about a month. Is there any bug ? Note that if I use the command "netstat -s -P tcp 6" then I see tcpRetransBytes is less than tcpOutDataBytes.
I have a feeling that tcpOutDataBytes counter is reset while tcpRetransBytes keeps accumulating since the last reboot.
I cannot show the output of the command at the moment. Any help will be appreciate, PLEASE
I got my answer. tcpOutDataBytes is kept in a 32-bit integer. This is why when the value goes above 4255151339 or there about it starts again from 0. It's really shame that it is happening in Solaris 10
Related
I have some problems with pinging hosts with big packet size.
I'm doing some research on latency between one configuration and another.
I have written bash/zsh script to make it simpler that pings 8.8.8.8 and then parses the output to get average ping value. Script below:
#!/bin/zsh
for SIZE in {100..65500..100}
do
ping 8.8.8.8 -c 5 -s $SIZE > tempfile
TEMP=$(cat tempfile | tail -1 | awk '{print $4}' | cut -d / -f 2)
echo "$SIZE - $TEMP" | tee -a results
done
rm tempfile
The problem is that with big packets (more than 30kB when the standard value is 64b) ping just doesn't work, I don't get any response just like the server was unavailable. Interestingly, when I was in another location, everything worked fine (Internet connection is a bit worse there), problems there started about 60kB but here they start about 30kB and to get one (out of ~300 to the end and bigger=worse) result I need to call this script ~10-20 times. It's really annoying because for smaller packets it's working like a charm (with the same server 8.8.8.8).
Anybody has an idea what causes it?
This behavior is related with IP Fragmentation, when you packet size is bigger that your maximum transmission unit (MTU) takes more that one packet and become pretty inefficient, take a look in https://en.wikipedia.org/wiki/IP_fragmentation
When I encounter "a server is already running" I use below command to solve this issue
lsof -wni tcp:3000"
kill -9 pid
I undertand lsof, but don't understand why "-wni", does anybody know what "-wni" stands for?
Also I could use lsof -i tcp:3000, but what is the difference between lsof -i tcp:3000 and lsof -wni tcp:3000?
Thanks.
You can run man lsof to find out those flags.
-w Enables (+) or disables (-) the suppression of warning messages.
-n inhibits the conversion of network numbers to host names for network files. Inhibiting conversion may make lsof run faster.
It is also useful when host name lookup is not working properly.
-i [i] selects the listing of files any of whose Internet address matches the address specified in i. If no address is specified,
this option selects the listing of all Internet and x.25 (HP-UX) network files.
users.
I want to capture traffic on port 5060 for one week in a file, than wants wireshark to rotate file and start capturing for next week with a different file name.
I know little about tshark, dumpcap but wants to know, what is more effective way to achieve this and how. As file will contain data of almost one week.
Any suggestions would be much appreciated.
Thanks.
You can use a ringbuffer:
tshark -i 1 -f "port 5060" -a files:n -b duration:604800 -w week.pcap
-a files:n
Stop capturing after n files
-b duration:604800
Switch to the next file after 604800 seconds
-w week.pcap
The names of the output files will look like:
week_00001_20150403194709.pcap
week_00002_20150403194739.pcap
week_00003_20150403194809.pcap
week_00004_20150403194839.pcap
I'm hitting a very odd issue with FreePBX 2.8.1.5 (yes yes I know; need to update - not that easy) with Asterisk 1.6.2.10.
I just enabled On-Demand call recording that is achieved by pressing *1 during a call. However - when I try to playback the call, it plays the incoming stream first in its entirety and then the outgoing stream in its entirety; it does not mix the two!
So for example: I talk to a colleague and I start the conversation by saying "How are you doing?" he would say "Ok" and then I would say "I will count to 5 - 1,2,3,4,5" to which he says "I will continue counting - 6,7,8,9,10."
When the call is terminated and I listen to the recording, what I hear first is my colleague saying "Ok" pause "I will continue counting - 6,7,8,9.10" and afterwards, I will hear my stream - "How are you doing?" pause "I will count...".
Obviously Asterisk is not mixing the streams but I've never encountered such behavior before with any version of Asterisk! Anyone has an idea of what's going on and how to potential resolve it?
Thanks in advance!
Hah - so looks like Sox was being naughty. Implemented a workaround found here and it worked great.
Workaround:
Edit global_custom.conf and add the following:
MONITOR_EXEC=/var/lib/asterisk/bin/soxmix.sh
Then create the script (make sure to chown accordingly):
#!/bin/sh
nice -n 19 soxmix $1 $2 $3
if [ -s $3 ]
then
rm -f $1
rm -f $2
fi
Restart amportal/asterisk.
Asterisk can mix the recorded streams on the fly. You should look for DYNAMIC_FEATURES and change monitor to mixmonitor. Look around at /etc/asterisk/features*.conf
I'm trying to plot the TCP congestion window and the slow start threshold using iperf and the tcp_probe module. I do exactly what is told here:
to obtain the data:
modprobe tcp_probe port=5001
chmod 444 /proc/net/tcpprobe
cat /proc/net/tcpprobe >/tmp/tcpprobe.out &
TCPCAP=$!
iperf -i 10 -t 100 -c receiver
kill $TCPCAP
Oops!
/tmp/tcpprobe.out is empty :(
This is Ubuntu 11.04 x86
and already tried the same on Ubuntu 11.04 x64
Any suggestions?
I was having the same problem. What worked for me was:
modprobe -r tcp_probe
sudo modprobe tcp_probe port=5002 full=1
sudo chmod 444 /proc/net/tcpprobe
cat /proc/net/tcpprobe > /tmp/tcpprobe.out &
TCPCAP=$!
iperf -c <servers IP address here> -p 5002 -t 100 -i 1
sudo kill $TCPCAP
See iperf parameters to check if those (-t 100 -i 1) are what you need by typing:
man iperf
I/O function in C standard library use buffer by default, usually 4k , so fread() only return when buffer full or EOF. You can use small buffer, 128 bytes, see:
dd if=/proc/net/tcpprobe ibs=128 obs=128
Now, message flush quickly.
By default the tcp_probe logs only when the cnwd changes, try modprobe tcp_probe ... full=1.
Linux source code referece: http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/net/ipv4/tcp_probe.c#L47
I had similiar issue, the tcp_probe module outputs only in non-obvious time intervals. I've created a modified version of it that flushes on every received tcp segments. This slows down the system, but allows to better monitor short-lived connections like HTTP.
Find the source code to the module here.
another issue which causes no output is file permission of output file tcpprobe.out
when cat tcpprobe directly, it's able to see the output, but if redirecting the output the file, the output file size is 0, which reminds me that it's the permission issue...
A very late answer, but have been struggling with this issue myself. I was trying out the version Dyna provided, yet still got no output, regardless of the parameters used. In the end, I found that the order was the problem.
The way I was using tcp_probe was: install/activate the module, run some tcp application (I was running some tcp unit tests), then start the copy process for /proc/net/tcpprobe (as shown in the other answers) and then remove/stop the module. The correct way is to start the copy process (barring killing of the process) BEFORE you perform the tcp intensive activity. Keep the cat process running while you perform the tcp activity and only kill it afterwards.
A pretty humbling experience for me, as it took hours to figure this out. Hopefully, people find this useful.