lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Loopback problems


From: Simon Goldschmidt
Subject: Re: [lwip-users] Loopback problems
Date: Tue, 04 Aug 2009 14:54:29 +0200

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




reply via email to

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