Hello Sergio and all,
I could not see how to use pbuf_cat for UDP purposes (aside from not
being able to store the ip somewhere), since it adjusts the len and
tot_len's and I would lose track of the packet boundaries (if I'm
mistaken here, please yell). I use it to great success for the TCP
equivalent though.
Since I cannot change the driver code in this example (serving lwip's
input routines), but have control over the lwip parametrization, I will
probably settle with adding tiny-sized RAM pools to lwip and allocate
linked list nodes from it (except when they're exhausted of course)
which store the source address, a reference to the udp packet's chain
and a reference to the next node in chain... sigh.
Thanks again
Michael
Am 16.02.2018 um 13:39 schrieb Sergio R. Caprile:
Talking about backfire: looking for the address info inside a pbuf
violates the layer independency (someone's got to play the pedantic
role...), so I would not rely on that unless willing to chase all sort
of strange problems in the field and/or future lwIP versions.
I would use the pbuf functions like pbuf_cat() for the queueing
(there's an example in the httpd code) and the standard procedures to
obtain the other layer info.
If you get msgs from many sources, roll your own structure with all
the info and a pointer to the pbuf, and queue those instead. Just an
idea. Get the sender from your callback arguments, you don't need to
unroll the pbuf
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
