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
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:
> 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
> 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
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
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
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
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 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
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
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
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
12 matches
Mail list logo
