nuttx
nuttx copied to clipboard
apache
usrsock: Don't clear recvfrom available flag
@zhhyu7 Hmm, spresense:wifi does not work.
nsh> uname -a
NuttX 10.3.0-RC0 51a5248e47 Apr 11 2022 21:00:21 arm spresense
nsh> ps
PID GROUP PRI POLICY TYPE NPX STATE EVENT SIGMASK STACK USED FILLED COMMAND
0 0 0 FIFO Kthread N-- Ready 00000000 001000 000376 37.6% Idle Task
1 1 224 RR Kthread --- Waiting Signal 00000000 002016 000460 22.8% hpwork 0x2d054598
2 2 60 RR Kthread --- Waiting Semaphore 00000000 002016 000276 13.6% lpwork 0x2d0545a8
3 3 100 RR Task --- Running 00000000 003048 001224 40.1% spresense_main
4 4 200 RR Task --- Waiting MQ empty 00000000 001000 000440 44.0% cxd56_pm_task
nsh> free
total used free largest nused nfree
Umem: 1213008 37488 1175520 1175520 106 1
nsh> mount
/mnt/spif type smartfs
/proc type procfs
nsh> ifconfig
wlan0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 at UP
inet addr:0.0.0.0 DRaddr:0.0.0.0 Mask:0.0.0.0
nsh> gs2200m raspi3-g wifi-test-24g &
gs2200m [5:50]
nsh> renew wlan0
ERROR: dhcpc_request() failed
@zhhyu7 What is the intention of this PR? Does this PR fix a bug?
@masayuki2009 Yes, is a bug fix. we use netutils/usrsock_rpmsg to supports cross core network data access. Related modifications is below: https://github.com/apache/incubator-nuttx-apps/pull/1132
We found that if the remote close the socket first, USRSOCK_EVENT_REMOTE_CLOSED may report prematurely before the client can read the rest data from socket. This patch try to report USRSOCK_EVENT_RECVFROM_AVAIL(in events field) through ack/data_ack response at the same time: https://github.com/apache/incubator-nuttx-apps/pull/1132/files#diff-cbd959feb557cd53ec9bb9130d741941d8d0af2cc713e0c39573a180175fe0d2R511-R520 Does gs2200m hit the similar issue before? BTW, it is also an optimization to reduce the event between socket client and usrsock server.
Yes, is a bug fix. we use netutils/usrsock_rpmsg to supports cross core network data access. Related modifications is below: https://github.com/apache/incubator-nuttx-apps/pull/1132
@zhhyu7 Do we need modify apps/wireless/gs2200m/gs2200m_main.c as well?
Yes, is a bug fix. we use netutils/usrsock_rpmsg to supports cross core network data access. Related modifications is below: apache/incubator-nuttx-apps#1132
@zhhyu7 Do we need modify apps/wireless/gs2200m/gs2200m_main.c as well?
It's optional. Since events field is set to zero by default in https://github.com/apache/incubator-nuttx-apps/pull/1116, the behavior keep same as before. gs2200m could modify later until the same issue is found or you want to reduce the message. It's very strange that gs2200m stop work with this change since we already consider all possible combination carefully before.
@xiaoxiang781216
We found that if the remote close the socket first, USRSOCK_EVENT_REMOTE_CLOSED may report prematurely before the client can read the rest data from socket. This patch try to report USRSOCK_EVENT_RECVFROM_AVAIL(in events field) through ack/data_ack response at the same time: https://github.com/apache/incubator-nuttx-apps/pull/1132/files#diff-cbd959feb557cd53ec9bb9130d741941d8d0af2cc713e0c39573a180175fe0d2R511-R520 Does gs2200m hit the similar issue before?
I've never seen the similar issue before.
It's optional. Since events field is set to zero by default in https://github.com/apache/incubator-nuttx-apps/pull/1116, the behavior keep same as before. gs2200m could modify later until the same issue is found or you want to reduce the message. It's very strange that gs2200m stop work with this change since we already consider all possible combination carefully before.
OK, I understand and yes, it's strange to me.
I have order one wifi board from chip1top.com two weeks ago, but the seller told me I still need wait for two more weeks to receive the board. We can find the root cause after the board is received.
@masayuki2009 can https://github.com/apache/incubator-nuttx-apps/pull/1139 fix this issue too?
@masayuki2009 can https://github.com/apache/incubator-nuttx-apps/pull/1139 fix this issue too?
@xiaoxiang781216 Unfortunately no. The PR fixes recvfrom() + TCP passive close case.