Re: [lwip-users] Which mbedTLS branch LWIP is supporting—only LTS or development too?

[Simon Goldschmidt via lwip-users]

Am 9. April 2024 08:16:46 MESZ schrieb Simon Goldschmidt via lwip-users 
:
>
>
>Am 8. April 2024 18:46:50 MESZ schrieb Javier Tia :
>>Hi,
>>
>>I was trying to build LWIP with mbedTLS (development branch), but got some 
>>build errors; not with the mbedTLS LTS branch. I like to confirm if LWIP is 
>>only supporting the mbedTLS TLS version and not the development branch.
>>
>
>As stated in the code, currently only LTS is supported. However, we'd happily 
>accept PayPal ches to build against newer versions!

As Dirk wrote, we accept patches, not PayPal. Sometimes I hate autocorrection!

Regards,
Simon

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

Re: [lwip-users] Which mbedTLS branch LWIP is supporting—only LTS or development too?

[Simon Goldschmidt via lwip-users]

Am 8. April 2024 18:46:50 MESZ schrieb Javier Tia :
>Hi,
>
>I was trying to build LWIP with mbedTLS (development branch), but got some 
>build errors; not with the mbedTLS LTS branch. I like to confirm if LWIP is 
>only supporting the mbedTLS TLS version and not the development branch.
>

As stated in the code, currently only LTS is supported. However, we'd happily 
accept PayPal ches to build against newer versions!

Regards,
Simon

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

Re: [lwip-users] TCPIP thread stack size

[Simon Goldschmidt via lwip-users]

On 28.03.2024 02:55, James Aguilar wrote:

Friends,

I have been playing with lwip, trying to get some various things working
on my Raspberry Pi Pico W. First off, thanks very much for putting this
library together.

One of the interesting things I noticed when I was getting my project to
announce itself on mdns was that the stack usage of the TCPIP thread
seems pretty high! According to FreeRTOS, the stack high water mark of
the TCP/IP thread is around 3500 words -- 14kB. I have questions:

- Is this a typical amount of TCP/IP thread stack usage? Do I have to
worry about it going much higher? This is in debug compilation mode.


I guess this is typical for mdns. However, this is at least partly a
known issue in the mdns code, which allocates too much on the stack
(where it should rather do static-, pool- or heap-allocations).


- Are there good defaults for this (and other) settings within the
lwipopts.h file?


No, such defaults greatly depend on your platform and your usage of the
stack, it doesn't make much sense for us to provide generic default options.


- Is there a good list anywhere of other "dangerous" (i.e. silently
corrupt your memory if set wrong) options?


Non that I know of, but there should be no silent memory corruption
other than stack overflow - and I strongly suggest to implement a
runtime check against stack overflow: things can always go wrong!



Any other tips for a newb? One thing I also can't seem to find much good
information on is the pros and cons of using the raw APIs, netconn, or
socket. I noticed that the apps seem to use netconn so that's what I'm
starting with.


No, most apps should be using the raw API. Apps using netconn are not
seen too often. The raw API is the smallest and has best performance, at
the cost of requiring the user to think of programs much like a state
machine (in contrast to multithreading used for netconn or sockets).

Regards,
Simon

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

Re: [lwip-users] Assistance Required: Errors in lwiplib.c and Related Files After Upgrading LWIP from 1.4.1 to 2.2.0

[Simon Goldschmidt via lwip-users]

On 10.01.2024 03:46, Timothy Martin via lwip-users wrote:

I'm including a zip file containing all the updated headers and source
files of LWIP for your reference.
[..]

Here are the details of the issues I'm facing:

 *

*Error #137 in |lwiplib.c| (Path: /NetworkModule/utils)*:

  o Struct "ip_addr" has no field "addr" at lines 739, 740, 741,
745, 746, 747, 1174, 1198, 1245, 1246, and 1247.


There's no file 'lwiplib.c' in you ZIP, but I guess you are invalidly
accessing the member 'addr' of the type 'ip_addr'. Don't do that. Use
the accessor functions (you find them in ip.h, I think) to ensure
portability accross versions.


 *

*Error #137 in |.ccsproject| (External Location:
C:\ti5\third_party\lwip-1.4.1\src\core)*:

  o Struct "udp_pcb" has no field "lwip_recv" at line 404 (File:
udp.c).


This and the other errors seem to come from the fact that 'recv' gets
defined to 'lwip_recv' (and probably same issue for 'poll' below). This
is done in sockets.h, but as a macro taking parameters, and sockets.h
should not even be included while compiling udp.c and others, so I can't
really help you here.

Regards,
Simon


  o Struct "tcp_pcb" has no field "lwip_recv" at lines 501, 541,
1568, and 1581 (File: tcp.c).
  o Struct "tcp_pcb_listen" has no field "lwip_accept" at lines
956 and 667 (File: tcp_in.c).
 *

*Error #56-D and #29 in |.ccsproject| (External Location:
C:\ti5\third_party\lwip-1.4.1\src\core)*:

  o Too many arguments in invocation of macro "recv" at line 404
(File: udp.c).
  o Expected an expression at line 1428 (File: tcp.c).
  o Too few arguments in invocation of macro "poll" at line 1428
(File: tcp.c).

I have attempted to troubleshoot these issues by reviewing the
documentation and searching for similar problems faced by others,
but I haven't found a clear solution yet.

Any help or pointers on how to address these errors would be
immensely helpful. I am especially interested in understanding if
these are known issues when upgrading from LWIP 1.4.1 to 2.2.0, and
if there are any specific changes or considerations I should be
aware of.

Thank you in advance for your time and assistance. Your expertise
and advice are invaluable to me and others facing similar challenges.

Best,
Timothy



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

Re: [lwip-users] Problem with http connections

[Simon Goldschmidt]

I'm not 100% sure what you think has changed, but the "reuseaddr" part
should not have changed that much between 2.0.0 and 2.1.2 to result in
this change.

Regards,
Simon

On 09.08.2023 21:35, dwsex...@dwstech-llc.com wrote:

Found solution: Apparently in LWIP 2.0.0 you could bind a socket right
after closing it, so for a server if you created a socket, did  bind,
listen accept then send and then close you could not immediately repeat
the process without an address in use error even if the socket options
were set to reuse address. I fixed this in 2.1.2 by keeping the bound
listening socket and continued to use it to accept new connections on
the same port (port 80). My little Web server now work again with 2.1.2.
It took a little bit to find this as I w2as not expecting this change in
behavior but once I noticed that the bind was failing with an address
reuse error and a little digging I figured out how to correct it.

*From:*lwip-users-bounces+dwsexton=dwstech-llc@nongnu.org
 *On Behalf Of
*dwsex...@dwstech-llc.com
*Sent:* Thursday, August 3, 2023 8:30 AM
*To:* 'Mailing list for lwIP users' 
*Subject:* Re: [lwip-users] Problem with http connections

Correction, the upgrade was to 2.1.2 not 2.0.2.

Dan Sexton

*From:*lwip-users-bounces+dwsexton=dwstech-llc@nongnu.org

mailto:lwip-users-bounces+dwsexton=dwstech-llc@nongnu.org>> *On
Behalf Of *dwsex...@dwstech-llc.com 
*Sent:* Thursday, August 3, 2023 8:06 AM
*To:* lwip-users@nongnu.org 
*Subject:* [lwip-users] Problem with http connections

I have a product based on the STM32F407 that has been working since
2017. It has both a home brew web server and a telnet server both using
LWIP to listen for clients.

The product uses LWIP 2.0.0 and I recently tried to upgrade to LWIP
2.0.2 but some issues have popped up. During the upgrade I did not
change any of my application code.

The Telnet server still works just fine, accepts connections and
communicates as expected.

However, the Web Server listening on port 80 no longer works,
connections seem to be rejected. Both Telnet and the web server share
the same code for setting up the server (different ports of course),
listening for and accepting connections. Is there something in 2.0.2 the
intercepts port 80 traffic or http requests, possibly a new option that
needs to be turned off? I searched the reflector and did not see
anything, a google search didn’t turn up anything as well.  I can share
a wireshark trace but I suspect the answer is simpler than setting that
up. I also have a Modbus TCP server running but have not even tried that
yet as I can’t get passed testing the web server.

Thanks

Dan Sexton


___
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] Linker error "multiple definitions of symbol"

[Simon Goldschmidt]

Have a look at the linker files for the example projects. fsdata.c is included 
by fs.c and not meant to be compiled and linked on its own.

Regards,
Simon


Am 7. August 2023 11:24:27 MESZ schrieb Zeeshan Rehman | TESVOLT AG 
:
>
>Hello there,
>I am trying to port lwip to Aurix Tricore TC387 kit. I'm having a lot of 
>difficulty.
>I implemented 
>this
> example and it works fine. But I want to integrate 
>http app. But I 
>get so many error and I kept resolving them but got stuck at 
>this.
>
>ltc E108: multiple definitions of symbol "file__img_sics_gif" in both 
>"fsdata.o" and "fs.o"
>ltc E108: multiple definitions of symbol "file__404_html" in both "fsdata.o" 
>and "fs.o"
>ltc E108: multiple definitions of symbol "file__index_html" in both "fsdata.o" 
>and "fs.o"
>make: *** [makefile:95: Ethernet_1_KIT_TC397_TFT.elf] Error 1
>
>
>Mit freundlichen Grüßen | With best regards
>Zeeshan Rehman
>Position Embedded Systems Ingenieur
>
>Tel:   +49 3491 8797 245
>E-Mail: zeeshan.reh...@tesvolt.com
> [TV_ees_Messe_2023_Signatur_Banner_DE.jpg] 
> 
>TESVOLT AG| Am Heideberg 31 | 06886 Lutherstadt Wittenberg | Germany
>Telefon +49 3491 8797 100 | Fax +49 3491 8797 102 | i...@tesvolt.com | 
>www.tesvolt.com
>Supported by:
>[Picture1.jpg]
>TESVOLT AG | Sitz der AG: Lutherstadt Wittenberg | Registergericht: Stendal 
>HRB 31785
>Vorstand: Daniel Hannemann (Vorsitzender), Simon Schandert, Philipp Koecke
>Aufsichtsratsvorsitzender: Oliver Borrmann | USt-IdNr. DE296431494
>Please think about your environmental commitment before printing this letter!
>
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Ping problem - lwip_sendto: invalid address

[Simon Goldschmidt]

Hi,

IS_SOCK_ADDR_TYPE_VALID = NO

That can't work. The type should be AF_INET. However, that seems to be hidden 
in how you call the espressif code, where I can't help.

Regards,
Simon


Am 4. Juli 2023 01:06:46 MESZ schrieb rangel moreira fischer via lwip-users 
:
>Hello,
>Can someone help me with this question ?
>
>Ping timeout (IDFGH-10552) · Issue #11792 · espressif/esp-idf  
>|  
>|   
>|   
>|   ||
>
>   |
>
>  |
>|  
>|   |  
>Ping timeout (IDFGH-10552) · Issue #11792 · espressif/esp-idf
> 
>Answers checklist. I have read the documentation ESP-IDF Programming Guide and 
>the issue is not addressed there. I have updated my IDF branch (master or 
>release) to the latest version and checked t...
>  |   |
>
>  |
>
>  |
>
>  
>
>Thank's.
>
>Enviado do Yahoo Mail no Android___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Frequent window closing (zero window) when receiving MP3 stream

[Simon Goldschmidt]

Hi Norbert,

in my opinion, this is ok: what you see here is that data is coming in faster 
than your application can process it. That's, ok. It would be bad the other way 
round as you would then probably get breaks in your mp3 stream.

The window being advertised as non-zero and then as zero again simply means the 
sender is fast in filling it again, which is a good thing.

Regards,
Simon


Am 3. Juli 2023 12:21:58 MESZ schrieb Norbert Morawski 
:
>Hello,
>
>I'm not sure if this is a problem, but my MP3 radio streamer (lwip @ RP2040) 
>frequently closes the window. This is caused by a initial inrush of data from 
>the server, which pushes the window from 12kB to almost 0. Then it only 
>oscillates between 0 and 4kB with a period of about 2 seconds.
>
>Isn't there a way to prevent the initial depletion of window size? I'd be much 
>comfortable if it'd oscillate around half of the window size. Changing window 
>size didn't help. Current config is:
>TCP_MSS 1460
>TCP_WND        (8 * TCP_MSS) = 11680 bytes
>
>The app ACKs data as it decodes the MP3 frames, which would be 2 fast calls to 
>tcp_recved of around 400 bytes each 50 ms. Here are some images regarding the 
>problem. A chart of advertised window size from lwip client to the server and 
>a wireshark dump where initial 8 packets of size 87% of the window are 
>received in about 0.2ms (https://imgur.com/gallery/TVVcTp2)
>
>Or I have nothing to worry about and this is a normal TCP behavior?
>
>Regards,
>Norbert.
>
>
>___
>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] lwIP 2.2.0-rc1

