Hello,
I am trying to compile with gcc 13.2 (from
arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi)
I have some warnings when compile dhcp.c, and I cannot understand why:
In function 'dhcp_option_byte',
inlined from 'dhcp_discover' at
ThirdParties/lwip/src/core/ipv4/dhcp.c:1053:25:
ThirdPart
b8aafa87-2c84-4406-9c9e-91da1b7684d0.png] <https://www.instagram.com/powersoft.audio/>
<https://www.instagram.com/powersoft.audio/> <http://www.powersoft-audio.com/en/>
On 21/06/22 20:56, goldsi...@gmx.de<mailto:goldsi...@gmx.de> wrote:
Am 21.06.2022 um 12:37 schrieb massimilia
.com/powersoft.audio/> <http://www.powersoft-audio.com/en/>
On 20/06/22 21:17, goldsi...@gmx.de<mailto:goldsi...@gmx.de> wrote:
Am 20.06.2022 um 11:22 schrieb massimiliano cialdi via lwip-users:
hello,
I am using lwip 2.1.3 and contrib 2.1.0.
in the ports/freertos/sys_arch.c
hello,
I am using lwip 2.1.3 and contrib 2.1.0.
in the ports/freertos/sys_arch.c file there is the sys_arch_mbox_fetch()
function, in which there is the timeout_ms parameter.
Given the name I expect the sys_arch_mbox_fetch() function to be blocking for a
maximum time corresponding to timeout_ms
Hello,
I have a similar problem (maybe the same?).
Not only with listening TCP sockets but also with already open TCP sockets.
When the IP address changes the lwip stack has unexpected behavior. Sometimes
no more data arrives, sometimes it arrives but the source address is wrong,
sometimes it
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
