Re: [lwip-users] altcp protocol specification

[goldsimon]

Bas Wijnen wrote:
>Ah. So the resulting connection is just regular TCP, and the other side
>doesn't
>see any difference?

Well, that depends on how you configure it. The remote side sees tcp, or tls, 
or

> In that case what you call altcp and what this
>hardware
>calls altcp is not the same thing. This documentation is about a UDP
>protocol
>which has TCP-like headers to get a connection-based protocol on top of
>UDP. Am
>I correct that that is not what altcp is in the context of this
>project?

I didn't know the name 'altcp' was being used outside lwIP. It was just my 
invention of an api namespace for the new functions...

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip, mqtt and mbedtls

[goldsimon]

Manu Abraham wrote:
> [..]
>  #error "lwip_sanity_check: WARNING: TCP_WND is larger than space
>provided by PBUF_POOL_SIZE * (PBUF_POOL_BUFSIZE - protocol headers).
>If you know what you are doing, define LWIP_DISABLE_TCP_SANITY_CHECKS
>to 1 to disable this error."
>
>So, What should be done ?
>
>Am I going on the right track, or something is wrong somewhere ?

I think so. TLS has this far only been used in setups with relatively large RAM 
settings. It could be tweaked, but you'd have to know what you're doing. The 
current compile time checks are there to help you to not get stuck in the 
middle of a transfer because you're out of memory. That doesn't mean you always 
need all memory...

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] netif->hwaddr_len of loopback interface is not ETH_HWADDR_LEN

[goldsimon]

Am 6. Juli 2020 19:09:51 MESZ schrieb "Laurenz Altenmüller" 
:
>Hi,
>
>I want to unit test some embedded firmware on native host arch by 
>building it against the lwip unix port (latest master). Right now I
>want 
>to add a fake IP and MAC to the ARP table with 
>`etharp_add_static_entry()` so that the tested function can find it
>when 
>it uses `etharp_query()` and then `etharp_find_addr()` in its 
>implementation. For all this I'm using the netif I get from 
>`netif_get_loopif()`.
>
>Unfortunately I hit the assert in etharp.c:1139 ("netif->hwaddr_len
>must 
>be the same as ETH_HWADDR_LEN for etharp!"). Using the debugger I can 
>confirm that `netif->hwaddr_len` of my loopback netif is 0.
>
>Should I even be able to use the loopback interface for ARP things?

No, the loopif is not meant to work with ARP. Our own unit tests use a 
dedicated tiny test netif for such tests.

Regards,
Simon

> Am
>I 
>just missing some initialization? (In my test's `setUp()` I call 
>`sys_init(); mem_init(); netif_init(); test_netif=netif_get_loopif();`)
>
>Cheers
>Laurenz
>
>
>___
>lwip-users mailing list
>lwip-users@nongnu.org
>https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip reply delayed after long communication idle time

[goldsimon]

Am 4. April 2020 08:04:32 MESZ schrieb Jochen Strohbeck :
>Now, in 2.1.x, the first http request after host and controller power
>up is
>served but still delayed for ca. 5s and I don't know if this is a
>"feature"
>or bug of ARP.
>Please have a look at the commented 1st trace below.

Please send packet captures as pcap file, not as text.

Regards,
Simon

>The second trace shows the normal behavior. The controller immediately
>sends
>out a ARP broadcast after receiving the first TCP msg. For me the host
>is
>expecting this broadcast but this is missing in the first trace.
>
>Who is to blame for the delay? The http server or the host? How to get
>rid
>of the delay if possible? I'm on windows 10.
>
>1880   73051.473650de:bd:00:00:00:29   Broadcast   ARP 60  
>ARP Announcement
>for
>192.168.0.100
>-> controller power on
>
>1881   73205.861086192.168.0.9 192.168.0.100   TCP 66  57961 → 
>80 [SYN]
>Seq=0
>Win=64240 Len=0...
>-> 1st http.get() request after power up (python requests)
>
>1882   73208.861658192.168.0.9 192.168.0.100   TCP 66  [TCP 
>Retransmission]
>57961 → 80 [SYN] Seq=0 Win=64240...
>-> retrans after 3s
>
>1883   73210.857278Dell_7a:2c:51   de:bd:00:00:00:29   ARP 42  
>Who has
>192.168.0.100? Tell 192.168.0.9
>-> host ARP request after 2s
>
>1884   73210.861936192.168.0.9 192.168.0.100   TCP 66  57962 → 
>80 [SYN]
>Seq=0
>Win=64240 Len=0 MSS=1460 WS=2...
>1885   73210.862961de:bd:00:00:00:29   Broadcast   ARP 60  
>Who has
>192.168.0.9?
>Tell 192.168.0.100
>1886   73210.862988Dell_7a:2c:51   de:bd:00:00:00:29   ARP 42  
>192.168.0.9 is
>at
>98:e7:43:7a:2c:51
>1887   73210.863678de:bd:00:00:00:29   Dell_7a:2c:51   ARP 64  
>192.168.0.100
>is at
>de:bd:00:00:00:29
>1888   73210.863679192.168.0.100   192.168.0.9 TCP 60  80 → 
>57962 [SYN,
>ACK]
>Seq=0 Ack=1 Win=2920 Len=0 MSS=1460
>:
>
>1990   74227.892538de:bd:00:00:00:29   Broadcast   ARP 60  
>ARP Announcement
>for
>192.168.0.100
>1991   74248.600750192.168.0.9 192.168.0.100   TCP 66  58120 → 
>80 [SYN]
>Seq=0
>Win=64240 Len=0 MSS=1460...
>1992   74248.601430de:bd:00:00:00:29   Broadcast   ARP 60  
>Who has
>192.168.0.9?
>Tell 192.168.0.100
>1993   74248.601456Dell_7a:2c:51   de:bd:00:00:00:29   ARP 42  
>192.168.0.9 is
>at
>98:e7:43:7a:2c:51
>1994   74248.601813192.168.0.100   192.168.0.9 TCP 60  80 → 
>58120 [SYN,
>ACK]
>Seq=0 Ack=1 Win=2920...
>
>
>
>
>--
>Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html
>
>___
>lwip-users mailing list
>lwip-users@nongnu.org
>https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] How to build LWIP test on linux

[goldsimon]

Am 14. März 2020 18:47:01 MEZ schrieb Sachin Gole :
>In 2.1.2 version, There is no dev folder to run lwip_unittest
>
>
>~/Downloads/lwip-2.1.2$ ls
>build  CMakeCache.txt  cmake_install.cmake  COPYING
> CPackSourceConfig.cmake  FEATURES  Makefile  src   UPGRADING
>CHANGELOG  CMakeFiles  CMakeLists.txt   CPackConfig.cmake  doc
> FILES READMEtest
>
>
>Great help if you can suggest.

Oh come on, really? I'm sure you can figure out the path from what I wrote.

Cheers,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] VLAN support

[goldsimon]

Am 25. Februar 2020 23:32:44 MEZ schrieb SimonW :
>I've searched all the documentation at
>http://www.nongnu.org/lwip/2_1_x/index.html. There is not mention of
>VLAN.

I said search the code. Sadly, we're not better than other open source software 
when it comes to documentation:-)

>There are 
>
>This forum has a number of threads from 2011 and 2012. Saying there is
>incomplete support for receiving tagged frames. There is one from 2014
>- not
>sure I understand it.
>
>What I'd like - it it's possible -  is to create a number of netifs (2
>or 3)
>- each generating and receiving packets tagged for specific VLAN.

No, such code indeed does not yet exist. But it shouldn't be too hard to write 
as a dummy netif driver.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] 802.1D bridge

[goldsimon]

Am 25. Februar 2020 22:38:31 MEZ schrieb SimonW :
>[..]
>Makes reference to including IPv4 config and not adding IPv6 addresses.

No, that might be misleading. The netifs get no addresses at all.

>I
>could do with fuller documentation - or better still an example.

This is a standard bridge. Before knowing how to use it in lwip, you should be 
sure it's the correct thing to use.

Most of the time, you rather need routing, not bridging. A bridge is what you 
know as a switch in network hardware. It mostly makes sense of all interfaces 
are of the same type and speed.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] 802.1D bridge

[goldsimon]

Am 24. Februar 2020 22:45:18 MEZ schrieb SimonW :
>Can anyone point me to an example using the bridge netif that is in
>lwip 2.1?
>Ideally with 1 leg using either an embedded MAC, or RNDIS over USB host
>- I
>have both legs working independently. 
>
>Bonus question: I understand that the 2.1 bridge only works with IPV4.
>Does
>anyone know if IPV6 support is on the horizon, or what is needed to add
>it?

I'd suggest you should first know what you want. A bridge does not know 
anything about the upper layer protocols. For the bridge, there is no 
difference between IP v4 or v6.

I guess what you need is something else...

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] VLAN support

[goldsimon]

Am 24. Februar 2020 23:42:06 MEZ schrieb SimonW :
>Does anyone know if support for VLAN is planned for lwip?

Did you grep through the code searching for "vlan"? If not, I'd suggest to do 
that.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] https server woes.

[goldsimon]

Am 22. Februar 2020 14:36:58 MEZ schrieb Trampas Stern :
>Do you have the example code for the STM32?  Even just the mbedtls
>config
>and lwip config files would be good starting point.

Not right now, sorry. I haven't done that myself but a collegue of mine. Plus 
the code in question is not currently publicly available, so I cannot just post 
it here.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LwIP tweaking the TCP stack behavior

[goldsimon]

Am 20. Februar 2020 17:00:46 MEZ schrieb eitan via lwip-users 
:
>Hello,
>
>I have a small device that sends data over TCP at a fast rate, this is
>a
>small and not very cable hardware.
>Now, LwIP is (as it should) maintains an acknowledge Q of ACKed packets
>so
>it could re-transmit if it has to.
>In my implementation, there is no need to handle ACKs at all.

Short answer: disable the whole tcp code by setting LWIP_TCP to 0 and implement 
it yourself by using raw a pcb.

You won't easily do this by changing our tcp code.

And yes, I wouldn't do this at all ;-)

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Need support on TCP/IP packet transmission

[goldsimon]

Am 20. Februar 2020 15:23:55 MEZ schrieb praveenkumar raavi 
:
>Hi,
>
>Any update on my query...

I'm not sure I even understand what your actual problem is. But being stuck in 
the timer function surely sounds like a threading problem...

Regards,
Simon