[Simon Goldschmidt]

The 1st release candidate version for lwIP 2.2.0 is now available via
git (using the STABLE-2_2_0_RC1 tag) or via this gitweb link:

http://git.savannah.nongnu.org/cgit/lwip.git/snapshot/lwip-STABLE-2_2_0_RC1.tar.gz

This release brings us back to releasing off the master branch (instead
of using a separate stable-branch, which hasn't worked out quite as I
liked and should end the phase of not releasing often enough). Being
like that, there are many minor bugs fixed but mainly, this is a cleanup
release allowing us to prepare for faster releases in the future.

In addition, we dropped the 'contrib' repository and moved everything
that was there into the 'contrib' directory in the main repository, so
one single repository now contains all the code, which should be easier
for both the developers and the users.

Please test and report bugs if you find any!
Many thanks to all contributors!!

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

Re: [lwip-users] Any known bugs in LWIP's internal heap?

[Simon Goldschmidt]

 Peter   wrote:
>Does anyone know if LWIP's internal heap management has this issue
>
>https://www.eevblog.com/forum/programming/help-needed-with-some-heap-test-code/

Ehrm, that's newlib. Why should we have the same bug? Did you meet any problems 
with the lwip heap? There are no known bugs there that I know of.

Regards,
Simon

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

Re: [lwip-users] Errors during build of lwip in Windows

[Simon Goldschmidt]

