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.
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'm trying to scan list of IP addresses using below command
nmap -v -n -sP -iL <IP-list-file.txt>
here I'm looking retry option with nmap command for the failed probe retransmission. Above command will do a single ICMP probe for each IP/hosts. Even I tried with --max-retries no result. So I'm looking a similiar option like { ping -c<2> IP > along with this nmap.
Even tried "-A -T5" no result
Note:- My purpose is to check only whether the host/IP is alive or dead that's it. Preferably nmap utility.
Nmap uses a lot of different methods for host discovery. The options that you used will do one of two things depending on whether you have root privileges:
If you do run Nmap as root, it will send four probes: ICMP Echo Request, TCP SYN to port 443, TCP ACK to port 80, and ICMP Timestamp Request. Only if all four fail to get a response will it mark the target as down.
If you do not run Nmap as root, it will attempt to make a TCP connection to port 80 and port 443. If both of these time out, it will mark the target as down.
So this method is already more robust than simply using /bin/ping. Nmap also retries probes a certain number of times depending on how reliable the network seems. For host discovery, this starts out at 2 retransmits per probe. There doesn't really seem to be a way to increase this without Nmap detecting network problems, so the best way to increase confidence in a "down" determination is to add more host discovery probes using the various -P* options.
The -A and -T5 options will not help at all. -A turns on extra features, none of which will run if the target is considered down, and -T5 simply tells Nmap to assume a very fast and reliable network. It will never retransmit more than 2 times, and will time out probes very quickly. This is almost certainly the opposite of what you want.
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
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.
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.