>
>Regards,
>PraveenKumar.
>
>On Thu, 13 Feb 2020, 09:54 praveenkumar raavi,
>
>wrote:
>
>> Hi Everyone,
>>
>>
>>
>> we are using LWIP 2.0.3 for one of our project to establish the TCP
>> connection from ECU and Atmel micro.
>> We got the LWIP from Atmel itself and I have modified little to
>support
>> VLAN data receive and transmit.
>>
>>
>>
>> But now we are seeing some issue during data transmission.
>> When the ECU goes to sleep, it cut down the Ethernet link and when it
>> wakes up it will establish the Ethernet connection.
>> But here when the ECU wakes up the communication is not going well
>from
>> our LWIP stack. We are seeing multiple re transmissions which are
>causing
>> issues in data transmission.
>>
>> So we planned to reinitialize the LWIP stack after ECU goes to sleep.
>> But when I do shut down the connection, the connection is not closing
>as
>> there is no FIN request response from ECU and its getting stuck in
>tcp_slow
>> timer.
>> Also I have seen new behavior like when i received new frame on TCP,
>I am
>> trying to ACK back using ACK now function(pcb->prio = TCP_PRIO_MAX;
>> tcp_send_empty_ack(pcb);  tcp_output(pcb);), but I am seeing the ACK
>> packet transmitted after my data packet is been transferred.
>> This I didn't understand like why the ACK packet is transferred after
>data
>> packet? this is also one of the reason for us to see communication
>failure.
>>
>> I am attaching the images for our communication issues.
>> Here LWIP_IP: 192.168.6.182
>>  ECU IP : 192.168.6.144
>> If you see LWIP_TCP_DataSentoutFirst.JPG, the data is send first and
>ACK
>> is sent after that even though the ACK transmission is initiated
>first with
>> priority level set to MAX.
>>
>> Please let us know how to solve this issue.
>>
>>
>>
>> I am adding following steps during lwip init.
>>
>> TCPIP_STACK_INTERFACE_0_init(st_ETH_ConfigStruct.u8_SourceMacAddress,
>> Src_IP, gw);
>>
>> netif_set_up(_STACK_INTERFACE_0_desc);
>>
>> netif_set_default(_STACK_INTERFACE_0_desc);
>>
>> mac_async_enable();
>>
>> etharp_add_static_entry(_IP, (struct eth_addr
>> *)_ETH_ConfigStruct.u8_DestMacAddress[0]);
>>
>> pcb_tcp = tcp_new();
>>
>> error = tcp_bind(pcb_tcp, ,
>st_ETH_ConfigStruct.u16_SourcePortNum);
>>
>> pcb_tcp = tcp_listen(pcb_tcp);
>>
>> tcp_accept(pcb_tcp, Etherdo_connected);
>>
>>
>>
>> After link established, below functions are used to do data transfer.
>>
>>
>>
>> tcp_write(pcb_tcp,u8_DataBuff,u16_DataLen,TCP_WRITE_FLAG_MORE);
>>
>> tcp_output(pcb_tcp));
>>
>>
>>
>> This is how I initialized LWIP stack and transmitting data over
>ethernet.
>> Here I have used static MAC address as we should connect to
>particular MAC
>> address.
>>
>>
>> Regards,
>>
>> PraveenKumar.
>>

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] DHCP problems

[goldsimon]

Am 17. Februar 2020 13:21:46 MEZ schrieb Trampas Stern :
>How should I be using the 'lwip_cyclic_timers' ?

It's an array of timer callback functions and their required timer frequency. 
You should use this to set up your timers, so you'll be calling all required 
timers in the future.

Regards,
Simon

>
>On Sat, Feb 15, 2020 at 2:36 PM goldsi...@gmx.de 
>wrote:
>
>> Am 14.02.2020 um 19:53 schrieb Trampas Stern:
>> > OK walking through the code it appears somewhere along the way the
>ACD
>> > module was added and it looks like it needs to have it's
>> > timer periodically called.
>> >
>> > I added it to the timer list and seem to work now.  I would have
>figured
>> > that the ACD timer would have been called from the DHCP timer for
>> > backwards compatibility. I assume this was done for a good reason.
>>
>> Sorry for the inconvenience. Yes, there *is* a reason: ACD has been
>> implemented in a bad way before inside dhcp.c plus it can now be used
>> without DHCP enabled, and its interval is 100ms, not 500ms like dhcp.
>>
>> However, calling all those timer functions yourself is not what you
>> should be doing. We need to be free in adding timers to change/fix
>> things like this.
>>
>> Even when not using the automatic timer handling provided by lwIP,
>you
>> should use the list of timers (and corresponding intervals) provided
>as
>> 'lwip_cyclic_timers' array by timeouts.h.
>>
>> Regards,
>> Simon
>>
>> ___
>> lwip-users mailing list
>> lwip-users@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] R: Re: lwip-users Digest, Vol 198, Issue 3

[goldsimon]

Please do not reply to digest mails. That breaks email threading for sure and 
you risk people lose track of your story.

Regards,
Simon


Am 4. Februar 2020 18:29:20 MEZ schrieb Renato Barresi 
:
>Hi Sylvain,
>
>I changed VJ_SUPPORT to 0 and still got the same behavior.
>
>I'm sending the PPP debug trace.
>
>Thank you for your help!
>
>Regards,
>
>Renato
>
>
>Updated lwipopts.h
>
>#define NETIF_DEBUG LWIP_DBG_ON
>#define HTTPD_DEBUG LWIP_DBG_ON
>#define TCP_DEBUG   LWIP_DBG_ON
>
>#define PPP_DEBUG   LWIP_DBG_ON
>#define PRINTPKT_SUPPORT1
>#define PPP_PROTOCOLNAME 1
>
> /*PPP*/
>#define PPP_USE_PBUF_RAM0
>
>#define PPP_NUM_TIMEOUTS_PER_PCB(1 + PPP_IPV4_SUPPORT +
>PPP_IPV6_SUPPORT + CCP_SUPPORT)
>
>#define VJ_SUPPORT  0
>#define CCP_SUPPORT 0
>#define EAP_SUPPORT 0
>
>#define PPP_MRU 1500
>#define PPP_DEFMRU  1500
>#define PPP_MAXMRU  1500
>#define PPP_MINMRU  128
>
>/*ICMP*/
>#define IP_DEFAULT_TTL  255
>
>#define MEMP_NUM_PBUF   120
>#define MEMP_NUM_TCP_PCB40
>
>/*TCP*/
>#define LWIP_TCP_SACK_OUT   1
>#define TCP_TTL255
>#define TCP_MAXRTX  12
>#define TCP_SYNMAXRTX   6
>#define TCP_MSS 1460
>#define TCP_WND (4 * TCP_MSS)
>#define TCP_SND_BUF (4 * TCP_MSS)
>
>//#define TCP_SND_QUEUELEN((4 * (TCP_SND_BUF) +
>(TCP_MSS -
>1))/(TCP_MSS))
>//#define MEMP_NUM_TCP_SEG16
>
> /*HTTP*/
>//#define LWIP_HTTPD_SUPPORT_REQUESTLIST  1
>//#define LWIP_HTTPD_SUPPORT_11_KEEPALIVE 1
>#define HTTPD_MAX_RETRIES   15
>#define HTTPD_POLL_INTERVAL 6
>#define HTTPD_TCP_PRIO  TCP_PRIO_MIN
>//#define LWIP_HTTPD_REQ_QUEUELEN 15
>//#define LWIP_HTTPD_MAX_REQ_LENGTH   LWIP_MIN(1023,
>(LWIP_HTTPD_REQ_QUEUELEN * PBUF_POOL_BUFSIZE))
>//#define HTTPD_MAX_WRITE_LEN(pcb) ((u16_t)(3 * altcp_mss(pcb)))
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] httpd POST gets stuck after few requests

[goldsimon]

Trampas Stern wrote:
>err_t httpd_post_receive_data(void *connection, struct pbuf *p)
>{
> pbuf_free(p);
>return ERR_OK;
>}

Ah, yes. And the problem still is that the example does not do that. I'll file 
a bug...

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] httpd POST gets stuck after few requests

[goldsimon]

Adam Baron wrote:
>I did search of POST related problems sorted by date. I will do so
>again.
>
>PBUF_POOL_SIZE is affecting number of POST I can do directly. That is,
>I
>can do as many posts as PBUF_POOL_SIZE is defined.

I think the user reporting this last time,did not free the pbuf passed to the 
post start callback, but I could remember wrong...

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] httpd POST gets stuck after few requests

[goldsimon]

Adam Baron wrote:
>OK, so my lwip gets stuck exactly after 16 POSTs.
>
>Maybe the POST is not freeing PCB, or other structures properly.

I rather think not freeing a pbuf could be the cause. I think we had that a 
little while ago. Have you searched the list archive?

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Post messages with the httpd.c example

[goldsimon]

Trampas Stern wrote:
>I was trying to use the httpd.c example which does some POST data
>parsing.
>From the httpd.h file it appears that httpd_post_begin() function is
>called
>with the first packet of data.  However in reality it appears in use
>that
>it is usually called with just the POST header.
>Since I assume the POST header could span multiple packets I assumed
>that
>the  httpd_post_begin() may not have the complete header but might just
>be
>first packet in the header.
>Therefore in my implementation of  httpd_post_begin()
>and httpd_post_receive_data() I was scanning for the double-CRLF to
>determine the end of the header and start of data.
>What I found is that the "\r\n\r\n" was actually "\0\n\r\n".  Looking
>through the http_post_request() code it appears that the code is
>putting
>the '\0' in the data:
>
>/* trim http header */
>* *crlfcrlf = 0;*
>err = httpd_post_begin(hs, uri, hdr_start_after_uri,
>hdr_data_len, content_len, http_uri_buf,
>LWIP_HTTPD_URI_BUF_LEN, _auto_wnd);
>
>Is this an error?   Specifically if the  httpd_post_begin() is not
>guaranteed to be sent with the full header for the POST then on the
>users
>application side we should be managing determining where the header
>ends
>and start of data is, and thus the httpd.c code should not be changing
>the
>data within the packet.

From the top of my head, the code buffers incoming pbufs until the complete 
http header is received. It then trims it to ensure pbuf strlen of the header 
is the header length.

I'd have to look at it again to be sure though...

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LwIP PCBs reset

[goldsimon]

Amena El Homsi wrote:
>Hello,
>
>After disconnecting from an AP I have to reset the PCBs pools. If I did
>not
>do that and I reconnect to the AP and If I tried to bind a socket to a
>port
>that I already used in the previous connection, binding fails (port in
>use).

That should not be required. Why don't you just close all connections instead 
of such a hack? You might have SO_REUSE or something like that...

>
>To reset the PCBs I have to call memp_init() with MEMP_MEM_INIT set to
>1,
>right?

No, no, no! Hack! Don't do that. And just so that everyone reading your post 
knows this is wrong, I *had* to answer this :-)

>
>When I call memp_init(), even if I did not set MEMP_MEM_INIT to 1, DHCP
>fails.