Am 17. April 2023 08:38:56 MESZ schrieb Giuseppe Modugno 
:
>Il 15/04/2023 01:58, Giuseppe Modugno ha scritto:
>[...]
>> Now I enabled LWIP_MQTT_APP and I receive the following errors during build:
>>
>> [ 99%] Linking C executable example_app.exe
>> liblwipcontribexamples.a(mqtt_example.obj): In function `mqtt_connection_cb':
>> C:/temp/lwip/contrib/examples/mqtt/mqtt_example.c:100: undefined reference 
>> to `mqtt_sub_unsub'
>> C:/temp/lwip/contrib/examples/mqtt/mqtt_example.c:104: undefined reference 
>> to `mqtt_sub_unsub'
>> liblwipcontribexamples.a(mqtt_example.obj): In function `mqtt_example_init':
>> C:/temp/lwip/contrib/examples/mqtt/mqtt_example.c:116: undefined reference 
>> to `mqtt_client_new'
>> C:/temp/lwip/contrib/examples/mqtt/mqtt_example.c:118: undefined reference 
>> to `mqtt_set_inpub_callback'
>> C:/temp/lwip/contrib/examples/mqtt/mqtt_example.c:123: undefined reference 
>> to `mqtt_client_connect'
>> collect2.exe: error: ld returned 1 exit status
>> mingw32-make.exe[2]: *** [CMakeFiles\example_app.dir\build.make:128: 
>> example_app.exe] Error 1
>> mingw32-make.exe[1]: *** [CMakeFiles\Makefile2:358: 
>> CMakeFiles/example_app.dir/all] Error 2
>> mingw32-make.exe: *** [Makefile:135: all] Error 2
>>
>> I couldn't understand why, because mqtt.c is really compiled and linked in 
>> liblwipallapps.a.
>
>I think I understood. In CMakeLists.txt there's the following line:
>
>target_link_libraries(example_app ${LWIP_SANITIZER_LIBS} lwipallapps 
>lwipcontribexamples lwipcontribapps lwipcontribaddons lwipcontribportwindows 
>lwipcore lwipmbedtls)
>
>I don't know exactly why, but the problem disappeared in my build system after 
>postponing lwipallapps, such as:
>
>target_link_libraries(example_app ${LWIP_SANITIZER_LIBS} lwipcontribexamples 
>lwipallapps lwipcontribapps lwipcontribaddons lwipcontribportwindows lwipcore 
>lwipmbedtls)
>

That's a known problem of the gnu linker: order of libraries is important!

>
>> Lastly another strange behaviour. If I enable LWIP_HTTPD_APP, the build 
>> process is ok, but I can't see the web page on the browser when I type the 
>> URL http://192.168.1.200.
>[...]
>
>I suspect there's a problem with WinPcap libraries. If I try to connect to the 
>http server from another machine, it works. Even ping to lwip doesn't work 
>from the Windows host machine.
>
>Do you know how this can be solved?

When talking loopback to the application, checksums are not generated as the 
windows driver or hardware generates them. Either you turn off that option in 
the windows driver or you disable checksum checks in lwip.

Regards,
Simon

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

Re: [lwip-users] icmp checksum error

[Simon Goldschmidt]

On 12.04.2023 07:27, Mohammed Shahid wrote:

hiii,
 I am working on ti mcu tm4c1294ncpdt , i have integrated lwip stack
2.1.3  icmp ping for ping query is responding but is responding with
the checksum as 0x, but in icmp.c file checksum is calculated and
it is correct.



Checksum being 0 is a hint that checksum offloading is enabled but the
hardware doesn't fill it in.


Regards,

Simon


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

Re: [lwip-users] mbedtls

[Simon Goldschmidt]

On 13.04.2023 13:23, Giuseppe Modugno wrote:

What is the latest mbedtls version that is compatible with lwip,
specifically the layer altcp_tls_mbedtls.c?



Sorry, the current source did not track the version which it is
compatible with. But I'd gladly accept patches covering that or
improving compatibility with newer mbedtls versions.


Regards,

Simon



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

Re: [lwip-users] mbedtls integration

[Simon Goldschmidt]

On 14.04.2023 10:08, Giuseppe Modugno wrote:

In the past I enabled ALTCP layer to add TLS and I used
altcp_tls_mbedtls examples present in lwip repo.
I thought it was the way to add TLS to lwip.



Let's say it is "our" way to do that.



Recently I looked at some example projects of NXP, such as this[1].
This is an example of a TLS httpd server. TLS is added by mbedtls, but
ALTCP lwip support is NOT enabled (and altcp_tls_mbedtls is NOT
enabled too).

It seems NXP uses a different (patched?) httpd implementation with
integrated mbedtls support. I couldn't understand if this is a smarter
way to add TLS support to lwip (that avoid ALTCP at all) or an old way
that should be avoided nowadays that is available ALTCP and
altcp_tls_mbedtls.



Hard to tell without being NXP, but I'd say they either just don't know
ALTCP or they refuse to use it because of other reasons. In the end,
both implementations work, but ALTCP saves you from doing the work
yourself or over and over again for every TCP server/client.


Regards,

Simon


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

Re: [lwip-users] LWIP and its keep-alive feature - does it work?

[Simon Goldschmidt]

Peter  wrote:
>
>[..] if say the server is rebooted during a connection, the
>connection is not re-established. Maybe that is how it is supposed to
>work

Yes, that's why it is called "keepalive", not "re-establish broken 
connections". By the way, it's not an lwip thing but an implementation of 
generic TCP concepts.

> i.e. if one wanted to re-establish a connection in such a
>situation, the client should be sending out regular "real" packets,
>not KA packets.

Exactly. If the server is restarted, there's no way a keepalive packet would do 
anything good. You need to send SYN packets to establish a new connection.

Regards,
Simon

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

Re: [lwip-users] ARP forwarding

[Simon Goldschmidt]

Am 13. Dezember 2022 20:19:00 MEZ schrieb "Александр via lwip-users" 
:
>
>Thank you all very much. I’v got some experience of routing frames on FPGA, 
>but didn’t use lwip for this purposes. Yes you are right — I need bridge. 
>Forwarding data is not the main function of this device but sometimes I need 
>to connect to the computer on the other side of my device. So I need to 
>forward broadcast arps by programming logic(for example), as far as I 
>understand. And there is no option to use lwip in bridge mode. Am I right?

There is a bridge netif which you could use for a start...

Regards,
Simon

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

Re: [lwip-users] ARP forwarding

[Simon Goldschmidt]

Am 13. Dezember 2022 17:50:34 MEZ schrieb "Александр via lwip-users" 
:
>
>Hello!
>I am trying to implement dual ethernet interface device on Xilinx baremetal 
>logic. I’v already implement receiving data from both of two interfaces but 
>now I want to realize forwarding from one interface to another. I’v connected 
>to 1st interface and try to ping the second one. On wireshark I see arp 
>requests that have no responses.
>May be problem is in forwarding of broadcast messages?
> 
>#if IP_FORWARD
>    /* non-broadcast packet? */
>    if (!ip4_addr_isbroadcast(ip4_current_dest_addr(), inp)) {
>      /* try to forward IP packet on (other) interfaces */
>      ip4_forward(p, (struct ip_hdr *)p->payload, inp);
>    } else
>#endif /* IP_FORWARD */

This is IP code. It would never touch or even see ARP packets at all.

> 
>I can not understand this part. Why do we forward only unicast messages?
>Sorry, i am niewbe in this stuff

Forwarding is between two IP subnets with known routes between that subnets. 
Think of lwip like a router here. And broadcasts should never be routed.

What you want sounds like a bridge maybe? A bridge forwards L2 traffic and 
would this also send on your ARP broadcast.

Regards,
Simon

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

Re: [lwip-users] Test offloading checksum for receive path

[Simon Goldschmidt]

On 13.10.2022 12:59, Giuseppe Modugno wrote:

LPC546xx MCUs have the capability to offload checksum for IP, TCP, UDP
and ICMP, for outgoing and ingoing packets.

I enabled the generation of checksum for IPv4 for outgoing packets and
it seems working well. Now I want to enable and test checksum offload
for incoming IPv4 datagrams, but I'm in trouble how to test.

I should have the possibility to generate and send an IP datagram with
a wrong checksum from a host on the same LAN of lwip device.

Do you know of any tool that can do this kind of thing on Windows?



There are multiple ways to go, but the simplest probably is to capture
with Wireshark, save a pcap with only one packet, open that packet in a
Hex Editor (like HxD) and change its checksum (verify again with
Wireshark). Then, find a tool to send that packet back to the net. A
quick online search yields "Packet Sender" or "PReplay" for that task.


Regards,

Simon


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

Re: [lwip-users] LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT

[Simon Goldschmidt]

Am 10. Oktober 2022 18:32:15 MESZ schrieb Giuseppe Modugno 
:
>I'm sorry to post again.
>
>I just understood LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEX is used in mem.c for 
>MEM_USE_POOLS=0 and MEM_LIBC_MALLOC=0 (default lwip heap management from a 
>statically allocated buffer).
>
>What about the reentrancy of memory pools? What happens when MEM_USE_POOLS=1 
>and pbuf_free is called in ISR, with or without 
>LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT? It seems memory pools free is safe to 
>be used from ISR, because I don't see any protection for them (differently of 
>lwip default dynamic allocator).

Yes, it is.

Regards,
Simon

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

Re: [lwip-users] why is my stack usage so high for the tx thread hosted by lwip?

[Simon Goldschmidt]

>Op zo 18 sep. 2022 om 21:11 schreef Peter :
>
>> I will be amazed if you find anybody who knows what most of the
>> options in the lwipopts.h file do *and* is willing to post it. LWIP is
>> a typical open source piece of code, unsupported and those who
>> developed it have moved on to more interesting things many years ago.
>> So the web is full of desperate people posting everywhere asking
>> questions like this.
>>
>> I have spent a chunk of my life this year messing about with this
>> stuff. LWIP does actually work very well, which is just as well
>> considering the above!

Have you bothered trying to improve the documentation with what you found out?

There were numerous people asking such questions in the past years. 
Unfortunately, none of them seems to have bothered partaking in the effort to 
improve anything here.

Regards,
Simon

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

Re: [lwip-users] LwIP v2.1.2 in UDP client mode gets stuck in etharp_query() after running for a long time without connection?

[Simon Goldschmidt]

Am 21. September 2022 06:08:28 MESZ schrieb Lan Yang :
>Hi LwIP users,
>
>I've been having some problems lately with lwIP v2.1.2's udp_send function.
>*The problem is: *
>*LwIP as UDP client gets stuck in etharp_query() after running for a long
>time without connection. *

Looks like yet another threading issue. Or in other words, it seems like you 
are using lwip in a wrong way, resulting in Rx processing, tx processing and 
possibly timer processing being active in the code at the same time.

Regards,
Simon

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

Re: [lwip-users] http post using lwip?

[Simon Goldschmidt]

Am 1. Juli 2022 17:48:50 MESZ schrieb Bas Prins :
>Dear lwip,
>I'd really appreciate some feedback on this. Would it make sense to extend
>the http_client.c in such a way so that I can choose whether to create
>HTTP_GET or HTTP_POST requests?

Yes.

>
>err_t httpc_get_file_dns(const char* server_name, u16_t port, const char*
>uri, const httpc_connection_t *settings,
>altcp_recv_fn recv_fn, void* callback_arg, httpc_state_t **connection);
>
>For example add parameters to that signature to specify the request type?
>GET/POST + optional post data ?

No, that function is called GET. Add a function called POST and add the new 
code there.

> [..] Would it be valuable for the community?

Yes.

Regards,
Simon

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

Re: [lwip-users] Why is the whole ping.c surrounded by "#if LWIP_RAW" ?

[Simon Goldschmidt]

Am 9. Juni 2022 11:07:15 MESZ schrieb Jonathan D :
>Hello,
>
>I have a project with LwIP working for several services (both client and 
>server) and so far, I didn't need to enable LWIP_RAW.
>Now, I want to ping the gateway from my device and I included the "ping" app 
>from the contrib repository.
>
>I find it strange that the whole ping.c is surrounded by "#if LWIP_RAW" as 
>even the comment says:
>
>This is an example of a "ping" sender (with raw API and socket API).

There's a difference between "raw API" (vs socket API, here, "raw" means the 
callback API) and LWIP_RAW (where raw means "raw IP socket": as there is no 
ICMP socket type, you need to implement ICMP yourself on top of IP, which is 
what that file does.

> [..]
>Should I enable LWIP_RAW in order to use functions in ping.c ?

Yes

> Will this not create problems ?

No.

Regards,
Simon

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

Re: [lwip-users] info hping3

[Simon Goldschmidt]

I think you're on the wrong list. lwIP is not related to hping3 in any way.

Regards,
Simon


Am 3. Mai 2022 18:09:19 MESZ schrieb "i...@outlook.com" :
>Then I'll try to use "lwip" to reduce the ram consuptions. But now:
>when I use the software "hping3" sending TCP packets on the port 80 or 443 on 
>185.79.118.12 (https://www.roseltorg.ru/) I've no effects on the target, it 
>says the target doesn't receive the packets. If I check it with wireshark it 
>doesn't true: the packets are sent to the target. But when I check the website 
>targeted is always online. The same think is true for any website.
>
>Are the packets transmitted to target or not?
>
>I'm a military services provider.
>
>Sincerely.
>
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] netconn_connect returns OK when connection refused?

[Simon Goldschmidt]

Am 11. April 2022 22:43:59 MESZ schrieb Grant Edwards 
:
>On 2022-01-20, Grant Edwards  wrote:
>
>> I'm running into a problem where netconn_connect always returns OK
>> immediately, even when the connection was refused by the server (it
>> replies to the SYN with a RST). Subsequent attempts to write to the
>> connection return -14 (ERR_RST) or -11 (ERR_CONN).
>
>> Shouldn't netconn_connect() return an error if the connection was
>> refused?  If the server accepts the conneciton, it seems to work OK.
>>
>> Here's the relevent code:
>>
>>
>>   conn = netconn_new(NETCONN_TCP);
>>   if (!conn)
>> {
>>   printf("conn NULL\n");
>>   return;
>> }
>>   e = netconn_connect(conn, , 7000);
>>   if (e != ERR_OK)
>> {
>>   printf("%s[%d] netconn_connect e=%d\n",__func__,exinf,e);
>>   netconn_delete(conn);
>>   return;
>> }
>>   printf("connected\n");
>>   ...
>>   e = netconn_write_partly(conn, data, dsize, NETCONN_COPY, 
>> );
>>   if (e != ERR_OK)
>> printf("%s[%d] netconn_write e=%d\n",__func__,exinf,e);
>
>I'm still stumped by this. It's 100% reliable: netconn_connect()
>returns ERR_OK even though the server responded to the SYN
>with a RST. Subsequent writes to that connection fail.
>
>I get the same resutls using the socket api. The call to connect()
>returns 0, but then send() fails.
>
>Nobody else has seen this?

No, but if you think this is a bug, please file a bug report!

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] Hello everybody

[Simon Goldschmidt]

Am 3. April 2022 16:33:08 MESZ schrieb Florin Medeleanu via lwip-users 
:
> [..] However I noticed the archive mail list is no longer active (and its 
> archive) athttp://www.sics.se/~adam/lwip/mailinglist.html

That link is totally outdated. Have a look at our official page:
https://savannah.nongnu.org/projects/lwip/

You can get to the list archives via the "mailing lists" link. The link to the 
lwip-users archive is this:
https://lists.nongnu.org/archive/html/lwip-users/

Regards,
Simon

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

Re: [lwip-users] Pbuf volatile flag for received packets

[Simon Goldschmidt]

Am 16. März 2022 12:26:04 MEZ schrieb Jarno Malmari :
>When passing received pbuf allocated with PBUF_TYPE_FLAG_DATA_VOLATILE
>(e.g. PBUF_REF) to tcpip_input(), the pbuf is immediately queued without
>checking the volatile flag.
>
>The comment on the volatile flag says:
>/** Indicates the data stored in this pbuf can change. If this pbuf needs
> * to be queued, it must be copied/duplicated. */
>
>The behavior seems contradictory to the flag's description. Am I reading it
>right? Should the comment be read only in the context of the lwip core, or
>maybe it only applies to transmitted packets?

Yes, it only applies to tx packets.

There's not much point in copying on the Rx side: the netif driver is 
responsible to create pbufs that can live longer. You could argue that pbufs 
might have to be copied when really enqueueing (e.g. in TCP Rx ooseq and the 
like), but if you need to copy for tcpip_input, the driver has to do it.

Regards,
Simon

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

Re: [lwip-users] Porting LwIP with RA6M4

[Simon Goldschmidt]

Am 17. Februar 2022 18:27:38 MEZ schrieb Taha Aboud :
>Hi, I am using RA6M4 for a project based on TCP connectivity and I want to
>add a library(freemodbus) which works with LwIP TCP stack.
>Since this MCU is using FreeRTOS+TCP stack, I want to switch to LwIP in
>order to use and integrate the library with my application.
>
>Is this feasible ? Do you have an idea on how to add Lwip to RA
>microcontrollers?
>(posted this in renesas forum but no answer :/ )

I don't know that MCU, but there is an lwip port for FreeRTOS, so what's 
missing should 'only' be your netif driver. Maybe you can coy the driver from 
the existing implementation, but the time it takes to get it running really 
depends on your experience with network devices/drivers.

Regards,
Simon

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

Re: [lwip-users] LwIP app and multithreading

[Simon Goldschmidt]

Am 17. Februar 2022 15:48:20 MEZ schrieb Jonathan D :
>[..]
>
>Is it OK to just surround the `http_write` caller by `(UN)LOCK_TCPIP_CORE` ?

Yes, that's enough.

Regards,
Simon

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

Re: [lwip-users] Expected behavior of linkoutput()?

[Simon Goldschmidt]

Am 12. Januar 2022 18:45:44 MEZ schrieb Grant Edwards 
:
>On 2022-01-12, Sylvain Rochet  wrote:
>
>> Actually, it should do both. Place the packet in the TX queue and return 
>> immediately, BUT if the queue is full it should wait for a free slot.
>
>So, when using an OS, I can assume that lwIP will never call
>linkoutput() from a non-thread context or from a protected region?

Yes.

Regards,
Simon

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

Re: [lwip-users] Is netconn/socket fullduplex still "really alpha"?

[Simon Goldschmidt]

Yeah, the documentation... I just haven't got around to uploading the updated 
2.1.3 documentation. However, it is included in the release zip in the download 
section.

Regards,
Simon

Am 17. November 2021 16:09:04 MEZ schrieb Grant Edwards 
:
>On 2021-11-17, goldsi...@gmx.de  wrote:
>
>> I just noticed that the new 2.1.3 release already had those comments
>> fixed
>
>Is this the wrong web page for 2.1.3 documentation?
>
>  https://www.nongnu.org/lwip/2_1_x/group__lwip__opts__netconn.html
>
>The "really alpha" statement and the requirement that mbox_free()
>wake up waiting threads is still on that page.
>
>I tried replacing the 2_1_x in the URL with 2.1.3, but that produces a
>404.
>
>
>___
>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 netconn/socket fullduplex still "really alpha"?

[Simon Goldschmidt]

On 16.11.2021 19:44, Grant Edwards wrote:

On 2021-11-16, Simon Goldschmidt  wrote:



On 16.11.2021 18:47, Grant Edwards wrote:

I've been reading up on netconn/sockets and thread-safety. At
https://www.nongnu.org/lwip/2_1_x/group__lwip__opts__netconn.html
it says this about the "fullduplex" option:

  "ATTENTION: This is currently really alpha!"

Is that accurate?


No, that comment is outdated and should be deleted by now.


Thanks, that's good news. :)

On that same page it says that for the fullduplex option to work...

sys_mbox_free() has to unblock receive tasks waiting on
recvmbox/acceptmbox and prevent a task pending on this during/after
deletion

Is that really required? I can't see how the freeRTOS port does that,
and AFAICT from reading freeRTOS docs and info, deleting a queue that
has a non-empty wait list is not allowed/undefined.


From what I've gleaned from the bugtracker, that mbox_free() behavior

might not be needed because a "closing" message is now sent through
the mailbox and the mailbox is not freed until later?


Yeah, well, that comment is outdated as well. Turned out that nearly no
OS supports this, so it got implemented in a different way.

Sorry for all the outdated comments.

Regards,
Simon

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

Re: [lwip-users] Is netconn/socket fullduplex still "really alpha"?

[Simon Goldschmidt]

On 16.11.2021 18:47, Grant Edwards wrote:

I've been reading up on netconn/sockets and thread-safety. At
https://www.nongnu.org/lwip/2_1_x/group__lwip__opts__netconn.html
it says this about the "fullduplex" option:

 "ATTENTION: This is currently really alpha!"

Is that accurate?


No, that comment is outdated and should be deleted by now.



That presumably applies to the socket api also?


Yes, of course. The socket implementation fully relies on netconn API,
so it would apply there too.



One of the main industrial protocol stacks we want to run requires
thread-safe socket operations (read from one thread, write from
another), so lwIP stable may not be usable for that product. [I don't
know if "close from a third" is required or not.]


You should be safe to do that with lwIP by now.

Regards,
Simon

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

Re: [lwip-users] LwIP manuals available anywhere?

[Simon Goldschmidt]

Well, fandom is the wiki someone started ages ago. That page doesn't really 
have anything to do with us as a project. Rather, it has been a user 
initiative. I haven't really followed the wiki, so I can't tell what's in there 
or even if it is correct.

As with many open source projects, documentation is (sadly) not our strength, 
but also sadly enough users wanting to share documentation after using lwip 
also haven't found the way back to us to improve official documtation.

Being like that, you can either stick with fandom (and yes, they want to 
somehow make money) or use (and possibly improve) our official documentation ob 
our project page  (http://www.nongnu.org/lwip/).

Regards,
Simon


Am 16. September 2021 18:55:01 MESZ schrieb Grant Edwards 
:
>I need to read up on how to develop an Ethernet driver for LwIP and
>port it to a new RTOS. I've found "manuals" on lwip.fnadom.com, but
>that site is horrendous: about 60% of the browser window is ads (some
>of them playing video). Can the mauals be download from somewhere as
>PDFs or ebooks or HTML?
>
>Or are they the property of fandom.com?
>
>Is there some other source for current devleopment documentation?
>
>-- 
>Grant Edwards   grant.b.edwardsYow! ... I don't like FRANK
>  at   SINATRA or his CHILDREN.
>  gmail.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] Why does user code need to lock tcp core?

[Simon Goldschmidt]

Am 17. Juni 2021 11:46:13 MESZ schrieb Bas Prins :
>Hi all,
>
>I just found out that my lwipopts.h was lacking quite a lot, which
>completely disabled the core locking assert. After fixing this, I did
>run
>into a few asserts. But all in places where I am not expecting them.
>
>Why do I need to lock for example:
>
>LOCK_TCPIP_CORE();
>netif_set_default(_netif);
>ppp = pppos_create(_netif, ppp_output_cb, ppp_link_status_cb,
>nullptr);
>if (!ppp)
>{
>logger.WriteDebug(LoggingCategoryPppClient,
>"Failed to create pppos client");
>return;
>}
>ppp_connect(ppp, 0);
>UNLOCK_TCPIP_CORE();
>
>or calls like this
>
>LOCK_TCPIP_CORE();
>err_t err = httpc_get_file(
>,
>port,
>"/513KB.zip",
>,
>rec_fn,
>nullptr,
>nullptr);
>UNLOCK_TCPIP_CORE();
>
>As far as I understand there I no need at all to make this a user code
>responsibility. The lwip functions could perfectly do this first hand
>*for
>me*.
>
>I can imagine a minor performance deal there. But if that's the
>argument,
>it could be made configurable, right? If the user of the library
>doesn't
>want to bother with these locks, at the cost of some unnecessary
>lock/unlocks, they could opt for that in the lwipopts.
>
>Would this be something that could be interesting to improve or am I
>missing something here?

The lwIP core code is currently written in a way that is not thread safe. Users 
have to ensure to use it in the correct way. The asserts help you to use it in 
the correct way.

Adding those locks to the code so that you don't need to care is not an easy 
task we could never know if the caller has already locked or not. Worse, some 
functions call other functions that are public, too, so that might lead to 
locking twice. And mutexes that allow such multiple locking (from a task that 
already owns the lock) are not easily available on every platform. Being like 
that, what you requested is currently not in the list of features to develop.

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

Re: [lwip-users] httpc_get_file doesn't seem to download entire file?

[Simon Goldschmidt]

Am 16. Juni 2021 20:15:02 MESZ schrieb "Rémy DZIEMIASZKO" 
:
>Le mer. 16 juin 2021 à 15:24, Bas Prins  a écrit
>:
>>
>> Hi Remy,
>>
>> Thanks for your answer.
>>
>> It feels a bit awkward this way though. Do you know any reason why
>user code should be bothered with reloading the timeout ticks? Why
>doesn't http_client deal with this when it gets notified about a new
>packet on "httpc_tcp_recv" ?
>>
>
>I agree with you that http_client timeout management shall be improved:

Definitely seems so. Would anyone please file a bug report for this? Or even 
better, a patch fixing this? The timeout should be reset when receiving a chunk 
but should probably be overridable at compile time or runtime, too.

Regards,
Simon

>1) By reloading the timer after each chunk reception (what you have
>implemented below)
>2) By giving the possibility for the application to choose the timeout
>value(s). From simple to more complex possible enhancement:
>2.a) By turning HTTPC_POLL_TIMEOUT into a lwip option instead of a
>fixed #define.
>2.b) By passing an additional parameter to httpc_get_file to configure
>for each connection a specific timeout value (because timeout value
>may depend on the server behaviour or network performance).
>2.c) By passing various parameters for various timeouts: timeout for
>the initial connection to the server, timeout between chunk
>receptions, timeout of the complete http request
>
>> And no, the opaque type is still as is in the latest and greatest
>version of lwip. Clearly indicating "I shouldn't be using their
>httpc_state_t, right?
>>
>> Would this make sense to you:
>>
>> /** http client tcp recv callback */
>> static err_t
>> httpc_tcp_recv(void *arg, struct altcp_pcb *pcb, struct pbuf *p,
>err_t r)
>> {
>>   httpc_state_t* req = (httpc_state_t*)arg;
>>   LWIP_UNUSED_ARG(r);
>> ...
>> ...
>> ...
>>   if ((p != NULL) && (req->parse_state == HTTPC_PARSE_RX_DATA)) {
>> req->rx_content_len += p->tot_len;
>>
>>
>> // - RESET TIMER TICKS HERE --
>> req->timeout_ticks = HTTPC_POLL_TIMEOUT;
>>
>>
>> if (req->recv_fn != NULL) {
>>   /* directly return here: the connection migth already be
>aborted from the callback! */
>>   return req->recv_fn(req->callback_arg, pcb, p, r);
>> } else {
>>   altcp_recved(pcb, p->tot_len);
>>   pbuf_free(p);
>> }
>>   }
>>   return ERR_OK;
>> }
>>
>> This solves my problem, and this way user code is not bothered with
>something I think it shouldn't have to bother with. And the
>httpc_state_t can remain opaque as well.
>>
>> Best regards, bas
>>
>>
>>
>> Op wo 16 jun. 2021 om 14:15 schreef Rémy DZIEMIASZKO
>:
>>>
>>> Hello,
>>>
>>> When you call 'httpc_get_file' the parameter 'connection' gives you
>a
>>> handle on the http_state used for that connection
>>> then you can passes this handle to 'httpc_get_file' via the
>parameter
>>> 'void * callback_arg'
>>> then your received function will get the handle via the parameter
>'void * arg'
>>> then in the received function you can do (http_state_t
>>> *)arg->timeout_ticks = MY_RELOAD_VALUE;
>>>
>>> http_state_t * foo;
>>> httpc_get_file(ip, port, uri, settings, my_recv_fn, foo, )
>>>
>>> err_t  my_recv_fn(void * arg, ...)
>>> {
>>>(http_state_t *)arg->timeout_ticks = MY_RELOAD_VALUE;
>>> }
>>>
>>> You might have a compilation issue because 'http_state_t' is
>normally
>>> an opaque type for the application then the member 'timeout_ticks'
>is
>>> not visible from the application.
>>> In a past project I solved that by exporting the definition of
>>> 'http_state_t' but maybe this is already fixed in the last release
>of
>>> lwip.
>>>
>>> Regards
>>> Rémy
>>>
>>> Le mer. 16 juin 2021 à 13:24, Bas Prins  a
>écrit :
>>> >
>>> > Dear ,
>>> >
>>> > I don't think I am able to reset the timer. The 'arg' passed  in
>>> >
>>> > err_t rec_fn(void *arg, struct altcp_pcb *conn, struct pbuf *p,
>err_t err)
>>> >
>>> > is not of type httpc_state_t. The rec_fn callback is called here:
>>> >
>>> > static err_t
>>> > httpc_tcp_recv(void *arg, struct altcp_pcb *pcb, struct pbuf *p,
>err_t r)
>>> > ...
>>> > ...
>>> > ...
>>> > if (req->recv_fn != NULL) {
>>> >   /* directly return here: the connection migth already be
>aborted from the callback! */
>>> >   return req->recv_fn(req->callback_arg, pcb, p, r);
>>> > }
>>> >
>>> > So what's the deal with this function
>>> >
>>> > /** http client tcp poll callback */
>>> > static err_t
>>> > httpc_tcp_poll(void *arg, struct altcp_pcb *pcb)
>>> > {
>>> >   /* implement timeout */
>>> >   httpc_state_t* req = (httpc_state_t*)arg;
>>> >   LWIP_UNUSED_ARG(pcb);
>>> >   if (req != NULL) {
>>> > if (req->timeout_ticks) {
>>> >   req->timeout_ticks--;
>>> > }
>>> > if (!req->timeout_ticks) {
>>> >   return httpc_close(req, HTTPC_RESULT_ERR_TIMEOUT, 0,
>ERR_OK);
>>> > }
>>> >   }
>>> >   return ERR_OK;
>>> > }
>>> >
>>> > It only decreases the ticks counter. It never gets reset. So I am
>not allowed to download files 

Re: [lwip-users] BRIDGEIF does not forward packets?

[Simon Goldschmidt]

Am 23. April 2021 18:39:31 MESZ schrieb Tomas Mudrunka :
>>   bridgeif_initdata_t bridge_initdata = BRIDGEIF_INITDATA1(1, 1024,
>> 16, ETH_ADDR(0, 1, 2, 3, 4, 5));
>>   if(netif_add(, , , , _initdata,
>> bridgeif_init, NO_SYS ? netif_input : ethernet_input) == NULL) {
>>  LOG(LL_WARN,("Cannot create bridge!"));
>>   }
>> 
>>   if(netif_add(, NULL, NULL, NULL, NULL, mynetif_init, NO_SYS
>?
>> netif_input : tcpip_input) == NULL) {
>>  LOG(LL_WARN,("Cannot create interface!"));
>>   }
>> 
>>   bridgeif_add_port(, );
>>   netif_set_up();
>>   netif_set_up();
>
>
>I've been looking bit more to what is going on and it does not even 
>respond to ARP requests...
>Perhaps there is some issue with MAC adresses?
>Maybe i need to set that bridge port to some PROMISCUOUS mode to accept
>
>packets for all HW addresses?
>But i was not able to figure out how that is done in LWIP.

That's not done by lwIP. You'll just need to implement that in your netif 
driver when using it with bridgeif.

Regards,
Simon

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

Re: [lwip-users] bind with link down

[Simon Goldschmidt]

On 31.03.2020 21:34, Massimiliano Cialdi wrote:

I have a process that polls the PHY to find out if the link is up or
down. It calls netif_set_link_up()/netif_set_link_down(). I also have
the link callback calling netif_set_up()/netif_set_down().


You're mixing link state with admin state here. That might work, but
might not work in some situations.



I wonder what happens if the functions:
   conn = netconn_new(NETCONN_UDP);
   netconn_bind(conn, IP_ADDR_ANY, 7);
are called when netif is still down. This happens because, for
example, the udpecho_thread() process starts before the netif is up.

Then when the link goes down while
err = netconn_recv(conn, );
is waiting, it doesn't exit with an error. Is that correct?


Correct or not depends on how you define it. There's currently no code
in lwIP to unblock on link loss. That could only work if you're bound to
a netif. I'm not sure if what you think of works in other stacks.

Regards,
Simon

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

Re: [lwip-users] Core locked checking when using the SNMP netconn implementation

[Simon Goldschmidt]

Dirk Ziegelmeier wrote:
> Hm, you again found a bug. In this case I don't even have quick fix...
> We (the company I work for) never used traps so they are basically untested.

I don't think traps are untested. But the combination of traps and using SNMP
via that netconn API might be untested. In fact, I think SNMP is most often
used with the callback API, so bug reports in this area are welcome!

Regards,
Simon

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

Re: [lwip-users] https server woes.

[Simon Goldschmidt]

On 20.02.2020 18:20, Trampas Stern wrote:

[..]
I am fairly new to TCP/IP so hold my hand in interpreting the wire shark
results.

image.png


Please send pcap files, not images, while ensuring the pcap files only
contain things they need (so don't send a file that is too large).

Thanks,
Simon

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

Re: [lwip-users] https mbed TLS lwip

[Simon Goldschmidt]

Trampas Stern wrote:
> right now I have the following settings:
> #define MEM_SIZE                 12 * 1024
> [..]
> It appears that I am getting handshake failures...
 
During runtime mbedTLS allocates hughe amounts of memory. Depending on your
configuration, this is routed to the lwIP heap (see altcp_tls_mbedtls_mem.c).
If so, this value is *much* too low!

The other values might be too low, too. Try to increase everything to the max
(that your system allows) and see how much you actually need by monitoring
lwip_stats.

Regards,
Simon


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

Re: [lwip-users] mbedtls

[Simon Goldschmidt]

Trampas Stern wrote:
> I found that chrome will not work with openssl keys generated by the comments 
> in the code I found I had to generate different keys using the following 
> commands. 
> [..]

Well, the code in the comment did work at some time. I don't think I can keep 
up with the speed that google changes TLS handling... :-)

Regards,
Simon

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

Re: [lwip-users] DNS thread-safe functions

[Simon Goldschmidt]

matteo.c...@alice.it wrote:
> - LOCK_TCPIP_CORE / UNLOCK_TCPIP_CORE. They allow to access in exclusive way
> to TCIPIP mechanism. However, I don’t want interfere with the regular
> mechanisms of TCIPIP thread and of operating system;

You don't. Unless you explicitly set LWIP_TCPIP_CORE_LOCKING to 0, tcpip_thread
uses LOCK_TCPIP_CORE as well.

> [..]
> At this point I would like to know your position about the use of the
tcpip_api_call function instead of your suggestions. Is it an equally acceptable
> alternative from your point of view?.

No. It's an internal function that can change at any time. You can see that from
having to include a header with "priv" in its name to get the definition of the
struct used as 2nd parameter.

Regards,
Simon

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

Re: [lwip-users] DNS thread-safe functions

[Simon Goldschmidt]

Ajay Bhargav wrote:
> [..]
> However, I am not sure if dns_setserver really needs to be protected so much
> as there is nothing much going on except copying of server in an array.

Please *don't* suggest things like this. You *need* protection:
a) there is no guarantee the code will stay like it is now
b) when switching to IPv6, the write is *not* atomic any more

Don't try to be smarter than the authors of the code or it might eat you in the
future ;-)

Regards,
Simon

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

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

[Simon Goldschmidt]

vysocan wrote:
> Re-posting the debug since raw text was removed...

If you want more people to read this, please: don't write from nabble. Instead,
send a good old text-only email to the list.

And ensure it's a readable length. I'm not even sure what your problem is...

Thanks,
Simon

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

Re: [lwip-users] LWIP IPV6 UDP STM32f746

[Simon Goldschmidt]

On 18.12.19 08:00, ajnlwip wrote:

Is there anyone that is using ipv6 with LWIP and raw udp interface?
If so, it would be nice if you can share some code. I am using stm32f746


Depending on which kind of problems you see, it might be better to ask a
more generic question. I don't see why IPv6 on that stm32 should be much
different from any other platform.

Regards,
Simon

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

Re: [lwip-users] fragmentation failure with stm32 if length > 1704

[Simon Goldschmidt]

ranran wrote:
> Hi,
>
> I've solved this issue after increasing size as was suggested here. Thanks !
> (The issue was also posted here:
> https://community.st.com/s/question/0D50XBozSc5SQE/ethernet-fragmentation-issues)
>
> Yet, whenever lwip receives (from PC) big packet , above its limit, it gets
> into exception as was described above.

I didn't quite get the post which seemed to suggest to increase some size, but
this still seems like a driver issue. lwIP does *not* in general have problems
with this!

>
> This seems like a high security issue.

Yes, it is!

>
> Any idea how it can be solved ?

Fix your driver :-)

Maybe your MAC just accepts jumbo packets? The idea of fragmentation is that
jumbo packets are split into multiple packets of 1514 bytes max each...

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

[Simon Goldschmidt]

"mtimm"  wrote:
> It looks like it stucked inside memp_priv.h inside typedef
> memp_pool_helper_t declaration. It is something wrong with the syntax. I am
> not sure how memp_priv.h and memp_std.h work and it is hard for me to
> eliminate this issue.
> I would like to work with static allocation which is available by using
> pools. Do I need both (memp_priv.h and memp_std.h) files including in my
> project?

No. The error is in your lwippools.h: you need to remove the include guards.
This file gets included multiple times with different defines set.

See our example here:
http://git.savannah.nongnu.org/cgit/lwip.git/tree/contrib/examples/example_app/lwippools.h

Regards,
Simon

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

Re: [lwip-users] https post_auto_wnd not work

[Simon Goldschmidt]

"tomek wilkxt" wrote:
> > > #define LWIP_HTTPD_POST_MANUAL_WND  1
> > > In normal http:
> > > if *post_auto_wnd=1 its work ok, i can read large file.
> > > if *post_auto_wnd=0, not work (I see TCP ZeroWindow flags).
> >
> > Well, these zero windows are expected, no? You'll have to update the
> > window from your application, of course.
>
> you can show an example from manual widows update ?

RTFM:
http://www.nongnu.org/lwip/2_1_x/group__httpd.html#ga6cb33693ee8f0c054be82a968ceff582

"post_auto_wnd  Set this to 0 to let the callback code handle window updates by 
calling 'httpd_post_data_recved' (to throttle rx speed) default is 1 (httpd 
handles window updates automatically)"

Is that clear enough?

Regards,
Simon

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

Re: [lwip-users] listen to multiple ports

[Simon Goldschmidt]

steffen_storck wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> I'm sorry, but maybe case is a little exotic.

No, it's not ;-)

>
> I need to listen to more than one port but only have one local interface. So 
> I tried to add more pcbs to the list of pcbs with this
>
> struct udp_pcb* upcb = udp_new();
> if (upcb)
> {
>   udp_bind(upcb, IP_ADDR_ANY, ports[i]);
>udp_recv(upcb, udp_server_receive_callback, pInst);
> }
>
>
> But after 4 pcbs, the memory allocation fails. How/where can I increase the 
> size so that 8 pcbs cann be allocated?

Look at MEMP_NUM_*** in opt.h. But don't change opt.h: create your own 
lwipopts.h instead, overriding the default settings.

Regards,
Simon

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

Re: [lwip-users] LWIP MQTT+HTTPd with ssi

[Simon Goldschmidt]

"JJ" wrote:
> I’m using your MQTT client app with success.  
> But when I activate HTTPD in LWIP, the SSI codes are not parsed anymore if
> MQTT client is active.
> I mean:
> 1.If I activate only HTTPD + SSi it works as expected.
> 2.If I activate only MQTT it works as expected.
> 3.If I activate HTTPD+SSI and MQTT, MQTT works as expected.  HTTPD works,
> but SSI codes are not parsed anymore, they are printed as strings onto the
> web pages. And, moreover, the page is rendered very slow in Chrome and
> Firefox, but normally fast in Edge.
> 
> May someone help me in finding the issue?

Both MQTT and HTTPD are separate apps. They don't have anything to do
with each other, so I see no apparent reason for your problem.

I guess you'll need to find that out yourself. Watch out for 
misconfigurations...

Regards,
Simon

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

Re: [lwip-users] tcp_poll

[Simon Goldschmidt]

"vrnud" wrote:
> Hello,
>
> How to call tcp_poll()?

What are you trying to do? Have you read the docs?

The callback registered via tcp_poll() is called by a timer in
the lwIP stack...

Regards,
Simon

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

Re: [lwip-users] HTTP keep alive SSI

[Simon Goldschmidt]

Hi Tomek,

are you aware of email threads and that you just hijacked another thread?
Never use the "reply" feature unless actually responding to a mail!

"tomek wilkxt" wrote:
> Hi
> I read this form "httpd_opts.h" file :
> " * A downside of the current SSI implementation is that persistent 
> connections
>  * don't work, as the file length is not known in advance (and httpd currently
>  * relies on the Content-Length header for persistent connections).
>  *
>  
> Do you have a way to solve this problem? I need a permanent connection for 
> xml.json.

You could use a form of HTTP chunked encoding, but I never got round to
implementing that.

Instead, I used custom files to create such JSON files (not using SSI). Your
custom file handler code can then set these files to have a length so that
a persistent connection is not a problem.

Regards,
Simon

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

Re: [lwip-users] Running perl makefsdata

[Simon Goldschmidt]

"Sel" wrote:
> Do you know if I have to compile the C version or is there an .exe available?
>
> If compile required, is there a guide for it?
>
> (I tried to do so earlier, but, noticed that there were header files missing)

To get a windows executable, you can use the VisualStudio project files under
'contrib\ports\win32\msvc\'.

Alternatively, the cmake build should work with cygwin, too.

I'll try to remember uploading an exe with the next release...

Regards,
Simon

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

Re: [lwip-users] `MEMP_NUM_PPP_PCB' undeclared here (not in a function)

