Re: [lwip-users] Loopback problems

[address@hidden]

Fabian Koch wrote:
> address@hidden 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