A return code of EINTR is perfectly normal, and isn't an error as such.
It's an indication that your program may need to do something because
a signal occurred, but if not, should re-call recv().
Signed-off-by: chao an <anchao@xiaomi.com>
dhcp6c.c:222:3: error: unknown type name ‘pthread_t’
222 | pthread_t thread;
| ^~~~~~~~~
dhcp6c.c: In function ‘dhcp6c_get_result’:
dhcp6c.c:415:7: warning: implicit declaration of function ‘netlib_prefix2ipv6netmask’ [-Wimplicit-function-declaration]
415 | netlib_prefix2ipv6netmask(presult->pl, &presult->netmask);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
dhcp6c.c: In function ‘dhcp6c_parse_ia’:
dhcp6c.c:1046:30: warning: unused variable ‘pdhcp6c’ [-Wunused-variable]
1046 | FAR struct dhcp6c_state_s *pdhcp6c = (FAR struct dhcp6c_state_s *)handle;
| ^~~~~~~
dhcp6c.c: In function ‘dhcp6c_precise_open’:
dhcp6c.c:1702:3: warning: missing braces around initializer [-Wmissing-braces]
1702 | {
| ^
......
1706 | {0},
| -
| {{0}}
dhcp6c.c:1796:43: error: ‘UDP_BINDTODEVICE’ undeclared (first use in this function); did you mean ‘SO_BINDTODEVICE’?
1796 | setsockopt(pdhcp6c->sockfd, SOL_SOCKET, UDP_BINDTODEVICE, ifname,
| ^~~~~~~~~~~~~~~~
| SO_BINDTODEVICE
dhcp6c.c:1796:43: note: each undeclared identifier is reported only once for each function it appears in
dhcp6c.c: In function ‘dhcp6c_request_async’:
dhcp6c.c:1886:9: warning: implicit declaration of function ‘pthread_create’; did you mean ‘timer_create’? [-Wimplicit-function-declaration]
1886 | ret = pthread_create(&pdhcp6c->thread, NULL, dhcp6c_run, pdhcp6c);
| ^~~~~~~~~~~~~~
| timer_create
Signed-off-by: chao an <anchao@xiaomi.com>
rename the UDP_BINDTODEVICE to SO_BINDTODEVICE to follow the linux
style to be compatible with non-UDP protocol binding requirements
Signed-off-by: chao.an <anchao@xiaomi.com>
Summary:
- This commit makes telnetd_daemon() in public so that we
can call it from applications.
- Also, adds new configs to support posix_spawnp()
Impact:
- telnetd only
Testing:
- Tested with sabre-6quad:netknsh (will be updated later)
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
NXStyle fixes
Apply suggestions from code review
Co-authored-by: Petro Karashchenko <petro.karashchenko@gmail.com>
API fixes and NXStyle fixes
Apply suggestions from code review
Co-authored-by: Petro Karashchenko <petro.karashchenko@gmail.com>
Use thread-safe ntoa functions
NXStyle fixes
Apply suggestions from code review
Co-authored-by: Petro Karashchenko <petro.karashchenko@gmail.com>
API fixes and NXStyle fixes
Apply suggestions from code review
Co-authored-by: Petro Karashchenko <petro.karashchenko@gmail.com>
NETUTILS_DHCPC_RECV_TIMEOUT -> NETUTILS_DHCPC_RECV_TIMEOUT_MS
Recently its unit has been changed from second to millisecond. [1]
Using the same Kconfig name for a different meaning is a pitfall
for an upgrade. I was using 3ms timeout because of this.
This commit renames it so that at least the default value
is used for a careless user like me.
[1]
```
commit 8fd4b6105b
Author: zrrong <zrrong@bouffalolab.com>
Date: Fri May 27 11:35:23 2022 +0800
netutils/dhcpc: Change the timeout unit to milliseconds
```
My primary motivation at this point is to use it for basic proxy auth.
(specify "Proxy-Authorization" header)
But there can be other use cases for proxy-specific extra headers.
If/when we want to support other non-trivial auth methods, probably
a callback-based mechanism will be necessary. But at this point,
this serves my purpose well.
Use a separate webclient_context for tunnel establishment.
I chose this way (instead of having tunnelling steps in
the state machine of a single webclient_context) because
I want to allow tunnelling of non-HTTP protocols sooner or later.
Add a primitive API for tunnel establishment.
(WEBCLIENT_FLAG_TUNNEL and webclient_get_tunnel)
I plan to use this to implement https proxy support.
That is, the primary user will be webclient itself.
nsh> ping 192.168.31.162
PING 192.168.31.162 56 bytes of data
56 bytes from 192.168.31.162: icmp_seq=0 time=8 ms
56 bytes from 192.168.31.162: icmp_seq=1 time=27 ms
56 bytes from 192.168.31.162: icmp_seq=2 time=17 ms
56 bytes from 192.168.31.162: icmp_seq=3 time=14 ms
56 bytes from 192.168.31.162: icmp_seq=4 time=16 ms
56 bytes from 192.168.31.162: icmp_seq=5 time=14 ms
56 bytes from 192.168.31.162: icmp_seq=6 time=8 ms
56 bytes from 192.168.31.162: icmp_seq=7 time=87 ms
WARNING: Received after timeout
56 bytes from 192.168.31.162: icmp_seq=8 time=1003 ms
56 bytes from 192.168.31.162: icmp_seq=8 time=6 ms
56 bytes from 192.168.31.162: icmp_seq=9 time=5 ms
10 packets transmitted, 11 received, 4294967287% packet loss, time 10011 ms
Signed-off-by: zhouliang3 <zhouliang3@xiaomi.com>
