Port number equals to 80 is obviously not a sufficient condition. Is it a necessary condition that Wireshark has found a request message or response message in application layer payload?
I'm not sure this is a full answer, but here is what I know regarding Wireshark's identification of HTTP packets (all items below are dissected as HTTP):
TCP port 80
TCP or UDP ports 8080, 8008, 591
TCP traffic (on all ports) that has line end (CRLF) and the line begins or ends with the string "HTTP/1.1"
SSDP (Simple Service Discovery Protocol) in TCP or UDP port 1900
DAAP (Apple's Digital Audio Access Protocol) in TCP port 3689
IPP (Internet Printing Protocol) in TCP port 631
Related
What are the differences between SMTP and TCP handshaking? Why is SMTP handshaking important?
A TCP handshake happens at the transport layer of the TCP/IP protocol stack, involving signaling using TCP flags, TCP sequence numbers, TCP port numbers and IP addresses.
SMTP handshaking occurs at the application layer of the TCP/IP protocol, above the transport layer. SMTP handshaking is rarely called a handshake and is composed of the server sending a 220 message representing its banner, the client sending an EHLO or a HELO message along with its name, to which the server will respond with a 220 message indicating success. Subsequent to this the actual email exchange begins.
You can read more about this in RFC 5321.
I am trying to capture the packets moving from my system when i searched URL www.google.com in the browser. This is the flow I am seeing in wireshark.
DNS request was made
TCP three-way handshake is done
TLSV1.2 handshake has started.
In between tlv1.2 handshake I am seeing TCP packets moving from my system to the same port. What is that traffic regarding? I am sharing the screenshot for the same.
The TCP packets with description "ACK" are TCP acknowledgement packets.
An acknowledgement packet is sent to the server for each time the client receives a TCP data packet from the server.
The TCP packets with description "TCP segment of a reassembled PDU" are TCP fragmented data packet.
TCP may divide an upper layer packet into multiple packets. A TCP fragmented data packet is a piece of a divided packet.
For example, the TLS server certificate packet (#1842) was divided into 3 packets by TCP, #1839, #1841, and #1842.
I'm just curious about how the server knows if the received segment is a UDP or a TCP segment, especially when the listening port can listen on both UDP and TCP.
I know the client can use SOCK_DGRAM to generate UDP segments and SOCK_STREAM for TCP segments, but the segment transmitted is still a bunch of bits. How can the server know whether it should interpret these bits as a UDP segment or as a TCP segment? What if these bits are a UDP segment, but accidentally do not mean "too weird" if they are interpreted as a TCP segment?
It's firstly an IP packet, which contains the protocol in the IP header. Inside the IP packet is a payload, which contains either a TCP segment or a UDP datagram.
Port 80 accept two different protocols: HTTP and Stratum. The latter is a line-based protocol always start with '{'. If the client connect to port 80 and sends something like 'GET / HTTP/1.0...', forward the connection to port 8000, if it sends '{"id": 1,...', forward it to port 3333. Is it possible to do it with iptables? Thanks!
I don't think you can do that with iptables.
The problem is that, at the time you can detect the first byte of the TCP payload, a connection has been established between source:port to server:80.
Forwarding the packets in mid-connection will result in the packets being rejected, because the TCP stack never sees the SYN/SYN-ACK packets for connection establishment to ports :8000 or :3333.
You'll need something listening on port :80, then based on the very first by received, open a connection to port :8000 or :3333 and replay the contents. That something must also perform reverse-replay of the webserver's/Stratumserver's replay toward the connection initiator.
I am trying to connect to an http server via IPv6 link-local address from Windows xp sp3 with firefox 6.
Although connecting by IPv4 address of serve worked well, IPv6 failed with connection failed error.
By Wireshark, the sequence is observed as:
direction protocol port transmission
1. client -> server: tcp 1061-> 80 [syn]
2. server -> client: tcp 80->1061 [syn, ack]
3. client -> server: tcp 1061->80 [ack]
4. client -> server: http [get /]
5. server -> client: http [200 OK]
In the 5th transmission, requested html file is included.
But the browser shows connection failed.
It seems tcp layer received the messages and cannot deliver it to http layer or browser.
I disabled firewall, and the result is the same.
Can someone give a clue or hint to pursue.
Thank you.
I suspect that it's not the whole response in packet 5.
Usually problems like this are caused by broken Path MTU Discovery. If there is a tunnel in the path then the MTU is probably smaller than 1500 bytes, i.e. 1480 bytes. All the packes that are smaller than 1480 bytes get through. When the server sends a 1500 byte packet it will be too big for the tunnel. The tunnel router sends back a Packet-too-big ICMP error, and the server sends the data in 1480-byte chunks. If the ICMP error is never generated or a firewall blocks the ICMP packet then the server never learns that it should send smaller packets, it keeps sending large packets, and they never arrive...
Most of the time such problems are caused by misconfiured firewalls. Sometimes it's broken hardware or software.