Ok, that's strange, but your problem lies somewhere else. Just "randomly" 
wiping some memory (memp_init) might make your problems go away for now, but 
others will arise!

>
>According to wireshark capture, we send DHCP discover packet, the AP
>replies with the Offer, however we didn't enter dhcp_handle_offer()
>function.
>
>Do you have any idea what is happening?

No.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] tcp_write function merges 2 different packets while sending

[goldsimon]

Liju John wrote:
>Still you can disable the streaming feature of the TCP and send like
>udp
>packets with TCP_NODELAY set socket option on the TCP level. This
>option is
>available on the socket. You can explore on it.

While this is correct, it's not a good suggestion in this thread: the remote 
host is free to combine multiple rx packets into one 'read' call, so even if tx 
is framed as written, it may or may not work on the remote side.

An I say it's even dangerous to rely on this as it might work until segments 
are dropped. You think the system is working, but in fact, it might break on 
first packet loss.

Instead, so the right think and create your application layer protocol so that 
it can handle a byte stream, not rely on packets.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] tcp_write function merges 2 different packets while sending

[goldsimon]

Urvi wrote:
>[..]
>
>But when I send 1 data packet of size=6 bytes (call tcp_write() and
>then
>tcp_output()) and next packet of size=45 bytes (call tcp_write() and
>then
>tcp_output()), then at server side it receives as a one single data
>packet
>of size=51 bytes; due to this my complete data packet becomes garbage
>and I
>got failure in communication. (this is just one packet example, but it
>happens often).
>
>
>How to solve this issue?

That's expected TCP behaviour, not an lwIP issue. Of you need datagrams 
strictly separated, use UDP.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] dhcp ip change and callback lwip 1.4.1

[goldsimon]

Am 8. November 2019 16:15:06 MEZ schrieb vinu :
>Suppose the DHCP server decides to change the ip issued to my device
>after
>the lease time expiry, how can the application know that there is an ip
>change? Does the status callback be called in this case?

Yes.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] SNMP v3 and v2

[goldsimon]

Am 8. November 2019 14:38:38 MEZ schrieb Harrold Spier 
:
>Hi Mario,
>
>As far as I know, the current stable version of lwIP does only support
>SNMPv1 traps. I'm now using the latest lwIP git checkout, which does
>have
>support for SNMP v2c traps.
>
>As far as I can see, there is no support for SNMPv3 traps yet.
>
>If you build lwIP for SNMPv3, the older SNMP version are enabled by
>default. I was also a little bit confused about this, because if you
>support v3, you probably don't want older versions to be enabled.
>Of course you can still disable them by calling the
>functions snmp_v1_enable(0) and snmp_v2c_enable(0).
>
>Using SNMPv3, I had a small issue with SNMP SET. I created a quick fix
>to
>solve it, but I have to dig a little bit deeper into it to find out
>whether
>this is indeed the correct solution.
>
>I attach the patch. It contains a diff with the current version of
>snmp_msg.c in Git, but it will not be difficult to use it for the
>current
>stable version also. At least you can see what I changed.

Would you mind sharing patches via our patch tracker instead of attaching them 
to an email here? That would greatly increase the chance of getting them 
upatreamed!

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] MEM_USE_POOLS issue

[goldsimon]

Am 7. November 2019 08:54:25 MEZ schrieb mtimm :
>Simon, 
>Thank you. It works better ;)
>One more question about purpose of using custom pools.
>LwIP uses few internal pools like PBUF_POOL_base, TCP_PCB_BASE,
>UDP_PCB_BASE.
>What can be the reason of using additional custom pools? Is it about
>preparing memory for copying data from PBUF_POOL_base for application
>tasks?
>Could you give some example, please?

That was the old way of defining custom pools for application code mainly.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Delay in web page loading on v1.4.2

[goldsimon]

Am 7. November 2019 11:06:07 MEZ schrieb vinu :
>
>We found that the issue was only occuring when the browser used is
>chrome
>and not evident while testing with Firefox browser or wget from a linux
>pc.

The problem might be the number of parallel connectionss then?

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] link down handling in dhcp v1.4.1

[goldsimon]

Am 7. November 2019 08:59:54 MEZ schrieb vinu :
>Hi Simon,
>
>Is it safe to call dhcp_network_changed() from application thread ? I
>tried
>it ans seems to be working properly.

No, it's not safe. Don't do that.

> Also, should i call
>netif_set_down()
>and netif_set_addr() before dhcp_network_changed() ?

No.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Bug in invalidate_cpu_cache() usage

[goldsimon]

Am 2. November 2019 00:34:41 MEZ schrieb Toshiyasu Morita :
>I was looking through the lwip and I found some obvious problems in the
>way
>invalidate_cpu_cache() is used.

That function does not exist in lwIP.  You're probably using some vendor 
version?

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] CMSIS V2 ??

[goldsimon]

Am 25. September 2019 23:37:22 MESZ schrieb Dave Nadler :
>I'm using lwip 2.1.2 on FreeRTOS, on ST platform.
>lwip-2.1.2\system\OS\sys_arch.c sys_mbox_new(..) uses macro

That file is not part of our distribution, don't know where you got it from.


Regards,
Simon 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] altcp API: altcp_active_pcbs

[goldsimon]

Am 20. September 2019 07:22:39 MESZ schrieb "koszo.simon" 
:
>Hi Simon,
>
>Thank you for your quick answer.
>
>Do you have any suggestion how I would be able to make my tcp server
>application to send out packages on every socket which is connected to
>the
>same tcp local port in a a supported manner?

Not via lwIP API. I'd suggest you create your own list at application level.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] altcp API: altcp_active_pcbs

[goldsimon]

Am 19. September 2019 17:20:29 MESZ schrieb "koszo.simon" 
:
>Hi everybody,
>
>I have a question about altcp API: Does "altcp_active_pcbs" (or
>something
>similar) exist?

No, I don't think so. And what you're doing with the old tcp isn't actually 
supported: it might work, but be prepared for side effects or changes to that 
variable. It's not a supported public api we expose to applications!

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Confused - Should I loop on pbufs in my receive callback?

[goldsimon]

Am 5. August 2019 17:40:51 MESZ schrieb lauziepi 
:
>Hello,
>
>Regarding question #2 I am talking about the rx callback (lwIP raw
>API).

I'm not absolutely sure what you mean, but p->next can contain another pbuf and 
so on, yes.

Regards,
Simon

>
>
>goldsi...@gmx.de wrote
>> Am 02.08.2019 um 20:29 schrieb 
>
>> goldsimon@
>
>> :
>>> Am 02.08.2019 um 17:34 schrieb lauziepi:
>>>> Hello,
>>>>
>>>> thanks for the reply! Regarding question #2, would you (or someone
>else)
>>>> be
>>>> kind enough to tell me how to verify if there is more than one
>packet to
>>>> handle? What should be my looping condition(s)?
>>>
>>> This is a mailing list. You're using a forum as a frontend to this
>list
>>> only. Please do those people using their mailers a favor and include
>>> older mails as citation.
>>>
>>> I'll now go searching what "question #2" was...
>> 
>> OK. After re-reading your original post, I'm not sure what "question
>#2"
>> really was about. The rx callback (lwIP raw API) or your driver
>interrupt?
>> 
>> Please try to explain again.
>> 
>> Regards,
>> Simon
>> 
>> ___
>> lwip-users mailing list
>
>> lwip-users@
>
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
>
>
>
>--
>Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html
>
>___
>lwip-users mailing list
>lwip-users@nongnu.org
>https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] ERR_ABRT: Out of pcbs or netconns

[goldsimon]

Please, this is an international community list, could you write in English so 
that everyone can understand?

Thanks,
Simon


Am 11. April 2019 16:22:25 MESZ schrieb Sarp Daltaban :
>Doğru kanka, tek thread yeterli eğer ppp'yi beslemiyorsan.
>Endoks & t4e'de çalışıyorum.
>
>tirmalabenikasibeni , 11 Nis 2019 Per, 16:47
>tarihinde şunu yazdı:
>
>> sarp wrote
>> > Kanka Netconn zaten multi client bağlanmasına izin veren bir soket.
>> > Bağlantı başına yeni thread yaratmana gerek yok.
>>
>> Yani diyosunki sadece listen thread olsun, her accepted bağlantı için
>bir
>> kez callback çağır yeterli. Doğru mu?
>>
>>
>> sarp wrote
>> > Hangi şirkette çalışıyorsun?
>>
>> Datakomda çalışıyorum moruk sen?
>>
>>
>>
>> --
>> Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html
>>
>> ___
>> lwip-users mailing list
>> lwip-users@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] makefs and mem_free errors

[goldsimon]

Am 2. April 2019 21:34:28 MESZ schrieb Mike Spenard :
>Submitted bug report on 404 missing issue.
>
>Could you provide some guidance on why the fsdata.c I generated with
>makefsfile.exe including headers is causing a "HTTP headers not
>included in file system" error?

I'd have to look at the sources to be aure, but it might be a configuration 
issue: by default, httpd does not generate the headers at runtime to reduce 
code and RAM footprint...

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Using LWIP with PPP and NAT

[goldsimon]

Am 28. Februar 2019 12:16:00 MEZ schrieb Ajay Bhargav 
:
>I am yet to update the repo to latest lwIP source, but you can still
>use it. 
>Usage information is given here:
>https://github.com/ajaybhargav/lwip_nat/blob/master/src/core/ipv4/ip4_nat.c
>
>I will better create a different howto file for this repo.

And while you're at it, you could provide a more meaningful document to be 
shown instead of the original lwIP README that states the difference between 
your repository and our original sources.

Thanks,
Simon

>Regards,
>Ajay Bhargav
>
>
>From: Flavio Castro Alves Filho
>Sent: Thursday, February 28, 2019 3:50 PM
>To: Mailing list for lwIP users
>Subject: Re: [lwip-users] Using LWIP with PPP and NAT
>
>And how do I use this code? Or I can't use this code?
>
>As I am not an LwIP expert, I couldn't even identify the different
>code from that repo :-|
>
>Best regards,
>
>Flavio

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Porting 2.1.2 to Atmel Studio 7... dirent.h?

[goldsimon]

