Tag Info

Hot answers tagged

9

This is what the nmap docs say about the filtered state filtered Nmap cannot determine whether the port is open because packet filtering prevents its probes from reaching the port. The filtering could be from a dedicated firewall device, router rules, or host-based firewall software... The only way to find out what is doing the filtering is to know ...


5

Short answer - No, there is no way that you can see it. Longer answer: From: https://nmap.org/book/man-port-scanning-basics.html "filtered Nmap cannot determine whether the port is open because packet filtering prevents its probes from reaching the port. The filtering could be from a dedicated firewall device, router rules, or host-based firewall ...


5

Nmap provides several ways to get more information about what is causing the filtering: The --reason option will show the type of response that caused the "filtered" port state. This could be "no-response" or "admin-prohibited" or something else. The TTL of response packets is reported in the XML output as the reason_ttl attribute of the state element for ...


3

You can open thousands of connections with just 2 machines. Remember, a TCP connection consists of 4 items, a Source IP:Port connecting to a destination IP:Port e.g. 192.168.2.1:24543 -> 192.168.2.101:80. The TCP/IP guide is a great resource here. On the destination side, it is often the case that whatever is listening is able to handle multiple ...


2

Try comparing a result of tcptrace to one of the filtered ports with a tcptrace to an open port (or a standard traceroute). If the tcptraces are the same it means that there's something on the destination machine filtering the ports. Update: I meant tcptraceroute, I have it aliased.


2

Edited because OP provided more information: Listening to TCP ports does not require administrator rights. However, some helpers like HTTPListener would require admin rights. In those case, try configuring a reservation, so that a user can listen on that port. netsh http add urlacl url=http://+:80/MyUri user=DOMAIN\user ...


2

I think this problem related to IO problem related or application problem and for any reason the socket buffer has finished the space I did something like this to reproduce the IO related problem in linux: /dev/vdb 2.0G 1.6G 470M 77% /brick1 [root@nod01 ~]# ls -l /dev/vdb brw-rw---- 1 root disk 252, 16 Apr 19 22:46 /dev/vdb echo ...


1

This seems to be normal behavior, as there will always be clients who have an unreliable connection leaving the server's connections in a "sending" state. They aren't reading any more data but Nginx will still wait until the send_timeout before closing the connection. These may also be attacks where the malicious clients deliberately do that to exhaust the ...


1

Try to turn off Ethernet PAUSE frames with ethtool -A devname autoneg off rx off tx off If that don't help, it can be a TCP windows scaling problem and/or an IRQ storming issue on the sending or receiver host. You can investigate both problems trying different settings with ethtool and sysctl entries regulating TCP traffic. Without other informations, it is ...


1

You should enable extended status of mod_status (http://httpd.apache.org/docs/2.2/mod/mod_status.html#extendedstatus) in order to monitor the current hosts and requests being processed. I think there's a script(s)/page(s) which takes too much time to release the connection and it makes the connections stacking.


1

5) Will our LAN be limited to 65536 (or some other theoretical limit) concurrent connections to the outside world through a single public IP address? No, because one port NAT IP can be used for multiple connections: cat /proc/net/ip_conntrack | grep 51380 tcp 6 191 ESTABLISHED src=10.1.8.5 dst=17.133.254.23 sport=51380 dport=5223 src=17.133.254.23 ...


1

These are retransmits from the client to the server. Here's what's happening: The client sends 2 segments. One with 117 bytes and one with 85 bytes (pkts 1 and 2) The client waits for an acknowledgement from the server which never comes After about 200ms, the client's retransmit timer expires so it uses repacketization and combines both the previous ...


1

This is caused by the phpredis library we are using to connect to the redis server. Basically phpredis sends a QUIT command to ask the redis server to close the connection. But right after doing that, phpredis closes the tcp socket itself, causing both sides trying to close the connection. Therefore the server has so many connections stuck at CLOSING ...


1

TCP does path MTU discovery to avoid fragmentation which can result in increased packet loss. Applications using UDP have two choices. They can just permit their datagrams to fragment. In that case, they won't get dropped, but if any fragments happen to get dropped, the entire datagram will not be received. This can magnify packet loss rates. They can also ...



Only top voted, non community-wiki answers of a minimum length are eligible