[Simon Goldschmidt]

markus forrer wrote:
> If I remove /*(PPP_SUPPORT*6*MEMP_NUM_PPP_PCB) +*/ it works.
> Looks like something changed in the new version of lwip?

Yes: the ppp configuration has been split out, as this is
"merely" a netif to lwip. As a result, MEMP_NUM_PPP_PCB is
not defined globally (it has been defined to 0 before).

Regards,
Simon

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

Re: [lwip-users] LWIP SNMPv1 howto

[Simon Goldschmidt]

On 23.06.19 17:27, Yigal Hochberg wrote:

Hi Steven,

DMH Software offers and SNMP-Agent solution for Lwip based platforms > It comes 
with a MIB-Compiler that generates all required code for

your MIBs.

All SNMP versions are supported: snmpv1, snmpv2c, and a full snmpv3
agent implementation.


We provide a MIB compiler as well. v1, v2c and v3 are supported as well
(although v3 is not complete yet).

If you use this list for advertising, maybe you'd want to explicitly
state what's better... ;-)

Regards,
Simon

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

Re: [lwip-users] why NA message is sent to upper layer by raw_input

[Simon Goldschmidt]

"Grace" wrote:
> I'm using lwip2.1.2 to implement ping ipv6 feature,
> [..]
> So why NA in IPv6 is passed to IP layer?