Am 8. Februar 2019 20:18:23 MEZ schrieb Stephen Cowell 
:
>
>On 2/7/2019 11:39 PM, goldsimon wrote:
>> Am 8. Februar 2019 00:27:58 MEZ schrieb Stephen Cowell 
>> :
>> ...
>
>> > Does everyone have to go through and edit
>> >the
>> >header file includes to reflect the new structure?  I can't see why
>> >this
>> >is not fixed in the release.
>>
>> That should not be required. Can you give an example?
>>
>
>In my example, I have replaced the lwIP folder lwip-1.4.1 with 
>lwip-2.1.2 as I received it.
>
>OK... I'm compiling along, and I get this error:
>
>"Error        lwip/apps/lwiperf.h: No such file or directory "
>
>This request lies in lwiperf.c, which resides in
>
>lwip/lwip-2.1.2/src/apps/lwiperf
>
>.  The file it wants resides in
>
>lwip/lwip-2.1.2/src/include/lwip/apps
>
>.  Every instance of this (there are dozens) requires me to change the 
>header include from
>
>#include "lwip/apps/lwiperf.h"
>
>to
>
>#include "../../include/lwip/apps/lwiperf.h"
>
>Am I doing something wrong?

Yes, obviously. You need to add 'include' to your include path.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Porting 2.1.2 to Atmel Studio 7... dirent.h?

[goldsimon]

Am 8. Februar 2019 00:27:58 MEZ schrieb Stephen Cowell 
:
>I'm attempting to update the SAM4E example project 
>THIRDPARTY_LWIP_BASIC_HTTP_EXAMPLE1 from 1.4.1 to 2.1.2.  The dev
>system 
>is Atmel Studio 7 using ARM/GNU Common toolchain.  I have NO_SYS =
>1 
>this is the bare-metal implementation.
>
>I've partway through the directory problems... it seems that the 
>directory structure has changed, but the files I have have not been 
>updated.  Is this normal?  Does everyone have to go through and edit
>the 
>header file includes to reflect the new structure?  I can't see why
>this 
>is not fixed in the release.

That should not be required. Can you give an example?

>
>Now I'm getting #error " not supported".  Does this mean that
>
>I'll have to go to a different toolchain?  Do I have to have tinydir

No. Just don't compile all the files. The one with dirent.h is probably 
'makefsdata', the host tool to create the embedded file system for httpd...

>for 
>the stack to work?  My eventual target (we've been selling our product 
>with lwip 1.4.1 for years) has FatFS already, I'd rather not do the 
>filesystem over as well.  Also getting "#error makefsdata not supported
>
>on this platform"... how do I carve up lwIP?  I've already deleted the 
>'api' folder, referring to this link:
>
>https://www.nongnu.org/lwip/2_0_x/group__lwip__opts__nosys.html
>
>This link was a great help, but I'm not sure if these guys are running 
>bare-metal or not...
>
>https://community.atmel.com/forum/upgrading-lwip-141-200-pbuf-issue
>
>Perhaps someone could throw me a bone?  Do I need an RTOS to move 
>forward?  Do I need a different toolchain?
>__
>Steve
>.
>--
>
>Stephen Cowell
>Project Manager/Engineer
>Plasmability LLC
>Office (512) 267-7087
>Cell  (512) 632-8593
>www.plasmability.com
>
>
>___
>lwip-users mailing list
>lwip-users@nongnu.org
>https://lists.nongnu.org/mailman/listinfo/lwip-users
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] How receive UDP broadcast with LwIP ?

[goldsimon]

Am 7. Februar 2019 16:56:04 MEZ schrieb Dirk Ziegelmeier :
>Can you at least check/debug to be sure your MAC delivers the desired
>packet to lwIP? e.g. by dumping the first few bytes of all received
>packets
>and looking for your desired broadcast?
>
>If that is not the case, consult your MAC manual about broadcast
>reception
>/ MAC filters.

Does non broadcast traffic work? Does ARP or DHCP work? If so, broadcast ETH 
works ok...

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LwIP and ARM Compiler 6

[goldsimon]

Am 4. Februar 2019 08:59:37 MEZ schrieb "Daniel Liquete García" 
:
>Good moorning,
>
>Thanks four your repply.
>
>The same day that i saw your answer, i found the error (Compile Error),
>but i dont know the exactly sintaxis to fix it.
>
>
>#if defined ( __CC_ARM   )
>ETH_DMADescTypeDef  DMARxDscrTab[ETH_RXBUFNB]
>__attribute__((at(0x2007C000)));/* Ethernet Rx DMA Descriptors */

I stopped reading here. You have a problem with the STM driver, not with lwIP. 
This is a mailing list for the lwIP stack. You may want to ask this question in 
the STM forum. Or have you tried that already? Support there is not the worst, 
if I remember correctly...

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LWIP/PPPOS for GSM module

[goldsimon]

Am 4. Februar 2019 06:53:47 MEZ schrieb Devanand Biradar :
>Hello Sylvain,
>I have corrected my input & output serial driver.
>Now I am getting the IP addr, GW, subnet from GSM using PPPOS over
>LWIP.
>Status - CONNECTED.
>
>Now I want to use PING (using ICMP).
>I want to ping google.com, how to proceed in this.
>I want the steps to perform.

Ignoring previous replies and just asking a question again does not make you 
very popular here...

How hard can it be to search through the lwIP sources to find the ping app file 
and an example using it? Have you done that?

If you want someone else to do your work, look for paid support. This mailing 
list tries to help, but you do have to show some interest in solving your 
problems yourself or you won't get too many answers to your mails...

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Help on porting lwIP to Beaglebone Black (AM335X) with Xenomai

[goldsimon]

Hi,

Am 28. Januar 2019 17:42:39 MEZ schrieb "Baur, Elias" 
:
>Hello everyone,
>
>
>I am new to lwIP and did a lot of research the last couple of days. My
>goal ist to do real time networking between wire-connected
>Beagleboards. Therefore, we have been setting up a Xenomai Co-Kernel on
>the boards. To actually send and receive UDP-packets, we want to use
>lwIP.

Why do you want to use lwIP. Of course it's possible to do that, but have you 
thought about using Linux with RT patch? Would that not be enough to reach your 
requited realtime timing?

With your approach, I guess you will need to give lwIP exclusive access to the 
petrol interface.

>I have found out that TI has already ported lwIP on its CPU in its
>Starterware:
>http://processors.wiki.ti.com/index.php/StarterWare_CPSW_Port_lwIP Now
>I am wondering whether it is possible to adapt this for my use case? Or
>what do you recommend to do to get lwIP running?

I really can't help you much there. If the network interface is for use 
exclusively to lwIP, I guess the netif driver can be reused. But you'll need to 
port lwIP to Xenomai (if that hasn't been done yet).

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] to free or not to free (pbuf_free in tcp_recv)

[goldsimon]

Am 23. Januar 2019 15:05:06 MEZ schrieb cbe...@vienco.de:
>Hi, 
>
>I'm working with the lwIP 1.4.1 on a TI M4 platform with rawapi and I'm
>having trouble to understand the documentation correctly.
>In particular the callback for tcp_recv(). In the rawapi.txt is said 
>
>"If there are no errors and the callback function is to return ERR_OK,
>then
>it must free the pbuf. 
>Otherwise, it must not  free the pbuf so that lwIP core code can store
>it."
>
>But in the echo example there is this part: 
>echo_recv() { 
>...
>else if(err != ERR_OK)
>  {
>/* cleanup, for unkown reason */
>if (p != NULL)
>{
>  es->p = NULL;
>  pbuf_free(p);
>}
>ret_err = err;
>  }
>
>The pbuf is freed AND the callback function returns an error. What
>would
>happen with the pbuf if it is not freed?

Try updating to a more recent version. Besides getting so many bugs fixed, 
you'll see that the echo code has changed as well since 1.4.1... 

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Make accept, recv and send non blocking

[goldsimon]

Am 22. Januar 2019 08:34:51 MEZ schrieb saad saeed :
>Dear All,
>
>I am using Socket API. How can I make lwip_accept(),lwip_recv() and
>lwip_send() non-blocking?

This is not an lwip specific question. It works the same as for all BSD 
compatible sockets implementations. Your favourite search engine should provide 
enough information

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Core lock check in unix port

[goldsimon]

Am 17. Januar 2019 12:11:22 MEZ schrieb Jacob Kroon :
>Hi,
>
>I apologize beforehand if the text looks like garbage, I'm pasting in
>gmail..
>
>I'm looking at the core lock check in the unix port:
>
>void sys_check_core_locking(void)
>{
>/* Embedded systems should check we are NOT in an interrupt context
>here */
>
>  if (lwip_tcpip_thread_id != 0) {
>pthread_t current_thread_id = pthread_self();
>
>#if LWIP_TCPIP_CORE_LOCKING
>LWIP_ASSERT("Function called without core lock", current_thread_id
>== lwip_core_lock_holder_thread_id);
>#else /* LWIP_TCPIP_CORE_LOCKING */
>LWIP_ASSERT("Function called from wrong thread", current_thread_id
>== lwip_tcpip_thread_id);
>#endif /* LWIP_TCPIP_CORE_LOCKING */
>  }
>}
>
>Would it make sense to unconditionally check the thread ids when using
>LWIP_TCPIP_CORE_LOCKING, since lwip_tcpip_thread_id is not used in the
>check in that configuration ?
>
>Is it allowed to call into LWIP API before the "tcpip_input" thread
>has started executing ?

It's not encouraged but should work. This is the reason the check is like it 
is...

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] DHCPv6 stateless and IPv6- auto address configuration

[goldsimon]

saad saeed wrote:
>Hello,
>Currently, I am using IPv6-auto address configuration. But in lwIP
>2.1.0, there is also DHCPv6 stateless.
>My Question: Are these one and a same thing?

No, the first configures an address via router solicitaions, the latter adds 
things that aren't available from router solicitations, like DNS server etc.

Stateful DHCPv6 would configure IPv6 addresses like DHCP does for IPv4, but 
that's not implemented yet, and probably not as broadly used as SLAAC.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] TCP - problems with large data

[goldsimon]

Am 8. Januar 2019 14:19:44 MEZ schrieb "Norberto R. de Goes Jr." 
:
>Hi Simon!
>I think a note about "gro" is appropriate,  for instance, in
>http://lwip.wikia.com/wiki/Tuning_TCP site.

The wiki is not really a thing I do edit or look at. Where in the lwip sources 
or docs (in the hit sources of on our homepage) would you have looked that we 
can put this?

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] TCP - problems with large data

[goldsimon]

Am 8. Januar 2019 11:50:48 MEZ schrieb "Norberto R. de Goes Jr." 
:
>How are you?
>
>After a long time spent in this issue with debugging in my network
>drive
>(socket raw), lwip configuration tuning (lwipopts.h), my client code,
>etc,
>etc; I noted (using simhost -d) that large packets  caused check-sum
>error
>in the lwip received side. So by searching in the internet, I found
>links
>relating to "offload segmentation".
>Resuming,  when I disable the "gro" (generic-receive-offload) of the
>NIC
>that treats the lwip packets the problem disappears.
>Command (for eth0):   > sudo ethtool -K eth0 gro off
>Verification:> ethtool -k eth0 | grep
>generic-receive-offload
>
>Please, does this make sense?

