I have a AST2600 evb board. After power on (w/ RJ45 connected), it boots into a OpenBMC kernel. From serial port, using ip command I can obtain its IP address. From my laptop, I can ssh into the board using account root/0penBmc:
bruin#gen81:/$ ssh root#192.168.6.132
root#192.168.6.132's password:
Then I want to find out which tcp ports are open. As there is no ss/lsof/netstat utilities, I cat /proc/net/tcp:
root#AMIfa7ba648f62e:/proc/net# cat /proc/net/tcp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
0: 00000000:14EB 00000000:0000 0A 00000000:00000000 00:00000000 00000000 997 0 9565 1 0c202562 100 0 0 10 0
1: 3500007F:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000 997 0 9571 1 963c8114 100 0 0 10 0
The strange thing puzzled me is that that tcp port 22 is not listed in /proc/net/tcp, which suggests that no process is listening on tcp port 22. If this is true, how the ssh connection is established?
Btw, as tested using ps, it's the dropbear process who is handling the ssh connection, and the dropbear is spawned dynamically (i.e., if no ssh connection, no such process exist; if I made two ssh connection, two dropbear processes were spawned).
PS: as suggested by John in his reply, I added the ss utilities into the image, and it shows what I expected:
root#AMI8287361b9c6f:~# ss -antp
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 0 0.0.0.0:5355 0.0.0.0:* users:(("systemd-resolve",pid=239,fd=12))
LISTEN 0 0 127.0.0.1:5900 0.0.0.0:* users:(("obmc-ikvm",pid=314,fd=5))
LISTEN 0 0 127.0.0.53:53 0.0.0.0:* users:(("systemd-resolve",pid=239,fd=17))
LISTEN 0 0 *:443 *:* users:(("bmcweb",pid=325,fd=3),("systemd",pid=1,fd=41))
LISTEN 0 0 *:5355 *:* users:(("systemd-resolve",pid=239,fd=14))
LISTEN 0 0 *:5900 *:* users:(("obmc-ikvm",pid=314,fd=6))
LISTEN 0 0 *:22 *:* users:(("systemd",pid=1,fd=49))
LISTEN 0 0 *:2200 *:* users:(("systemd",pid=1,fd=50))
ESTAB 0 0 [::ffff:192.168.6.89]:22 [::ffff:192.168.6.98]:34906 users:(("dropbear",pid=485,fd=2),("dropbear",pid=485,fd=1),("dropbear",pid=485,fd=0),("systemd",pid=1,fd=20))
Good question.
First, it is pretty straigt forward to add common tools/utitlies to an image.
It could be added (for local testing only) by adding a line
OBMC_IMAGE_EXTRA_INSTALL:append = " iproute2 iproute2-ss"
to the https://github.com/openbmc/openbmc/blob/master/meta-aspeed/conf/machine/evb-ast2600.conf file (or to your own testing/deveopment layer). Adding useful tools is often worth it.
Second, if you are using ipv6 you will need to check /proc/net/tcp6
Third, you can also look for a port by looking up the pid of your application ps | grep <application name>. Then reading the port used by that pid cat /proc/<pid>/net/tcp
Last, if you have any more question or these steps don't work. Please reach out to us on discord https://discord.com/invite/69Km47zH98 or Email https://lists.ozlabs.org/listinfo/openbmc (they are the preferred place to ask questions)
On one of my systems at work good ol' netstat shows multicast group membership information, and ss is missing a couple. I wonder why. For example:
[root#myhost ~]# netstat -gn | egrep "Inter|239.192"
Interface RefCnt Group
em4.204 1 239.192.33.183
em1.16 2 239.192.35.1
em1.16 2 239.192.12.98
em1.16 1 239.192.32.1
[root#myhost ~]# ss -apu | egrep "State|239.192"
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 0 239.192.35.1:12965 *:*
UNCONN 0 0 239.192.12.98:12965 *:*
UNCONN 0 0 239.192.35.1:12965 *:*
UNCONN 0 0 239.192.12.98:12965 *:*
Notice that ss shows only those groups with a RefCnt of 2.
Technically, ip maddr show is the replacement for netstat -gn but it doesn't include the RefCnt, and its output is more cumbersome. Also, we're interested in the more detailed output of ss which can include the PID of the listening processes (not seen here because no processes are actually currently listening to the multicast, as show by netstat -ulpn:
[root#myhost ~]# netstat -ulpn | egrep "Proto|239.192"
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 239.192.35.1:12965 0.0.0.0:* -
udp 4480 0 239.192.12.98:12965 0.0.0.0:* -
udp 0 0 239.192.35.1:12965 0.0.0.0:* -
udp 0 0 239.192.12.98:12965 0.0.0.0:* -
I have setup a pxeboot which basically works fine. I can run any configured linux image.
Then I have enabled the firewall, released UDP port 69 for TFTP
~# iptables -L |grep tftp
ACCEPT udp -- anywhere anywhere udp dpt:tftp
ACCEPT udp -- anywhere anywhere udp dpt:tftp
~# netstat -tulp|grep tftp
udp 0 0 0.0.0.0:tftp 0.0.0.0:* 15869/in.tftpd
udp6 0 0 [::]:tftp [::]:* 15869/in.tftpd
~# cat /etc/services|grep tftp
tftp 69/udp
and now I get a timeout when pxeboot is pulling tftp://192.168.0.220/images/pxelinux.0 (rc = 4c126035).
Anywhere is ok here for now as there is another firewall running between the pxeserver and the router which blocks everything unwanted from/to WAN
The funny part is that tcpdump shows that the request is incoming on the pxeboot server:
~# tcpdump port 69
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp5s0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:00:47.062723 IP 192.168.0.136.1024 > mittelerde.tftp: 47 RRQ "images/pxelinux.0" octet blksize 1432 tsize 0
14:00:47.415412 IP 192.168.0.136.1024 > mittelerde.tftp: 47 RRQ "images/pxelinux.0" octet blksize 1432 tsize 0
14:00:48.184506 IP 192.168.0.136.1024 > mittelerde.tftp: 47 RRQ "images/pxelinux.0" octet blksize 1432 tsize 0
14:00:49.722630 IP 192.168.0.136.1024 > mittelerde.tftp: 47 RRQ "images/pxelinux.0" octet blksize 1432 tsize 0
14:00:52.798136 IP 192.168.0.136.1024 > mittelerde.tftp: 47 RRQ "images/pxelinux.0" octet blksize 1432 tsize 0
Once I stop the firewall service pxeboot works fine again. Of course the conntrack module is loaded:
~# lsmod|grep conntrack
nf_conntrack_tftp 16384 0
nf_conntrack_ftp 20480 0
xt_conntrack 16384 4
nf_conntrack_ipv4 16384 20
nf_defrag_ipv4 16384 1 nf_conntrack_ipv4
nf_conntrack 131072 9 xt_conntrack,nf_nat_masquerade_ipv4,nf_conntrack_ipv4,nf_nat,nf_conntrack_tftp,ipt_MASQUERADE,nf_nat_ipv4,xt_nat,nf_conntrack_ftp
libcrc32c 16384 2 nf_conntrack,nf_nat
x_tables 40960 8 xt_conntrack,iptable_filter,xt_multiport,xt_tcpudp,ipt_MASQUERADE,xt_nat,xt_comment,ip_tables
What I am missing here?
Problem solved. For tftpd-hpa the following UDP ports must be open as well:
1024
49152:49182
I'm tryign to telnet from one linux env (10.205.116.141) to 10.205.117.246 on port 7199 but keep getting a connection refused. I did a chkconfig iptables off on both servers and even make sure iptables if stopped as well.
what else should I be looking at?
[root#ip-10-205-116-141 bin]# telnet 10.205.117.246 7199
Trying 10.205.117.246...
telnet: connect to address 10.205.117.246: Connection refused
trace route seems to be working as well...
[root#ip-10-205-116-141 bin]# traceroute 10.205.117.246 -p 7199
traceroute to 10.205.117.246 (10.205.117.246), 30 hops max, 60 byte packets
1 ip-10-205-117-246.xyz.cxcvs.com (10.205.117.246) 0.416 ms 0.440 ms 0.444 ms
also, I'm on a aws vpc so we don't get public IPs provisioned for use...
checked my security group and it looks like all ports are open as well
EDIT:
here is netstat as well, they look the same on both nodes:
[ec2-user#ip-10-205-116-141 ~]$ netstat -an | grep LISTEN
tcp 0 0 127.0.0.1:46626 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:9160 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:36523 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:9042 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2738 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 10.205.116.141:7000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8089 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:4445 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:7199 0.0.0.0:* LISTEN
shouldn't 127.0.0.1:7199 really be 10.205.116.141:7199?
sorry, can't post a sc of the security groups...
On Oracle Linux "Linux bjzv0880 3.8.13-16.2.1.el6uek.x86_64 #1 SMP Thu Nov 7 17:01:44 PST 2013 x86_64 x86_64 x86_64 GNU/Linux"
I have 1 TCP Server and 2 TCP Clients running with the connection status below:
******[root]# netstat -anp | grep 58000
tcp 0 0 192.168.250.102:58000 0.0.0.0:* LISTEN 3614/AppServer
tcp 0 0 192.168.250.102:44500 192.168.250.102:58000 ESTABLISHED 3673/AppClient1
tcp 0 0 192.168.250.102:44488 192.168.250.102:58000 ESTABLISHED 3631/AppClient2
tcp 0 0 192.168.250.102:58000 192.168.250.102:44500 ESTABLISHED 3614/AppServer
tcp 0 0 192.168.250.102:58000 192.168.250.102:44488 ESTABLISHED 3614/AppServer******
Then I forcefully stop the AppServer without cleaning up the socket. And make the AppClient* to try to reconnect to AppServer very quickly. After a little moment, I got a weird connection:
*[root]# netstat -anp | grep 58000
tcp 0 0 192.168.250.102:58000 192.168.250.102:58000 ESTABLISHED 3673/AppClient1*
Note: I have done a wireshark capture on the tcp communication, and from the traffic log
1. there are 2 rounds of retries to connect from source port selected by OS
2. In the 1st round, 58000 was not selected by OS
3. but in the 2nd round, 58000 was selected and it happened to be able to established
How could it be possible? Appreciated for your advice.