In the IPv4, ARP has its own ethtype, so ARP packets are of course
not sent to IP.

In contrast, in IPv6 world, address resolution is implemented on
top of IPv6 instead of having its own ethtype, so naturally,
raw IP access gets those frames, too.

Regards,
Simon

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

Re: [lwip-users] Handling Socket Errors

[Simon Goldschmidt]

On 01.05.19 21:47, Brandon Noel wrote:

Hi,

We are using lwIP’s (STABLE-2.1.2) non-blocking  BSD socket interface in
an application. Our current setup is two threads which each have their
own socket and are communicating with different peers. Currently if
lwip_send() returns -1 we call getsockopt(SOL_SOCKET, SO_ERROR) to get
the error for that socket. We are unsure about what types of errors lwIP
supports with getsockopt() and how to appropriately handle those errors.

What is the appropriate way to handle getsockopt(SOL_SOCKET, SO_ERROR)
returning a fatal error? Should we call lwip_close()? Is it improper to
call lwip_close() (in other words we should do nothing because of
possible double freeing)? Does it depend on the error type? We also
cannot rely on errno because of race conditions between the two threads.


Calling close is required if you're sure that the socket was valid as
it's not closed internally otherwise. The lwIP pcb *is* freed by the
stack, but not the socket.

In contrast, there's no check that the socket is yours, so if you just
call close() with any integer in the socket range, you could close some
connection. There's no risk of double-free though.

About 'errno': it's more or less mandatory for this to be a per-thread
value, so you might want to implement thread-local storage. Implementing
nonblocking socket programs without errno is rather pointless I guess...

Regards,
Simon

___
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

[Simon Goldschmidt]

On 18.04.19 11:06, tirmalabenikasibeni wrote:

goldsi...@gmx.de wrote

Which code?


In the  initial code

, or revised one:


There's no code here. I guess the problem is that you're using nabble
while this is a mailing list, not a nabble forum. Nabble just provides a
(somewhat nasty) view to this list, which also has the downside of
people not citing older messages when replying...

Here's what your post looks like in the official mailing list archive:
http://lists.nongnu.org/archive/html/lwip-users/2019-04/msg00055.html

Regards,
Simon

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

Re: [lwip-users] LWIP altcp_mbedtls webserver performance issue

[Simon Goldschmidt]

Amr Elsayed wrote:
> Thank you for the response, Can you share with me the chip name for the RSA ?

No, sorry, I'm not involved in the details there. But as Tomek wrote, the
ATECC508A (or also the ATECC608A) should do a good job for ECDH.

> I have implemented  the cryptography hardware accelerators on mbedtls library
> from ST examples, the accelerators are used in AES, DES, MD5, SHA1, SHA256 ,
> and Entropy for the random generator.

It's a shame that ST doesn't provide official code for integration into 
mbedtls...

> that's why the encryption is fast but the problem is only the Handshaking,
> as Far as I got, There's no hardware accelerators examples from ST for RSA.

No, the STM32 don't support anything to speed up RSA or ECDH.

Regards,
Simon

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

Re: [lwip-users] LWIP altcp_mbedtls webserver performance issue

[Simon Goldschmidt]

Amr Elsayed wrote:
> Hi Guys,
> 
> I am using the LWIP altcp_mbedtls and httpd for implementing a webserver
> on STM32F437 which has a Cryptography processor ,Hash processor, and
> random generator [..]

mbedTLS does not use the hardware functions of this chip by default, you
need to add that by yourself (*). We do have a https webserver running on such
a chip at 80 MHz, so it should definitively be possible. We do have an external
helper chip doing the RSA though...

(*) you might find examples for STM in the embed-os repository

Regards,
Simon

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

Re: [lwip-users] using lwip with static memory

[Simon Goldschmidt]

On 04.04.19 07:18, Ranran wrote:

Hello,

Is it possible to use lwip with static memory ?
We need to use lwip with safertos (safertos does not support heap).

Is it done by enabling MEM_USE_POOLS=1


Exactly. You then have to define the pools for mem_malloc to use. You
also need to enable MEMP_USE_CUSTOM_POOLS and provide a file
"lwippools.h" that sets the element size and count of pools used instead
of the heap.

Regards,
Simon

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

Re: [lwip-users] tcp_active_pcbs corrupt after resetting connection ???

[Simon Goldschmidt]

On 27.03.19 22:00, Terence Darwen wrote:

Hi Simon - Thanks for the reply.  I've made my own replies below:

 > Hi, I'm using lwIP 1.41 with a Texas Instruments Tiva Launchpad
development
 > board (the TM4C1294).
 >>Now that's a really old version of lwIP!

Yes, unfortunately 1.41 is the version that is packaged in TI's latest
release of Tivaware and not a more recent version.

 > [..]
 > This code is run in the lwIPHostTimerHandler.  Which of course is called
 > from the Ethernet interrupt handler.

 >>Wait a minute, "of course"? Have you read this (mostly valid for 1.4.x
 >>as well):
 >>https://www.nongnu.org/lwip/2_1_x/pitfalls.html

