I apologize for thinking too suddenly about a bug.
Actually it was enough to set LWIP_NETIF_EXT_STATUS_CALLBACK to have
the expected behavior.
I apologize again.
best regards
Max
On Mon, Mar 14, 2022 at 3:49 PM massimiliano cialdi via lwip-users
wrote:
>
> continuing to read RFC 6762 at section
Hi all, I am trying to implement ping6 like functionality from an
application using ICMPv6 RAW socket. I am able to create an ICMPv6 ECHO
request and send but however the socket is receiving other ICMPv6 packets
like NA etc. and hence the response type (expecting ICMPv6 ECHO REPLY)
matches fails. I
hello,
In RFC 6762 I find (section 8):
"Whenever a Multicast DNS responder starts up, wakes up from sleep,
receives an indication of a network interface "Link Change" event, or
has any other reason to believe that its network connectivity may
have changed in some relevant way, it MUST perform t
it seems that such a commit was not cherry-picked in the last release.
Massimiliano Cialdi
FIRMWARE ENGINEERING PROFESSIONAL LEADER
Powersoft
S.p.A.
Via E. Conti, 5
- Scandicci (Fi) 50018 - Italy
OFFICE:+39 055
7350230
On 03/03/22 22:31, Erik Ekman wrote:
> Does adding
continuing to read RFC 6762 at section 8.4
(https://datatracker.ietf.org/doc/html/rfc6762#section-8.4) I find:
At any time, if the rdata of any of a host's Multicast DNS records
changes, the host MUST repeat the Announcing step described above to
update neighboring caches. For example, if any
Hi,
I'm using LWIP-2.1.3 and NETCONN api.
I'm using a single thread to do a http request that works well until I
noticed an error when it was unable to connect to the server.
I replicated the issue by using a wrong port number and this triggers the
tcp_slowtmr: max SYN retries reached.