Yes, it does. Sorry for not having found the time to dig into this. It has been 
on my list...

But it seems you found the reason. We should add this to our documentation 
somewhere. Where would you have looks for this?

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Randomly delayed frame (STM32070 package including LwIP v1.4.1)

[goldsimon]

stevestrong wrote:
>Hi again,
>The whole system seems very dependent on the debug outputs.
>I placed debug prints on different places and I always get different
>results, with partially strange behavior, including sending ACK for not
>received frames.
>
>So I think this is a dead end, because no developer would probably
>assist me
>to have this issue solved.

Sorry, but I think that would need some time I currently don't have...

>That is why I decided to upgrade to v2.1.2, downloaded form here:
>http://download.savannah.nongnu.org/releases/lwip/lwip-2.1.2.zip

Very good idea!

>And here comes the very first problem: the compiler throws the error:
>
>lwip/arch.h:48:10: fatal error: arch/cc.h: No such file or directory
> #include "arch/cc.h"
>
>Do I make something wrong or is this header really missing from the
>zip?

It is of course missing. The zip contains the lwip library but not the adaption 
to your compiler, OS and network adapter.

However, you should be able to use those adaption from your old lwip version.

>I searched for any report regarding this error message in the mailing
>list
>archives, but could not find any.
>
>Did anyone tested this version at all?

Oh please, just because you don't get it you assume there is a bug in lwip and 
no one has tested it??

>Where can I find a really working no-sys webserver example using
>v2.1.2?

Use the example port for Windows or Linux in the contrib zip.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip + modbus TCP + UDP

[goldsimon]

Pablo Ledergerber wrote:
>
>hello,
>
>I'm working on a project for a new sensor with ethernet connectivity, 
>modbus TCP for data and a kind of discovery function with udp packets 
>for identificationdata. During the sensor is working well, there are 
>sometime packet retransmission and after a cupple of minutes or when I 
>send new data over UDP to the sensor the software got stuck. This is
>the 
>first time for me that I use the lwip stack in a project. I've tried to
>
>set the parameters into the lwipopts.h file without success.
>In this function get stuck:
>
>tcp_fasttmr(void)
>{
>   struct tcp_pcb *pcb;
>   ++tcp_timer_ctr;
>tcp_fasttmr_start:
>   pcb = tcp_active_pcbs;
>   while (pcb != NULL) {
>     if (pcb->last_timer != tcp_timer_ctr) {  <-- exactly here!

Looks like a threading issue to me.

>Enclosed you find a wireshark data file. My setup is the following:
>- xmc4400 from Infineon
>- KSZ8081 Phy from Microchip
>- RTOS: CMSIS
>- Freemodbus Library for Modbus TCP
>- lwip 2.2
>The freemodbus library uses the TCP Raw library and the upd discovery 
>function the netconn api. We have one thread for modbusTCP,

Having a thread for modbusTCP when that library uses the raw (callback) API 
looks like a threading violation.

Have you read the docs at http://www.nongnu.org/lwip/ (especially the chapter 
"common pitfalls")?

Regards,
Simon

> one for the
>
>sensor data (ADC) and one for the discovery function (UDP Netconn API).
>
>I tried to implement the netconn API for TCP into the freemodbus
>library 
>without success. I don't know exactly if I'm having a memory leak or 
>another problem.
>I'm a bit lost in the jungle and I would appreciate a lot if somebody 
>could me lead to the right way, so that I could solve this problem. 
>Please don't excitate to ask me. I have done a lot of things and right 
>now I don't know exactly which information is important to find a
>solution.
>Thank you in advance.
>
>Pablo Ledergerber

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Application callback for dhcp reboot with unchanged address

[goldsimon]

Niklas Gürtler" wrote:
> [..]
>When I restart my WiFi access point, the link is reconnected as
>desired, 
>and lwIP performs a DHCP reboot and receives the same address as
>before. 
>Unfortunately, in this case, the status callback is never called after
>a 
>dhcp reboot. I think this is because in netif_do_set_ipaddr, the 
>"NETIF_STATUS_CALLBACK" only happens when the address is actually
>different.
>
>So, how do I know when the link is ready for TCP connections after a 
>WiFi re-association and DHCP reboot?

I think there might be missing something here. Would you mind filing a bug 
report to our bugtracker to prevent this getting lost?

Thanks,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] DHCP requesting additional options via option 55

[goldsimon]

Am 13. November 2018 06:10:32 MEZ schrieb Craig McQueen 
:
>I wrote:
>> 
>> I have tried using LWIP_HOOK_DHCP_APPEND_OPTIONS() and
>> LWIP_HOOK_DHCP_PARSE_OPTION() to request additional DHCP options
>> from the server, using DHCP option 55
>> (DHCP_OPTION_PARAMETER_REQUEST_LIST).
>> 
>> At first I thought it was working fine. But on closer examination, it
>seems the
>> server is not sending all requested options (e.g. options 3 and 6).
>That is
>> evidently because the DHCP request contains the option 55 twice (once
>from
>> the lwIP core code, a second time from my
>> LWIP_HOOK_DHCP_APPEND_OPTIONS()). According to the DHCP RFC 2131, "
>> Options may appear only once, unless otherwise specified in the
>options
>> document." So I guess the DHCP server (Microsoft in this case) is
>ignoring the
>> first occurrence of option 55.
>> 
>> So, it would be good to improve the DHCP hook mechanism so that user
>code
>> can request additional options via option 55, without duplicating the
>option
>> contrary to the RFC. Ideally, it could be dynamic not a static array,
>so the user
>> code could decide at run-time which additional options are requested.
>> 
>> What would be a good way to improve the hook mechanism?
>> 
>> (I'm interested in contributing some code back to the lwIP project,
>as long as
>> I have a rough idea what would be accepted.)
>
>I worked out that in LWIP_HOOK_DHCP_APPEND_OPTIONS(), I can actually do
>a search through the existing options in msg->options[], looking for
>any pre-existing DHCP_OPTION_PARAMETER_REQUEST_LIST. Then I can insert
>the extra options into it. It's a bit fiddly, but I've got it working.
>Does that sound like a reasonable thing to do in
>LWIP_HOOK_DHCP_APPEND_OPTIONS()?

No. That seems too complicated. I would prefer a seaparate method.

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Passing ARP replies to host

[goldsimon]

Am 5. November 2018 19:15:51 MEZ schrieb Martin Kortmann 
:
>Hi,
>
>I have to copy and modify the code of etharp.c since several years.
>My problem with etharp.c is: My Ssstem includes one microcontroller
>(with lwip running on it) and several FPGAs. All of them are
>communicating via TCP/UDP, so i need one instance who can deliver the
>right ARP responses. And this one is the microcontroller.
>Unfortunately, the ARP implementation of lwip cannot be extended for
>this type of response. So i have to copy the code and modify it on
>every release of lwip.

It sounds like what you need would be the same extension as would be required 
for ppp proxy app support.

If you have an interest in getting this supported, why don't you post a patch? 
Lwip lives from people contributing useful things back!


Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Passing ARP replies to host

[goldsimon]

Am 5. November 2018 17:49:42 MEZ schrieb Amena El Homsi 
:
>Thanks for your reply. So if I want to support it I have to add some
>changes to etharp.c file.

Yes.

> Is there a plan to support such feature?

No, but I'm not opposed to accepting patches adding hooks for such things (see 
the other hooks in opt.h).


Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] [RST, ACK] from port zero

[goldsimon]

Am 31. Oktober 2018 16:26:27 MEZ schrieb Bob Jones <0xdeadbeef2...@gmail.com>:
>Hello,
>
>I'm using lwIP the stack with sockets in our project to create multiple
>HTTP connections to a non-lwIP server. I've noticed in Wireshark traces
>that on some occasions the server will send a [FIN, ACK], and the lwIP
>stack will respond with two [RST, ACK]s, one from port 0 and then one
>from
>the correct port it was using. Is this normal behavior or is this
>indicative of a porting issue in our implementation?

This is a bug tha will be fixed soon in a bugfix release. Its already fixed in 
git.

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Smallest possible PBUF_POOL_SIZE and MEM_SIZE (UDP only), PBUF allocation

[goldsimon]

Hamme, Janis" wrote:
> Since each packet would be processed
>immediately I can't think of any situation where I would need to store
>more than one incoming and one outgoing packet at a time. Queueing
>shouldn't occur anywhere - or am I missing something?

If your netif driver doesn't queue, tx packets can still be queued for a short 
time if the MAC address for the next hop needs to be resolved. For multicast, 
this should not be required, so your assumption might hold.


>My other question is what would be the most efficient way to allocate
>PBUFs for outgoing packets. I'm using a statically allocated buffer to
>generate outgoing packets and I could easily increase the buffer size
>to hold all other headers in contiguous memory. But I must be sure that
>the buffer can be reused once udp_sendto(...) returns. Is there any way
>to achieve that or is the overhead of using PBUF_REF with chained
>header PBUFs negligible?

That would involve some work, I think. Using a PBUF_RAM should be the most 
simple solution, I guess? In your simple setup you could also use a PBUF_POOL 
for tx pbufs to get rid of the heap...


Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] [TCP raw API] Nagle + tcp_output interaction (behavior in 24 throughput tests)

[goldsimon]

vr roriz wrote:
>That's my point, I thought it would be totally unpredective. But after
>some certain amount of data is periodically queued, the RTT starts to
>go down again and the throughput is achieved. That is what I would
>like to understand.

I think tcp_output() is called every time an rx segment is processed for a pcb, 
even if it doesn't contain data but only an ack. This is to,achieve throughput 
like you want. You just cannot rely on it regarding throughput. But this could 
well explain your measurements...

>Do you think it would be a good idea to call
>tcp_output from some custom timer? (Since the poll callback has a very
>high resolution).

No. You'll just get threading problems when starting something like that...

Call tcp_output() when you want to send data. In other words, if the 
application calling your code controls send_now, make them set it to 1 for the 
last call.

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] [TCP raw API] Nagle + tcp_output interaction (behavior in 24 throughput tests)

[goldsimon]

vr roriz wrote:
>[..]
>Then, I added the send_now control option, letting tcp_output (with
>send_now = 0) to be called by lwip itself.

Ok, so the application *never* calls tcp_output() but you leave this completely 
to the stack? That might work somehow, but will lead to totally unpredictive 
performance, as you have measured.

Also, even if you don't call tcp_output(), that doesn't always ensure two 
segments get sent together. Trying to achieve something like that is just not 
what TCP is like. TCP is a streaming protocol, which is what people tend to not 
understand. You can try to work around its streaming nature and make it 
datagram like, but once you think you got it working like you want to, don't be 
surprised if it doesn't in the next version...

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] multiple ports/interfaces

[goldsimon]