Yes, I've been working with lwIP on the Tiva for some time now and have
been aware of these instructions for quite a while and have taken great
care to make sure all lwIP calls (all tcp_* calls) are made on a single
"thread", this being the Tiva's Ethernet interrupt.  For example, when
needing to send new data outside of the Ethernet interrupt I place the
data in a thread safe queue.  This queue is then processed (i.e. the
data from the queue is sent using tcp_wtite and tcp_output) only during
the Tiva's Ethernet interrupt.

 > Based on other examples, I see no problem with this.

 >>Ehrm, based on which examples?

TI's Tivaware contains examples of using lwIP where the
lwIPHostTimerHandler function makes tcp_ calls.  The examples
have lwIPEthernetIntHandler() as the ISR, this calls  lwiplib.c's
lwIPServiceTimers() which calls lwIPHostTimerHandler()

 >>When running code from ETH interrupt
 >>handler, you have to *know* what you are doing! Basically this means:
 >>*no* access into lwIP from any other interrupt priority or main loop
 >>*unless* the ethernet interrupt is disabled.

Totally agree.  I've taken great care in my code to always do this and,
as far as I can tell, this is indeed what I am doing.  I never do any
calls into lwIP from anywhere except the Ethernet interrupt handler.

 >> However, intermittently, it appears to corrupt the
 >> lwIP's tcp.c's tcp_active_pcbs linked list.

 >And I would have written that as an example if you hadn't watched out
 >for what I wrote in the lines above ;-)

Right, you're saying the tcp_active_pcbs linked list being corrupted
like this is a common result of multiple execution contexts in lwIP
code.  I could understand that.

 >Try to clean up your code (in terms of execution threads) and if you
 >can, think about upgrading to a more recent version.

The code is quite clean, and, as an experienced developer, I've reviewed
it many times to verify the logic is correct and no thread issues
exist.  Other than this issue I'm having, the 1.41 lib is performing
very well.  I'm doing a lot of communication with a number of clients
over long periods of time without any issues.  Unfortunately, using
non-Tivaware 3rd party code is probably not an option for me at this
point.  I do understand 1.41 is quite an old version of lwIP so if the
answer boils down to "upgrade" being the advised solution I could
understand this.


Well, I'm sorry to say I cannot tell you what's the reason for the bug
you're seeing. I cannot recall a specific bug leading to this, but of
course it could be that it's a bug that has been fixed by now. However,
using lwIP like that (only in the ETH interrupt) is quite uncommon and
hard to review, so I wouldn't put concurrency problems aside as a reason
here...

Regards,
Simon

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

Re: [lwip-users] TCP state machine problem? LWIP 1.4.1

[Simon Goldschmidt]

On 08.03.2019 15:47, Sergio R. Caprile wrote:

mmm... the ACK number..., I think I've seen this one or two years ago,
search the list and or the patches for "one less" or something like that.
I'm not fresh on this, but I think that is the problem, the ACK to the
RST has the wrong number and causes a retransmission. I can't remember
if this is also related to the half-closed connection; you might check
on that too.


I know this might not be an option, but 1.4.1 is *really* old and this 
one as well as numerous other things might already be fixed in one of 
the newer versions.


Regards,
Simon

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

Re: [lwip-users] lwIP trouble

[Simon Goldschmidt]

On 26.02.2019 22:07, Slava Zilberfayn wrote:

Hello all,

I've  done some more testing with tcpecho example. When I set
chunk  size  to  be  less  than the size of the tcpecho
packets,  I  get  exactly  the same failure during the second
call  to netconn_write. When the packet size small than chunk
size  it  crashes fairly quickly. For example I set chunk size
to  400  in the tcpecho example and send 400 bytes packets to
it. Works fine.

If   I  start  sending  401 bytes, it crashes fairly quickly.
There   must   me   something  wrong  with  my  settings. Any
help would be appreciated.



If you could get this reproduced with minimal changes on the win32 or 
linux port, it would be *much* easier to see what's going on.



Regards,

Simon


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

Re: [lwip-users] altcp_tls_mbedtls

[Simon Goldschmidt]

On 26.02.2019 17:15, Giuseppe Modugno wrote:

Il 26/02/2019 09:58, Simon Goldschmidt ha scritto:

Giuseppe Modugno wrote:

[snip]

No. TCP_WND is not something you have allocated. It's the amount of data
the remote host can send before we reopen the window.

In the altcp TLS case, the data is received and ACKed, then the TLS
adaption layer passes it into mbedtls and frees the buffer. However, the
window update is sent by the application code that is TLS-agnostic. So
the window update is only sent after the block has been decrypted.


Could you point me to the code that reopen the window after the block 
has been decrypted? I couldn't find it, my shame.



There's not "the code" that does this. The raw tcp callback application 
does this by calling altcp_recved(), which is directly mapped through to 
the lower protocol (TCP in this case). The mbedtls layer only calls 
tcp_recved() for the overhead bytes that don't get handled by the 
application, so that it is ensured the window always reopens correctly.



Isn't possible to reopen the window (call tcp_recved) even when a 
partial TLS block is received? I couldn't understand why lwip needs to 
reopen the window only when an entire block is received (and decrypted 
by mbedTLS).
Suppose 1kB of a 16kB encrypted block is received, altcp_tls_mbedtls 
pass the data to the application mbedTLS that copy them in its buffer, 
then frees the received pbufs. Now we can reopen the window. What's 
wrong with this approach that can keep TCP_WND small?



That would also be possible. But then you would lose the ability for the 
application to throttle the remote host's sending speed (in case the 
application handles data slower than it possibly arrives - again, think 
of an upload programmed to flash).



You'd then just call tcp_recved for everyhing you successfully pass into 
mbedtls and ensure the altcp_recved() calls from the application don't 
get passed through to TCP.




And
since such a block may be up to 16 kByte, the tcp window has to be at
least that big, too, or you can get a deadlock.


Suppose I have a TCP_WND of only 2kB and incoming TLS buffer of 16kB.
The TLS transmitter could send maximum 2kB of data that are buffered in
the lwip receiving window. lwip calls altcp_recv(), so
altcp_mbedtls_lower_recv() with received data (2kB maybe segmented in
small pbufs and pbuf chains).

I can't follow the code, but I expect those data are immediately passed
to mbedTLS library that should copy those data to its 16kB incoming
buffer, freeing receiving window. I think the lwip TCP receiving window
could be smaller than mbedTLS incoming data buffer.

To make the receiving window smaller, you'd have to change the code.
However, you would gain nothing: TCP_WND is *not* a buffer. The actual
buffer is in mbedtls and you can't shrink that. TCP_WND just describes
this behaviour.


TCP_WND isn't a buffer, however I need to reserve a sufficiently sized 
memory pools (I'm using memory pools for pbufs with 
MEMP_MEM_MALLOC=0). And memory pools are statically allocated memory, 
so I end up with 16kB allocated buffer for mbedTLS and 16kB memory 
pools for storing at least TCP_WND bytes.


In core/init.c there's an error:

