On Sun, 2011-07-31 at 15:41 +0200, Kai Parow-Souchon wrote: > Any suggestions or anything I can try or have a look at are welcome, Your UDP code looks fine to me. I suggest tracing a received packet through the stack (e.g. by turning on some of the debugging code that prints stuff out) and seeing where the packet gets dropped (or if it never reaches lwIP at all). Kieran
_______________________________________________ lwip-users mailing list lwip-users@... https://lists.nongnu.org/mailman/listinfo/lwip-users
On Mon, 2011-08-01 at 11:35 +0100, Marcos Guerra Medina wrote: > sorry: > > upcb->remote_ip.addr = IP_ADDR_PC_LAB; > upcb->remote_port = 1338; > upcb->local_ip.addr = IP_ADDR_LOCAL; No, you shouldn't be setting internal state of the PCB directly. udp_bind() will set the local ip and port fields, udp_connect() will set the remote ip and port fields, but without a udp_connect() you should be able to receive traffic (I think). Kieran
Quoting Kai Parow-Souchon <kai.parow@...>: > Hey! > > I'm trying to get a simple UDP-server to work on an LM3S8538 stellaris arm. > You talk about a server? A server sends data to something else. Looking at the code you seem to be trying to receive UDP data ie client! Are you clear which one you are doing? Chris. > TCP works great, but my UDP server initialized by: > > pcb = udp_new(); > udp_bind(pcb, IP_ADDR_ANY, 1338); > > udp_recv(pcb, myUDPrcv, NULL); > > always returns ICMP "destination unreachable (port unreachable)" > messages when I try to send a package to it. > > In die config file I only defined LWIP_UDP - is there anything else > that needs to be configured? > > I don't have any idea left to try...it's really simple but still > doesn't work ;) > > Any suggestions or anything I can try or have a look at are welcome, > Thanks, > Kai > > _______________________________________________ > lwip-users mailing list > lwip-users@... > https://lists.nongnu.org/mailman/listinfo/lwip-users > > -- -- --------------------------------------------------------------------------- | Chris Williams EMail chris@... | | Web www.chrydesn.co.uk | | Tel/Fax 01686 688065 | | Chrysalis Design. Electronics, Computers, Hardware, Software. | | Design and development to meet all your needs. | ---------------------------------------------------------------------------
On Mon, 2011-08-01 at 09:46 +0100, Chris Williams wrote: > > You talk about a server? A server sends data to something else. > Looking at the code you seem to be trying to receive UDP data ie > client! The distinction between server and client is always a difficult one, as both involve sending and receiving, but a server will typically first receive a request, then send its response, with a client the other way round. I think their server is trying to receive the request and failing. Kieran
Hey! first, let me thank you all for your help :) And yes, Kieran is right, my "server" should be able to receive commands or requests and should answer with anything appriopriate to that. In my understanding this would make it a server ;) <at> Marcos: doesn't work, but this values are definitively written in udp_bind... <at> Kieran: tracking a packet through debug-outputs is kind of difficult, as my debug outputs are crashing the ARM from time to time (when setting IP_DEBUG). Setting only UDP_DEBUG i just get a lot of confusing logs which doesn't seem to be related to the event me sending a debug-packet to the ARM. I once got a "UDP: not for us" message, but that was just once. The outputs for bind are completely chaotic, number encoding doesn't seem to like me at the moment. I'll have a look on that soon... Thanks all, Kai Am 01.08.2011 14:19, schrieb Kieran Mansley: > On Mon, 2011-08-01 at 09:46 +0100, Chris Williams wrote: >> You talk about a server? A server sends data to something else. >> Looking at the code you seem to be trying to receive UDP data ie >> client! > The distinction between server and client is always a difficult one, as > both involve sending and receiving, but a server will typically first > receive a request, then send its response, with a client the other way > round. I think their server is trying to receive the request and > failing. > > Kieran > > > _______________________________________________ > lwip-users mailing list > lwip-users@... > https://lists.nongnu.org/mailman/listinfo/lwip-users
On Mon, 2011-08-01 at 14:29 +0200, Kai Parow-Souchon wrote: > tracking a packet through debug-outputs is kind of difficult, > as my debug outputs are crashing the ARM from time to time (when > setting > IP_DEBUG). I wonder if that is due to some assertion firing. It could be related to your problem. > Setting only UDP_DEBUG i just get a lot of confusing logs > which doesn't seem to be related to the event me sending a > debug-packet > to the ARM. Perhaps you would be better turning off most of the messages, and just changing the log level of a couple of useful ones so you see those. That should make it easier to see things that are relevant. > I once got a "UDP: not for us" message, but that was just once. > > The outputs for bind are completely chaotic, number encoding doesn't > seem to like me at the moment. > I'll have a look on that soon... I don't like the sound of that. I think it's worth looking into. Kieran
The FreeRTOS project has now been updated to include a sockets API based example, in addition to the already existing raw API based example. The sockets example implements a Telnet "style" interface that can be connected to using either a telnet client (only tested from Windows) or dumb terminal type TCP/IP interface (connecting on port 23). The code and a little set up explanation can be found here: http://interactive.freertos.org/entries/20290712-freertos-win32-project-with-lwip-web-server As the command interpreter is not re-entrant, the implementation only allows a single connection at a time. One quick question, and one longer question: 1) As this is to be used (by me at least) as a reference, I would like to ensure it is set up optimally. When implementing a telnet style server (i.e. sending and receiving very small packets), using a sockets API, how/should I configure the socket for optimal performance? Is there a way to do that? 2) This relates to the SSI functionality. I want to minimise RAM usage for when this code is running on real microcontroller targets. The SSI functions I have implemented return a very large string, so I have set LWIP_HTTPD_MAX_TAG_INSERT_LEN 1024. At the time, I didn't realise this resulted in 1024 bytes being allocated for each http connection, whether it was using SSI or not. Ideally I would like to use a single, global buffer. Is that possible (obviously I would need to change the lwIP code a little in my local copy). To elaborate a little on this second question. The command interpreter just implemented for the sockets example returns the same amount of data as the SSI functions (in fact, they call the same functions). In the command interpreter I have allocated one large buffer that uses a mutex to ensure only one command uses the buffer at a time. This is ok, as the sockets based server runs in its own task, and can block on the mutex. Ideally, I would like the SSI functions to use the exact same buffer - but as the http server uses the raw API I don't think it can block without blocking the entire stack. Is there a solution to this? Regards, Richard. + http://www.FreeRTOS.org Designed for Microcontrollers. More than 7000 downloads per month. On 26/07/2011 07:20, Paul Archer wrote: > Hi Richard, > >> Done - although I think it should be SYS_STATS_INC_USED( mbox ) /* >> without the .used on the mbox. */ > You are corerct, it should have been just SYS_STATS_INC_USED( mbox ) > >> I could not see that there was a SYS_STATS_DEC_USED equivalent. > Also correct, just use the SYS_STATS_DEC as you have. > >> I have attached my current file. It has also been bent into the >> FreeRTOS coding style since I posed it up, as it is FreeRTOS specific file. > This file looks good. And does all that it needs to. > > The only comment I have is due to my requirement for DNS lookups. > In my sys_arch.c file I needed to add a way to track tasks. This is due > to performing DNS lookups without needing to lock for each task. > > There is a function > struct hostent *sys_thread_hostent(struct hostent *hostent) > > My function that I have is > /** > * Get the thread's hostent structure > * > * \param[in] hostent Copy the data from this into the threads hostent > * > * \return The threads hostent with the data copied from the argument > */ > struct hostent * > sys_thread_hostent(struct hostent *hostent) > { > sys_tcb_t *current; > > syslog(LOG_DEBUG, "Got here: '%s'", inet_ntoa(hostent->h_addr)); > > /* Find the current thread */ > if ((current = sys_arch_thread_current()) == NULL) > { > return NULL; > } > > /* Check if we need to allocate the memory */ > if (current->hostent == NULL) > { > current->hostent = pvPortMalloc(sizeof(*current->hostent)); > if (current->hostent == NULL) > { > return NULL; > } > } > > /* Copy the data into the return result */ > memcpy(current->hostent, hostent, sizeof(*hostent)); > > return current->hostent; > } > > What is needed here is a way to get a per tasks hostent structure. > The way that I did this is sub-par, and is just an linked list of task > handles, which is searched when needed. > It works, but its not particularly quick or memory efficient. > > If you can find a better solution and include that in the sys_arch > example I am sure that many people would like > thread safe DNS resolving out of the box. > >> To demonstrate sockets use, the current plan is to add in a simple >> telnet "like" console (just single connection to keep it really simple), >> and command interpreter (to return the same information that is already >> being returned by the web server). Then it will just be a case of >> adding in a sockets client side demo. > I think this is a perfect example and is exactly what most people would want. >
Has there ever been interest in integrating throughput statistics tracking into lwIP at the netif level (or is there something available to do this)? I know close to zero about SNMP so I apologize if this is something that is provided by the SNMP layer. What I'm interested in is tracking (for example) the throughput for the past 60 seconds, mainly for debugging of performance purposes. I have written something to do this at the emac driver layer, but it seems like something that could easily be integrated at the netif layer and might be something that people using different platforms are interested in as well. The way I implemented it was basically counting total packet bytes transmitted and received for 60 one second intervals. The storage for these byte counts and the overhead of adding to the count is pretty minimal. Tyrel
RSS Feed70 | |
|---|---|
100 | |
60 | |
71 | |
85 | |
111 | |
98 | |
73 | |
48 | |
97 | |
184 | |
137 | |
186 | |
197 | |
54 | |
125 | |
157 | |
123 | |
86 | |
173 | |
130 | |
275 | |
169 | |
149 | |
110 | |
171 | |
184 | |
163 | |
80 | |
49 | |
105 | |
151 | |
173 | |
105 | |
120 | |
102 | |
111 | |
139 | |
152 | |
231 | |
230 | |
175 | |
91 | |
108 | |
213 | |
232 | |
241 | |
271 | |
178 | |
134 | |
171 | |
214 | |
162 | |
119 | |
138 | |
155 | |
159 | |
128 | |
177 | |
107 | |
47 | |
162 | |
126 | |
185 | |
170 | |
234 | |
138 | |
168 | |
147 | |
177 | |
70 | |
126 | |
155 | |
189 | |
133 | |
239 | |
164 | |
55 | |
52 | |
62 | |
167 | |
142 | |
91 | |
82 | |
54 | |
71 | |
95 | |
98 | |
40 | |
60 | |
77 | |
92 | |
49 | |
45 | |
73 | |
48 | |
70 | |
41 | |
37 | |
41 | |
70 | |
86 | |
109 | |
113 | |
105 | |
126 | |
91 | |
125 | |
109 | |
44 | |
1 | |
1 |
