i use centos 7 64 bit
for incoming tcp connection in port 443 we have a problem
packet only come in but centos can not send answer to it
in this image you can see a normal response
in error time we see win 65520, options [mss 1260,nop,wscale 8,nop,nop,sackOK], length 0 but in normal we see win 516, length 0
can anyone help me?
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.
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.
In an application (voip rtp media server), netstat -na on the server (172.16.226.3 bound to udp port 1286) gives the following line :
udp 0 0 172.16.226.3:1286 172.25.14.11:10000 ESTABLISHED
As an udp connection can not be really "established", it strikes me to see such a line. netstat documentation says that this field is used for tcp connection states, but I am sure that this really is an udp network flow. So : what does it means ? I know (wireshark dump) that my server sends back udp packets from 173.16.226.3:1286 to 172.25.14.11:10000, but I don't see why it should matter...
Os is debian 6.
A UDP socket can be connected via the connect(2) system call, so that the socket will only accept packets from the named peer.
I expect this is the source of the ESTABLISHED column.
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.
Can any data exchanged on a local machine using the loopback IP 127.0.0.1 (localhost) be packet sniffed if the PC is also connected to a network (wireless or landline)?
Would like to know if the loopback, as a means of interprocess communication for locally running processes, can be regarded as a secure means of exchanging data (i.e., not privy to ease-dropping by anyone that resides externally on the network with a packet sniffer program).
This question is being asked in respect to all the pertinent OS platforms:
Win2K/WinXP
Vista
Windows 7
Mac OS X
Linux
Yes, this is secure.
As VBNight stated, the traffic never hits the wire or air.
But, you can actually sniff localhost traffic on your local machine. For example on my linux box I did the following:
sudo tcpdump -i lo
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes
15:29:58.056585 IP localhost.56010 > localhost.16001: S 3572335637:3572335637(0) win 32792 <mss 16396,sackOK,timestamp 132126218 0,nop,wscale 6>
15:29:58.056604 IP localhost.16001 > localhost.56010: R 0:0(0) ack 3572335638 win 0
15:29:59.026016 IP localhost.41664 > localhost.41664: UDP, length 1
15:29:59.026346 IP localhost.41664 > localhost.41664: UDP, length 1
15:29:59.126838 IP localhost.41664 > localhost.41664: UDP, length 1
15:29:59.127486 IP localhost.41664 > localhost.41664: UDP, length 1
So, you can use it to sniff your own traffic/IPC messages, but nobody else can see it on the network.
This is a very common case in systems to use a protocol like TCP or UDP for local IPC over the lo interface.
It should be safe from packet sniffing off the network because the traffic never goes on the wire (or airwaves).
A process on that local machine could sniff the packets tho.
You can use RawCap (a raw socket sniffer) to sniff localhost traffic in Windows. RawCap will create a pcap file that you can load into Wireshark, NetworkMiner or whatever you'd like.
You'll find more info on this StackOverflow thread:
Sniffer for localhost (Windows OS)
I'm pretty sure that popular packet sniffers can't sniff the loopback interface (a cause of much grief and annoyance when debugging stuff on localhost).
The loopback interface can be regarded as secure with respect to the external network. It isn't secure within the same host.
The answers so far are correct, but I will phrase it a different way. It is possible to sniff the loopback adapter communications on the localhost itself, but it usually requires special drivers depending on the operating system. Loopback communications is safe from external sniffers though.
I have had cases where I needed to sniff loopback communications and it was not easy to setup, but it was possible (at least on Windows and I would bet so with Linux as well).