http://permalink.gmane.org/gmane.network.lwip.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.network.lwip.devel/9228 <pre>After working through it this patch appears to solve the problem. It might not be a good way of doing things but it works. I'm not getting any out of memory errors if writing more then the buf (which was stalling SYN ACK for 2-3 seconds) and the speed of replying to a GET has improved, reducing the chance of a retry. --- C:/Users/bwhitten/Desktop/contrib-1.4.1/apps/httpserver_raw/httpd.c Mon Dec 17 19:07:22 2012 +++ C:/Users/bwhitten/Desktop/contrib-1.4.1/apps/httpserver_raw/httpd - Copy.c Thu May 23 12:56:32 2013 &lt; at &gt;&lt; at &gt; -1197,7 +1197,7 &lt; at &gt;&lt; at &gt; * the buffer contents looking for SSI tags. */ while((ssi-&gt;parse_left) &amp;&amp; (err == ERR_OK)) { /* &lt; at &gt;todo: somewhere in this loop, 'len' should grow again... */ - if (len == 0) { + if (tcp_sndbuf(pcb) == 0) { return data_to_send; } switch(ssi-&gt;tag_state) { &lt; at &gt;&lt; at &gt; -1344,15 +1344,18 &lt; at &gt;&lt; at &gt; if (ssi-&gt;tag_end &gt; hs-&gt;file) { /* How much of the data can we send? */ #if LWIP_HTTPD_SSI_INCLUDE_TAG - if(len &gt; ssi-&gt;tag_e</pre> Ben Whitten 2013-05-23T12:02:01 http://permalink.gmane.org/gmane.network.lwip.devel/9227 <pre>Hey, This generates working userpass auth strings. Tested with GMX, Lavabit, Aol, Plusnet, and Yahoo. With various username/password sizes. I am also hunting a bug in the httpserver_raw, when including SSI tags; it finds the tag, sends the preceding data, then the tag. But then the sending length is never reset so it sends the remaining page at the tag length. As a result serving a webpage takes 2-3 seconds if its a 4K file with an SSI tag in the &lt;title&gt;. The problem seems to be around :1351 where I think len is being mistaken for something else, where its actually the length of the previously sent section (last tag length). Could someone more familiar with the code take a look too? Thanks, Ben Whitten --- C:/Users/bwhitten/Desktop/contrib-1.4.1/apps/smtp/smtp.c Mon Dec 17 19:03:22 2012 +++ C:/Users/bwhitten/Desktop/contrib-1.4.1/apps/smtp/smtp - Copy.c Thu May 23 08:51:16 2013 &lt; at &gt;&lt; at &gt; -804,8 +804,8 &lt; at &gt;&lt; at &gt; s8_t j; size_t target_idx = 0; size_t longer = 3 - (source_len % 3); - size_t source_len_b64</pre> Ben Whitten 2013-05-23T08:22:17 http://permalink.gmane.org/gmane.network.lwip.devel/9226 <pre>Follow-up Comment #3, task #12586 (project lwip): Hi, we still don't have any implementation of 6LowPAN and RPL for LwIP so I would stongly advise against adding this task for 1.5.0-Beta1. The main goal now is to have a stable release and this is a new feature (vs. bug fix). (PS: at the moment I run 6LowPAN/RPL in a parallel uIP stack) _______________________________________________________ Reply to this item at: &lt;http://savannah.nongnu.org/task/?12586&gt; _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ </pre> Ivan Delamer 2013-05-14T17:16:04 http://permalink.gmane.org/gmane.network.lwip.devel/9225 <pre>Follow-up Comment #2, task #12586 (project lwip): Hi Ivan whether or not to support the 6LoWPAN and RPL? I'm looking forward to version 1.5 includes support for this, ^-^ Best regards! _______________________________________________________ Reply to this item at: &lt;http://savannah.nongnu.org/task/?12586&gt; _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ </pre> hanhui 2013-05-14T07:45:04 http://permalink.gmane.org/gmane.network.lwip.devel/9224 <pre>We' just moving our comms protocol to run over UDP from RS232 using STM32F1 and F2 chips. The current ST ethernetif_input port allocates a PBUF_POOL and memcpy's the data from the DMA buffer in to it before passing it on to netif-&gt;input to process. We've got quite a bit of RAM and not much traffic and are looking to get away from the memcpy. I've changed this to allocate a PBUF_REF and then set the payload to point to the DMA buffer directly to save copying as the processing of these packets is very quick. This works for UDP traffic but fails for ICMP (echo requests). The reason is that LWIP does a couple of pbuf_header calls with -ve values while processing the header but when ICMP wants to send the reply (in icml.c line 143), it readjusts the header backwards using pbuf_header with a positive value. This doesn't work for PBUF_REF/ROM types as it can't safely check for underflow. The underflow for PBUF_RAM/POOL is checked for by comparing the new payload pointer to the pbuf pointer + sizeof(pbuf) whi</pre> rh_maillist< at >mac.com 2013-05-10T09:21:18 http://permalink.gmane.org/gmane.network.lwip.devel/9223 <pre>Follow-up Comment #2, bug #38886 (project lwip): #define s6_addr un.u8_addr is right from IEEE Std 1003.1, 2004 Edition. &lt;http://pubs.opengroup.org/onlinepubs/009696899/basedefs/netinet/in.h.html&gt; The &lt;netinet/in.h&gt; header shall define the in6_addr structure that contains at least the following member: uint8_t s6_addr[16]; so, #define s6_addr un.u8_addr is right! _______________________________________________________ Reply to this item at: &lt;http://savannah.nongnu.org/bugs/?38886&gt; _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ </pre> hanhui 2013-05-08T06:17:24 http://permalink.gmane.org/gmane.network.lwip.devel/9222 <pre>Follow-up Comment #1, bug #38886 (project lwip): Thanks for reporting. In bug #37585 you suggested #define s6_addr8 un.u8_addr which one should it be? _______________________________________________________ Reply to this item at: &lt;http://savannah.nongnu.org/bugs/?38886&gt; _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ </pre> Ivan Delamer 2013-05-07T18:25:23 http://permalink.gmane.org/gmane.network.lwip.devel/9221 <pre>http://grandkobayashi.sakura.ne.jp/5bxcuo.php </pre> Ivan Delamer 2013-04-10T16:34:38 http://permalink.gmane.org/gmane.network.lwip.devel/9220 <pre>Follow-up Comment #1, task #12586 (project lwip): I'm going to start working on fixing reported bugs and merging all patches related to IPv6. I'm not set up to use the win32/linux ports or contrib apps, so maybe someone else can take a look at that? _______________________________________________________ Reply to this item at: &lt;http://savannah.nongnu.org/task/?12586&gt; _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ </pre> Ivan Delamer 2013-05-07T17:28:38 http://permalink.gmane.org/gmane.network.lwip.devel/9219 <pre>Additional Item Attachment, patch #7858 (project lwip): File name: window_scaling_1_4_1.patch Size:28 KB _______________________________________________________ Reply to this item at: &lt;http://savannah.nongnu.org/patch/?7858&gt; _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ </pre> Alexander Boettcher 2013-05-06T08:30:41 http://permalink.gmane.org/gmane.network.lwip.devel/9218 <pre>URL: &lt;http://savannah.nongnu.org/bugs/?38886&gt; Summary: in6_addr error Project: lwIP - A Lightweight TCP/IP stack Submitted by: hanhui03 Submitted on: Sat May 4 13:27:55 2013 Category: IPv6 Severity: 3 - Normal Item Group: Change Request Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Planned Release: lwIP version: CVS Head _______________________________________________________ Details: struct in6_addr { union { u8_t u8_addr[16]; u32_t u32_addr[4]; } un; #define s6_addr un.u32_addr }; should be: #define s6_addr un.u8_addr _______________________________________________________ Reply to this item at: &lt;http://savannah.nongnu.org/bugs/?38886&gt; _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/</pre> hanhui 2013-05-04T13:27:56 http://permalink.gmane.org/gmane.network.lwip.devel/9217 <pre>URL: &lt;http://savannah.nongnu.org/task/?12600&gt; Summary: struct in6_addr error Project: lwIP - A Lightweight TCP/IP stack Submitted by: hanhui03 Submitted on: Sat May 4 13:27:05 2013 Category: IPv6 Should Start On: Sat May 4 00:00:00 2013 Should be Finished on: Sat May 4 00:00:00 2013 Priority: 5 - Normal Status: None Privacy: Public Percent Complete: 0% Assigned to: None Open/Closed: Open Discussion Lock: Any Planned Release: None Effort: 0.00 _______________________________________________________ Details: struct in6_addr { union { u8_t u8_addr[16]; u32_t u32_addr[4]; } un; #define s6_addr un.u32_addr }; should be: #define s6_addr un.u8_addr _______________________________________________________ Reply to this item at: &lt;http://savannah.nongnu.org/task/?12600&gt; </pre> hanhui 2013-05-04T13:27:07 http://permalink.gmane.org/gmane.network.lwip.devel/9216 <pre>Follow-up Comment #1, bug #38853 (project lwip): Add tcp_connect() do not use LWIP_ERROR(...) to check pcb state! _______________________________________________________ Reply to this item at: &lt;http://savannah.nongnu.org/bugs/?38853&gt; _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ </pre> hanhui 2013-04-29T15:56:13 http://permalink.gmane.org/gmane.network.lwip.devel/9215 <pre>URL: &lt;http://savannah.nongnu.org/bugs/?38853&gt; Summary: connect() use a wrong errno Project: lwIP - A Lightweight TCP/IP stack Submitted by: hanhui03 Submitted on: Mon Apr 29 15:51:35 2013 Category: sockets/netconn Severity: 3 - Normal Item Group: Faulty Behaviour Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Planned Release: lwIP version: git head _______________________________________________________ Details: EALREADY : A connection request is already in progress for the specified socket. EISCONN: The specified socket is connection-mode and is already connected. EALREADY is NOT same as EISCONN, but lwip is only use "ERR_ISCONN" as EALREADY. Some software(for example Qt/Embedded) whill check EISCONN to determine whether the connection is successful! I suggest th</pre> hanhui 2013-04-29T15:51:36 http://permalink.gmane.org/gmane.network.lwip.devel/9214 <pre>URL: &lt;http://savannah.nongnu.org/patch/?8037&gt; Summary: LWIP server fails if we connect multiple clients Project: lwIP - A Lightweight TCP/IP stack Submitted by: krantip Submitted on: Mon 29 Apr 2013 05:04:17 AM GMT Category: None Priority: 7 - High Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: None _______________________________________________________ Details: I am using LWIP stack version 4.0.My requirement is,connect minimim 50 clients to lwip server using single thread. Single client server is working fine,but if i connect 2-3 clients,then after some time,I found , tcp_write out of memory error,because of TCP_SND_QUEUELEN gets over. I get below error,when it shows tcp-write error. LWIP_DEBUGF(TCP_OUTPUT_DEBUG | 3, ("tcp_write: too long queue %"U</pre> Krantip 2013-04-29T05:04:19 http://permalink.gmane.org/gmane.network.lwip.devel/9213 <pre>URL: &lt;http://savannah.nongnu.org/patch/?8034&gt; Summary: autoip: added autoip_remove_struct Project: lwIP - A Lightweight TCP/IP stack Submitted by: marathon96 Submitted on: Sat 27 Apr 2013 07:23:52 PM GMT Category: IPv4 Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: None _______________________________________________________ Details: From: Grant Erickson &lt;marathon96&lt; at &gt;gmail.com&gt; Date: Sat, 27 Apr 2013 12:20:29 -0700 Subject: [PATCH] autoip: add autoip_remove_struct Added previously-missing autoip_remove_struct as a companion to autoip_set_struct and to parallel dhcp_{set,remove}_struct. --- src/include/ipv4/lwip/autoip.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/include/ipv4/lwip/autoip.h b/src/include/ipv4/lwip/</pre> Grant Erickson 2013-04-27T19:23:54 http://permalink.gmane.org/gmane.network.lwip.devel/9212 <pre>Update of bug #37353 (project lwip): Status: None =&gt; Wont Fix Open/Closed: Open =&gt; Closed _______________________________________________________ Follow-up Comment #2: PPP_INPROC_OWNTHREAD feature removed in ppp-new, which make this bug not relevant anymore. Git commit 25f9f55878f008113bc1f4a0068d4827ed4595b9. _______________________________________________________ Reply to this item at: &lt;http://savannah.nongnu.org/bugs/?37353&gt; _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ </pre> Sylvain Rochet 2013-04-26T20:05:21 http://permalink.gmane.org/gmane.network.lwip.devel/9211 <pre>Update of bug #37278 (project lwip): Open/Closed: Open =&gt; Closed _______________________________________________________ Reply to this item at: &lt;http://savannah.nongnu.org/bugs/?37278&gt; _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ </pre> Sylvain Rochet 2013-04-26T20:05:04 http://permalink.gmane.org/gmane.network.lwip.devel/9210 <pre>Update of bug #37278 (project lwip): Status: In Progress =&gt; Wont Fix _______________________________________________________ Follow-up Comment #2: PPP_INPROC_OWNTHREAD feature removed in ppp-new, which make this bug not relevant anymore. Git commit 25f9f55878f008113bc1f4a0068d4827ed4595b9. _______________________________________________________ Reply to this item at: &lt;http://savannah.nongnu.org/bugs/?37278&gt; _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ </pre> Sylvain Rochet 2013-04-26T20:04:46 http://permalink.gmane.org/gmane.network.lwip.devel/9209 <pre>URL: &lt;http://savannah.nongnu.org/patch/?8030&gt; Summary: Correct spelling of received Project: lwIP - A Lightweight TCP/IP stack Submitted by: morepork Submitted on: Thu 25 Apr 2013 09:48:14 PM GMT Category: None Priority: 3 - Low Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: None _______________________________________________________ Details: diff --git a/src/core/tcp.c b/src/core/tcp.c index a0cbb15..8690cd2 100644 --- a/src/core/tcp.c +++ b/src/core/tcp.c &lt; at &gt;&lt; at &gt; -667,7 +667,7 &lt; at &gt;&lt; at &gt; tcp_recved(struct tcp_pcb *pcb, u16_t len) tcp_output(pcb); } - LWIP_DEBUGF(TCP_DEBUG, ("tcp_recved: recveived %"U16_F" bytes, wnd %"U16_F" (%"U16_F").\n", + LWIP_DEBUGF(TCP_DEBUG, ("tcp_recved: received %"U16_F" bytes, wnd %"U16_F" (%"U16_F").\n", len, pc</pre> Liam 2013-04-25T21:48:15 http://permalink.gmane.org/gmane.network.lwip.devel/9208 <pre>Follow-up Comment #4, bug #38748 (project lwip): At present, the netif is the canonical structure for getting network interface information, including IP addresses, MTU and link layer address. So, from that perspective, yes. _______________________________________________________ Reply to this item at: &lt;http://savannah.nongnu.org/bugs/?38748&gt; _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ </pre> Grant Erickson 2013-04-24T21:52:49 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.network.lwip.devel