Hey guys,
I'm starting to use the Loopback connection at the moment and am running
into what appears to be race conditions.
(Still using 1.3.0 and in the process of looking at 1.3.1)
Now in 1.3.0 in loopif.c it is said that loopif_output() copies the pbuf
and calls netif->input() with it. And n
Hey all,
I still have the Problem that I can't determine a Broadcast on higher
levels (netconn/netbuf), which I need.
I saw the SOF_BROADCAST option added in 1.3.1, but that won't help me
unless I'm willing to rewrite a lot of our code (which I'm not).
The other problem is that we treat LwIP as
Err.. sorry the subject on this is completely wrong... but anyways___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
In 1.3.1, we added the function ip_current_header(), which should give
you everything you need (unless I understood you wrong).
Simon
Fabian Koch wrote:
Hey all,
I still have the Problem that I can't determine a Broadcast on higher
levels (netconn/netbuf), which I need.
I saw the SOF_BROAD
lwip-users-bounces+fabian.koch=de.abb@nongnu.org wrote on 03.08.2009
17:47:34:
> 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 imple
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 del
lwip-users-bounces+fabian.koch=de.abb@nongnu.org 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,
> eit
Fabian Koch wrote:
lwip-users-bounces+fabian.koch=de.abb@nongnu.org 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
lwip-users-bounces+fabian.koch=de.abb@nongnu.org wrote on 04.08.2009
16:31:35:
> 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
> 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!
This poses some more questions...
Until now I used:
conn->pcb.tcp->state: to print the s
Fabian Koch wrote:
> 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!
This poses some more questions...
Until now I used:
conn->pcb.tcp->state
lwip-users-bounces+fabian.koch=de.abb@nongnu.org wrote on 04.08.2009
17:56:10:
> The variables you read/write from the wrong thread are relatively
> static, so no wonder it works for you. However, the correct way to do it
> is to use tcpip_callback() to get a user-specific function called i
Fabian Koch wrote:
> No patches necessary there. What else are you missing to use lwIP as is?
Well for example my first mail regarding this. Getting dest-addr up to
the netbuf level. I think SOF_BROADCAST is nice and elegant but I'd
have to mangle a lot with the rest of our system to get that
13 matches
Mail list logo