#if !MEMP_MEM_MALLOC && PBUF_POOL_SIZE && (TCP_WND > (PBUF_POOL_SIZE * 
(PBUF_POOL_BUFSIZE - (PBUF_LINK_ENCAPSULATION_HLEN + PBUF_LINK_HLEN + 
PBUF_IP_HLEN + PBUF_TRANSPORT_HLEN
#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."

#endif



Yes, that's room for improvement :-)


You probably don't need to buffer a complete TCP_WND in the rx pbufs as 
I suppose mbedtls just copies the data into its buffers until a whole 
message is received...



Regards,

Simon


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

Re: [lwip-users] altcp_tls_mbedtls

[Simon Goldschmidt]

Giuseppe Modugno wrote:
> An: lwip-users@nongnu.org
> Betreff: Re: [lwip-users] altcp_tls_mbedtls
>
> Il 25/02/2019 20:19, goldsi...@gmx.de ha scritto:
> > Am 22.02.2019 um 10:24 schrieb Giuseppe Modugno:
> >> Il 22/02/2019 09:43, Simon Goldschmidt ha scritto:
> >
> > [snip]
> >
> >>>> Is this warning correct? I think TCP_WND should be compared with
> >>>> MBEDTLS_SSL_IN_CONTENT_LEN or MBEDTLS_SSL_OUT_CONTENT_LEN or the 
> >>>> maximum
> >>>> of them (of course, I hope to compare it with OUT buffer only, because
> >>>> it is smaller).
> >>> I think you're right: this should compare to the IN buffer. No that it
> >>> would help you here... :-)
> >>
> >> I'm not an expert here, so my question could be very stupid. TCP_WND is
> >> the TCP window that is used to avoid continuous ack for small data. The
> >> transmitter sends data filling the window and then waits for the ack.
> >
> > TCP_WND is what we announce to the remote host to be able to buffer 
> > for RX.
> >
> > For TX, what we buffer is the minimum of what the remote host tells us 
> > to be able to buffer and the memory we have/allow (both available heap 
> > memory and the limitation defines SND_BUF and SND_QUEUE_LEN).
> 
> Ok, but I couldn't understand the relation between lwip receiving window 
> and TLS incoming buffer. If MBEDTLS_SSL_IN_CONTENT_LEN is 16kB, should I 
> need a TCP_WND at least 16kB, for a total of 32kB of memory only to 
> handle incoming TLS traffic?

No. TCP_WND is not something you have allocated. It's the amount of data
the remote host can send before we reopen the window.

In the altcp TLS case, the data is received and ACKed, then the TLS
adaption layer passes it into mbedtls and frees the buffer. However, the
window update is sent by the application code that is TLS-agnostic. So
the window update is only sent after the block has been decrypted. And
since such a block may be up to 16 kByte, the tcp window has to be at
least that big, too, or you can get a deadlock.

> Suppose I have a TCP_WND of only 2kB and incoming TLS buffer of 16kB. 
> The TLS transmitter could send maximum 2kB of data that are buffered in 
> the lwip receiving window. lwip calls altcp_recv(), so 
> altcp_mbedtls_lower_recv() with received data (2kB maybe segmented in 
> small pbufs and pbuf chains).
> 
> I can't follow the code, but I expect those data are immediately passed 
> to mbedTLS library that should copy those data to its 16kB incoming 
> buffer, freeing receiving window. I think the lwip TCP receiving window 
> could be smaller than mbedTLS incoming data buffer.

To make the receiving window smaller, you'd have to change the code.
However, you would gain nothing: TCP_WND is *not* a buffer. The actual
buffer is in mbedtls and you can't shrink that. TCP_WND just describes
this behaviour.

The only downside I see is that this way, all other non-TLS applications
get a bigger TCP_WND too. That's why we want to add code to control TCP_WND
at runtime per pcb.

Regards,
Simon

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

Re: [lwip-users] Again confused about tcp_recved() and pbuf_free()

[Simon Goldschmidt]

Giuseppe Modugno wrote:
[..]
> >> What are the situations when it should be better to not call 
> >> tcp_recved() in recv() callback()? Here the application has the 
> >> received data, can process and free the pbufs or can avoid freeing 
> >> the pbufs to wait for additional data. In both cases I think the 
> >> application should call tcp_recved().
> >
> > If you need to process the received data further at slower speed, it's 
> > better to not call tcp_recved() right away. For example if you're 
> > programming into slow flash, calling tcp_recved after the bytes are 
> > programmed ensures the client does not send faster than you can program.
> 
> In this case you don't free the pbuf, because data is being written to 
> the Flash. So it seems to me that when you free the pbuf (you have 
> processed the incoming data), you can call tcp_recved(). If you don't 
> free the pbuf, you haven't processed the data yet, so you don't call 
> tcp_recved().
> 
> I don't understand when the two things can be different.

They might be the same for you. But if you have a different buffering
scheme (e.g. a ring buffer for flash writes or whatever), it could be
different. With a library like lwIP, you just don't know how it will
be used in the actual targets.

Regards,
Simon

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

Re: [lwip-users] altcp_tls_mbedtls

[Simon Goldschmidt]

Giuseppe Modugno wrote:
> I'm trying to integrate lwip and mbedTLS on a project running on LPC1769 
> MCU from NXP. This MCU features 64kB SRAM in two separate banks of 32kB.

If it works at all, it will certainly get *very* hard. Aside from the
input buffer, we saw really many small allocations (especially at
connection startup time) that summed up to some amount. I can't remember
exactly how the numbers were, but we're running it with more than 64 kB.

But then again, we need to support more than 1 connection to do being a
https server...

> As you can understand, I'm fighting putting all together with so small 
> SRAM. I'm not sure mbedTLS+lwip could really work in 64kB. I'm 
> interested in creating only one TLS connection with a MQTT server 
> (Amazon IoT or similar service). I'd like to know some experience about 
> a similar application in similar hw platform.
> 
> The first thing I made to reduce RAM requirements was decreasing 
> MBEDTLS_SSL_OUT_CONTENT_LEN from 16384 to 2048 (I understood output 
> buffer is under my control, so I can reduce it without letting informed 
> the server about this, differently from IN_CONTENT_LEN that must be at 
> least 16384).
> 
> My mbedTLS config.h:
> 
> #define MBEDTLS_SSL_IN_CONTENT_LEN  16384
> #define MBEDTLS_SSL_OUT_CONTENT_LEN 2048
> //#define MBEDTLS_SSL_MAX_CONTENT_LEN
> 
> In mbedtls/ssl.h appears:
> 
> #if !defined(MBEDTLS_SSL_MAX_CONTENT_LEN)
> #define MBEDTLS_SSL_MAX_CONTENT_LEN 16384   /**< Size of the 
> input / output buffer */
> #endif
> 
> So MBEDTLS_SSL_MAX_CONTENT_LEN is defined as 16384. Anyway it seems this 
> symbol is never used in mbedTLS code (it is useful only to define IN and 
> OUT content len when they aren't defined).
> 
> In altcp_tls_create_config() appears:
> 
>    if (TCP_WND < MBEDTLS_SSL_MAX_CONTENT_LEN) {
>      LWIP_DEBUGF(ALTCP_MBEDTLS_DEBUG|LWIP_DBG_LEVEL_SERIOUS,
>    ("altcp_tls: TCP_WND is smaller than the RX decryption buffer, 
> connection RX might stall!\n"));
>    }
> 
> Is this warning correct? I think TCP_WND should be compared with 
> MBEDTLS_SSL_IN_CONTENT_LEN or MBEDTLS_SSL_OUT_CONTENT_LEN or the maximum 
> of them (of course, I hope to compare it with OUT buffer only, because 
> it is smaller).

I think you're right: this should compare to the IN buffer. No that it
would help you here... :-)

> Another question, more TLS related. I know some servers don't implement 
> MFL (Maximum Fragment Length) extension in order to reduce input buffer 
> size too. Do you know of some way to understand if the server really 
> implement this extension? I'm interested in IoT services from Amazon, 
> Google, Microsoft or similar. It seems they don't explicit this feature, 
> so I have to check in other ways.

I don't think I can help you here.

Regards,
Simon

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

[lwip-users] 2.1.x bugfix branch updated

[Simon Goldschmidt]

Hi all,

the 2.1.x branch [1] just got about 20 or so bugfix cherry-picks.
This means I'd like to release 2.1.3 shortly. Please test :-)

[1] http://git.savannah.nongnu.org/cgit/lwip.git/log/?h=STABLE-2_1_x

Regards,
Simon

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

Re: [lwip-users] DNS lookup table or dynamic local hostlist?

[Simon Goldschmidt]

On 16.02.2019 20:58, Roman Lwip wrote:

Hi,

I am using lwip as part of the espressif/arduino-esp32 library and 
there is something I don't understand.


My question is about DNS implementation of lwip:
https://github.com/espressif/arduino-esp32/blob/master/tools/sdk/include/lwip/lwip/dns.h

If I understand correctly there is a lookup table, which contains the 
host names, which have been queried before and their ip adress. Can I 
add a host to that lookup table during runtime?



Yes, see |DNS_LOCAL_HOSTLIST, ||DNS_LOCAL_HOSTLIST_ISDYNAMIC and 
||dns_local_addhost().|


||

|
|

So what I want is this: The ESP32 wakes up and only does the DNS query 
(dns_gethostbyname), if the IP address of an MQTT server has changed, 
because an IP change of that server is not likely to happen often. So 
I would save the IP address over deep sleep and use it again, when the 
ESP wakes up. Do I need a dynamic host list for that (the 
DNS_LOCAL_HOSTLIST macro is undefined now)? Or can I edit the lookup 
table directly?



No, you can't edit the lookup table directly. However, I don't get how 
you detect the IP address has changed without using dns, as that's what 
dns is for...?



Regards,

Simon


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

Re: [lwip-users] dhcp_release_and_stop() clears the assigned IP address

[Simon Goldschmidt]

R. Diez wrote:
> Last time I looked, I could not find a proper network discovery protocol like
> zeroconf or Bonjour in lwIP. Is there anything new in this respect?

Zeroconf and Bonjour are marketing words from Apple, aren't they? We try to
implement standards.

We provide AutoIP and mDNS, what are you missing?

Regards,
Simon

___
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 ?

[Simon Goldschmidt]

Pekub wrote:
> [..]
>  err = udp_bind(upcb, IP_ADDR_BROADCAST, 8000);

Maybe you should bind to the ANY addr, not to BROADCAST.

Regards,
Simon

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

Re: [lwip-users] Webserver based on lwip 1.4.1

[Simon Goldschmidt]

"Keppler, Uwe" wrote:
> Does really nobody have an idea or found a similar issue?

Please don't top-post.

Your problem looks like a threading issue. Did you read and understand 
http://www.nongnu.org/lwip/2_1_x/pitfalls.html ?

And why are you using 1.4.1, which is really old?

Furthermore, I wasn't the one offering to debug your lwipopts.h. Sending such a 
large file is not a common way to ask for help here. I would have expected the 
one asking you to send this to continue supporting you...

Regards,
Simon

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

Re: [lwip-users] Problems with a HTTP server - DHCP - etharp.c - v2.1.2

[Simon Goldschmidt]

stevestrong wrote:
> Just as final comment to close this issue:
> 
> In the new Version (2.x) the DHCP should not be stopped by the application
> (*do not call dhcp_stop()*), as the STM32 application does for v1.4, when an
> IP address has been assigned.

That has nothing to do with the new version: you should never stop DHCP when
using an address assigned by it! Maybe the old version had a bug that did not
delete the address when stopping the client...

> 
> So this is not a bug, it is a feature ;).
> 
> PS. I will not delete this topic, should serve as information for anyone
> else struggling with this.

How could you delete a topic from a mailing list? Mails are sent out, the
archive holds them.

> --
> Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

Oh, you're using nabble... :-(

Simon

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

Re: [lwip-users] Netconn write and non-blocking

[Simon Goldschmidt]

kncy9876 wrote:
> I am having this exact issue did you ever find the resolution

Which issue? Some context please. Not everyone is using nabble.


Simon

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

Re: [lwip-users] UDP and Raw API, lwip running with RTOS

[Simon Goldschmidt]

zulu4711 wrote:
> Simon,
> Sorry for that !
> My "everyday" reading of lwip topics is done on nabble, hence I did the
> question there.

There's no problem in using nabble, you just have to make sure the result
is readable by everyone reading the list, not only by nabble users.
If you want a response, that is... ;-)

> Anyway, here is the original question, Hope it is readable now.

Yes, it is readable now.

I think your example looks correct. You might want to try the new hook
LWIP_ASSERT_CORE_LOCKED() that checks for correct threading (added with
2.1.0).


Simon

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

Re: [lwip-users] UDP and Raw API, lwip running with RTOS

[Simon Goldschmidt]

zulu4711 wrote:
> Simon,
> I access it here:
> http://lwip.100.n7.nabble.com/UDP-and-Raw-API-lwip-running-with-RTOS-td33221.html

Ok, so you're using nabble. That's fine for you. I'm using this list. By now, 
you
may have noticed the difference ;-)

In other words, the formatting of your mail is still messed up. If you want
everyone being able to read your mails, not just nabble users, send correct 
mails.

Plus (and that goes for all nabble users): on mailing lists, you normally 
include
the text you reply to. In forums, you don't. That makes a difference regarding
readability and I quickly skip mails where I can't find the context fast 
enough...


Simon

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

Re: [lwip-users] UDP and Raw API, lwip running with RTOS

[Simon Goldschmidt]

zulu4711 wrote:
> I edited my post on the forum afterwards (as I also discovered that it was
> unreadable).

Which forum are you talking about? This is a mailing list and you cannot
edit mails after you have sent them.

> Anyway, I have included it here also, hope it works ?

I'm not sure I understand that.


Simon

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

Re: [lwip-users] Pbuf Assert

[Simon Goldschmidt]

Greenwood, Gregory A. wrote:
> I have stopped the problem but I am not sure of the root cause.
> It does not seem to have anything to do with LWIP itself.  I was
> using a utility feature supplied by STM that prints debug messages
> to the LCD screen on the evaluation board.  When I reduced the
> number of messages and text length, the Assert stopped occurring.

This top-posting somehow makes the whole thread unreadable...
 
> [..]
> I cannot figure out why I am getting an Assert in pbuf.c at line 747:
>   LWIP_ASSERT("pbuf_free: p->ref > 0", p->ref > 0);
> I know the obvious answer, in the p->ref cannot be 0.
> The problem is that I cannot tell what would cause p->ref to be 0.
> And this is occurring in a while loop that depends on p != NULL.
> I am using the LWIP that comes from CubeMX for STM32H7.
> LWIP version 2.0.3.

Either you're double-freeing a pbuf (like Patrick alread wrote). In
that case, the changed debug messages might just have changed the
runtime behaviour in a way that hides this bug.

Or you just might have a memory corruption issue where the debug
output code overwrites arbitrary memory.

In any case, this is not a bug in lwIP. Have you asked in ST specific
forums already?

I haven't yet found the time to test the new CubeMX release where
they finally managed to include 2.0.3, so I can't tell if it is
correct. But this is on my list... How did you create the project,
did you use an example project or a project completely generated by
CubeMX where you enabled the lwIP library?

Simon

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

Re: [lwip-users] LwIP RAW - Simultaneous (full-duplex) communication

[Simon Goldschmidt]

Nenad Pekez wrote:
> I took a look at this. This has been provided by Xilinx drivers already. 
> In their MAC receive handler they allocate memory for pbuf (call to 
> pbuf_realloc() actually) and enqueue it. In the main loop, I call Xilinx 
> function xemacif_input() which check if there is anything in the queue 
> and if there is netif->input() is called as described in the example.

And from which context are timers processed? If you don't have an OS, you
still have to ensure *not* to call into lwIP from an ISR.

> 
> What I also noticed, when Zynq->PC side becomes active, in the TCP recv 
> callback I get p->tot_len much larger than 1446, and from time to time 
> there is also a print "Receive over run" from MAC error handler.

With OOSEQ queueing enabled, you can get pbuf chains after some segments
were lost and retransmissions have been received. This is normal, but if
you encounter this unexpectedly, you could either just have buffer overruns
(i.e. processor is not fast enough, or not enough memory available) or
driver bugs.


Simon

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

Re: [lwip-users] LwIP RAW - Simultaneous (full-duplex) communication

[Simon Goldschmidt]

Nenad Pekez wrote:
> > Have you checked the stats if you run out of memory somewhere? 
> I have checked them, and there is certainly something wrong. After some 
> time, stats for memory seem to overflow, at least that's my impression.
> 
> At one point I have this:
> MEM HEAP
>      avail: 6
>      used: 13C40
>      max: 14340
>      err: 0
> 
> And next print (after 1 second):
>   MEM HEAP
>      avail: 6
>      used: FFFC6480
>      max: FFFC6A80
>      err: 5

That seems like a threading issue. Have you read this:

http://www.nongnu.org/lwip/2_0_x/pitfalls.html

> > Actually, I'm too lazy to check out myself what the images contain. 
> But not too lazy to write out that many sentences. :)

Not for every mail that leaves me with questions. For some though...

> A picture is worth a thousand words.

Well, certainly not this one!


Simon

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

Re: [lwip-users] lwIP RAW - Low throughput during first few seconds

[Simon Goldschmidt]

"Nenad Pekez" wrote:

> [..]
> This seems like drivers issue, doesn't it?

Yes, it does.

This is a Xilinx driver, right? Have you read this (also Xilinx):

http://lists.nongnu.org/archive/html/lwip-devel/2017-12/msg00070.html

There seem to be cache issues in that driver, maybe you have a similar problem.


Simon

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

Re: [lwip-users] PBUF_RAM allocation

[Simon Goldschmidt]

"Amena El Homsi" wrote:
> For PBUF_RAM type, LwIP mentions that "struct pbuf and its payload are
> allocated in one piece of contiguous memory (so the first payload byte
> can be calculated from struct pbuf)."
> 
> What If the pbuf structure is in place and the payload is in another
> place (non-contiguous)? Is there any issue if I allocate the pbuf structure
> from the pools and I set p->payload to point to the data in the frame memory?