Ranran wrote:
>On Thu, Oct 4, 2018 at 9:28 PM goldsi...@gmx.de 
>wrote:
>>
>> On 04.10.2018 17:14, Ranran wrote:
>> > Does lwip support using multiple ports (physical interface) ?
>>
>> Yes. Do you want a single IP address or each netif with its own IP?
>> For a single IP address, you need something like a switch (see
>> bridgeif.c for a start).
>>
>
>I need to have each netif with its own IP.

That's no problem. You only might get routing problems when the two netifs are 
in the same subnet.

>> > Is there any example showing how we should configure more than one
>port?
>>
>> That depends on the above question.
>>
>Is there a simple example for multiple netif each with itw own IP ?

No. Just call netif_add etc. for each netif.


Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] CHANGELOG items disappeared?

[goldsimon]

Nathan Hartman wrote:
>Under git tag STABLE-2_1_0_RC1 it appears that CHANGELOG entries for
>STABLE-2.0.2 and STABLE-2.0.3 have disappeared. Is this intentional or
>an
>error?

This is intentional as those 2 stable versions are bugfix branches and this not 
direct parents of the master branch.

I have fixed this for the final release though.

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Pbuf struct size

[goldsimon]

Amena El Homsi wrote:
>The pbuf structure is 16 bytes. Is their a plan to add more elements to
>it
>in the next lwip versions or its size will not be changed?

Its size has long been 16 bytes and there are requirements to leave it like 
that. However, there are other requirements to change this, maybe depending on, 
pbuf type.

So please, don't plan your software relying on this size :-)

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] SNMP v3

[goldsimon]

Andy Pont wrote:
>Do we know when 2.1 will be out of beta and formally released?  I’m not
>
>sure I would want to build the product using a beta or current top of 
>tree!

That's only a matter of some days hopefully. I'll do that as soon as I get back 
to work.

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] tcpip_init changes for lwip 2.02

[goldsimon]

Am 2. August 2018 15:47:21 MESZ schrieb GuyH :
>Hi,
>
>I had my application running with freertos OS with lwip 1.4 and I just
>moved
>to SDK 18.1 with lwip 2.02

What is SDK 18.1? I guess you are talking about some vendor-modified version of 
our stack...

> - I've noticed that one of the changes for
>the
>2.02 version is omitting the call to lwip_init from inside tcpip_init
>(it is
>now remarked in #if 0).

Ok, this is definitively not our code you're looking at there. Can't really 
help you there I guess. You can compare the sources at hand 28th our official 
2.0.2 sources of that helps...

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Socket API send command packaging up data

[goldsimon]

This sounds even more like a driver issue.

Am 1. August 2018 10:45:26 MESZ schrieb Mike Danby :
>When the test program is run for the first 3-5 seconds the each send
>call will result is the string (approx. 15 bytes) being transmitted to
>the client in separate frames. After that (even though the calls to
>send continue at a rate of 1Hz) the strings start to get packaged up
>into single frames. The number of strings in the packaged frames grows
>on a few iterations to be around 20 -25 (frames around 300 bytes).
>
>I also see  the server respond to ARP requests, however the frame is
>1514 bytes.  The data in the ARP request is correct but Wireshark notes
>the "Ethernet Frame Check Sequence Incorrect", I assume (probably
>incorrectly) because the frame size incorrect even though data is good.
>
>-Original Message-
>From: lwip-users 
>On Behalf Of Sergio R. Caprile
>Sent: 31 July 2018 16:38
>To: lwip-users@nongnu.org
>Subject: Re: [lwip-users] Socket API send command packaging up data
>
>Completely missed the "20 second" part.
>You don't remember wrong, and you know it ;^)
>
>___
>lwip-users mailing list
>lwip-users@nongnu.org
>https://lists.nongnu.org/mailman/listinfo/lwip-users
>
>___
>lwip-users mailing list
>lwip-users@nongnu.org
>https://lists.nongnu.org/mailman/listinfo/lwip-users
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Socket API send command packaging up data

[goldsimon]

Am 31. Juli 2018 14:34:14 MESZ schrieb "Sergio R. Caprile" :
>What you see is the Naggle algorithm.

I thought so, too, but if he is seeing 20 seconds delay, it's not Nagle but 
some bug.

In fact, nagle should only hold off sending data if there is already unacked 
data under way. If unsent and unacked are empty, I'd expect to see the data 
immediately. Unless I remember wrong, of course...

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Socket API send command packaging up data

[goldsimon]

Am 31. Juli 2018 11:13:00 MESZ schrieb Mike Danby :
>Hello,
>
>Forgive my ignorance I am new to the TCP/IP stack scene. I am currently
>trying to get the LWIP stack up and running with FreeRTOS on a
>Microblaze based system. I have successfully started a TCP server and
>managed to connect a client. The test code I have hacked together
>simply writes a string containing an incremental count from the server
>to the client (15 bytes or so at 1Hz), which the client receives and
>then prints to the screen.
>
>I am aware that the when sending data to LWIP it is under no obligation
>to put the data on the wire as soon as it receives it (I think that is
>part of the TCP protocol). It can wait a period of time to see if new
>data arrives so it can send it in more efficient manner. Are these
>statements correct ?

Yes.

>Using Wireshark, I am seeing the data packaged up into various size
>frames (maximum about 300 bytes). LWIP can do this for approximately 20
>seconds, however, the client does not seem to be losing any data.

20 seconds is much too long. I'd expect to see some 100ms Delay. Could it be 
that your timers aren't running?

>What are the parameters of the stack that govern this behaviour? Can
>LWIP be configured (lwipopts.h) to minimize this effect? Would this be
>in keeping the TCP protocol design principles?
>
>I have read using the raw API tcp_output can be used to 'flush' the
>queued data. Is this recommended?

No. That doesn't necessarily work.

> I am trying to gauge whether the
>behaviour I am seeing is a problem or not. My previous experience with
>TCP (always at the application level) is that send data through the
>socket should produce frames almost immediately.

If you really want them immediately, disable nagle. But that's not standard 
either. If, by "almost immediately", you mean some 100ms maximum, lwip does 
that normally. There must be something wrong in your setup.

>I have used the stats functionality and activated some of the debug in
>the TCP layers, they do not seem to be indicating there is an issue. I
>have checked that the timer is firing periodically at the correct tick
>rate and set the threads (TCP thread and the xemacif input thread) be
>the highest priority. There is one other thread in the test that is
>lower in priority and periodically outputs to the console, again 1Hz)
>
>I am using LWIP version 1.4.1

This is really much too old. No wonder you have problems ;-)

> and FreeRTOS 9 (both of these come
>packaged with the Xilinx SDK along with the drivers for the hardware).

Check the list archive: the drivers have/had bugs.

Simon 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] netif setup for IPv6 traffic (static /128 address assignment)

[goldsimon]

I must say I've never tried. I have only tested slaac an link local addresses 
so far. At which point does it reject using your address?

Simon


Am 25. Juli 2018 21:32:03 MESZ schrieb josephjah :
>Thanks for responding. I've tried using netif_ip6_addr_set() per your
>suggestion but while it sets the address correctly for the netif, it
>doesn't
>seem to take me any closer to an operational state. I'm just not sure
>where
>to find a good example to follow. Can you clarify "mixing
>responsibilities"?
>Here's a snippet which might be closer to standard usage (but still
>exhibits
>the same problem).
>
>Am I doing something out of order? or does lwIP not support assigning a
>static ipv6 address of this form?
>
>Thanks.
>
>static err_t netif_init(struct netif *netif)
>{
>   netif->hwaddr_len = 6;
>   netif->name[0]= 'l';
>   netif->name[1]= '0'+lwipInterfacesCount;
>   netif->linkoutput = lwip_eth_tx;
>   netif->output = etharp_output;
>   netif->output_ip6 = ethip6_output;
>   netif->mtu= MY_MTU;
>   netif->flags  = NETIF_FLAG_BROADCAST 
>   | NETIF_FLAG_ETHARP 
>   | NETIF_FLAG_ETHERNET 
>   | NETIF_FLAG_IGMP 
>   | NETIF_FLAG_MLD6 
>   | NETIF_FLAG_LINK_UP 
>   | NETIF_FLAG_UP;
>   _mac.copyTo(netif->hwaddr, netif->hwaddr_len);
>   netif->hwaddr_len = sizeof(netif->hwaddr);
>   return ERR_OK;
>}
>
>void setup(...) {
>   static ip6_addr_t ipaddr;
>   memcpy(&(ipaddr.addr), ip.rawIpData(), sizeof(ipaddr.addr));
>   netif_add(, NULL, NULL, NULL, NULL, netif_init,
>ethernet_input);   
>   netif.state = this;
>   s8_t idx = 1;
>   netif_ip6_addr_set(, 1, );
>   netif_set_status_callback(, netif_status_callback);
>   netif_set_default();
>   netif_set_up();
>   netif_set_link_up();
>}
>
>
>
>--
>Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html
>
>___
>lwip-users mailing list
>lwip-users@nongnu.org
>https://lists.nongnu.org/mailman/listinfo/lwip-users
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] two logical ethernet interfaces on the same, physical port?

[goldsimon]

Unless you want to use VLANs, I guess pretty much everything has been said here 
:-)

Simon



Am 14. Juni 2018 17:04:04 MESZ schrieb Kamil Khoury :
>Thank you both for your response.
>To be specific, all received messages have the same multicast address.
>the
>only difference between the two types of messages is contained in the
>message header that should be unpacked later at the protocol engine
>(over
>layer 2) not at the port. So the port should not have authority to
>decide
>the type of the message or to handle it. The job of the port is to
>receive
>the message and forward it up.
>In my case, the logical port should not even receive the message at all
>unless it belongs to its (virtual domain). To put it in simple words,
>I'm
>looking for two separate logical Ethernet connections on the same
>physical
>port that can be identified somehow by an ID. Just like how UDP
>identifies
>sessions by port numbers.
>
>Is this even realistic? because that's the only way I could understand
>this
>paragraph:
>"the node communicates with the network via two logical interfaces
>based on
>a single physical port"
>
>
>On Thu, Jun 14, 2018 at 4:32 PM, Sergio R. Caprile 
>wrote:
>
>> Regarding your image, it didn't get through my mail, "An HTML
>attachment
>> was scrubbed..." and I'm too lazy to go dig it. Anyway... it belongs
>> here now:
>> http://lists.nongnu.org/archive/html/lwip-users/2018-06/msg00050.html
>>
>> So you still want two hosts.
>> And as far as I can see, you need a bridge among them and the
>physical
>> port. How would a bridge respond to an incoming multicast frame on
>the
>> physical port? It will forward to both netifs, and the interested one
>> will answer... Does it help ?
>>
>>
>> ___
>> lwip-users mailing list
>> lwip-users@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] DHCP discover skips hostname

