openbmc
openbmc copied to clipboard
SSH AND OUTSIDE PING NOT WORKING WITH LATEST HELIUM BRANCH
Hi ,
We are using the new helium branch openbmc code for wedge100 platform.
With the new code , dhcp is taking in the ip and local ping is working. But ssh and outside ping communication is not working.
Is there some steps we should do to enable this outside world communication ?
Could anyone please help us with this issue ?
Thanks and Regards, Radhika
The SSH server and ping should come up without any changes. Are you using IPv4, IPv6, or both? Are there any useful log messages from dhclient or sshd in /var/log/messages? If you have the right IPv6 network topology, you can also try ping6 to the eth0 IPv6 SLAAC address.
Hi Christopher ,
Thanks for your reply.
What we have is ipv4. We are getting a timeout error when we try to do ssh. And when we try to do "ping www.google.com" we get host not reachable error. No other logs come on dmesg either. We dont have an FRU eeprom in our board like in wedge100.
Thanks and Regards, Radhika
Can you ping your default gateway?
"ip route"
It should have a "default via x.x.x.x dev eth0" , try pinging x.x.x.x . See if you can wget against a local web server in your local network. Compare "ip route" output and interface settings of helium vs fido. What does "traceroute 8.8.8.8" say?
Hi ,
Please find the log from latest and fido version of openbmc
LATEST HELIUM LOG
root@bmc:~# ip route default via x.x.x.x dev eth0 x.x.x.y/24 dev eth0 proto kernel scope link src x.x.x.62 root@bmc:~# ping x.x.x.x PING x.x.x.x (x.x.x.x): 56 data bytes 64 bytes from x.x.x.x: seq=0 ttl=64 time=30.000 ms 64 bytes from x.x.x.x: seq=1 ttl=64 time=0.000 ms 64 bytes from x.x.x.x: seq=2 ttl=64 time=0.000 ms 64 bytes from x.x.x.x: seq=3 ttl=64 time=0.000 ms
^C --- x.x.x.x ping statistics --- 17 packets transmitted, 17 packets received, 0% packet loss round-trip min/avg/max = 0.000/1.764/30.000 ms root@bmc:~# traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *
FIDO LOG
root@bmc:~# ip route x.x.x.y/24 dev eth0 proto kernel scope link src x.x.x.61 192.168.0.0/24 dev usb0 proto kernel scope link src 192.168.0.1 default via x.x.x.x dev eth0 root@bmc:~# ping x.x.x.x PING x.x.x.x (x.x.x.x): 56 data bytes 64 bytes from x.x.x.x: seq=0 ttl=64 time=13.382 ms 64 bytes from x.x.x.x: seq=1 ttl=64 time=1.621 ms 64 bytes from x.x.x.x: seq=2 ttl=64 time=5.344 ms ^C --- x.x.x.x ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 1.621/6.782/13.382 ms root@bmc:~# root@bmc:~# traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets 1 x.x.x.x (x.x.x.x) 3.124 ms 5.386 ms 2.778 ms 2 61.2.209.1 (61.2.209.1) 25.394 ms 25.672 ms 26.294 ms 3 218.248.58.130 (218.248.58.130) 26.155 ms 31.373 ms 51.660 ms 4 * 218.248.235.161 (218.248.235.161) 54.838 ms 218.248.235.141 (218.248.235.141) 118.693 ms 5 * * * 6 72.14.211.114 (72.14.211.114) 55.753 ms 72.14.195.21 (72.14.195.21) 47.449 ms 72.14.211.114 (72.14.211.114) 49.275 ms 7 108.170.253.97 (108.170.253.97) 55.287 ms 57.018 ms 108.170.253.113 (108.170.253.113) 50.486 ms 8 209.85.240.149 (209.85.240.149) 45.847 ms 72.14.239.7 (72.14.239.7) 52.477 ms 72.14.239.9 (72.14.239.9) 52.768 ms 9 google-public-dns-a.google.com (8.8.8.8) 54.816 ms 61.900 ms 53.006 ms
Thanks and Regards, Radhika
I have the same (or similar) problem. I cannot ping to or from the embedded system. The embedded system gets an IP address, so I believe the DHCP has worked. This is with the Helium release on a Portwell Neptune board with AST2500 BMC. Target of build is fbtp-image. Below is a log. Any help would be appreciated.
root@bmc:~# ip route default via 192.168.6.1 dev eth0 192.168.6.0/24 dev eth0 proto kernel scope link src 192.168.6.101 root@bmc:~# ping 192.168.6.1 PING 192.168.6.1 (192.168.6.1): 56 data bytes ^C --- 192.168.6.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss root@bmc:~# ifconfig -a eth0 Link encap:Ethernet HWaddr AE:93:F8:50:D7:1F inet addr:192.168.6.101 Bcast:192.168.6.255 Mask:255.255.255.0 inet6 addr: fe80::ac93:f8ff:fe50:d71f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:29 errors:0 dropped:1 overruns:0 frame:2 TX packets:43 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3928 (3.8 KiB) TX bytes:3100 (3.0 KiB)
eth1 Link encap:Ethernet HWaddr 06:90:B9:DD:30:C6 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:12 errors:0 dropped:0 overruns:0 frame:0 TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1510 (1.4 KiB) TX bytes:1510 (1.4 KiB)
sit0 Link encap:IPv6-in-IPv4 NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
root@bmc:~# root@bmc:~# root@bmc:~# root@bmc:~# traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets 1 192.168.6.101 (192.168.6.101) 3000.000 ms !H 3000.000 ms !H 3000.000 ms !H root@bmc:~# ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.000 ms 64 bytes from 127.0.0.1: seq=1 ttl=64 time=0.000 ms 64 bytes from 127.0.0.1: seq=2 ttl=64 time=0.000 ms 64 bytes from 127.0.0.1: seq=3 ttl=64 time=0.000 ms ^C --- localhost ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.000/0.000/0.000 ms root@bmc:~#
Hi @radhikapradeep , @tlane17
We recently fixed this at (https://github.com/theopolis/linux/commit/9395c7644974cdac19a8321b1d66895c71ee3c26)
Please try building wedge100 with latest code and verify if you still see this issue.
Hi ,
Thanks . Will try the build and let know of the result.
Thanks and Regards, Radhika
I tried the build with the new ftgmac100.c file and I still do not get any response to the ping command. I have an AST2500 in my system so the change for AST2400 does not affect it. Below are some messages from the startup, I noticed an error in the second set of messages that may help. I'm guessing that the NCSI software may be doing something which prevents the normal ethernet traffic from working, as my system is able to perform the DHCP operation at startup and get a valid IP address, but it does not indicate any additional received packets after I log in and attempt to do the ping.
ftgmac100 ftgmac100.0 eth0: irq 2, mapped at dca40000 ftgmac100 ftgmac100.0 eth0: generated random MAC address aa:b0:c0:a5:87:11 dev_attr_cmd_payload registered dev_attr_powerup_prep_host_id registered ftgmac100 ftgmac100.1 eth1: irq 3, mapped at dca80000 ftgmac100 ftgmac100.1 eth1: generated random MAC address b6:ae:38:4a:0b:b0
Configuring network interfaces... Found NCSI NW Controller at (0, 0) NCSI error: Unknown Mezz Vendor! NCSI: MAC 00:00:00:00:00:00: Using NCSI Network Controller (0, 0) done.
Hi @tlane17 The issue you're seeing is different from Radhika originally posted (i.e. pingable but not ssh-able)
The issue you posted appear to be related to NC-SI configuration. During init BMC retrieves MAC from NIC via NC-SI command and configures AST2500. This step seems to have failed from the log you showed. Can you let us know which the vendor/model of the NIC you're using?
The PHY is a Realtek RTL8211E. It is what is provided by Portwell on the Neptune board.
I may have misread the post by Radhika. I thought that he meant that ping to localhost was working but ping was NOT working to outside hosts.
Hi ,
With the new build we first got the ssh and ping working. But it is not permanent with each testing. Most of the times we are not getting the ip address even with dhclient.
Also added the ncsi-util in wedge100-image.bb and enabled CONFIG_FTGMAC100_NCSI=y in kernel. Now we are not getting the ip address with dhclient and getting the same error message for ncsi.
Please find the logs below
root@bmc:~# dhclient -r root@bmc:~# dhclient eth0 root@bmc:~# ifconfig -a eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:01 inet6 addr: fe80::200:ff:fe00:1%984/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:47 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:5442 (5.3 KiB)
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1%984/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:180 errors:0 dropped:0 overruns:0 frame:0 TX packets:180 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:11440 (11.1 KiB) TX bytes:11440 (11.1 KiB)
usb0 Link encap:Ethernet HWaddr 02:00:00:00:00:01 inet6 addr: fe80::1%984/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:64 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
root@bmc:~# dhclient -r root@bmc:~# dhclient eth0 -v Internet Systems Consortium DHCP Client 4.3.3 Copyright 2004-2015 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth0/00:00:00:00:00:01 Sending on LPF/eth0/00:00:00:00:00:01 Sending on Socket/fallback DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4 No DHCPOFFERS received. No working leases in persistent database - sleeping.
NCSI ERROR
INIT: Entering runlevel: 5f Configuring network interfaces... Found NCSI NW Controller at (0, 0) NCSI error: Unknown Mezz Vendor! NCSI: MAC 00:00:00:00:00:00: Using NCSI Network Controller (0, 0)
Please help with this issue.
Thanks and Regards, Radhika
Hi ,
With more testing we found that we are not getting the ip address after enabling the NCSI.
Could anyone please help with this issue.
Thanks and Regards, Radhika
Hello!
NCSI ERROR INIT: Entering runlevel: 5f Configuring network interfaces... Found NCSI NW Controller at (0, 0) NCSI error: Unknown Mezz Vendor! NCSI: MAC 00:00:00:00:00:00: Using NCSI Network Controller (0, 0)
I have such error with Intel i210 NIC. Probably there is not support for i210 in openbmc. As I am right?
Best regards tohas1986