Yes. The parts in lwIP that are coded with the above assumption will stop 
working
and you will get all kinds of bogus memory errors.
 
> [..]
> I updated pbuf_alloc(), when the type is PBUF_RAM, to allocate a pbuf stucture
> only from the lwIP pools, and calls the MMU to allocate memory to the frame,
> then I set p->payload to the frame pointer.

Why to people think the core files need modification? Why don't you indstead
search the list archive for people with similar problems?

Allocating a PBUF_REF or PBUF_ROM is what you want. PBUF_RAM allocates heap 
memory.

Simon

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

Re: [lwip-users] How to limit the UDP Rx packet size to avoid big RAM allocations

[Simon Goldschmidt]

"R. Diez"  wrote:
> This time it worked. I guess you used an e-mail program instead of a web 
> mailer. I suggest that you always do that if you can.

You guessed wrong. I manually added you CC. And thanks for the suggestion, but 
I think I can decide for myself which mail client I use ;-)

> > Why don't you instead change your subscription settings
> > to get the mails? > In the admin interface, I see you disabled getting
> > mails from the list...
> 
> lwIP is just one of the many components I use. If I had to subscribe to 
> all the mailing lists whenever I post a question, I would get too many 
> e-mails. I wish I had the time to participate more in many of those 
> projects.
> 
> Is there a way to tell the mailing list server to only get e-mails with 
> same subject (same thread) of the question you posted?

None that I know of. If you manage to send your mails in a way that hitting 
"response" is enough for everyone for you (or the list) to be CC'ed, that's 
fine. I'm afraid I don't know how to help you there, though, sorry.

Maybe you can ask one of the savannah or nongnu hackers for help, which 
maintain the servers/mailers.


Simon

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

Re: [lwip-users] How to limit the UDP Rx packet size to avoid big RAM allocations

[Simon Goldschmidt]

I've manually added your mail as CC, please still fix your subscription.

"R. Diez" 
>  > That's why we have IP_REASS_MAX_PBUFS.
> 
> That does not really help, because it is a counter, and not a limit on 
> the number of allocated bytes. That distinction is important in my 
> resource-constrained environment.

It does. Input pbufs are PBUF_POOL pbufs which consume a constant memory size.

>  > Yes. The MTU has nothing to do with the size of
>  > the packets you want to receive. That's why we have
>  > fragmentation and reassembly.
> 
> There is a relation. Nobody sends huge UDP packets, because they tend to 
> get dropped.

That's your assumption. In that case, you even might want to disable reassembly 
without facing a problem (although I wouldn't suggest that).

The problem I see is: how do you know the reassembled size in advance?

Simon

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

Re: [lwip-users] How to limit the UDP Rx packet size to avoid big RAM allocations

[Simon Goldschmidt]

"R. Diez"  wrote:
>  > I found it awkward to answer, because I did not get
>  > any e-mails from the mailing list on this subject.
>  > I had to manually check the mailing list archive to see your messages.
> 
> Regarding my previous comment above, I wonder if you could change the 
> way you send e-mails, so that I do get direct e-mails too, like on most 
> other mailing lists.

The nongnu lists somehow don't work that way. Reply-to always replies to the 
list. E.g. in my web mailer theres nothing I can configure to change that.

Why don't you instead change your subscription settings to get the mails? In 
the admin interface, I see you disabled getting mails from the list...

Simon

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

Re: [lwip-users] [lwip-devel] lwIP 2.1 cleanup - remove UNIX test apps

[Simon Goldschmidt]

Dirk Ziegelmeier wrote:
> Hello all,
> 
> in order to clean up for lwIP 2.1, I'd like to remove the UNIX port test 
> applications
> 
> - lib
> - minimal
> - unixsim
> 
> The only remaining test/debug app would be the new "example_app" that shares 
> most of the code with the windows port.
> We would then have only one common app shared between windows and unix port 
> to reduce maintenance effort.

Does that mean only 'tapif' is used/compiled/supported under unix now?
What happens to the other, now unused netifs?


Simon

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

Re: [lwip-users] LwIP with SSH

[Simon Goldschmidt]

Elinux wrote:
> >" lwIP does neither provide a shell nor the protocols required for ssh. 
> >I suggest taking a look at mbedtls and using sockets to use mbedtls on top 
> >of lwIP. "  
> 
> what do you mean by his?
> If we implement the tls.mbed sockets over LwIP with sockets, does that mean
> we can add the SSH protocol to LwIP using sockets?

What's the idea. I don't know how to implement an ssh server, but using lwIP
sockets, it should somehow work. I just wanted to say ssh won't be a part of
lwIP.

Simon

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

Re: [lwip-users] LwIP with SSH

[Simon Goldschmidt]

Elinux wrote:
> Knowing that I work with a *STM32* Cortex-M microcontroller by programming
> with Workbenche (Eclipse) under wndows, I would like to know if we could
> implement and add the *SSH* protocol to the *LwIP stack* ?

lwIP does neither provide a shell nor the protocols required for ssh.
I suggest taking a look at mbedtls and using sockets to use mbedtls on top
of lwIP.

Simon

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

Re: [lwip-users] Re-Transmission from PC is ignored due to sequence number

[Simon Goldschmidt]

Daniel L wrote:
> [..]
> However, the overall behaviour still looks weird.
> Wireshark now reports "Spurious Retransmissions" because lwip retransmittes
> a frame which was correctly acknowledged by PC.

That could well be because you changed TCP_TMR_INTERVAL. Don't do that!

> Attached file shows the behaviour.
> 
> Our setup is now:
> NO_SYS = 1
> TCP_TMR_INTERVAL = 10  (I don't get the idea of this define...)

Then don't change it. It's not supposed to be changed. If it was, it would
be in opt.h, not in tcp_priv.h!

If guess you want to have faster retransmission, but messing with TCP is
not the correct way to achieve that.

> sys_check_timeouts() is called every 10ms (according to google search,
> sys_check_timeouts() should be called instead of tcp_tmr(), right?)

Right.


Simon

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

Re: [lwip-users] BSD 4-clause in some of lwIPs files

[Simon Goldschmidt]

Wolf Heidrich wrote:
> we noticed that there are some source files that have a BSD 4-clause licence 
> in them, e.g., in src\include\netif\ppp_oe.h it says after the BSD 3-clause 
> header: 
> /* based on NetBSD: if_pppoe.c,v 1.64 2006/01/31 23:50:15 martin Exp */
> 
> 
> 
> Question: Do we have to abide by that BSD 4-clause as well? If so, is there a 
> version that does not include the BSD 4-clause licence?

This should only be the case in the PPP sources. That is because
they were copied from pppd (ppp.samba.org) and of course we cannot
change their license. This should cover files under 'src/netif/ppp'
and 'src/include/netif/ppp'.

As long as you don't use PPP, you could just remove the files from
your copy and be fine.


Simon

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

Re: [lwip-users] Re-Transmission from PC is ignored due to sequence number

[Simon Goldschmidt]

Patrick Klos wrote:
> > [..]
> > Is lwip acting correct?
> 
> Based on your description, yes, LwIP is acting properly.  You need to 
> find out why the payload packet isn't making it to the PC?  How big is 
> the payload packet?  Can you share a file with the packets from Wireshark?
> 
> > Are there possibilities to handle this problem?
> 
> First let's figure out where the payload packet went.  Maybe you can add 
> debug output in your ethernet output routine?

No, testing retransmission works is really fine for product development :-)

Let's instead start with explaining *why* lwIP is acting properly:
TCP is a "reliable stream" protocol. All bytes have a sequence number at
transmission. Delivering the retransmitted bytes again to the application
would double them (there's no information about the sequence numbers in the
application API).

Being like that, lwIP is only saying: "it's OK, I already got those bytes"
by sending its empty ACK.

How come your PC retransmits with the same sequence number after 300ms? The
Modbus implementations I know are retransmitting the application data (i.e.
Modbus frame), not the TCP seqnos.

Simon

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

Re: [lwip-users] Help debugging IPv6 SLAAC

[Simon Goldschmidt]

thomasfogh  wrote:
> LWIP_IPV6_MLD is enabled and I got a bit further be setting the
> NETIF_FLAG_MLD flag.
> How do I join the allnodes group?

Try setting LWIP_IPV6_MLD to 0. I was remembering incorrectly, it was
the solicited node group, not the allnodes group. This should be joined
automatically (from reading the code), but somehow that did not happen
at least in my 6lowpan tests...

The allnodes group does not have to be joined but your mac driver needs
to deliver those frames to the stack. So your mac RX filter might need
to be adjusted to let these frames through. Standard behavior of many
macs is to only receive their own address and broadcasts...

Simon

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

Re: [lwip-users] Thread safety of socket API

[Simon Goldschmidt]

Sam Kearney wrote:
> I have a question about the thread-safety of the socket API, specifically with
> regard to recvfrom() and close(). I am using lwIP 2.0.2, ported for FreeRTOS
> and ARM Cortex M4.

What you're trying to do does not (yet) work. First, you need to enable
LWIP_NETCONN_FULLDUPLEX in your lwipopts.h, but then asynchronously closing a 
socket
while another thread is waiting for RX still does not work.

I'm at it though, check for bug #52554, which should be closed in some days (or
weeks, or months):
https://savannah.nongnu.org/bugs/?52554

Chances are high that this will work with 2.1.0, which should not be too far 
away.


Simon

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

Re: [lwip-users] help with mDNS sending a DNS_RRTYPE_SRV query

[Simon Goldschmidt]

antonio wrote:
> The problem is the function that requires recursion (*mdns_readname*). The
> error is related to */Stack Overflow/.. *

So this is not related to threads? Then please describe the actual problem you 
see.
I'm getting lost in all the other things you write...

Simon

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

Re: [lwip-users] Slow HTTP put request

[Simon Goldschmidt]

joc...@strohbeck.net wrote:
> [..]
> Regarding the expect/continue overhead, according to wireshark trace 
> below it is about 30ms extra - way to much for what I intended to use 
> PUT (write a couple of bytes to twi interface).

Speaking of that, why do you use PUT anyway? I would have used POST to
implement what you seem to do. PUT seems rather "unusual" to me...

> [..]
> I always thought there is a mechanism to tell the client that my server 
> supports HTTP 1.0 only and this should prevent the client from asking me 
> things I do no support. Am I wrong ?

I don't know how that client knows about the version of the remote server.
It can issue a first request to get the server's version, but that seems
rather unusual, too. And from your traces, that doesn't happen...

But you can try to just make the server report "HTTP/1.0" in every response
instead of "HTTP/1.1" and see what happens...

Simon

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

Re: [lwip-users] Slow HTTP put request

[Simon Goldschmidt]

joc...@strohbeck.net wrote:
> I see the following solution:
> - server sends reply to expect/continue and then... well, frankly don't 
> know exactly what happens then and how much overhead this means
> [..]

I see 2 solutions: implement a HTTP 1.1 server that keeps to the
specification (I'll have to do that for the lwIP httpd, too) or implement
a HTTP 1.0 server that keeps to the 1.0 specification (in which case the
client should not depend on the Expect header, I guess).

Simon

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

Re: [lwip-users] MEM_SIZE

[Simon Goldschmidt]

Giuseppe Modugno wrote:
> [..]
> I think with the following options:
> 
> #define MEM_LIBC_MALLOC  0
> #define MEM_USE_POOLS  1
> #define MEM_USE_CUSTOM_POOLS 1  /* Needed by MEM_USE_POOLS */

It's MEMP_USE_CUSTOM_POOLS, not MEM_USE_CUSTOM_POOLS. And it compiles for me,
see the win32 port for an example.

Simon

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

Re: [lwip-users] MEM_SIZE

[Simon Goldschmidt]

Giuseppe Modugno wrote:
> [..]
> In my case, I have a completely free (not used by the linker) 32kB RAM 
> region starting from 0x2007C000. To instruct lwip to use that region for 
> heap, I think I have to define:
> 
> #define MEM_SIZE  (32 * 1024 - 1 * SIZEOF_STRUCT_MEM)
> #define LWIP_RAM_HEAP_POINTER ( (void *)0x2007C000 )
> 
> Supposing we don't need other additional space for alignment.
> In this case the total free heap memory available for data is exactly 
> MEM_SIZE, that is less than 32kB.
> 
> Is it correct?

I think so, yes. However, your definition of MEM_SIZE won't compile outside
of mem.c. Maybe it would be better to rework the code to use MEM_SIZE as
size of the available block, at least if an external block is used...

Simon

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