[goldsimon]

Am 18. Mai 2018 17:03:21 MESZ schrieb Biafra :
>Hi everyone, 
>
>I'm new to lwip.
>I've noticed that the dhcp_option_hostname() function (to set the
>hostname for DHCP session) isn't executed on dhcp_discover() function. 
>
>Is it the correct behaviour? 

Is it incorrect behaviour?


Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Slow HTTP put request

[goldsimon]

Sergio R. Caprile wrote:
>You should capture the traffic on your customer premises to make sure
>this is what's happening. I'm curious to know.

You could also implement handling the Expect header in your http server and see 
if this speeds up the transfer.

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Netconn api & keepalive

[goldsimon]

"Александр секрет" wrote:
>Hello.
>Tell me how to manage KEEPALIVE with NETCONN API
>
>It seems to me that they forgot about it and did not make the necessary
>functions or macros in  NETCONN API.

Exactly. For keepalive, the socket api directly uses the raw tcp api instead of 
going through the netconn api. Because of that, the netconn api was forgotten 
here.

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] snd_queuelen underflow frustration

[goldsimon]

If the error persists with the current version, please open a bug at Savannah 
and upload everything required to reproduce.

Thanks,
Simon



Am 11. März 2018 03:59:09 MEZ schrieb JM :
>I'm trying to port lwIP 1.4.1 and httpserver_raw to a PIC32MZ. No RTOS.
>After a web client establishes a TCP connection, it sends a GET to
>httpserver_raw/lwIP, it returns with two large packets (1514 bytes),
>then the client sends an ACK. It's at that point an underflow occurs in
>tcp_in.c line 1026. pbuf_clen() returns with MEMP_NUM_PBUF no matter
>what it's set to.
>Here's the thing: I captured the exchange with Wireshark and converted
>the packets sent from the client to lwIP as C arrays and put it into
>Microchip MPLAB simulator, optimization is turned off. After
>initializing lwIP I simply feed each packet into ethernet_input() and
>it *still* does the same thing. I am not simulating any microcontroller
>hardware, I'm only running code. No interrupts, nothing. Should it even
>be possible to cause this by only feeding simulated packets into lwIP?
>I deleted the lwIP and httpserver_raw source from my project and
>replaced it with new stuff retrieved from the lwIP website and it still
>fails in the same way. Other than inserting a simple if() statement in
>tcp_in.c to catch when pcb->snd_queuelen hits some crazy value and
>using a slightly larger webpage for httpserver_raw, it's all stock. 
>I tried the fsdata.c I'm testing with on another lwIP 1.4.1
>implementation that's successfully running on a TI ARM and it worked
>beautifully. I'm at my wits end with this. The nice thing is the
>simulation is behaving just like what's occurring on real hardware, so
>I can step through the entire process. The issue is being able to
>follow what's going on.
>
>What can I look for? This isn't making any sense. I'd really like to
>get this working.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Trying to work out DHCP issue

[goldsimon]

Chris Seto wrote:
>I have a custom board with an STM32F4, and a TLK110 running LwIP 2.0.3.
>The
>board works great when it gets, an address, and I can freely exchange
>data
>with a socket server.
>
>On board bootup, I set the IP to 0 and then use dhcp_start() to start
>DHCP.
>When the code sees that the IP is no longer just 0, it tries to connect
>to
>the socket server.
>
>Most of the time this works well.

This looks like a threading issue. The examples from STM are horribly wrong in 
that respect. Read the docs at http://www.nongnu.org/lwip/ to learn about 
threading. Also, try upgrading to fit master and use the new 
LWIP_ASSERT_CORE_LOCKED() check (has to be implemented for your arch, look at 
our Freertos port for an example).

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] no PCB match found at simultaneously TCP connections

[goldsimon]

twagner wrote:
>I have also a webserver running.
>I can see that the used pcb mem goes back if the Client (not the MCU)
>closes
>the connection (modbus),
>but if the server (the MCU) closes the connection the used pcbs doesn't
>go
>back (webserver).
>If i have only the mobus connection in use the maximum of the pcbs is
>only 2
>(similar to the real connections).

Ok, so that's expected.

>Strange is also that the destination port of the received message seems
>to
>be wrong.
>I debugged the tcp_input function a bit and i get a wrong destination
>Port
>in the tcphdr struct:

That's strange, but I don't see what's wrong here.

Simon

>
>tcphdr error (mb):
>srcu16_t   7378
>dest   u16_t   62977   
>seqno  u32_t   752975085   
>ackno  u32_t   2805334016  
>_hdrlen_rsvd_flags u16_t   6224
>wndu16_t   28151   
>chksum u16_t   48586   
>urgp   u16_t   0   
>
>tcphdr error (mb):
>srcu16_t   8658
>dest   u16_t   62977   
>seqno  u32_t   575249432   
>ackno  u32_t   1732313088  
>_hdrlen_rsvd_flags u16_t   6224
>wndu16_t   1017
>chksum u16_t   23595   
>urgp   u16_t   0   
>
>tcphdr error (mb):
>srcu16_t   10450   
>dest   u16_t   62977   
>seqno  u32_t   601707332   
>ackno  u32_t   929038336   
>_hdrlen_rsvd_flags u16_t   6224
>wndu16_t   62709   
>chksum u16_t   10063   
>urgp   u16_t   0   
>
>tcphdr error (web):
>srcu16_t   4307
>dest   u16_t   20480   
>seqno  u32_t   1664538112  
>ackno  u32_t   2808348672  
>_hdrlen_rsvd_flags u16_t   4176
>wndu16_t   61690   
>chksum u16_t   42544   
>urgp   u16_t   0   
>
>tcphdr error (web):
>srcu16_t   31443   
>dest   u16_t   20480   
>seqno  u32_t   518157564   
>ackno  u32_t   2617311488  
>_hdrlen_rsvd_flags u16_t   4176
>wndu16_t   61690   
>chksum u16_t   60395   
>urgp   u16_t   0   
>
>tcphdr correct (mb):
>srcu16_t   53789   
>dest   u16_t   502 
>seqno  u32_t   3167854155  
>ackno  u32_t   62947   
>_hdrlen_rsvd_flags u16_t   6224
>wndu16_t   63921   
>chksum u16_t   18806   
>urgp   u16_t   0   
>
>
>
>--
>Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html
>
>___
>lwip-users mailing list
>lwip-users@nongnu.org
>https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Is it possible to pass ARP requests from the Ethernet to PPPoS?

[goldsimon]

Sturman_1 wrote:
>I use microcontroller and want to connect GSM(PPPos) modem to
>PC(Ethernet)
>via controller. I have read that LwIP can forward ipv4 packets. But in
>order
>to forward ipv4 packets first need a set connection.

That's not how ip forwarding works. Ip forwarding is one hop in a route and 
only may be done between different subnets.
ARP is only required for hosts on the LAN to know where to send the packet.

You either need 2 subnets or NAT to properly achieve what you want.

Simon


>The PC sends an
>ARP
>request and how to make it get an answer. Can I take bytes from the
>receive
>buffer and encode them into the PPP packet? and after send to the GSM
>modem
>
>
>
>--
>Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html
>
>___
>lwip-users mailing list
>lwip-users@nongnu.org
>https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] unable to find MEMP_SEPARATE_POOLS macro

[goldsimon]

Amena El Homsi wrote:
>I am using lwip 2.0.3 Release version, I din't find MEMP_SEPARATE_POOLS
>Macro. How to know if the pools are placed in one array or separate
>arrays?

They are always separate since 2.0.0, as the previously used common array for 
all pool had no real advantage.

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] UDP routing over IPv6?

[goldsimon]

Barnabás Králik wrote:
>I also don't see any reliable way to recover the destination address in
>the udp receive callback.

Have you tried ip_current_dst_addr() (or something like that)?

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Crash when doing stresstest with ppp and sockets/UDP

[goldsimon]

goldsimon wrote:
> Core locking is really for the you layer only.

That should have been API layer!

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] new at lwip, running test on windows using PPP

[goldsimon]

zulu4711 wrote:
>just an update! I think it was the PPP_INPROC_IRQ_SAFE not being set
>that
>was my problem.

Yes, it can't work without that set. I'll update the port's lwipopts. I wasn't 
aware of the changed defaults here (at some time in the past, this has worked 
when I last checked it, but that's quite long ago).

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Problem running lwip on cortex M7 with D cache enabled

[goldsimon]

Jan Menzel wrote:
> I'd suggest to align (position and size) all receive
>buffers to d-cache lines so that invalidation does not cause any side
>effects.

And it's exactly this that lwip does not fully support yet. It doesn't work for 
the tx side at all and for the rx side, we only have the workaraound with 
custom pbufs (see the link Dirk posted).

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Problem running lwip on cortex M7 with D cache enabled

[goldsimon]

Jochen Strohbeck wrote:
>I'm using lwip 1.4.1 and FreeRTOS on a SAME70 custom board with success
>if D-cache is disabled. If I enable the D-cache no more packets are
>received. If I place the RX descriptor into a non-cacheable region I
>get
>packets again

No surprises so far ;-)

> but the received data is corrupt.
> [..]
> I guess this is due to the
>D-cache requirements that the (GMAC) DMA buffer must be aligned to
>32bytes

I don't know that MAC yet, but does it really require this alignment? Whatever, 
you'll need this requirement to ensure cache flushes don't interfere with 
adjacent data. In other words, you need tx/rx pbufs where struct pbuf and it's 
payload don't share a cache line.

I have no short fix for this at hand. Sorry. You could try to create headroom 
in the pbuf to separate struct and data a bit, but this is only an idea...

We still have a task open to work on fully supporting zero copy tx/rx.

Supporting this on the stm boards would be interesting, too.

Aside from this, don't stick with Atmel's old version of lwip. You'll get many 
bugs that are already fixed, including some security related ;-)

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Problem running lwip on cortex M7 with D cache enabled

[goldsimon]

Noam Weissman wrote:
>I am working with STM32F7 with LwIP 2.02 + FreeRTOS 9
>
>D and I cache are enabled.

The drivers supplied by ST, although using DMA transfer, are still copying the 
frame payload to/from pbuf payload using memcpy. If you haven't changed this 
yourself, you have cache line alignment requirements for the driver's tx/93rd 
buffers only, but not for pbufs.

>TX/RX descriptors are hard coded inside DTCM. We have no problems for
>now.

Well, DTCM does not go via the cache, does it? So this is probably unrelated?

>I strongly suggest upgrading to LwIP 2.02 or even 2.03

I always suggest this, too. However, I'm almost sure the OP's issue is not 
solved by simply upgrading.

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] SNMP Communication

[goldsimon]

