Update: Bug was introduced in apps repo git commit 75455d3788601e7730a17a228c31d254e4fbfd61. Not sure which part of this commit yet, but this commit reuses nsh_session logic in nsh_telnetmain to remove code duplication; part of the old telnet code which didn't make it past this change includes this comment:
- /* The following logic mostly the same as the login in nsh_session.c. It - * differs only in that gets() is called to get the command instead of - * readline(). - */ Hmmm... This needs deeper study. Nathan On Mon, Feb 13, 2023 at 10:34 AM Nathan Hartman <hartman.nat...@gmail.com> wrote: > > Looks like a bug was introduced sometime between October and now. > > I just built the following revision, which is from October 1. NSH via > telnet is working perfectly: > > nuttx: 2a574427c6b97e3309aeadf6a4374420121f8f7b > apps: 0e0ac0656be9f812653802b3282b56380b69585b > > Several changes were made in the apps repo to telnet and nsh since > then. I'll need to bisect to figure out which revision introduced it, > and that should (hopefully) narrow it down considerably. > > Cheers, > Nathan > > On Mon, Feb 13, 2023 at 9:44 AM Nathan Hartman <hartman.nat...@gmail.com> > wrote: > > > > Posting the config in question: > > > > # > > # This file is autogenerated: PLEASE DO NOT EDIT IT. > > # > > # You can use "make menuconfig" to make any modifications to the > > installed .config file. > > # You can then do "make savedefconfig" to generate a new defconfig > > file that includes your > > # modifications. > > # > > # CONFIG_ARCH_LEDS is not set > > # CONFIG_DEV_CONSOLE is not set > > # CONFIG_DISABLE_OS_API is not set > > CONFIG_ALLOW_BSD_COMPONENTS=y > > CONFIG_ALLOW_MIT_COMPONENTS=y > > CONFIG_ARCH="arm" > > CONFIG_ARCH_BOARD="CM_TM4C" > > CONFIG_ARCH_BOARD_CM_TM4C=y > > CONFIG_ARCH_CHIP="tiva" > > CONFIG_ARCH_CHIP_TIVA=y > > CONFIG_ARCH_CHIP_TM4C129=y > > CONFIG_ARCH_CHIP_TM4C129ENCPDT=y > > CONFIG_ARCH_CHIP_TM4C=y > > CONFIG_ARCH_HIPRI_INTERRUPT=y > > CONFIG_ARCH_RAMVECTORS=y > > CONFIG_ARCH_STACKDUMP=y > > CONFIG_ARMV7M_LIBM=y > > CONFIG_ARMV7M_MEMCPY=y > > CONFIG_BOARDCTL_IOCTL=y > > CONFIG_BOARD_LATE_INITIALIZE=y > > CONFIG_BOARD_LOOPSPERMSEC=11401 > > CONFIG_BUILTIN=y > > CONFIG_DEBUG_ERROR=y > > CONFIG_DEBUG_FEATURES=y > > CONFIG_DEBUG_INFO=y > > CONFIG_DEBUG_SYMBOLS=y > > CONFIG_DEBUG_WARN=y > > CONFIG_DEV_GPIO=y > > CONFIG_DEV_GPIO_NSIGNALS=0 > > CONFIG_FS_PROCFS=y > > CONFIG_INIT_ENTRYPOINT="nsh_main" > > CONFIG_LIBM=y > > CONFIG_NET=y > > CONFIG_NETDB_DNSCLIENT=y > > CONFIG_NETINIT_DHCPC=y > > CONFIG_NETINIT_THREAD=y > > CONFIG_NETINIT_THREAD_PRIORITY=120 > > CONFIG_NETUTILS_DHCPC_HOST_NAME="nuttx-cm" > > CONFIG_NETUTILS_NETCAT=y > > CONFIG_NETUTILS_TELNETD=y > > CONFIG_NET_ARP_IPIN=y > > CONFIG_NET_ARP_SEND=y > > CONFIG_NET_BROADCAST=y > > CONFIG_NET_ETH_PKTSIZE=1518 > > CONFIG_NET_ICMP=y > > CONFIG_NET_ICMP_SOCKET=y > > CONFIG_NET_ROUTE=y > > CONFIG_NET_STATISTICS=y > > CONFIG_NET_TCP=y > > CONFIG_NET_TCPBACKLOG=y > > CONFIG_NET_TCP_WRITE_BUFFERS=y > > CONFIG_NET_UDP=y > > CONFIG_NET_UDP_CHECKSUMS=y > > CONFIG_NET_UDP_NOTIFIER=y > > CONFIG_NET_UDP_WRITE_BUFFERS=y > > CONFIG_NSH_BUILTIN_APPS=y > > CONFIG_PREALLOC_MQ_MSGS=4 > > CONFIG_PREALLOC_TIMERS=4 > > CONFIG_RAM_SIZE=262144 > > CONFIG_RAM_START=0x20000000 > > CONFIG_RAW_BINARY=y > > CONFIG_RR_INTERVAL=200 > > CONFIG_SCHED_HPWORK=y > > CONFIG_SCHED_LPWORK=y > > CONFIG_SCHED_WAITPID=y > > CONFIG_SERIAL_TERMIOS=y > > CONFIG_STACK_CANARIES=y > > CONFIG_STACK_COLORATION=y > > CONFIG_START_YEAR=2015 > > CONFIG_SYSTEM_DHCPC_RENEW=y > > CONFIG_SYSTEM_NSH=y > > CONFIG_SYSTEM_PING=y > > CONFIG_TESTING_OSTEST=y > > CONFIG_TESTING_OSTEST_LOOPS=0 > > CONFIG_TIVA_BOARDMAC=y > > CONFIG_TIVA_ETHERNET=y > > CONFIG_TIVA_UART2=y > > CONFIG_TIVA_UART_BREAKS=y > > CONFIG_UART2_BAUD=9600 > > CONFIG_USERLED=y > > CONFIG_USERLED_LOWER=y > > > > > > On Mon, Feb 13, 2023 at 9:34 AM Nathan Hartman <hartman.nat...@gmail.com> > > wrote: > > > > > > Finally I have a chance to look at this again. > > > > > > If I have CONFIG_NSH_CLE, the board boots, gets a DHCP lease, and > > > responds to telnet, but with that ^[[62;6R business... and doesn't > > > seem to function much beyond that. > > > > > > If I have CONFIG_NSH_READLINE instead (the two options are mutually > > > exclusive, right?), the board does *not* get a DHCP lease and I can't > > > locate it on the network, let alone try to telnet to it. > > > > > > I'm single-stepping through the NSH initialization to see where things > > > are taking a wrong turn... > > > > > > Nathan > > > > > > On Fri, Feb 10, 2023 at 4:31 PM Gregory Nutt <spudan...@gmail.com> wrote: > > > > > > > > On 2/10/2023 3:19 PM, Nathan Hartman wrote: > > > > > You know what, I think that might be it. I think I did notice that > > > > > CLE was > > > > > enabled and didn't think about it. Let me look into it... > > > > > > > > Even if that is the case, it is still and error if the escape sequence > > > > from the host appears on the NSH console. It should be completely > > > > consumed by the function cle_getcursor() at line 479 of > > > > apps/system/cle/cle.c > > > > > > > >
