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.
Related
The below screenshot shows the relevant packets I am analysing on my laptop. I am confused as to why source port number is increasing by 1. And also I am not sure what and why this large number of SYC/RSTs are coming from.
wireshark print screen
Port 9229 is the default node.js debugging port.
When you open DevTools in your browser, it automatically starts trying to connect to port 9229. If you are not running a node debug server then the debugger client fails to form a TCP connection.
The large number of [SYN] / [RST, ACK] packets are basically the debugging client trying to connect. For each new connection request, the browser requests from a new port increasing it by 1.
In a TCP connection, the [RST] flag is set to reset the connection. It indicates that the receiver should delete the connection without further interaction (source: TCP RFC). Here, the [RST] flag signifies that port 9229 is not accepting any TCP connections.
You can fix it by closing all the DevTools windows in your browser.
You can also try to run a simple HTTP server in node with the command node --inspect server.js and then launch the DevTool window to check that these [RST, ACK] packets are gone and the DevTools window has a made a successful TCP connection.
THIS IS ALL UDP
Let say I have an internal port 25000 that isn't forwarded.
I send a UDP Message through that port to a server.
I now listen to that 25000 port locally for a reply from that server.
The server received my message.
The server thinks the port the message came from is 27833.
How much time does the server have to send a message back to me through port 27833?
If I locally keep listening to port 25000 will the 27833 port stay open indefinitely until I stop listening?
I'm not an expert but I think the timeout of the forwarding of the port on the NAT will not be influenced because you listen to new datagram on a computer behind your NAT (As only the OS will know you want to read those packets, not the NAT).
For the time the port will be forwarded by the NAT, I've find this response on stackoverflow: For how long a router keeps records in the NAT and can they be reused forwarding requests from other hosts? (Shortcut from the response, in practice less than 120 sec)
Let say I have a server XYZ that listens on port 50000 for TCP clients and port 80 for HTTP clients. And on the other side, I have a client that uses a WebSocket to establish a socket connection to port 50000 and will use HTTP port 80 for the handshake (of course).
Now, when the client begins, it will first send a request to server XYZ via the HTTP port 80, and the server will receive its request on port 80 for the handshake and will send a response for welcome. So, in that case, both parties are using port 80 (of course).
Now, when the handshake is done, the standard documentation says that the same TCP connection that is used for HTTP request/response for handshake purposes is then converted to the TCP socket connection. Ok right.
But, but if this whole handshake process and TCP connection for the HTTP request/response uses port 80 the first time, and that the same TCP connection is converted to the TCP socket connection, and this whole process is done via port 80, then how does the same TCP connection get converted to port 50000 for the TCP socket on both parties? Does the client initialize another TCP connection internally for changing to port 50000?
So, can anyone tell how the port conversion is performed and works in the WebSocket from port 80 to a different port in both parties? How does a complete single socket connection get established on the different ports? How does the same TCP connection change/flip its ports?
A TCP socket connection cannot change ports at all. Once a connection has been established, its ports are locked in and cannot be changed. If you have a TCP socket connection on port 80, the only way to have a connection on port 50000 is to make a completely separate TCP socket connection.
A WebSocket cannot connect to port 80 and then switch to port 50000. However, an HTML page that is served to a browser from port 80 can contain client-side scripting that allows the browser to make a WebSocket object and connect it to port 50000. The two TCP connections (HTTP and WebSocket) are completely separate from each other (in fact, the HTTP socket connection does not even need to stay open once the HTML is served, since HTTP is a stateless protocol).
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.
Some things look strange to me:
What is the distinction between 0.0.0.0, 127.0.0.1, and [::]?
How should each part of the foreign address be read (part1:part2)?
What does a state Time_Wait, Close_Wait mean?
etc.
Could someone give a quick overview of how to interpret these results?
0.0.0.0 usually refers to stuff listening on all interfaces.
127.0.0.1 = localhost (only your local interface)
I'm not sure about [::]
TIME_WAIT means both sides have agreed to close and TCP
must now wait a prescribed time before taking the connection
down.
CLOSE_WAIT means the remote system has finished sending
and your system has yet to say it's finished.
I understand the answer has been accepted but here is some additional information:
If it says 0.0.0.0 on the Local Address column, it means that port is listening on all 'network interfaces' (i.e. your computer, your modem(s) and your network card(s)).
If it says 127.0.0.1 on the Local Address column, it means that port is ONLY listening for connections from your PC itself, not from the Internet or network. No danger there.
If it displays your online IP on the Local Address column, it means that port is ONLY listening for connections from the Internet.
If it displays your local network IP on the Local Address column, it means that port is ONLY listening for connections from the local network.
Foreign Address - The IP address and port number of the remote computer to which the socket is connected. The names that corresponds to the IP address and the port are shown unless the -n parameter is specified. If the port is not yet established, the port number is shown as an asterisk (*). (from wikipedia)
What is the distinction between 0.0.0.0, 127.0.0.1, and [::]?
0.0.0.0 indicates something that is listening on all interfaces on the machine.
127.0.0.1 indicates your own machine.
[::] is the IPv6 version of 0.0.0.0
My machine also shows *:\* for UDP which shows that UDP connections don't really have a foreign address - they receive packets from any where. That is the nature of UDP.
How should each part of the foreign address be read (part1:part2)?
part1 is the hostname or IP addresspart2 is the port
127.0.0.1 is your loopback address also known as 'localhost' if set in your HOSTS file. See here for more info: http://en.wikipedia.org/wiki/Localhost
0.0.0.0 means that an app has bound to all ip addresses using a specific port. MS info here: http://support.microsoft.com/default.aspx?scid=kb;en-us;175952
'::' is ipv6 shorthand for ipv4 0.0.0.0.
Send-Q is the amount of data sent by the application, but not yet acknowledged by the other side of the socket.
Recv-Q is the amount of data received from the NIC, but not yet consumed by the application.
Both of these queues reside in kernel memory.
There are guides to help you tweak these kernel buffers, if you are so inclined. Although, you may find the default params do quite well.
This link has helped me a lot to interpret netstat -a
A copy from there -
TCP Connection States
Following is a brief explanation of this handshake. In this context the "client" is the peer requesting a connection and the "server" is the peer accepting a connection. Note that this notation does not reflect Client/Server relationships as an architectural principal.
Connection Establishment
The client sends a SYN message which contains the server's port and the client's Initial Sequence Number (ISN) to the server (active open).
The server sends back its own SYN and ACK (which consists of the client's ISN + 1).
The Client sends an ACK (which consists of the server's ISN + 1).
Connection Tear-down (modified three way handshake).
The client sends a FIN (active close). This is a now a half-closed connection. The client no longer sends data, but is still able to receive data from the server. Upon receiving this FIN, the server enters a passive close state.
The server sends an ACK (which is the clients FIN sequence + 1)
The server sends its own FIN.
The client sends an ACK (which is server's FIN sequence + 1). Upon receiving this ACK, the server closes the connection.
A half-closed connection can be used to terminate sending data while sill receiving data. Socket applications can call shutdown with the second argument set to 1 to enter this state.
State explanations as shown in Netstat:
State Explanation
SYN_SEND Indicates active open.
SYN_RECEIVED Server just received SYN from the client.
ESTABLISHED Client received server's SYN and session is established.
LISTEN Server is ready to accept connection.
NOTE: See documentation for listen() socket call. TCP sockets in listening state are not shown - this is a limitation of NETSTAT. For additional information, please see the following article in the Microsoft Knowledge Base:
134404 NETSTAT.EXE Does Not Show TCP Listen Sockets
FIN_WAIT_1 Indicates active close.
TIMED_WAIT Client enters this state after active close.
CLOSE_WAIT Indicates passive close. Server just received first FIN from a client.
FIN_WAIT_2 Client just received acknowledgment of its first FIN from the server.
LAST_ACK Server is in this state when it sends its own FIN.
CLOSED Server received ACK from client and connection is closed.
For those seeing [::] in their netstat output, I'm betting your machine is running IPv6; that would be equivalent to 0.0.0.0, i.e. listen on any IPv6 address.