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... Simon BTW: could you please respond in ASCII, not HTML? The font in your responses is *very* small sometimes! > fabian koch wrote: > > > In 1.3.1, we added the function ip_current_header(), which should give > > you everything you need (unless I understood you wrong). > > I don't know if that will work. > I basically have a system that wants me to implement a Receive function. > It has a parameter that means "isBroadcast?" and I have to fill that with > true or false obviously. > But inside the function I use the netconn-API and do a netconn_receive() > and then a netbuf_data(). I don't have any means of getting to the > (dest)addresses there. Now when I do ip_current_header() in that context, > what will it return? The Netbuf I get from netcon_receive will be > something cached, not a packet that is just going through the stack. > I somehow can't imagine that it will yield the correct addresses that I > want. IF I am even allowed to use it in that layer/context... > > Or I am just completely wrong? > > regards, > Fabian -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
