This is strange. How this actually works. So far I know it is "impossible" to have a network like this.
I'm going to explain in details how my network works.
I have a LAN. 192.168.1.0/24 and router is on 192.168.1.1, This router has a public address.
I can share the IP address because I'm running there a server for tests nothing more. It is ok so far.
Now the magic happens.
When I trace the route to an IP I got this (To google DNS):
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 zonhub.home (192.168.1.1) 1.160 ms 1.676 ms 1.340 ms
2 * * *
3 10.137.211.97 (10.137.211.97) 12.915 ms 12.526 ms 12.145 ms
4 10.255.49.90 (10.255.49.90) 10.349 ms 10.255.49.102 (10.255.49.102) 11.483 ms 11.042 ms
5 80.157.128.249 (80.157.128.249) 34.577 ms 80.157.130.41 (80.157.130.41) 32.917 ms 80.157.130.33 (80.157.130.33) 30.602 ms
6 mad-sa3-i.MAD.ES.NET.DTAG.DE (217.5.95.161) 33.396 ms 80.157.128.22 (80.157.128.22) 27.107 ms mad-sa3-i.MAD.ES.NET.DTAG.DE (217.5.95.161) 29.510 ms
7 80.157.128.22 (80.157.128.22) 28.050 ms 72.14.235.20 (72.14.235.20) 32.767 ms 80.157.128.22 (80.157.128.22) 27.932 ms
8 72.14.235.20 (72.14.235.20) 29.780 ms 72.14.235.18 (72.14.235.18) 27.020 ms 26.706 ms
9 216.239.43.233 (216.239.43.233) 49.456 ms 209.85.240.191 (209.85.240.191) 44.034 ms 216.239.43.233 (216.239.43.233) 51.935 ms
10 72.14.236.191 (72.14.236.191) 53.374 ms 209.85.253.20 (209.85.253.20) 50.699 ms 216.239.43.233 (216.239.43.233) 44.918 ms
11 209.85.251.231 (209.85.251.231) 50.151 ms * 216.239.49.45 (216.239.49.45) 47.309 ms
12 google-public-dns-a.google.com (8.8.8.8) 51.536 ms 50.180 ms 45.505 ms
What is that 2nd, 3rd and 4th hop? How can it be on class A private address when 192.168.1.1 is running the NAT service where I have my LAN and my external 3 publics addresses (yes I have 3 and is 3 "class A" IP's on 88,89,93 network).
Another thing is how on 4th hop we have the 2nd octet 255?
Anyone feel free to traceroute my no-ip domain: synackfiles.no-ip.org
Just don't mess with my router (it blocks if you port scan or fail to log in in ssh or http auth so you get banned for this. If you just traceroute it is fine) :P
Now, second magic and weird stuff happens.
I'm going to run nmap. So i GOT THIS:
sudo nmap -sV -A -O 10.137.211.113 -vv -p 1-500 -Pn
Starting Nmap 6.00 ( http://nmap.org ) at 2013-11-14 15:24 WET
NSE: Loaded 93 scripts for scanning.
NSE: Script Pre-scanning.
NSE: Starting runlevel 1 (of 2) scan.
NSE: Starting runlevel 2 (of 2) scan.
Initiating Parallel DNS resolution of 1 host. at 15:24
Completed Parallel DNS resolution of 1 host. at 15:24, 0.04s elapsed
Initiating SYN Stealth Scan at 15:24
Scanning 10.137.211.113 [500 ports]
SYN Stealth Scan Timing: About 30.40% done; ETC: 15:26 (0:01:11 remaining)
SYN Stealth Scan Timing: About 60.30% done; ETC: 15:26 (0:00:40 remaining)
Completed SYN Stealth Scan at 15:26, 101.14s elapsed (500 total ports)
Initiating Service scan at 15:26
Initiating OS detection (try #1) against 10.137.211.113
Initiating Traceroute at 15:26
Completed Traceroute at 15:26, 9.05s elapsed
Initiating Parallel DNS resolution of 1 host. at 15:26
Completed Parallel DNS resolution of 1 host. at 15:26, 0.01s elapsed
NSE: Script scanning 10.137.211.113.
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 15:26
Completed NSE at 15:26, 0.00s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Nmap scan report for 10.137.211.113
Host is up (0.0010s latency).
All 500 scanned ports on 10.137.211.113 are filtered
Device type: general purpose|specialized|media device
Running: Barrelfish, Microsoft Windows 2003|PocketPC/CE|XP, Novell NetWare 3.X, Siemens embedded, Telekom embedded
OS CPE: cpe:/o:barrelfish:barrelfish cpe:/o:microsoft:windows_server_2003::sp1 cpe:/o:microsoft:windows_server_2003::sp2 cpe:/o:microsoft:windows_ce cpe:/o:microsoft:windows_xp:::professional cpe:/o:novell:netware:3.12
Too many fingerprints match this host to give specific OS details
TCP/IP fingerprint:
SCAN(V=6.00%E=4%D=11/14%OT=%CT=%CU=%PV=Y%G=N%TM=5284EBAB%P=armv7l-unknown-linux-gnueabi)
T7(R=Y%DF=N%TG=80%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=R)
U1(R=N)
IE(R=N)
TRACEROUTE (using proto 1/icmp)
HOP RTT ADDRESS
1 2.32 ms zonhub.home (192.168.1.1)
2 ... 30
NSE: Script Post-scanning.
NSE: Starting runlevel 1 (of 2) scan.
NSE: Starting runlevel 2 (of 2) scan.
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 122.65 seconds
Raw packets sent: 1109 (49.620KB) | Rcvd: 4 (200B)
Well, this is odd. I don't know how my country's WAN is designed and built.
I'm from Portugal and my ISP is "ZON TVCABO". You can search now. :P
This is very very very interesting..
Sincerely,
int3
I cannot tell you how your providers WAN is built - but in order to
save public IPs - one can design an ISPs internal network with private
IPs. The routers that are not needed to be available from public will
have private IPs only - the IPs assigned to you can be routed to your
uplink over routers that are ISP internally only.
the 2nd hop has no tracing allowed, but allows to forward them.
the 4th - 10.255.x.x is a private IP in the 10.0.0.0/8 A range. (you
can use numbers from 0-255)
Related
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed last month.
Improve this question
System: Host: rpi32 Kernel: 5.15.56-v7+ armv7l bits: 32 Console: tty 0 Distro: Raspbian GNU/Linux 11 (bullseye)
Machine: Type: ARM Device System: Raspberry Pi 3 Model B Rev 1.2 details: BCM2835 rev: a22082 serial: 000000009a5073f1
I had a working machine before the upgrade, ntp, dhcp (is actually isc-dhcpserver), dns all working.
Then upgraded the OS (to Bullseye) and could no longer connect to the rPi.
dmesg revealed that eth0 could not be connected to.
The interface was identified as enxb827eb5073f1. en = Ethernet plus MAC address.
Some research revealed that what I am seeing is called "Predictable Network Interface Names".
It said this is the new standard/approach, due to multi-interface machines not necessarily assigning the interface name at kernel boot; e.g., it could be eth0 on one boot, and eth1 during another; not good for firewalls, etc.
So I changed the following config files to get dhcp working:
/etc/default/isc-dhcp-server
/etc/network/interfaces
/etc/dhcp/dhcpd.conf
... and changed eth0 to enxb827eb5073f1.
No luck.
sudo service dhcpcd status
● dhcpcd.service - dhcpcd on all interfaces
Loaded: loaded (/lib/systemd/system/dhcpcd.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/dhcpcd.service.d
└─wait.conf
Active: failed (Result: exit-code) since Fri 2022-08-19 15:04:18 AEST; 28min ago
Process: 859 ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -w (code=exited, status=6)
CPU: 11ms
Aug 19 15:04:18 rpi32 systemd[1]: Starting dhcpcd on all interfaces...
Aug 19 15:04:18 rpi32 dhcpcd[859]: Not running dhcpcd because /etc/network/interfaces
Aug 19 15:04:18 rpi32 dhcpcd[859]: defines some interfaces that will use a
Aug 19 15:04:18 rpi32 dhcpcd[859]: DHCP client or static address
Aug 19 15:04:18 rpi32 systemd[1]: dhcpcd.service: Control process exited, code=exited, status=6/NOTCONFIGURED
Aug 19 15:04:18 rpi32 systemd[1]: dhcpcd.service: Failed with result 'exit-code'.
Aug 19 15:04:18 rpi32 systemd[1]: Failed to start dhcpcd on all interfaces.
and
dhcpd -t /etc/dhcp/dhcpd.conf
/etc/dhcp/dhcpd.conf: interface name too long (is 20)
Researching this topic pointed to incorrect dhcpd config, pointing to udev rules, and I do not understand, and from what I could see, did not contain interface reference.
I read here: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ that this naming scheme can be reverted by adding this: net.ifnames=0 to the kernel command line (/boot/cmdline.txt).
This is what I did. I reverted all changes in the three config files listed above, plus in the cmdline.txt.
(I rebooted as required after these changes.)
and dhcpd -t /etc/dhcp/dhcpd.conf still returns:
/etc/dhcp/dhcpd.conf: interface name too long (is 20)
All services work, except dhcp (ntp is back up as well, as no changes where made here WRT eth0 changes).
Now I wonder what else I need to do to get dhcp working again.
Config files:
ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.8 netmask 255.255.255.0 broadcast 192.168.1.255
ether b8:27:eb:50:73:f1 txqueuelen 1000 (Ethernet)
RX packets 14682 bytes 1148952 (1.0 MiB)
RX errors 0 dropped 3460 overruns 0 frame 0
TX packets 7079 bytes 1063400 (1.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 105 bytes 10173 (9.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 105 bytes 10173 (9.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
cat /etc/default/isc-dhcp-server
# Path to dhcpd's config file (default: /etc/dhcp/dhcpd.conf).
DHCPDv4_CONF=/etc/dhcp/dhcpd.conf
#DHCPDv6_CONF=/etc/dhcp/dhcpd6.conf
# Path to dhcpd's PID file (default: /var/run/dhcpd.pid).
DHCPDv4_PID=/var/run/dhcpd.pid
#DHCPDv6_PID=/var/run/dhcpd6.pid
#OPTIONS=""
# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
# Separate multiple interfaces with spaces, e.g. "eth0 eth1".
#INTERFACESv4="enxb827eb5073f1"
INTERFACESv4="eth0"
#INTERFACESv6=""
cat /etc/dhcpcd.conf
# A sample configuration for dhcpcd.
# Inform the DHCP server of our hostname for DDNS.
hostname
# Use the hardware address of the interface for the Client ID.
clientid
# Persist interface configuration when dhcpcd exits.
persistent
# Rapid commit support.
option rapid_commit
# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu
# Most distributions have NTP support.
#option ntp_servers
# A ServerID is required by RFC2131.
require dhcp_server_identifier
# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private
cat /etc/dhcp/dhcpd.conf
# 190803-1530 installed DHCP server on rPi32
#
# 170611-1933 MaxG: changed from none to interim
#ddns-update-style none;
ddns-update-style interim;
# 170612-2300 MaxG: added based on
# https://blog.bigdinosaur.org/running-bind9-and-isc-dhcp/
ddns-updates on;
update-static-leases on;
ddns-domainname "argylecourt.lan";
ddns-rev-domainname "in-addr.arpa.";
authoritative;
# 190804-1424 MaxG: added key and 2 zones
key DHCP_UPDATER {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
# Important: Replace this key with your generated key.
# Also note that the key should be surrounded by quotes.
secret "someKeyBlah";
};
zone argylecourt.lan. {
primary 127.0.0.1;
key DHCP_UPDATER;
}
zone 1.168.192.in-addr.arpa. {
primary 127.0.0.1;
key DHCP_UPDATER;
}
# 150301 MaxG - added to shut up Windows PC from clogging
# syslog with DHCPACK and DHCPINFORM msgs (WPAD)
option wpad-url code 252 = text;
# my subnet specifications
subnet 192.168.1.0 netmask 255.255.255.0 {
#interface enxb827eb5073f1;
# pool range; can have multiple ranges in this file
range 192.168.1.50 192.168.1.199;
option subnet-mask 255.255.255.0;
option routers 192.168.1.1;
ddns-domainname "argylecourt.lan";
ddns-rev-domainname "in-addr.arpa";
option broadcast-address 192.168.1.255;
option domain-name "argylecourt.lan";
option domain-name-servers 192.168.1.8;
option ntp-servers 192.168.1.8; # Default NTP server to be used by DHCP clients
default-lease-time 86400; # 1 day
max-lease-time 604800; # 7 days
option wpad-url "\n";
}
# reservations; must NOT be in pool
# sorted by assinged IP address
host maxg-x570 {
# MaxG's PC -- x570
# added 20220409-2106
hardware ethernet 04:42:1a:95:2b:37;
fixed-address 192.168.1.13;
}
host brother-mfc {
# Brother Network Printer -- BRN_368926
hardware ethernet 00:80:77:36:89:26;
fixed-address 192.168.1.33;
ddns-hostname "brothermfc8820d";
}
I ran into the same situation and was not able to tell where the mistake was.
try $ dhcpd /etc/dhcp/
this will search the whole file and will point directly where the mistake is
Well, well... how embarrassing!
The solution is simple:
sudo service isc-dhcp-server start
Start the correct service. It is not dhcp, it is isc-dhcp-server!
What I do not understand is why this service was no longer auto-starting.
Anyway, problem, or rather stupidity solved.
I installed Ubuntu 18.04 on Hyper-V Win Server 2016.
And network performance of the Ubuntu is bad: I'm hosting few sites (Apache + PHP) and sometime response time is > 10 seconds. Sometimes it is fast.
As I troubleshooted, I see this netstat results:
# netstat -s | egrep -i 'loss|retran'
3447700 segments retransmitted
226 times recovered from packet loss due to fast retransmit
Detected reordering 6 times using reno fast retransmit
TCPLostRetransmit: 79831
45 timeouts after reno fast retransmit
6247 timeouts in loss state
2056435 fast retransmits
107095 retransmits in slow start
TCPLossProbes: 220607
TCPLossProbeRecovery: 3753
TCPSynRetrans: 90564
What can be cause of such high "segments retransmitted" number? And how to fix it?
Few notes:
- VMQ is disabled for Ubuntu VM
- The host system Network adapter is Intel I210
- I disabled IPv6 both on host and in VM
Here is WireShark showing, that it takes ~7 seconds to connect (just initial connection) to my site Propovednik.com:
Sep 20: So far, the issue seems to be caused by OVH / SoYouStart bad network:
This command shows 20-30% packets loss:
sudo ping us.soyoustart.com -c 10 -i 0.2 -p 00 -s 1200 -l 5
The problem could be anywhere along the network, including the workstation where you work from. I suggest you check the network as retransmissions and packetloss means that either something is malfunctioning or misconfigured. If this is on a wireless network, you could be out of range of your router.
I am pinging the website you noted from my computer and there is no packetloss.
package main
import (
"io"
"net/http"
)
func hello(w http.ResponseWriter, r *http.Request) {
io.WriteString(w, "Hello world!\n")
}
func main() {
http.HandleFunc("/", hello)
http.ListenAndServe(":8000", nil)
}
I've got a couple of incredibly basic HTTP servers, and all of them are exhibiting this problem.
$ ab -c 1000 -n 10000 http://127.0.0.1:8000/
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
apr_socket_recv: Connection refused (61)
Total of 5112 requests completed
With a smaller concurrency value, things still fall over. For me, the issue seems to show up around the 5k-6k mark usually:
$ ab -c 10 -n 10000 http://127.0.0.1:8000/
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
apr_socket_recv: Operation timed out (60)
Total of 6277 requests completed
And in fact, you can drop concurrency entirely and the problem still (sometimes) happens:
$ ab -c 1 -n 10000 http://127.0.0.1:8000/
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
apr_socket_recv: Operation timed out (60)
Total of 6278 requests completed
I can't help but wonder if I'm hitting some kind of operating system limit somewhere? How would I tell? And how would I mitigate?
In short, you're running out of ports.
The default ephemeral port range on osx is 49152-65535, which is only 16,383 ports. Since each ab request is http/1.0 (without keepalive in your first examples), each new request takes another port.
As each port is used, it get's put into a queue where it waits for the tcp "Maximum Segment Lifetime", which is configured to be 15 seconds on osx. So if you use more than 16,383 ports in 15 seconds, you're effectively going to get throttled by the OS on further connections. Depending on which process runs out of ports first, you will get connection errors from the server, or hangs from ab.
You can mitigate this by using an http/1.1 capable load generator like wrk, or using the keepalive (-k) option for ab, so that connections are reused based on the tool's concurrency settings.
Now, the server code you're benchmarking does so little, that the load generator is being taxed just as much as the sever itself, with the local os and network stack likely making a good contribution. If you want to benchmark an http server, it's better to do some meaningful work from multiple clients not running on the same machine.
IP address of source host is 10.192.240.10 and destination is 10.192.250.10. do the both hosts reside on same network or not ?
If so, How can we find it.
The first thing to know is the netmask. If the bits that are different are in the zero range of the netmask, then they should route on the same network. For instance, my home network uses 192.168.0.0/255.255.254.0 which means that 192.168.0.0-192.168.1.255 are routed by my home router ... 192.168.1.10 is on the same network with 192.168.0.10.
You could also try to traceroute from one to the other to determine how many hops. One hop means there's no active routing between the hosts, thus most likely the same network.
One hop, same network (kinda .. desktop is a wired connection, remote is a wireless connection; but from an IP point of view, the same):
paulw#desktop:~/PROJ$ traceroute 192.168.1.208
traceroute to 192.168.1.208 (192.168.1.208), 30 hops max, 60 byte packets
1 remote (192.168.1.208) 218.838 ms 219.288 ms 219.484 ms
paulw#desktop:~/PROJ$
Many hops, different network:
paulw#desktop:~/PROJ$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 router.asus.com (192.168.1.1) 0.232 ms 0.410 ms 0.485 ms
2 xx.xxx.xx.x (xx.xxx.xx.x) 161.662 ms 161.701 ms 161.701 ms
3 xe-10-3-3-32767-sur03.arvada.co.denver.comcast.net (68.86.129.153) 87.925 ms 87.963 ms 88.518 ms
4 te-0-13-0-2-ar02.denver.co.denver.comcast.net (162.151.8.41) 89.585 ms xe-10-0-2-0-sur02.arvada.co.denver.comcast.net (68.86.128.138) 89.493 ms te-0-13-0-2-ar02.denver.co.denver.comcast.net (162.151.8.41) 89.574 ms
5 pos-0-7-0-0-ar02.aurora.co.denver.comcast.net (68.86.128.246) 91.431 ms 92.441 ms 97.540 ms
6 he-3-9-0-0-cr01.denver.co.ibone.comcast.net (68.86.92.21) 92.421 ms 95.757 ms 96.290 ms
7 xe-1-0-2-0-pe01.910fifteenth.co.ibone.comcast.net (68.86.84.122) 159.017 ms 74.074 ms 74.119 ms
8 as15169-1-c.910fifteenth.co.ibone.comcast.net (23.30.206.106) 74.667 ms 73.637 ms 73.654 ms
9 72.14.234.59 (72.14.234.59) 74.204 ms 72.14.234.57 (72.14.234.57) 78.921 ms 72.14.234.59 (72.14.234.59) 77.861 ms
10 216.239.46.146 (216.239.46.146) 89.413 ms 216.239.46.150 (216.239.46.150) 84.180 ms 216.239.46.146 (216.239.46.146) 83.705 ms
11 216.239.46.55 (216.239.46.55) 88.090 ms 72.14.239.50 (72.14.239.50) 27.409 ms 81.115 ms
12 216.239.46.193 (216.239.46.193) 85.238 ms 216.239.46.191 (216.239.46.191) 81.420 ms 216.239.43.217 (216.239.43.217) 81.457 ms
13 * * *
14 google-public-dns-a.google.com (8.8.8.8) 82.888 ms 83.473 ms 85.024 ms
paulw#desktop:~/PROJ$
OK, we all know how to use PING to test connectivity to an IP address. What I need to do is something similar but test if my outbound request to a given IP Address as well as a specif port (in the present case 1775) is successful. The test should be performed preferably from the command prompt.
Here is a small site I made allowing to test any outgoing port. The server listens on all TCP ports available.
http://portquiz.net
telnet portquiz.net XXXX
If there is a server running on the target IP/port, you could use Telnet. Any response other than "can't connect" would indicate that you were able to connect.
To automate the awesome service portquiz.net, I did write a bash script :
NB_CONNECTION=10
PORT_START=1
PORT_END=1000
for (( i=$PORT_START; i<=$PORT_END; i=i+NB_CONNECTION ))
do
iEnd=$((i + NB_CONNECTION))
for (( j=$i; j<$iEnd; j++ ))
do
#(curl --connect-timeout 1 "portquiz.net:$j" &> /dev/null && echo "> $j") &
(nc -w 1 -z portquiz.net "$j" &> /dev/null && echo "> $j") &
done
wait
done
If you're testing TCP/IP, a cheap way to test remote addr/port is to telnet to it and see if it connects. For protocols like HTTP (port 80), you can even type HTTP commands and get HTTP responses.
eg
Command IP Port
Telnet 192.168.1.1 80
The fastest / most efficient way I found to to this is with nmap and portquiz.net described here: http://thomasmullaly.com/2013/04/13/outgoing-port-tester/ This scans to top 1000 most used ports:
# nmap -Pn --top-ports 1000 portquiz.net
Starting Nmap 6.40 ( http://nmap.org ) at 2017-08-02 22:28 CDT
Nmap scan report for portquiz.net (178.33.250.62)
Host is up (0.072s latency).
rDNS record for 178.33.250.62: electron.positon.org
Not shown: 996 closed ports
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
443/tcp open https
8080/tcp open http-proxy
Nmap done: 1 IP address (1 host up) scanned in 4.78 seconds
To scan them all (took 6 sec instead of 5):
# nmap -Pn -p1-65535 portquiz.net
The bash script example of #benjarobin for testing a sequence of ports did not work for me so I created this minimal not-really-one-line (command-line) example which writes the output of the open ports from a sequence of 1-65535 (all applicable communication ports) to a local file and suppresses all other output:
for p in $(seq 1 65535); do curl -s --connect-timeout 1 portquiz.net:$p >> ports.txt; done
Unfortunately, this takes 18.2 hours to run, because the minimum amount of connection timeout allowed integer seconds by my older version of curl is 1. If you have a curl version >=7.32.0 (type "curl -V"), you might try smaller decimal values, depending on how fast you can connect to the service. Or try a smaller port range to minimise the duration.
Furthermore, it will append to the output file ports.txt so if run multiple times, you might want to remove the file first.