Arun Jyothi wrote:
>char  data[100]={"snmpget -d -v2 -c public 10.1.1.196
>1.3.6.1.4.1.20246.2.3.1.1.1.2.5.3.1.0"};
> [..]
>/* Sending packet by UDP protocol */
>err = udp_sendto(udpecho_raw_pcb, pkt_buf,snmp device IP Address, 161);

Do you really expect that you can send a shell command to the remote snmp 
agent? Or is this supposed to be some kind of joke?

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] No-IP Update Client implementation

[goldsimon]

Giuseppe Modugno wrote:
>Any suggestions on how to detect my public IP address?

Would ipify.org work?

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] How to use LWIP_HTTPD_FS_ASYNC_READ

[goldsimon]

You're right in that it doesn't work. The browser has no way to know the body 
size.
The downside of not sending conten length is that the server will have to close 
the connection. Reopening it might take longer than just sending zero bytes to 
create the correct content size...

Simon___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Packet queuing to an ARP table entry

[goldsimon]

Amena El Homsi wrote:
>> I tried to explain that before. Your ROM is not ROM. Data must be
>kept
>> unchanged until it is actually sent. How do you ensure this??
>>
>Our System will take care of this, Data will be kept unchanged until it
>is
>actually sent. Headers are copied from the Pbuf_RAM to the frame memory
>and
>the whole frame will stay in frame memory until it is actually sent.

Ok, so how do actually know *when* it is sent?

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] httpd: how to implement AJAX

[goldsimon]

Giuseppe Modugno wrote:
> It's a pity lwip doesn't feature those 
>secure network layers.

Actually, it's not that far away. Have a look at the for master. It's not in 
the releases, yet.

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] httpd: how to implement AJAX

[goldsimon]

Noam Weissman wrote:
>Create an empty file named ajax.shtml or ajax.html and add it to your
>file list.
>
>Inside the file you only write one tag without anything else. For
>example 

That's a nice idea. I also have task #14269 open to make ssi processing 
independent of the file's extension (a makefsdata change).

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] SNMP communications

[goldsimon]

Arun Jyothi wrote:
>Can I get an example or steps to do SNMP Communication.

Have a look at the win32 or Unix ports in contrib, they would both include snmp 
support.

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] httpd and authentication

[goldsimon]

Giuseppe Modugno wrote:
>I'd like to protect some or all web pages and show them only to
>authorized
>people. I understood there are two methods: basic and digest.

I guess both are outdated. Modern web pages use a custom input field which is 
sent to the server via POST. You'll need TLS obviously if you want the data to 
be protected. The server then opens a session by sending the client a session 
cookie which is then included in all further requests from the client.

Sadly, this is not implemented in lwip httpsd yet. The server code supports 
POST but not sending/parsing cookies (although that part should be easy to 
add). An overall example and session handling is missing though.

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] "HIDE the declaration of PBUF STRUCT in pbuf.h"

[goldsimon]

antonio wrote:
>I *moved* the declaration of *struct pbuf from pbuf.h to pbuf.c*.

That won't work as in many places the struct needs to be known. Including 
sizeof() and other direct instantiations (not via pbuf_alloc). We started a 
scheme for private header files to solve this.

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] HTTPD is working on LWIP2.0.3

[goldsimon]

kevin wrote:
>sys_thread_new("httpd", httpd_init, NULL,

httpd is a callback API application. Please make sure you understand lwips 
thrading requirements.

In other words: RTFM ;-)

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] ERR_MEM when sending large data, LWIP stats show no error

[goldsimon]

Adrian Figueroa wrote::
>I have no idea why I have no packet loss with TCP_WND and TCP_SND_BUF
>set to 2xTCP_MSS. Instead, I get rare ZeroWindow errors from my PC.

Because you don't fill your DMA buffers in this case and as a result, you don't 
drop tx segments.

Implementing a zero copy driver in lwip is, unfortunately, still not that easy.

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] ERR_MEM when sending large data, LWIP stats show no error

[goldsimon]

Adrian Figueroa wrote:
>This fails:
>
>  if((DmaTxDesc->Status & ETH_DMATXDESC_OWN) != (uint32_t)RESET)
>  {
>errval = ERR_USE;
>goto error;
>  }
>
>When DmaTxDesc->Status  equals 818937856. What does this mean? Is the
>DMA used by something else?

I could mean your DMA buffer ring is full. You can do two things from here: 
either busy-poll until a buffer is available again or continue sending when the 
TX interrupt fires.

Simon 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LWIP_MPU_COMPATIBLE set to 1, but still get memory management fault in lwip_select.

[goldsimon]

Looks correct. I guess mpu mode is not used too often. My suggestion would 
probably be to get select_cb from a Memo pool...

Simon


Am 6. September 2017 16:12:47 MESZ schrieb David Lockyer 
:
>Hi,
>
>I have a project that uses an STM32F MCU running FreeRTOS (cortex mpu 
>port) & lwip, with the MPU enabled.
>
>I'm upgrading to lwip 2.0.2 from lwip 1.4.1, that I had to customize to
>
>be compatible with the MPU, in particular in lwip_select().
>
>The motivation was to use the LWIP_MPU_COMPATIBLE define, so a direct 
>modification of the stack source was not required.  However for me it 
>still appears to try to access another threads memory, triggering an 
>exception.
>
>The changes I had to make were:
>
>Index: lib/lwip-2.0.2/src/api/sockets.c
>===
>--- lib/lwip-2.0.2/src/api/sockets.c(revision x)
>+++ lib/lwip-2.0.2/src/api/sockets.c(working copy)
>@@ -1428,7 +1428,9 @@
>  /* Put this select_cb on top of list */
>  select_cb.next = select_cb_list;
>  if (select_cb_list != NULL) {
>+  RAISE_PRIVILEGE();
>select_cb_list->prev = _cb;
>+  RESET_PRIVILEGE();
>  }
>  select_cb_list = _cb;
> /* Increasing this counter tells event_callback that the list has 
>changed. */
>@@ -1508,7 +1510,9 @@
>  /* Take us off the list */
>  SYS_ARCH_PROTECT(lev);
>  if (select_cb.next != NULL) {
>+  RAISE_PRIVILEGE();
>select_cb.next->prev = select_cb.prev;
>+  RESET_PRIVILEGE();
>  }
>  if (select_cb_list == _cb) {
>LWIP_ASSERT("select_cb.prev == NULL", select_cb.prev == NULL);
>@@ -1515,7 +1519,9 @@
>select_cb_list = select_cb.next;
>  } else {
>LWIP_ASSERT("select_cb.prev != NULL", select_cb.prev != NULL);
>+  RAISE_PRIVILEGE();
>select_cb.prev->next = select_cb.next;
>+  RESET_PRIVILEGE();
>  }
> /* Increasing this counter tells event_callback that the list has 
>changed. */
>  select_cb_ctr++;
>
>Is there something else I missed here that would remove the need for 
>this modification?
>
>
>Kind regards,
>
>David Lockyer
>
>
>
>__
>This email has been scanned by the Symantec Email Security.cloud
>service.
>For more information please visit http://www.symanteccloud.com
>__

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] time out on last ack

[goldsimon]

Mike Rosing wrote:
> After searching a while I see that the LwIP is waiting for LAST_ACK, but the 
> server never sends it.

I would have expected lwip to time out this PCB eventually (although that can 
need quite some time). How long did you wait?

Simon___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwIP 1.4.1 stable tcp connection stall

[goldsimon]

Hey Bill,

Great to hear 2.0.2 fixes this. I'm a bit lost thinking about a bug fix. We had 
some since then I guess, and I would have to dig through the log myself.
However, the most obvious would be a zero window where the persist timer 
doesn't start or somehow doesn't work correctly.

Are you able to reproduce this now? Can you debug it? Would you need help in 
debugging?

I'm not at my PC very often right now, but I'll see if I find something. Maybe 
you can dump the PCB in question once it stops plus lwip_stats, that could help 
finding the issue.

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LwIP 1.41 select does not return ?

[goldsimon]

Noam Weissman:
>Were is the semaphore released ?

In "event_callback()", if I remember correctly.

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LwIP 1.41 select does not return ?

[goldsimon]

Noam Weissman wrote:
>My question was simple ... does anyone have an idea why select
>
>does not return when a connection to the correct port is initiated.

Can't help you much there other than saying: try to check the socket's status: 
is there an acceptable connection pending in the queue? Has the event callback 
been called to release the semaphore?

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Listen/Accept lwip 2.0.0

[goldsimon]

You might achieve the required connection limitation by having only 4 TCP PCBs 
in the memo pool...

Simon


Am 4. Mai 2017 17:56:09 MESZ schrieb Joel Cunningham :
>
>Do you have TCP_LISTEN_BACKLOG enabled in your port?
>
>Also keep in mind, the backlog only limits connections that have not
>been accepted.  Once accepted by your application, the connections are
>not part of the backlog.  If your goal is to support 4 simultaneous
>connections at once (with no pending connections), you need to close
>the listener once the server has 4 connections.
>
>Joel
>
>> On May 4, 2017, at 9:44 AM, Marcelo V  wrote:
>> 
>> Hello,
>> 
>> I am implementing a small web-server using lwip 2.0.0 and it seems
>that the TCP stack is accepting more connections than set by my listen
>call.
>> In my use-case I have an webpage with HTML requesting many external
>resources to be loaded. However, I want to only serve max of 4 requests
>simultaneously (4 sessions) and “keep-alive” is disable (replies 200 OK
>with "connection: close”).
>> 
>> However, as soon as my code replies the very first accepted
>connection then I see my web browser issuing 8~10 GET’s even before I
>call accept again. Wireshark shows those 8~10 connections each with
>their port number and the entire GET had flown to the server.
>> 
>> It seems that the number of connections provided by the listen were
>ignored and TCP is accepting and buffering all requests.
>> 
>> I browsed the bug track and I did not find anything being reported.
>> 
>> How can I prevent this?
>> 
>> Thanks in advance,
>> Marcelo
>> 
>> 
>> 
>> 
>> 
>> ___
>> lwip-users mailing list
>> lwip-users@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
>___
>lwip-users mailing list
>lwip-users@nongnu.org
>https://lists.nongnu.org/mailman/listinfo/lwip-users
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] DSCP diffserve marking

[goldsimon]

dworkdev wrote:
>A short interrogation : Does LWIP supports DSCP marking ?

Yes.

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Transfer Mibs of data over TCP

[goldsimon]

Am 3. April 2017 23:30:52 MESZ schrieb Sylvain Rochet:
>WTF. Did you even read what the netbuf_next() function actually does ?


I can only agree to Sylvain. Noam, I am thankful to everyone contributing here, 
but this example is just so wrong! Please stop confusing people.

Sion

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users