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 > >>>> > >> > >
