I am using tcpdump to collect packet data through wlan0. But I find many packets with length of 0 like following picture shows. Well, length 0 packets... Is tcpdump reliable or I have missed something?
OK, those are TCP packets, and that's the TCP payload length. That can be zero, if a TCP packet is just acknowledging data sent by the other side of the connection, and not sending any data.
For example, the next to the last packet is from 121.186.151.61.dial.xw.sh.dynamic.163data.com.cn, port 80 (that's the ".http" at the end - it's not part of the domain name, it's an indication that it's from port 80) to android-1b46862a4910306b, port 53876, with 16 bytes of data. The last packet is android-1b46862a4910306b sending an ACK to 121.186.151.61.dial.xw.sh.dynamic.163data.com, probably acknowledging the previous 16 bytes.
The other zero-length packets in your sample output are TCP FIN packets, which don't have to have data in them (the host sending it is just saying "I don't have any more data to send you, and never will have any more data to send you on this connection - I'm done"), and TCP RST packets, which are just forcibly shutting down the connection and also don't have to have data in them.
Related
While understanding SMTP PIPELINING RFC 2920 Section 3.2 indicates that a server supporting pipelining MUST NOT buffer responses to unrecognized commands. Is the ideal response to expect an SMTP Protocol Violation Error?
For example, here's a transcript without pipelining but when using an UNKNOWNCOMMAND:
C: EHLO domain
S: 250-ServerName ..... 250-PIPELINING
C: UNKNOWNCOMMAND
S: 500 Unrecognized Command
C: EHLO domain
S: 250-ServerName ..... 250-PIPELINING
With pipelining
C: EHLO domain
S: 250-ServerName ..... 250-PIPELINING
C: UNKNOWNCOMMAND\r\nEHLO domain
S: 500 Unrecognized Command
S: 250-ServerName ..... 250-PIPELINING
Is this the expected behavior or should the SMTP server not buffer responses to unknown commands and to specific commands like EHLO | DATA | NOOP (RFC 2920 Section 3.2 Point 5)? So for the pipelined UNKNOWNCOMMAND\r\nEHLO domain, should the server send only one 500 Unrecognized Command response and flush the TCP input buffer? Are the servers which exhibit this behavior adhering to a stricter constraints?
The relevant points of section 3.2 are:
(6) [The server] MUST NOT buffer responses to unrecognized commands.
(9) [The server] MUST NOT flush or otherwise lose the contents of the TCP input buffer under any circumstances whatsoever.
I interpret these two points as follows: If you send an unknown command followed by a known command in a "single" TCP packet, the server has to send its response to the unknown command immediately before it reads from its input again. In other words, you receive "two" TCP packets instead of one. Unless you monitor your network traffic (or measure the precise timing programmatically), you won't be able to notice the difference. As indicated by the point 9 above, the server may not reset its input buffer.
As a client, you can usually also send commands after EHLO and DATA immediately without any issues because most server don't look ahead in their input buffers. However, such a client violates the pipelining extension. Detecting this can be used as an anti-spam technique (see invalid pipelining in this Wikipedia article).
I am using following filter expression to sniff IPv4/IPv6 SYN/ACK/FIN/RST packets. This works fine using tcpdump for IPv4 however for IPv6 I dont see any thing coming
tcp port 80 and (tcp[tcpflags] & (tcp-syn|tcp-ack|tcp-fin|tcp-rst) != 0)
Currently, TCPDump (and Wireshark) do not support embedded protocol BPF filters under IPv6. In order to find these packets, you would have to use BPF offsets and masks.
For example:
ip6 proto tcp and ip6[13+40]&0x17!=0
Here we are checking to see if TCP is the embedded protocol in the IPv6 header. From there, we are going 13 bytes into the TCP header and adding 40 bytes since we are referencing it from the start of the ip6 header. I'm assuming that you know already that 0x17 would be the mask to match what you have written (SYN|ACK|FIN|RST).
While there is a protochain option which can find TCP anywhere in the protocol chain, it really isn't practical to use BPF to track down which "Next Header" contains TCP (it should be the last one).
To add the port to the above, you would just add:
and ip6[(40+2):2]=80
When I am trying to ping with packet size > 25152 I am getting 100% packet loss. can anyone please help me out on why is it happening ???
ping -c 1 -s 25153 time.nist.gov
--- ntp.glb.nist.gov ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
ping -c 1 -s 25152 time.nist.gov
PING ntp.glb.nist.gov (64.236.96.53) 25152(25180) bytes of data.
25160 bytes from dtc-nist01.ntp.aol.com (64.236.96.53): icmp_req=1 ttl=45 time=76.8 ms
--- ntp.glb.nist.gov ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 76.887/76.887/76.887/0.000 ms
As very quick google shows you are exceeding amount of fragments (data) that fits into one packet. In order to support that you would have to change configuration on your machine (and possibly the remote) to utilize it.
No, it’s not because of hardware, it’s because of IP restriction or it could be because the data choking happening in the router that you were pinging. It will consider large packets as data packets and drops it. If you try small packets, it never shows you any drop because the device will prioratized the input as voice or video.
when I usetcpdump -i eth0 -nn,you can see the packet from 192.168.19.101
(I don't have enough reputation to post a picture)
but when I specify ip,tpyetcpdump -i eth0 -nn host 192.168.19.101,tcpdump captured no packets but recieved some packets.
WHY?
OK, then it's an unfortunate consequence of the difficulty of handling VLAN encapsulation in BPF. VLAN packets captured on a "raw" interface (that supplies packets with their VLAN headers intact) aren't treated as IP packets, they're treated as VLAN packets, so you need to do "vlan and" to skip past the VLAN header.
When i was checking for mysql load time on site. i got result showing connections as TIME_WAIT. Even though i close connection on every page. Sometimes the site doesnt load saying too many connections. What could be solution to this problem?
Thanks in Advance for any replies or suggestions
If a client connects to a MySQL-Server, it usually opens a local port, example:
localhost:12345 -> mysqlserver:3306
If the client closes the connection, the client gets a TIME_WAIT. Due to TCP routing, a packet might arrive late on the temporary port. A connection in TIME_WAIT just discards these packets. Without a TIME_WAIT, the local port might be reused for another connection and might receive packets from a former connection.
On an high frequent application on the web which opens a mysql-connection per request, a high amount of TIME_WAIT connections is expectable. There is nothing wrong with it.
Problems can occur, if your local port range is too low, so you cannot open outgoing connections any more. The usual timeout is set to 60 seconds. So a problem can already occur on more than 400 requests per second on low ranges.
Check:
To check the amount of TIME_WAIT, you can use the following command:
$ cat /proc/net/sockstat
sockets: used 341
TCP: inuse 12 orphan 0 tw 33365 alloc 23 mem 16
UDP: inuse 9 mem 2
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0
The value after "tw", in this case 33365, shows the amount of TIME_WAIT.
Solutions:
a. TIME_WAIT tuning (Linux based OS examples):
Reduce the timeout for TIME_WAIT:
# small values are ok, if your mysql server is in the same local network
echo 15 > /proc/sys/net/ipv4/tcp_fin_timeout
Increase the port range for local ports:
# check, what you highest listening ports are, before setting this
echo 15000 65000 > /proc/sys/net/ipv4/ip_local_port_range
The settings /proc/sys/net/ipv4/tcp_tw_recycle and /proc/sys/net/ipv4/tcp_tw_reuse might be interesting, too. (But we experienced strange side effects with these settings, so better avoid them. More informations in this answer)
b. Persistent Connections
Some programming languages and libraries support persistent connections. Another solution might be using a locally installed proxy like "ProxySQL". This reduces the amount of new and closed connections.
If you are getting alot of TIME_WAIT connections on the Mysql Server then that means that Mysql server is closing the connection. The most likely case in this instance would be that a host or several hosts got on a block list. You can clear this by running
mysqladmin flush-hosts
to get a list of the number of connections you have per ip run,
netstat -nat | awk {'print $5'} | cut -d ":" -f1 | sort | uniq -c | sort -n
you can also confirm this is happening by going to one of your clients that is having trouble connecting and telnet to port 3306. It will thow a message with something like,
telnet mysqlserver 3306
Trying 192.168.1.102...
Connected to mysqlserver.
Escape character is '^]'.
sHost 'clienthost.local' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts'Connection closed by foreign host.
As #Zimbabao suggested in the comment, debug your code for any potential errors that may halt the execution of closing the Mysql connection.
If nothing works, check your my.cnf for a system variable called wait_timeout. If its not present add it to the section [mysqld] and restart your Mysql server.
[mysqld]
wait_timeout = 3600
Its the number of seconds the server waits for activity on a noninteractive connection before closing it. Further information can be found http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_wait_timeout
Tune the figure 3600 (1 hour) to your requirements.
HTH