[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Loopback problems

From: address@hidden
Subject: Re: [lwip-users] Loopback problems
Date: Tue, 04 Aug 2009 16:31:35 +0200
User-agent: Thunderbird (Macintosh/20090605)

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?).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]