openbmc icon indicating copy to clipboard operation
openbmc copied to clipboard

SSH AND OUTSIDE PING NOT WORKING WITH LATEST HELIUM BRANCH

Open radhikapradeep opened this issue 7 years ago • 13 comments

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

radhikapradeep avatar Sep 25 '17 09:09 radhikapradeep

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.

covracer avatar Sep 25 '17 16:09 covracer

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

radhikapradeep avatar Sep 26 '17 04:09 radhikapradeep

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?

ConSeannery avatar Sep 26 '17 22:09 ConSeannery

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

radhikapradeep avatar Sep 27 '17 11:09 radhikapradeep

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:~#

tlane17 avatar Oct 10 '17 20:10 tlane17

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.

benwei13 avatar Oct 26 '17 18:10 benwei13

Hi ,

Thanks . Will try the build and let know of the result.

Thanks and Regards, Radhika

radhikapradeep avatar Oct 27 '17 03:10 radhikapradeep

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.

tlane17 avatar Oct 27 '17 15:10 tlane17

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?

benwei13 avatar Oct 30 '17 23:10 benwei13

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.

tlane17 avatar Oct 31 '17 13:10 tlane17

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

radhikapradeep avatar Nov 02 '17 11:11 radhikapradeep

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

radhikapradeep avatar Nov 21 '17 12:11 radhikapradeep

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

tohas1986 avatar Aug 06 '18 11:08 tohas1986