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
Should we create a new pool for SNMP response and trap?
Alex
- Original Message -
From: Simon Goldschmidt goldsi...@gmx.de
To: Mailing list for lwIP users lwip-users@nongnu.org
Sent: Tuesday, August 04, 2009 1:23 AM
Subject: Re: [lwip-users] Relationship between lwIP options
If you
Hi,
It seems that in the current release, 1.3.0, it is impossible to add static ARP
entries. Would you consider making update_arp_entry() public?
Best regards,
Marek
___
lwip-users mailing list
lwip-users@nongnu.org
Hi all,
I use an HTTP server built over lwip. My server provides the following
functions:
static err_t
http_accept(void *arg, struct tcp_pcb *pcb, err_t err)
{
struct http_connect_state* hcs;
tcp_setprio(pcb, TCP_PRIO_MIN);
/* Allocate memory for the structure that holds
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
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,
Baptiste Chaboud-crousaz wrote:
Sometimes, the face trouble with my callback http_connect - called by
the macro TCP_EVENT_SENT - because arg is null.
I don't understand that one:
a) there is no function 'http_connect' in the code you posted
b) TCP_EVENT_SENT calls the function set by
Now I'm more confused. I found a post by bill, which appears to be regarding
v1.3 who said:
What is your TCP_SND_QUEUELEN? If you tie up all of your pbufs to send queued
packets, you won't have any pbufs left to support receiving packets.
Is there any truth to this statement (except for the
JM schrieb:
Now I'm more confused. I found a post by bill, which appears to be
regarding v1.3 who said:
What is your TCP_SND_QUEUELEN? If you tie up all of your pbufs to
send queued packets, you won't have any pbufs left to support
receiving packets.
Is there any truth to this statement
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
Hi,
For a better understanding I give a part of the code of my HTTP server:
===
void httpd_init(void)
{
struct tcp_pcb *pcb;
pcb = tcp_new();
tcp_bind(pcb, IP_ADDR_ANY, 80);
pcb = tcp_listen(pcb);
tcp_accept(pcb, http_accept);
}
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 state
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 in
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
JM escreveu:
I'm using OpenOCD on Eclipse, Luminary ARM Cortex-M3, and CodeSourcery
compiler. I remember that sometimes OpenOCD refuses to program the
micro because offset breaks required alignment.
That seems to be fixed on OpenOCD 0.2.0, at least WFM...
Alain
I'm starting to wonder if the OpenOCD issue is only an issue with OpenOCD
itself, and not related to why my code breaks. Maybe it's not an alignment
issue at all.
--- On Tue, 8/4/09, Alain Mouette ala...@pobox.com wrote:
From: Alain Mouette ala...@pobox.com
Subject: Re: [lwip-users] Sort of
18 matches
Mail list logo
