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
