Fabian Koch wrote:
[email protected] wrote on
04.08.2009 14:54:29:
> No, you're not wrong. Of course the function is not usable from the
> netconn thread. However, my proposal is not much different to yours:
> having a flag UDP_FLAGS_IS_BROADCAST in the PCB won't help you,
> either, since that flag is not added to the netbuf but only stored
> in the PCB: it might get deleted by the time you received the netbuf...
>
> Therefore, I thought you'd be using the raw API...
Yes, but I do have the pcb in that layer. I have the netconn, so I
just go conn->pcb.udp->flags and look for the new broadcast flag.
Big Fat Warning! This is not how it works! You are cleary violating
threading rules here!!! Don't ever access the pcb from a different
thread than the tcpip_thread or you will get random results!
In the tests this worked as intended, but might be coincidence.
It might work for you when the broadcast flag is the same for all
received packets. But it will almost surely stop working if the other
end sends broadcast/unicast at random.
Any ideas how I can achieve my goal?
The only clean solution is to change the function recv_udp() in
api_msg.c to get the setting (broadcast flag or target address) and
store it with the netbuf so that you can access it when reading from the
application thread.
However, this is clearly not wanted by most lwIP users as it would need
additional memory and processing time even if not used.
Linux (or posix?) provides recvmsg() (see
http://www.opengroup.org/onlinepubs/000095399/functions/recvmsg.html)
for receiving more than the pure data, but we don't have that (yet?).
Simon
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
