Works like a charm. Thank you! Simon Filgis <si...@ingenieurbuero-filgis.de> schrieb am Fr., 9. Feb. 2024, 19:58:
> I ordered a new board, to have more time testing at home and to rules out > hw error... > > Thank you for the effort!! > > Roberto Bucher <roberto.bucher.2...@gmail.com> schrieb am Fr., 9. Feb. > 2024, 19:50: > >> Tested on NUCLEO-H743ZI2 board with >> >> ./tools/configure.sh nucleo-h743zi2:pysim >> >> My PC has WIFI and the nucleo board connected to the WIFI box >> >> bucher@debian:~/sviluppo/NUTTX/nuttx$ tio /dev/ttyACM0 >> [18:58:30.631] tio v2.7 >> [18:58:30.631] Press ctrl-t q to quit >> [18:58:30.631] Connected >> telnetd [5:100] >> >> NuttShell (NSH) NuttX-12.4.0 >> nsh> ifconfig >> eth0 Link encap:Ethernet HWaddr 52:d3:8e:aa:5d:41 at UP mtu 1486 >> inet addr:192.168.1.251 DRaddr:192.168.1.1 Mask:255.255.255.0 >> >> lo Link encap:Local Loopback at RUNNING mtu 1518 >> inet addr:127.0.0.1 DRaddr:127.0.0.1 Mask:255.0.0.0 >> >> IPv4 TCP UDP ICMP >> Received 0002 0000 0002 0000 >> Dropped 0000 0000 0000 0000 >> IPv4 VHL: 0000 Frg: 0000 >> Checksum 0000 0000 0000 ---- >> TCP ACK: 0000 SYN: 0000 >> RST: 0000 0000 >> Type 0000 ---- ---- 0000 >> Sent 0002 0000 0002 0000 >> Rexmit ---- 0000 ---- ---- >> nsh> ping 192.168.1.155 >> PING 192.168.1.155 56 bytes of data >> 56 bytes from 192.168.1.155: icmp_seq=0 time=89.0 ms >> 56 bytes from 192.168.1.155: icmp_seq=1 time=116.0 ms >> 56 bytes from 192.168.1.155: icmp_seq=2 time=47.0 ms >> 56 bytes from 192.168.1.155: icmp_seq=3 time=82.0 ms >> 56 bytes from 192.168.1.155: icmp_seq=4 time=112.0 ms >> 56 bytes from 192.168.1.155: icmp_seq=5 time=40.0 ms >> 56 bytes from 192.168.1.155: icmp_seq=6 time=77.0 ms >> 56 bytes from 192.168.1.155: icmp_seq=7 time=110.0 ms >> 56 bytes from 192.168.1.155: icmp_seq=8 time=42.0 ms >> 56 bytes from 192.168.1.155: icmp_seq=9 time=74.0 ms >> 10 packets transmitted, 10 received, 0% packet loss, time 10010 ms >> rtt min/avg/max/mdev = 40.000/78.900/116.000/27.332 ms >> nsh> >> >> Best regards >> >> Roberto >> >> On 2/9/24 18:23, Simon Filgis wrote: >> > Dear all, >> > >> > I'm back at the board (NUCLEO-H743ZI2). Using latest master (with >> > >> https://github.com/apache/nuttx/commit/31817335e453eec65e8f5d1163c32efd5da373cb >> ) >> > and pysim config is stable. >> > >> > But I am not able to ping. I tried the following setups: >> > PC <-> Nucleo-Board >> > PC <-> Switch <-> Nucleo-Board >> > >> > *Here the output from the board:* >> > nsh> ping 192.168.178.1 >> > PING 192.168.178.1 56 bytes of data >> > No response from 192.168.178.1: icmp_seq=0 time=1000 ms >> > No response from 192.168.178.1: icmp_seq=1 time=1000 ms >> > No response from 192.168.178.1: icmp_seq=2 time=1000 ms >> > No response from 192.168.178.1: icmp_seq=3 time=1000 ms >> > No response from 192.168.178.1: icmp_seq=4 time=1000 ms >> > No response from 192.168.178.1: icmp_seq=5 time=1000 ms >> > No response from 192.168.178.1: icmp_seq=6 time=1000 ms >> > No response from 192.168.178.1: icmp_seq=7 time=1000 ms >> > No response from 192.168.178.1: icmp_seq=8 time=1000 ms >> > No response from 192.168.178.1: icmp_seq=9 time=1000 ms >> > 10 packets transmitted, 0 received, 100% packet loss, time 10010 ms >> > nsh> ifconfig >> > eth0 Link encap:Ethernet HWaddr 02:55:10:e5:49:a2 at UP mtu 1486 >> > inet addr:192.168.178.5 DRaddr:192.168.178.1 Mask:255.255.255.0 >> > >> > lo Link encap:Local Loopback at RUNNING mtu 1518 >> > inet addr:127.0.0.1 DRaddr:127.0.0.1 Mask:255.0.0.0 >> > >> > IPv4 TCP UDP ICMP >> > Received *0020* 0000 001e 0000 *--> there seems to be some >> traffic* >> > Dropped 0002 0000 0000 0000 >> > IPv4 VHL: 0000 Frg: 0000 >> > Checksum 0000 0000 0000 ---- >> > TCP ACK: 0000 SYN: 0000 >> > RST: 0000 0000 >> > Type 0000 ---- ---- 0000 >> > Sent 000a 0000 0000 000a >> > Rexmit ---- 0000 ---- ---- >> > nsh> >> > >> > *And the output of the PC:* >> > ping 192.168.178.5 >> > PING 192.168.178.5 (192.168.178.5) 56(84) bytes of data. >> > From 192.168.178.1 icmp_seq=1 Destination Host Unreachable >> > From 192.168.178.1 icmp_seq=2 Destination Host Unreachable >> > >> > What could it be that I'm doing wrong? Is using DHCP mandatory with >> this >> > config? I set a initial IP adress via menuconfig and I also tried with >> > ifconfig eth0 192.... >> > >> > Thanks for your help, >> > >> > Simon >> > >> > -- >> > Hard- and Softwaredevelopment Consultant >> > Ingenieurbüro-Filgis >> > USt-IdNr.: DE305343278 >> > >> > >> > On Wed, Feb 7, 2024 at 10:58 AM Roberto Bucher < >> > roberto.bucher.2...@gmail.com> wrote: >> > >> >> I did some tests and sometimes it works and sometimes (the most >> >> times...) it gives the error... >> >> >> >> The error usually appears when I give the command >> >> >> >> nsh> ifconfig >> >> >> >> or >> >> >> >> nsh> renew eth0 >> >> >> >> but not all the times. I think that it can be a problem with memory >> >> sizes; I'll try more investigations >> >> >> >> BR >> >> >> >> Roberto >> >> >> >> NuttShell (NSH) NuttX-12.4.0-RC0 >> >> nsh> ping 192.168.1.155 >> >> PING 192.168.1.155 56 bytes of data >> >> 56 bytes from 192.168.1.155: icmp_seq=0 time=38.0 ms >> >> 56 bytes from 192.168.1.155: icmp_seq=1 time=62.0 ms >> >> 56 bytes from 192.168.1.155: icmp_seq=2 time=104.0 ms >> >> 56 bytes from 192.168.1.155: icmp_seq=3 time=124.0 ms >> >> 56 bytes from 192.168.1.155: icmp_seq=4 time=62.0 ms >> >> 56 bytes from 192.168.1.155: icmp_seq=5 time=84.0 ms >> >> 56 bytes from 192.168.1.155: icmp_seq=6 time=12.0 ms >> >> 56 bytes from 192.168.1.155: icmp_seq=7 time=46.0 ms >> >> 56 bytes from 192.168.1.155: icmp_seq=8 time=75.0 ms >> >> 56 bytes from 192.168.1.155: icmp_seq=9 time=106.0 ms >> >> 10 packets transmitted, 10 received, 0% packet loss, time 10010 ms >> >> rtt min/avg/max/mdev = 12.000/71.300/124.000/32.655 ms >> >> nsh> ifconfig >> >> eth0 Link encap:Ethernet HWaddr 52:d3:8e:aa:5d:41 at UP mtu 1486 >> >> inet addr:192.168.1.251 DRaddr:192.168.1.1 Mask:255.255.255.0 >> >> >> >> lo Link encap:Local Loopback at RUNNING mtu 1518 >> >> inet addr:127.0.0.1 DRaddr:127.0.0.1 Mask:255.0.0.0 >> >> >> >> IPv4 TCP UDP ICMP >> >> Received 000c 0000 0002 000a >> >> Dropped 0000 0000 0000 0000 >> >> IPv4 VHL: 0000 Frg: 0000 >> >> Checksum 0000 0000 0000 ---- >> >> TCP ACK: 0000 SYN: 0000 >> >> RST: 0000 0000 >> >> Type 0000 ---- ---- 0000 >> >> Sent 000c 0000 0002 000a >> >> Rexmit ---- 0000 ---- ---- >> >> >> >> >> >> >> >> On 2/6/24 16:55, Gregory Nutt wrote: >> >>> The network monitor is part of apps/netutils/netinit so it is not a >> >>> part of NSH. NSH can automatically perform the network initialization >> >>> if so configured and which, optionally, starts the network monitor >> >>> thread. But the logic is not architecturally a part of NSH nor does >> >>> it depend on N SH. >> >>> >> >>> On 2/6/2024 9:32 AM, Nathan Hartman wrote: >> >>>> On Tue, Feb 6, 2024 at 8:45 AM Sebastien Lorquet < >> sebast...@lorquet.fr> >> >>>> wrote: >> >>>> >> >>>>> However, the default network configuration provided in NuttX >> >>>>> examples is >> >>>>> cumbersome and too much linked with NSH >> >>>>> >> >>>>> It can work for simple tests and demos, but you will have to write a >> >>>>> proper network management daemon if you plan to use more than one >> >>>>> network app. >> >>>> >> >>>> It would be a nice thing if the network management daemon could be >> >>>> factored >> >>>> out of NSH so that boards that don't run NSH could have the same >> network >> >>>> management without implementing it again. >> >>>> >> >>>> Cheers >> >>>> Nathan >> >>>> >> >> >> >>
