From MAILER-DAEMON Wed Feb 01 17:19:02 2023 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1pNLRW-00026E-Ni for mharc-lwip-users@gnu.org; Wed, 01 Feb 2023 17:19:02 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pNLJC-0000ZF-CZ for lwip-users@nongnu.org; Wed, 01 Feb 2023 17:10:26 -0500 Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pNLJA-0007Lo-Jc for lwip-users@nongnu.org; Wed, 01 Feb 2023 17:10:26 -0500 Received: by mail-ej1-x62f.google.com with SMTP id gr7so727845ejb.5 for ; Wed, 01 Feb 2023 14:10:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=cKT6inTGkXCeKVIZpob4LxKmaHdZSZXY0SKEivXXWbQ=; b=XxhJGp5BITmVEnmyaAMScJmnS4TuDOgyiUQRAWMMSAUJd82Om3KrTRR/o+M1IRsEYH qYLJ16QRVBWbM0Hl2+nveQ52dbfFDU1Pw6i6pukPMLZzOoB14//t11Ocg5YEjE/e4UR6 eN0TzbfmYLBjsmdjWIKo+vHVK6SVnyFl19nuWARekl8D4vchyTmUEU4vVHRNUsAlgO6U 8Gze7Q9XHQk7SFhgJhqXeUsrsyIw+ZLA//ox97k4ZV4fT9LeT37qc6HynPgZtbs3UuG8 dyRLQ8fKsrKSqIJ5DvysbXfrAaz1TaV7uAcmQdtEX1LKyQerw3nX9szz2m+aZe2otBiW 5wYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=cKT6inTGkXCeKVIZpob4LxKmaHdZSZXY0SKEivXXWbQ=; b=lQTr/aOeKblsl1ZljU/OHVHMKNjMbansx2EBi9vsk26C4oxWJpUPgPYZNpBrdh8WeZ CZwemdV8uOHmxzC4JWI8zpG2oDYNznKH5AKL+u1ejC2GPtT9Njoj0mY+xk1S782eIRmq LzjhKgSFnm8zIW2eQhHcqdnRPWtMyOwPK+HOiSuy+dmsAgQkRSG8vVcFRLcyMrtadM/G ftV8fkyFPtQvk5nEjSk5rAV4i8dBadr09asbKKNPRj59bHwmqTitLGioL6+okNNPP/Df 6NsB7TAIOPZKmaDCVFzmc6JHeuzBuss8RzTuxrykYS+WXWtNC4OdLjjhtMQ5zUhOfrgl E73A== X-Gm-Message-State: AO0yUKXuRET3lXqrlOgzi0wCeKGmOjS9mF7YxC8J5VeVtdw1rGNBX2Nc hR0wkjMN7quxWLUzrva5QZc9mAh7/iVVUURIWTcR+G+C8so= X-Google-Smtp-Source: AK7set867evc6TOxMgcNluLrWM4PwA1MJ4p8iihdxMeYWD9luqnV8vG4xrDASMbyJz7nIdoBWa5zYcUX9Dh2hD7Gze4= X-Received: by 2002:a17:906:1155:b0:882:c2dd:f29e with SMTP id i21-20020a170906115500b00882c2ddf29emr1333386eja.268.1675289422061; Wed, 01 Feb 2023 14:10:22 -0800 (PST) MIME-Version: 1.0 From: Dan Nygren Date: Wed, 1 Feb 2023 14:10:10 -0800 Message-ID: To: lwip-users@nongnu.org Content-Type: multipart/alternative; boundary="000000000000e602fb05f3aab619" Received-SPF: pass client-ip=2a00:1450:4864:20::62f; envelope-from=dan.nygren@gmail.com; helo=mail-ej1-x62f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 01 Feb 2023 17:19:00 -0500 Subject: [lwip-users] lwIP UDP echo server fails to send message lengths of 4385 & 4386 X-BeenThere: lwip-users@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for lwIP users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2023 22:10:27 -0000 --000000000000e602fb05f3aab619 Content-Type: text/plain; charset="UTF-8" Hello fellow lwIP users. Can anyone point me in the right direction on how to resolve or report to the right folks the below issue? I'm seeing rather bizarre behavior in that messages of length 4385 and 4386 I send to a lwIP based UDP echo server are not received back. udp_sendto() appears to be getting called and completing successfully. Wireshark indicates there are "bogus, payload length" errors with these lengths. I have a detailed write up showing the behavior here: https://github.com/Xilinx/embeddedsw/issues/212 I can copy the info above into an email for this mailing list if you prefer. Let me know your suggestions on how to proceed. ... Dan Nygren , --000000000000e602fb05f3aab619 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello fellow lwIP users. Can anyone point = me in the right direction on how to resolve or report to the right folks th= e below issue?

I'm seeing rather bizarre b= ehavior in that messages of length 4385 and 4386 I send to a lwIP based UDP= echo server are not received back. udp_sendto() appears to be getting call= ed and completing successfully. Wireshark indicates there are "bogus, = payload length" errors with these lengths.

I = have a detailed write up showing the behavior here:

I can copy the info above into = an email for this mailing list if you prefer.

= Let me know your suggestions on how to proceed. ... =C2=A0 Dan Nygren
=

,
--000000000000e602fb05f3aab619-- From MAILER-DAEMON Thu Feb 02 12:26:19 2023 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1pNdLm-0003ll-Sw for mharc-lwip-users@gnu.org; Thu, 02 Feb 2023 12:26:19 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pNdLl-0003lK-6y for lwip-users@nongnu.org; Thu, 02 Feb 2023 12:26:17 -0500 Received: from outmail149061.authsmtp.co.uk ([62.13.149.61]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pNdLi-0005LX-J7 for lwip-users@nongnu.org; Thu, 02 Feb 2023 12:26:16 -0500 Received: from mail-c245.authsmtp.com (mail-c245.authsmtp.com [62.13.128.245]) by punt20.authsmtp.com. (8.15.2/8.15.2) with ESMTP id 312HQ7wc006907; Thu, 2 Feb 2023 17:26:07 GMT (envelope-from peter@peter2000.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peter2000.co.uk; s=authsmtp; t=1675358767; bh=ujM13o7gjjF57lcPpxm2qvFX7dacFbHaX7ONxJvB218=; h=Date:From:To:Subject; b=P3zSueynOGLv8GdgiVa6y5JrNwOI3aJkI1nZly/qPTQjH9erVRETFVt9G3i2siWHj zD8UGS4FNBX0NlOA7fshVyb9Gr66JxlwMlFMy5x92wapuOgqZIbduTZE6ujc2jplcD KX8ROQJG41y7bT5zhPkhG/Q5c0wEBtpEmyxHW+Sw= Received: from KK-PH (238.14.187.81.in-addr.arpa [81.187.14.238]) (authenticated bits=0) by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPA id 312HQ7S7051390; Thu, 2 Feb 2023 17:26:07 GMT (envelope-from peter@peter2000.co.uk) Message-Id: <202302021726.312HQ7S7051390@mail.authsmtp.com> From: Peter To: lwip-users@nongnu.org Date: Thu, 02 Feb 2023 17:26:09 +0000 References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Server-Quench: ad736972-a31e-11ed-9114-7cd30ad787f4 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd0ZA4dC1ZNQRgX EAscATNNU199fkUK ChhFMAhMJUcNSQVJ NksadBtFaAdba1xT HGQLWVdEUVp7W2V/ aw0fZQRDY0JJQQRu TkpKSk1QERpoTx8A BGZ/VXp1dwBHe3dw K0NlWXAVDRB9dkB0 RUxJRG4HMHphaTVL TUlZdgdJd1AefR8U Pld3UyUJLw5bISMg WhIoMioqCH1bNwVt CjwhFRofSkYMViUx XQ4PB30hFEwBXG0v KFQ9J1gQVEMcKV47 PlZpXV8ePAMSEUVZ EQkRW38EbxdJG3F7 U2sA X-Authentic-SMTP: 61633734363838.1039:8335 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 81.187.14.238/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. Received-SPF: pass client-ip=62.13.149.61; envelope-from=peter@peter2000.co.uk; helo=outmail149061.authsmtp.co.uk X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action Subject: [lwip-users] lwIP UDP echo server fails to send message lengths of 4385 & 4386 X-BeenThere: lwip-users@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for lwIP users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2023 17:26:17 -0000 4385/4386 could be 3x MTU ? Not a lot surprises me, after spending many days on this https://www.eevblog.com/forum/microcontrollers/anyone-here-familiar-with-= lwip/msg4660942/#msg4660942 Peter >Send lwip-users mailing list submissions to > lwip-users@nongnu.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.nongnu.org/mailman/listinfo/lwip-users >or, via email, send a message with subject or body 'help' to > lwip-users-request@nongnu.org > >You can reach the person managing the list at > lwip-users-owner@nongnu.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of lwip-users digest..." > > >Today's Topics: > > 1. lwIP UDP echo server fails to send message lengths of 4385 & > 4386 (Dan Nygren) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Wed, 1 Feb 2023 14:10:10 -0800 >From: Dan Nygren >To: lwip-users@nongnu.org >Subject: [lwip-users] lwIP UDP echo server fails to send message > lengths of 4385 & 4386 >Message-ID: > >Content-Type: text/plain; charset=3D"utf-8" > >Hello fellow lwIP users. Can anyone point me in the right direction on = how >to resolve or report to the right folks the below issue? > >I'm seeing rather bizarre behavior in that messages of length 4385 and = 4386 >I send to a lwIP based UDP echo server are not received back. = udp_sendto() >appears to be getting called and completing successfully. Wireshark >indicates there are "bogus, payload length" errors with these lengths. > >I have a detailed write up showing the behavior here: >https://github.com/Xilinx/embeddedsw/issues/212 > >I can copy the info above into an email for this mailing list if you = prefer. > >Let me know your suggestions on how to proceed. ... Dan Nygren > >, >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: = > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >lwip-users mailing list >lwip-users@nongnu.org >https://lists.nongnu.org/mailman/listinfo/lwip-users > > >------------------------------ > >End of lwip-users Digest, Vol 234, Issue 1 >****************************************** From MAILER-DAEMON Fri Feb 03 16:25:05 2023 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1pO3YP-0006tX-D2 for mharc-lwip-users@gnu.org; Fri, 03 Feb 2023 16:25:05 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pO3YO-0006tO-ME for lwip-users@nongnu.org; Fri, 03 Feb 2023 16:25:04 -0500 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pO3YM-0008Am-Rm for lwip-users@nongnu.org; Fri, 03 Feb 2023 16:25:04 -0500 Received: by mail-ej1-x634.google.com with SMTP id k4so18955999eje.1 for ; Fri, 03 Feb 2023 13:25:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=aeBqNbGxTaeDXgH2DChaaR3/e5Vo/E7g10NKvDMAyy8=; b=U2xhXY6Nw8JLk2T9XGtHDm+vSRiugscUVdrQI6/PqgVfcaenf1f0vaJkZzqip2hkSm nE7/DLXVQLOJXnR43pWoyqSiRPBCHv4v26zv2lXrBOvU7Er6HMm2r1S5pK589OkB+8se 5McvlkmxfdADMLz3Gdfdrs108r9IdNQXheRdRl/Zri3LBW6pnnTXBccXz7cDrDxnh7zQ 2MxLFlf5lXUyqkCcC2djE9g6eyOJppkiVh5fGsfQVAlKfw5+jZcThdm5lHXLZeHJYCiK pLOEqUgqCKAhLdc5LK+Fxc0xJxUPLlHYUP1EM5n6zzs2u1ldHRNuqxsUnTX3KVuo2DlJ tpsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aeBqNbGxTaeDXgH2DChaaR3/e5Vo/E7g10NKvDMAyy8=; b=kHCswu/bm9uzSytNOoiG4SH9BkFVAYZyPWb9Al8j+myBtj6yaEAGS53PtP9fyCOrEt OkPpQpZ5NZgWsrqCP6O4XyOJnD+Fx/fNPZvuMl/wnBevjjsAaqi38BAQdnNe97jsui8L 8jZWIltOGPpeuQ4kil8b1et0Z99D3y7AQERX/+7B3SgJQelbAG9mojdl4B5OY0ep9mCK sbjx2ldIPep80yZHsGjI6rC+PNQmafoey00oxWIhf6LR9yTmToUNeIWb0endynqvle4s IcuzReG1WpOk6W+nstdRtlONrtxPBqv4AJZ9Tu73brQRrNW2kLkw+4JZI7O9eJWYh6rY NDGg== X-Gm-Message-State: AO0yUKVq86hqFp85lDWXcc7lK/9sjmfiBdz2IcoVHDl57yFipjPogiqC owcRG/z39DK3l0qPvjPx1xpcn4yzPog+KUb++cD+WMXo4Og= X-Google-Smtp-Source: AK7set9qDFODY/HS+T5k/wEbU27lm8kXA++uNzheNLTWP1RRiVGKxJDLRK7KJSBhc09WJvmH1kLeMYHjBw1B7c6NUwY= X-Received: by 2002:a17:906:80d1:b0:87b:da77:ffce with SMTP id a17-20020a17090680d100b0087bda77ffcemr3515011ejx.217.1675459500071; Fri, 03 Feb 2023 13:25:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dan Nygren Date: Fri, 3 Feb 2023 13:24:48 -0800 Message-ID: To: lwip-users@nongnu.org Content-Type: multipart/alternative; boundary="000000000000565ea905f3d25090" Received-SPF: pass client-ip=2a00:1450:4864:20::634; envelope-from=dan.nygren@gmail.com; helo=mail-ej1-x634.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action Subject: Re: [lwip-users] lwIP UDP echo server fails to send message lengths of 4385 & 4386 X-BeenThere: lwip-users@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for lwIP users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2023 21:25:04 -0000 --000000000000565ea905f3d25090 Content-Type: text/plain; charset="UTF-8" Peter wrote: > 4385/4386 could be 3x MTU ? ... Peter, thanks for responding! Yes, it seems like I've hit some corner case. Is this the right place to notify the lwIP maintainers of problems? This is not a current problem for me as my messages are under the MTU size. I just hit this while developing some diagnostics for my board and I wanted to let others know about it. Dan , On Wed, Feb 1, 2023 at 2:10 PM Dan Nygren wrote: > Hello fellow lwIP users. Can anyone point me in the right direction on how > to resolve or report to the right folks the below issue? > > I'm seeing rather bizarre behavior in that messages of length 4385 and > 4386 I send to a lwIP based UDP echo server are not received back. > udp_sendto() appears to be getting called and completing successfully. > Wireshark indicates there are "bogus, payload length" errors with these > lengths. > > I have a detailed write up showing the behavior here: > https://github.com/Xilinx/embeddedsw/issues/212 > > I can copy the info above into an email for this mailing list if you > prefer. > > Let me know your suggestions on how to proceed. ... Dan Nygren > > , > --000000000000565ea905f3d25090 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Peter wrote:

> 4385/4386 = could be 3x MTU ? ...

Peter, thanks for responding= !
Yes, it seems like I've hit some corner case.
Is this the right place to notify the lwIP maintainers of proble= ms? This is not a current problem for me as my messages are under the MTU s= ize. I just hit this while developing some diagnostics for my board and I w= anted to let others know about it.

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Dan
,
On Wed, Feb 1, 2023 at 2:10 PM Dan Nygren <dan.nygren@gmail.com> wrote:
=
Hello fellow lwIP users. Can anyone point me in the right direct= ion on how to resolve or report to the right folks the below issue?

I'm seeing rather bizarre behavior in that messag= es of length 4385 and 4386 I send to a lwIP based UDP echo server are not r= eceived back. udp_sendto() appears to be getting called and completing succ= essfully. Wireshark indicates there are "bogus, payload length" e= rrors with these lengths.

I have a detailed write = up showing the behavior here:

I can copy the info above into an ema= il for this mailing list if you prefer.

Let me= know your suggestions on how to proceed. ... =C2=A0 Dan Nygren
<= br>
,
--000000000000565ea905f3d25090-- From MAILER-DAEMON Fri Feb 03 16:39:25 2023 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1pO3mH-0004M7-Nd for mharc-lwip-users@gnu.org; Fri, 03 Feb 2023 16:39:25 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pO3mF-0004KH-9g for lwip-users@nongnu.org; Fri, 03 Feb 2023 16:39:23 -0500 Received: from atreides.gradator.net ([212.85.155.42]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pO3mD-0002M5-Ew for lwip-users@nongnu.org; Fri, 03 Feb 2023 16:39:23 -0500 Received: from gradator by atreides.gradator.net with local (Exim 4.84_2) (envelope-from ) id 1pO3m7-0004ZU-7w for lwip-users@nongnu.org; Fri, 03 Feb 2023 22:39:15 +0100 Date: Fri, 3 Feb 2023 22:39:15 +0100 From: Sylvain Rochet To: Mailing list for lwIP users Message-ID: <20230203213915.GA17368@gradator.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gradator@atreides.gradator.net X-SA-Exim-Version: 4.2.1 (built Thu, 09 Jan 2020 16:15:24 +0000) X-SA-Exim-Scanned: Yes (on atreides.gradator.net) Received-SPF: none client-ip=212.85.155.42; envelope-from=gradator@atreides.gradator.net; helo=atreides.gradator.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action Subject: Re: [lwip-users] lwIP UDP echo server fails to send message lengths of 4385 & 4386 X-BeenThere: lwip-users@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for lwIP users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2023 21:39:23 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Feb 03, 2023 at 01:24:48PM -0800, Dan Nygren wrote: > Peter wrote: >=20 > > 4385/4386 could be 3x MTU ? ... >=20 > Peter, thanks for responding! > Yes, it seems like I've hit some corner case. > Is this the right place to notify the lwIP maintainers of problems? This = is > not a current problem for me as my messages are under the MTU size. I just > hit this while developing some diagnostics for my board and I wanted to l= et > others know about it. This kind of issues set all red lights to full brightness about a low=20 level driver issue or a buggy MAC offloader on fragmented IP packets. Anyway, basic rule about using fragmented IP packets: avoid (to not say=20 don't). Sylvain --DocE+STaALJfprDB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAmPdfwMACgkQDFub3qtEsS+VQgCfXe9Yk2Jwu7Ii9eDnDZshrg3R WU4AoLX3/pmbenlLMv1hYzp2YVzlSr5e =s2z/ -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- From MAILER-DAEMON Fri Feb 03 16:55:27 2023 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1pO41n-0001Nu-QP for mharc-lwip-users@gnu.org; Fri, 03 Feb 2023 16:55:27 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pO41k-0001Ml-TI for lwip-users@nongnu.org; Fri, 03 Feb 2023 16:55:25 -0500 Received: from mail-dm6nam04on2081.outbound.protection.outlook.com ([40.107.102.81] helo=NAM04-DM6-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pO41i-0006jC-Iw for lwip-users@nongnu.org; Fri, 03 Feb 2023 16:55:24 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GAFiTStlVd+8qK8EEltQh5doPBaU2M+nHSPtHXxs922kZuF+hsVZZy5JLS3HhXFbwH3PoLDFQVM9slC0OEZGytMvatPl/pW/ay6pZhiYJAts/Ag+YPh+y962nh6OjPFVkyvW23LSeNXmXOO8tmsehL1dG48WcgsLTLUjbrxKhoRTL0VrgiA6HbUQKGOBm3H/FP6KQy/UpdD3E3FNpoCZIIdz4nziMbAtSqDXC1oGCrC/2jmZpSSVDHqD+KdsJR983iatutZqPXXU6d0ZEh6L6AX1uzhZ4Oc96p2mdDI1bOuEptizt/Zmjzitv/2yLPOYoJu2e7SLp6el1XD5dwJLXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fdwCJe1qatCFyVuxT2RH/qj/8A/RLl4lsHRnprINuGI=; b=SAPHjAlkyP1bRxUKpnluBtKvGi/PpOe08tp+cAHVPX1nlhEG/KRXknYsE8p0Kz+6qKGeIa3nMNLPvALvzisUKL+SOPYDaAzmsCzO24V/BOd9R8uzO9CjSBtPCgzMDTeh6+gCbDlMYFS5iZWOMERYtHA/4DkHtzIXx3grPppg/cmjCPhB7gCa1YHXW2S5dxzGdG+47lAadAboURG1DKb6jM1tVd4ZQG2AB3ZSAk9Ri4k8HJsrizlQC53nih+Xh96fRDDY/19r89fxHOvwRy4i+WKiAupZkI8COhdyovXXlpL4IsX2fZLlTs9jLyvmfYcKjzUwy26ygE/Znxh8W0SC+A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=invue.com; dmarc=pass action=none header.from=invue.com; dkim=pass header.d=invue.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=invuesecurity.onmicrosoft.com; s=selector2-invuesecurity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fdwCJe1qatCFyVuxT2RH/qj/8A/RLl4lsHRnprINuGI=; b=tNRRc2SjxfbI0iE9Q2oA5vE5tLNTgyu03aujM/2JrnQ3xpG8r6ulHgyZfTY5Dg5eQhDZTuWplDa4Nm32azS4LsqJKef1kpEmkO2dfx+lLeigPZgARwjYL0FDGEBnCy73w54xACmrfu/sWsqoUPEGB+fvSwIAzj5/g7GjOUcvJsA= Received: from BN8PR03MB4610.namprd03.prod.outlook.com (2603:10b6:408:9e::13) by PH0PR03MB5816.namprd03.prod.outlook.com (2603:10b6:510:34::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6064.25; Fri, 3 Feb 2023 21:50:17 +0000 Received: from BN8PR03MB4610.namprd03.prod.outlook.com ([fe80::2022:6cb4:919a:2a0]) by BN8PR03MB4610.namprd03.prod.outlook.com ([fe80::2022:6cb4:919a:2a0%7]) with mapi id 15.20.6064.027; Fri, 3 Feb 2023 21:50:17 +0000 From: "Thompson, Jeff" To: "lwip-users@nongnu.org" Thread-Topic: lwIP deInit Thread-Index: Adk4GKqy7DZ3u9KlS2CGlMBLHAfXZg== Date: Fri, 3 Feb 2023 21:49:49 +0000 Deferred-Delivery: Fri, 3 Feb 2023 21:49:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=invue.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BN8PR03MB4610:EE_|PH0PR03MB5816:EE_ x-ms-office365-filtering-correlation-id: 1029d41e-f03b-4dde-a910-08db0630a34a x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CEtGQX56DZg5JKrSDVbUqhs+YEpB8KUWPdc5hg4V6WW20AT38Z/0W4cJbp38iNoN74uke37Qgq/eG71CMOUAQO3/L5yIeidB3b1nuJftVkmcthempuixYSVe5TDBo85nejeA/DDMuORWL84rF9EArfvKtiDcxgg2Yg0zv8tE5DUM7o6bncQ8SlTQusoFfUPM5TF4s95rZaHjwS2nyiRqmycNNrOS/8gHiunufOnjXVceCcn6jwkBBs4D5emXo4AImfNRkG+Ra2TTYTsxFVukUYg4olrsjOk/YfSJzzEe7gvHCofmGg0Zg5BOgfl2R94lkNAA+JGIJrRdPexLemJPj79cUtHyvBaUxUgpJgaxZvok/6VdiSL5cwt46uK3Vx/0MOzCt5nHWRfcR8MAHO2hhY9cnRoaDDBM3QGPXxmmTvxbiFnjZ+ETXZQsnfmkYTOgjrLvHP4TRcf3cv6yUnfgNEdt2H5AGx3TGiG3SgwHb4mOXOksqOSIy+FubGXg9CVrrprN+oe+lmivO5R7Da7sj/GmJV0nC7cAgtLeKxS0ncmvQmtOcKtHu8y1ve6TT/4+/DA7VuPhEAOMCjpoFwRDshSYJGpfAYonahir9JdjHYUHjSYPctts+dv+/y1L7WxeAYqU3nnA83npE56hTTEkboH1bJqRiawCWulpPcngPm6MNATtqeX5q7UVv/OIY4fMDSB7RRLB0k5iugcYf8gxSBezZAuHgnMf+ukktNQmqc8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR03MB4610.namprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(4636009)(346002)(136003)(366004)(39850400004)(396003)(376002)(451199018)(6666004)(3480700007)(316002)(2906002)(40140700001)(33656002)(71200400001)(38100700002)(26005)(122000001)(9686003)(7116003)(66446008)(64756008)(66556008)(66946007)(66476007)(76116006)(186003)(7696005)(478600001)(6506007)(55016003)(6916009)(41300700001)(99936003)(8936002)(8676002)(38070700005)(52536014)(86362001)(5660300002)(4744005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?4myas2EqQypPMXm4DWeMVov2DTl3Q6T/v2tfhOWBn1B0QqzigJh387UeFLpw?= =?us-ascii?Q?+TeSQjVZeS8XU7sBi02bvyaT5n4shtLcAdP+WQgN8bq5C5w90kxmHZiDOVfw?= =?us-ascii?Q?BWgXVgi7YibczFLFWf3PyklEmrrVahpW8WGn8QDamuI90X3j3aiyeN29N5Gs?= =?us-ascii?Q?fOAm7bzjSYm7OOhpJblJF85xYF/lIkXu9eieiRJcp60ztjvWkpj2YEHb41Bm?= =?us-ascii?Q?zNJjneXUWiOGQNzh/3yB+x+HA3cIZKlINyEDmXTG1SNgzfe5GA3tQdNfR5nc?= =?us-ascii?Q?7aJtvKgiXvfCLLLZCD7p1CiUC5FSSwnmb88QSV7NCD6iGgDEQd3Hq7YVd1vv?= =?us-ascii?Q?rNaln8VDjS/0IezJowF1EN156mt2oI3f2wTmkYN2ihSTNvAXJfjGLJCoW7Lm?= =?us-ascii?Q?C/DoIs9h/pu1oU1ymtN/DZr1Jid4VxRQJNENx//4dBYRF96UE2YSkj7eE6jw?= =?us-ascii?Q?tsckA1gVy1cnxqyJmpU0KGgKBEIOtBAuOR3uh5XSgh9Jz69yeq2GsxPc+HJX?= =?us-ascii?Q?Aq0zrw2Y66m2V1eiCz5r8tX0nHEaxI5773GesbSuWRastPitqqznzaJbvAAu?= =?us-ascii?Q?lLR7LpTuHx/5HGA8tfBOUNKSLu0+ZH42ZGDhSz45sFSJmpHmq4b3VbTAYQxh?= =?us-ascii?Q?gBG49MIr1bGTz8Qau1HuFfVICF6YPi6xQQ4wPbzSi9P+SbBpg2ISjNHQOlSh?= =?us-ascii?Q?5yB7+RsTJj4+wcR2IXoZmxj+AdXlDV0LUIzeRe/pA0T1gNLTlH/xERQmiTpd?= =?us-ascii?Q?B0Pttvi4YSKYhqWUBcqQsg6tB8taRVsj7kEWl6psJnzbgaYZKdWMFyYjn9tf?= =?us-ascii?Q?CD7O8DmkAkHQFYYGQlvkOdz8EYywD2CmA7S970mp2m5icmsYUspBJGynZPoi?= =?us-ascii?Q?zkYuTbRLJxD4TAVQwAMmLLEYLhtXmdTLdbpoEn8/nVe82s4IldnkhkAOjNLw?= =?us-ascii?Q?hj4014Y0NWjr3M4x1MT56bXn2Vp+vCj/OM1py3WKJ8VhmZ1xwcX6DcC67MZs?= =?us-ascii?Q?NEwysgEJfPwduKP0QtVg6xqiTJT/VjBLo2wNhqfI5BgKSqVeWYfEU8e4mDk+?= =?us-ascii?Q?8+RAsSmqvk3j+vkC8o34GvHV+WJBOG0Q7OMGsvQ1E8qJ4fHsLHIXkrhqRCs1?= =?us-ascii?Q?5MnKZbo6TQB5xKbwL0p/OEaXCwLEuhfg7WWK9iw8xXjna6Pfak9MU8N6eFbC?= =?us-ascii?Q?5Dpg8QqXa2kH4o6jI6dmC2yD43yn+XfvbJI+AAG4TJxzHjJcFi0+RvPuLzQN?= =?us-ascii?Q?lfPOf/dDicY9UkS0YdQP5lR8pLpx8Exo6zknmCvBNfoVxaUpPX9HMHbLg82s?= =?us-ascii?Q?xo7fscUPYQq9sEEQYTLZHr2sH43Wt38NAsE11OLslHYZzt4R4EJy1zjToWGQ?= =?us-ascii?Q?QapktYqjAjNpxRtBRKbT68KXL7MI+QThRVu+scj1O3M7KjDGtt9MvhC/Xyzz?= =?us-ascii?Q?YDr9e2hZkqbjbxO3omxc92hRkpZhAnr6zb+x2gY8AKPVadif6nBPAPKdCmwd?= =?us-ascii?Q?N8KcgLVShUkpsaVCL2ZdROG19e4oArd2Tjrfnnc7LIDiBn6MNYqQWLJjkXUR?= =?us-ascii?Q?kBKbnsMpW/0hYKULMeG/URy2KAXt1CTkC24M7bcP?= Content-Type: multipart/related; boundary="_004_BN8PR03MB46104630EA9C293B3040169DC7D79BN8PR03MB4610namp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: invue.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN8PR03MB4610.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1029d41e-f03b-4dde-a910-08db0630a34a X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2023 21:50:17.0364 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: aa8f9ce5-7216-4b20-ba36-a831b28419fc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6ZLzGDVLPYwoOKK8I7wmkT3w7AcScS/xDN7bCSvTR/TL8H5Koc2yzoPgS4EVOQJrScx/GAY8duA+nqouJAOVPQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB5816 Received-SPF: pass client-ip=40.107.102.81; envelope-from=JeffThompson@invue.com; helo=NAM04-DM6-obe.outbound.protection.outlook.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action Subject: [lwip-users] lwIP deInit X-BeenThere: lwip-users@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for lwIP users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2023 21:55:26 -0000 --_004_BN8PR03MB46104630EA9C293B3040169DC7D79BN8PR03MB4610namp_ Content-Type: multipart/alternative; boundary="_000_BN8PR03MB46104630EA9C293B3040169DC7D79BN8PR03MB4610namp_" --_000_BN8PR03MB46104630EA9C293B3040169DC7D79BN8PR03MB4610namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As part of a robust network recovery scheme, I need to take down the TCP/IP= stack, reset my Ethernet PHY, then bring it all back up again. I looked fo= r a de-init function but didn't see one. Is there a graceful way to accompl= ish this? Right now, I just reboot to avoid issues with freeing up any allo= cated memory and causing fragmentation or other problems. Jeff Thompson | Senior Electrical Engineer - Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D937EF.62713CC0] --_000_BN8PR03MB46104630EA9C293B3040169DC7D79BN8PR03MB4610namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As part of a robust network recovery scheme, I need = to take down the TCP/IP stack, reset my Ethernet PHY, then bring it all bac= k up again. I looked for a de-init function but didn’t see one. Is th= ere a graceful way to accomplish this? Right now, I just reboot to avoid issues with freeing up any allocated memory an= d causing fragmentation or other problems.

 

Jeff Thompson  |  Senior Electrical Engineer - Firmware
+1 704 752 6513 x1394
www.invue.com<= /span>

 

--_000_BN8PR03MB46104630EA9C293B3040169DC7D79BN8PR03MB4610namp_-- --_004_BN8PR03MB46104630EA9C293B3040169DC7D79BN8PR03MB4610namp_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=3596; creation-date="Fri, 03 Feb 2023 21:49:49 GMT"; modification-date="Fri, 03 Feb 2023 21:49:49 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhrwAiAPcAADgzNSUhIvb29u/u7u/v79fX14eFhWtoaW1ra2BdXTMxMTYxMt3d3cPCwoaD hZCOjvj4+CQgIcrJyTs4ODo4OPT09F9cXPz7/HBtbp6dnfn5+ff390ZERYOBgf7+/vz8/MHAwPX0 9SYiI2tpaeyqIH58fe7t7nJvcDk1Nvb19e3t7ZKQkXNxcaSiovr6+jQxMWxqaiwoKfDw8CsnKHp5 eX57fCwpKi0pKjcyM0ZCRCUjI/39/ScjJKmnqMfGxtrZ2TIwMby6u9bW1uPj49jX2KalpUdFRt/e 36qpqbGwsJyamigkJWpmaISBgmllZ3d0dT45OnNycuXl5ezs7PPz8/789mJeYI+NjWRhYsbFxSwq KsnIyOrq6k9MTfLy8sLBwTMvMC4qK9PS0u6xNVZTVF5bW/Hx8evr6zk3OHJwcLCur3p4eI6MjIB/ f2ZkZENAQObm5mNfYSolJ3VycjIuLz88PUtHR4WDhNHQ0XZzdNva2rWztDEsLsvKy5+dntDPz//+ /ElGRpGPkOjn50RAQLi3t7u6uu2tKtzb2316e6GfoNbV1Xh0dmdlZmViYpuZmtnY2TArLIuJipmX mEZBQzk2N5iWl8C/v1NQUq6sraOhodzc3F1aW7e2tj04OZWTk2VjY1hVVVJOTm9sbWBeX83MzOyr IIKAgMXExO6wMZqYmf348J2bm0xJS6Sjo6elpoB+flJPT/C7Ta+tru2tJ6imp4qIiH97e++/YUA+ P/78+NXU1IiGhunp6YyKiz86PJSSk1pXWdLR0uHg4EVAQba0tX99fqWkpNDQ0PHAW6uqqtTT0+no 6OyvK8PCw+Pi4ldUVP359PLDYkpHR/779aekoeLh4bq5ue7Wq4uIifPIbvC7Tvvt0L69vUxISvDB W+qmJuqmIVlWVuC9fLm4uJCNiOysM8/OzvXr3cTDxEE/P/n5+PTRjpeVlXFtb+fm54SCg+usJPfd p87NzZGPj56cnPHCXbe1tvjhsq2srHh2d5aUlI2LjOjJlCMfIP///yH/C1hNUCBEYXRhWE1QPD94 cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4gPHg6eG1w bWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS42 LWMwNjcgNzkuMTU3NzQ3LCAyMDE1LzAzLzMwLTIzOjQwOjQyICAgICAgICAiPiA8cmRmOlJERiB4 bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8 cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2Jl LmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu MC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtbG5zOnhtcD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAv MS4wLyIgeG1wTU06T3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOmYwZTViZTYzLTY3M2QtZGE0 NS1iMjg5LWMwMzMyYTdmYmQyNCIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDpDNjMwQTVEMTUw RDExMUU1QTQwRTg3RThBRTUzQzlFNiIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDpDNjMwQTVE MDUwRDExMUU1QTQwRTg3RThBRTUzQzlFNiIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3No b3AgQ0MgMjAxNSAoV2luZG93cykiPiA8eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJ RD0ieG1wLmlpZDpEOEYzN0YzMDUwQjkxMUU1OTU3NTk1NTM5MTlEMEI3QyIgc3RSZWY6ZG9jdW1l bnRJRD0ieG1wLmRpZDpEOEYzN0YzMTUwQjkxMUU1OTU3NTk1NTM5MTlEMEI3QyIvPiA8L3JkZjpE ZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/PgH/ /v38+/r5+Pf29fTz8vHw7+7t7Ovq6ejn5uXk4+Lh4N/e3dzb2tnY19bV1NPS0dDPzs3My8rJyMfG xcTDwsHAv769vLu6ubi3trW0s7KxsK+urayrqqmop6alpKOioaCfnp2cm5qZmJeWlZSTkpGQj46N jIuKiYiHhoWEg4KBgH9+fXx7enl4d3Z1dHNycXBvbm1sa2ppaGdmZWRjYmFgX15dXFtaWVhXVlVU U1JRUE9OTUxLSklIR0ZFRENCQUA/Pj08Ozo5ODc2NTQzMjEwLy4tLCsqKSgnJiUkIyIhIB8eHRwb GhkYFxYVFBMSERAPDg0MCwoJCAcGBQQDAgEAACH5BAAAAAAALAAAAACvACIAAAj/AOXJanZojMFU tLTp+sewocOHECNKnEixosWLGDNq3FgREDdph0iIFPmtCseTKFOqXMnyJCB82+KZEmnPZMubOHPq 3MlwFTtz4Uwls8mzqNGjSBuiGwcOF7WkUKNKxbiBgFWrEDZg6xcNqQcvZ66KvTrgwk0BJsZelaHC xIepR2chmIsABoJb5aqtS2ooQSO6gBGMiNOgJRwDWOwGRoAhmC0qcI22ieCvsmV/ZTYkLfDmsufK mKSwtPT58ySzkXk6CFDaggCoRUp7FoQapY8Fsi3DIJC6qAHWnxO8dthLzKICyJMrVy7kiIkBZmpD hPAkd+UYWVKawGLdHwVIDD1Q/5kyoHx5FSreUrxAQIX58lMIqK/oIcTz9/jzD1CRwsPD36UJ99Ak KLxhBAcIJqiggqI4wcQod1iSBBEpQPSDEd2RMQhKfnTnTxENabACKEwcYOIBWKQhGkVizEHKCCcO 9gQzE+3wzD2fSJKHEyf26GOPTMShRAj/AeeZgA7V4GF3IuTwRCHDNdSDh0rMl9E8aHRHyhkNpSBK aWgIU9EeYZQmxw8ReaAHG5gssWRuVqhQZIBRMuTAmx7yUAMXDoXgRHd0/LGRFzB0p0UfDmlgQWkU FFARCACUtgADEHnQgDd4WneCGXMGV+c/d2ba3QFENlTKBN05MoBGU3anykMQLP/6WaOPRvrZpBDt 4omoucEgQ6dHfhqqPzHcYCSvlUnykBIetmAlixR0ZwWfDsXKqKMUQSoppYm6gaxsB/DmEICePjSs CBgok8ED7LbL7gpruONEDrnloIdDFVjRXSXgWZQCI91F4Mx0snpGa7a2eoarQ8vMUJoIRowwBy/t XOHuxexeYUAnEAB7GZINDeuPHT5Y5MEiecimhRoPZYFCdyeUSpEaHrLhH6wFX3bwRNreym14rrjp mQj6DHGzSuQGa65nNtAAh0Xv0PuZCIpAJEjA+exAESKdWRfK0wRfW+u2Dn1gzLGVkfFpSkl/LGxp v1xSUQgnlBYBKxDJwEl3UKz/GNEGbXhIjkTWzootzwlftjBDFyBA2WU6sIFT25aBbKdsbWg2UQhp lBZABhEFAUZ3JWggURAeOnA0zmIjTHZDF7DwuGUznIJHHxLkrvvuvEuwBSoMPEt5ZZaDKhssmktU AQaegx6RAd3xcE1EQ9jRXRdHTFS4wYdL1LPCP/8T++yVBQAEFJ5MoP767Lc/AQVgMPLruGgT/3Zp HZg+0fLNS3RGKN2ZxoYcIoAmeCgJFNmezroXke8pLnzj+1ZpQGECj1Xufp/JH0X495nPTaQYfLCO CJpgpQbwoDs1qIgCLbMz7yXOMosTn+wk+JlNWdB+S8Of/pTHvA46TyI0AFQ6/xrCBXF0hxJCUGHO WMhAiFwCB69j3AxpeBk3rIp+dMphBncYEQ56xoMTGUIrMjSFf7jgEx5CgkVWWBkKEKEiQQBCFGVI Pn8sAQFIeIUmWsDHFhyjBb6gQQ1KQMhC1uAJSPjU8PxRPJFdRoP76+EXfyiRJIQwNyK4wj8kUCbr ROFZf1tiG5NIkR9Yz2cOuQAG6siDFUzkAikQwAZmSUsBpMAFEFlkI2UDSR72ryJR6E4dDBFE69RB UGsUpT8ikQmLIOIAqITdCeroDzdMrn6MxKBnetlFSV4GjBQ5AiGsEwAF2MA6EaBkRRohmy6ETyIu OMcIdADD8O0AGCL4DBAQ2P8SXWrzkVyEiBe/qU6J9OAGNBwBKCeSjXyWhhBNKEIhfNCAilq0AV/Y whGCEIh6PsQHCL3VGpDwhSxc9KQX/UI3fiCdf/hTi9sM6EMGahlwUmQHI5BgLpChkU2oIzcB0AIY XqCAohq1qEBAAxRi4FGHmKALsgnADRRA1KNa9ag2QMAVh7CJD7zUIY60DDcF6s2aFlQiRIACsgLw CI74wWFUbGpDPJAJesbVHyPgzR7WkIhafDVkvJQpvspavrNKRBHnFFUCvMARCDyCqXeNIUM2QI+7 +uMEFRjGChAQiyjAA5tl+JQB8dex/Y3CbvXISAiYIKo6lAIlLvBBGmYQAGqBZkoB72QIBDoBjQhg E08IqAAR9nEKTsxhBQvAAQCWC4AXyAEDpW3ICnRABxQwFwUR4AcuJ5ICGszAustFwQ0i0QON4MEI MVAuc9d73TDYQAkrCYEQ1HAHRwQCBwtgr37ZWwk5UMIaE5HBFh5QBmK8QL373e8LlpAIyBQhCifQ REAAADs= --_004_BN8PR03MB46104630EA9C293B3040169DC7D79BN8PR03MB4610namp_-- From MAILER-DAEMON Fri Feb 03 17:57:47 2023 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1pO507-0001oj-EH for mharc-lwip-users@gnu.org; Fri, 03 Feb 2023 17:57:47 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pO505-0001md-8B for lwip-users@nongnu.org; Fri, 03 Feb 2023 17:57:45 -0500 Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pO4zy-0005b4-4E for lwip-users@nongnu.org; Fri, 03 Feb 2023 17:57:42 -0500 Received: by mail-ej1-x62c.google.com with SMTP id hx15so19336443ejc.11 for ; Fri, 03 Feb 2023 14:57:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=QBdwa40dpjzpoPn5QvXSJJ1jXIlFtIfazqs1VNgep6E=; b=m2khWqacGe/67UigedFEbzwDgyYDoLYCFi9ddptMRjv3kZvcskQYniEfVdFFdT+YJs PSY0RPGgZpZNVmtbZpiUUCeJ36/ZVzOFpmTqKy2/P7nxpSmdEOrT7SCxukgQjGpkQFHN CEhYyV3Pc23iEGcTpfSPauwRVZMCGPj6Z3J11p/lNhtFx6qgiYSjBkWRlqU3O/tcbCIz ZSzLR/9DYv139IGayZGk+xzFzrGP0s9tasRcAY37W87KB9kircFgL8QHzL/ZzeDIDDlT GLqX2yYDC5FUw8pkGCS/7IO8F9tY0ACAqmpL3tc8nGkXk0y/MllnGdLlBTJU3tdJ1UES 1JSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QBdwa40dpjzpoPn5QvXSJJ1jXIlFtIfazqs1VNgep6E=; b=NSm+peX+wWvX/trk6BJSbQoEQB6z8U//x0pLQMdGd1IT7A24MeUvlYw4xLw/gahwuC /2ntyrsgun6rzw7qW23Kx9Wj9fI6P9p0DPZfwFsVOkki6y2eu+fRN60HVzd4IAn4dQQ4 Vdn5joM/1kIfSi4W21gH0S3xcAnvxJfEdJfDOHKhRS1suy4QCObal4G0VgBswutL8nRi pQHjgYov+aqsVNaXki7L4y1M1Wn9nAFnZ3o9hQQCpJhVvBOH+p5eFDcSg/DsydV2gpNv eMmeBKM9geP12TqfZFv9TXOjIELUCKVoXKbYzaJ1TnT+osQak3CazFf0Iz4sfse8zGu0 DwKg== X-Gm-Message-State: AO0yUKW1uNblHmWGh79Nb1HBrl1qP+Qa3hMX9fVELJJaY/kOU7gfa6J+ gumTKTXV5y0BeXJ0I99HmicBKMO+3DYokMCqaOkuEqaZG85Usg== X-Google-Smtp-Source: AK7set/XZMrTAhOZ+KaebqvgVnfvy1pvG/7ZPG1wU6VxzwvsU0weAvNCSLjVmijp9aWjBAj4T9BJukhagI2jo2Hm2Lc= X-Received: by 2002:a17:906:80d1:b0:87b:da77:ffce with SMTP id a17-20020a17090680d100b0087bda77ffcemr3582731ejx.217.1675465056262; Fri, 03 Feb 2023 14:57:36 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dan Nygren Date: Fri, 3 Feb 2023 14:57:24 -0800 Message-ID: To: lwip-users@nongnu.org Content-Type: multipart/alternative; boundary="000000000000831c5205f3d39b8d" Received-SPF: pass client-ip=2a00:1450:4864:20::62c; envelope-from=dan.nygren@gmail.com; helo=mail-ej1-x62c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action Subject: Re: [lwip-users] lwIP UDP echo server fails to send message lengths of 4385 & 4386 X-BeenThere: lwip-users@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for lwIP users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2023 22:57:45 -0000 --000000000000831c5205f3d39b8d Content-Type: text/plain; charset="UTF-8" Sylvain wrote > ... Anyway, basic rule about using fragmented IP packets: avoid (to not say don't). Thank you for the advice Sylvain. My design is keeping its packets under the Ethernet 1500 octet MTU. I had made a diagnostic command to have my design send back arbitrarily sized messages to prove everything was working correctly when I ran into the 4385/4386 message size problem. Dan , On Fri, Feb 3, 2023 at 1:24 PM Dan Nygren wrote: > Peter wrote: > > > 4385/4386 could be 3x MTU ? ... > > Peter, thanks for responding! > Yes, it seems like I've hit some corner case. > Is this the right place to notify the lwIP maintainers of problems? This > is not a current problem for me as my messages are under the MTU size. I > just hit this while developing some diagnostics for my board and I wanted > to let others know about it. > > Dan > > , > On Wed, Feb 1, 2023 at 2:10 PM Dan Nygren wrote: > >> Hello fellow lwIP users. Can anyone point me in the right direction on >> how to resolve or report to the right folks the below issue? >> >> I'm seeing rather bizarre behavior in that messages of length 4385 and >> 4386 I send to a lwIP based UDP echo server are not received back. >> udp_sendto() appears to be getting called and completing successfully. >> Wireshark indicates there are "bogus, payload length" errors with these >> lengths. >> >> I have a detailed write up showing the behavior here: >> https://github.com/Xilinx/embeddedsw/issues/212 >> >> I can copy the info above into an email for this mailing list if you >> prefer. >> >> Let me know your suggestions on how to proceed. ... Dan Nygren >> >> , >> > --000000000000831c5205f3d39b8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sylvain wrote > ... Anyway, basic rule= about using fragmented IP packets: avoid (to not say
don't).
=

Thank you for the advice Sylvain. My design is keeping = its packets under the Ethernet 1500 octet MTU. I had made a diagnostic comm= and to have my design send back arbitrarily sized messages to prove everyth= ing was working correctly when I ran into the=20 4385/4386 message size problem.

=C2=A0 Dan

,

On Fri, Feb 3, 2023 at 1:24 PM Dan Nygren= <dan.nygren@gmail.com> w= rote:
Peter wrote:

> 4385/4386 could be= 3x MTU ? ...

Peter, thanks for responding!
<= div>
Yes, it seems like I've hit some corner case.
Is this the right place to notify the lwIP maintainers of proble= ms? This is not a current problem for me as my messages are under the MTU s= ize. I just hit this while developing some diagnostics for my board and I w= anted to let others know about it.

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Dan
,
On Wed, Feb 1, 2023 at 2:10 PM Dan Nygren <dan.nygren@gmail.com= > wrote:
Hello fellow lwIP users. Can anyone point me i= n the right direction on how to resolve or report to the right folks the be= low issue?

I'm seeing rather bizarre behav= ior in that messages of length 4385 and 4386 I send to a lwIP based UDP ech= o server are not received back. udp_sendto() appears to be getting called a= nd completing successfully. Wireshark indicates there are "bogus, payl= oad length" errors with these lengths.

I have= a detailed write up showing the behavior here:

I can copy the info= above into an email for this mailing list if you prefer.
Let me know your suggestions on how to proceed. ... =C2=A0 Dan = Nygren

,
--000000000000831c5205f3d39b8d-- From MAILER-DAEMON Sat Feb 04 05:17:49 2023 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1pOFcD-00042r-Kl for mharc-lwip-users@gnu.org; Sat, 04 Feb 2023 05:17:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pOFcB-00042c-LQ for lwip-users@nongnu.org; Sat, 04 Feb 2023 05:17:47 -0500 Received: from outmail148138.authsmtp.net ([62.13.148.138]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pOFc8-00019p-8U for lwip-users@nongnu.org; Sat, 04 Feb 2023 05:17:46 -0500 Received: from mail-c245.authsmtp.com (mail-c245.authsmtp.com [62.13.128.245]) by punt21.authsmtp.com. (8.15.2/8.15.2) with ESMTP id 314AHbR9082385 for ; Sat, 4 Feb 2023 10:17:37 GMT (envelope-from peter@peter2000.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peter2000.co.uk; s=authsmtp; t=1675505857; bh=AQwCaQ8ecYjH3/APUtJH2IabGFUIc07s8FpwfHaRklk=; h=Date:From:To:Subject; b=hdbR1hu21kEsJ3XIRB1rnbLbQL5LmhPyQRI0AFZFdBRRChWPD9TPeGum89jHtJ8Kp lEd0r2BLqn8Tvw2KsZhE7rUMVbuoK69FwuNU2il1gy83gXjxHDZQXKLASaBPw4Mgvg Z5blNbFGpzCy7DFY97h35s5dmUlZ4bu8U187C9lQ= Received: from PETER-HOME (static-87-75-102-77.vodafonexdsl.co.uk [87.75.102.77]) (authenticated bits=0) by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPA id 314AHbdw064282 for ; Sat, 4 Feb 2023 10:17:37 GMT (envelope-from peter@peter2000.co.uk) Message-Id: <202302041017.314AHbdw064282@mail.authsmtp.com> From: Peter To: lwip-users@nongnu.org Date: Sat, 04 Feb 2023 10:17:40 +0000 Organization: - References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Server-Quench: 2610e03d-a475-11ed-9114-7cd30ad787f4 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd0ZA4dC1ZNQRgX EAscATNNU199fkUK ChhFMAhMJEUITUFM KUtANXJVN1sTQ0wf XCRcFVRQTyskC3x3 awhSfQRdaEtJVQZt HkBOXFVXCgRoAwIG AQEcVwZyOQZHfA8I NxIlXnZfXkx4O09/ QU8aF2sHZTJgazQC AURfch5VcVYeYxZE a1RiUyBZYmVWMn1o QAFvKTQuHA0XFQht CgwGLVVaWksRADMm Dx4LHDE0VVECDz4+ KRBuL1MHB08ePy0A X-Authentic-SMTP: 61633734363838.1039:8335 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 87.75.102.77/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. Received-SPF: pass client-ip=62.13.148.138; envelope-from=peter@peter2000.co.uk; helo=outmail148138.authsmtp.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action Subject: [lwip-users] lwIP UDP echo server fails to send message X-BeenThere: lwip-users@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for lwIP users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2023 10:17:48 -0000 AFAIK there is no support forum or "community" for LWIP today. It is a project which was at its height about 15 years ago and the devs have generally moved on long ago. This also means that if somebody develops a solution for something, they have nowhere to post it. Googling digs up lots of old stuff, mostly pre-2011. There is also a lot of clickbait - sites which collate content from other sites. I post questions all over the place (EEVBLOG, the ST forum) and occassionally somebody bites, or I find someone who replies privately. I doubt LWIP has any obvious bugs after all these years but there is certainly some complex behaviour related to how much buffering has been allocated. Like that business of broadcast packets messing stuff up. Peter >Send lwip-users mailing list submissions to > lwip-users@nongnu.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.nongnu.org/mailman/listinfo/lwip-users >or, via email, send a message with subject or body 'help' to > lwip-users-request@nongnu.org > >You can reach the person managing the list at > lwip-users-owner@nongnu.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of lwip-users digest..." > > >Today's Topics: > > 1. Re: lwIP UDP echo server fails to send message lengths of > 4385 & 4386 (Dan Nygren) > 2. Re: lwIP UDP echo server fails to send message lengths of > 4385 & 4386 (Sylvain Rochet) > 3. lwIP deInit (Thompson, Jeff) > 4. Re: lwIP UDP echo server fails to send message lengths of > 4385 & 4386 (Dan Nygren) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 3 Feb 2023 13:24:48 -0800 >From: Dan Nygren >To: lwip-users@nongnu.org >Subject: Re: [lwip-users] lwIP UDP echo server fails to send message > lengths of 4385 & 4386 >Message-ID: > >Content-Type: text/plain; charset=3D"utf-8" > >Peter wrote: > >> 4385/4386 could be 3x MTU ? ... > >Peter, thanks for responding! >Yes, it seems like I've hit some corner case. >Is this the right place to notify the lwIP maintainers of problems? This= is >not a current problem for me as my messages are under the MTU size. I = just >hit this while developing some diagnostics for my board and I wanted to = let >others know about it. > > Dan > >, >On Wed, Feb 1, 2023 at 2:10 PM Dan Nygren wrote: > >> Hello fellow lwIP users. Can anyone point me in the right direction on= how >> to resolve or report to the right folks the below issue? >> >> I'm seeing rather bizarre behavior in that messages of length 4385 and >> 4386 I send to a lwIP based UDP echo server are not received back. >> udp_sendto() appears to be getting called and completing successfully. >> Wireshark indicates there are "bogus, payload length" errors with = these >> lengths. >> >> I have a detailed write up showing the behavior here: >> https://github.com/Xilinx/embeddedsw/issues/212 >> >> I can copy the info above into an email for this mailing list if you >> prefer. >> >> Let me know your suggestions on how to proceed. ... Dan Nygren >> >> , >> >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: = > >------------------------------ > >Message: 2 >Date: Fri, 3 Feb 2023 22:39:15 +0100 >From: Sylvain Rochet >To: Mailing list for lwIP users >Subject: Re: [lwip-users] lwIP UDP echo server fails to send message > lengths of 4385 & 4386 >Message-ID: <20230203213915.GA17368@gradator.net> >Content-Type: text/plain; charset=3D"utf-8" > >Hi, > >On Fri, Feb 03, 2023 at 01:24:48PM -0800, Dan Nygren wrote: >> Peter wrote: >>=20 >> > 4385/4386 could be 3x MTU ? ... >>=20 >> Peter, thanks for responding! >> Yes, it seems like I've hit some corner case. >> Is this the right place to notify the lwIP maintainers of problems? = This is >> not a current problem for me as my messages are under the MTU size. I = just >> hit this while developing some diagnostics for my board and I wanted = to let >> others know about it. > >This kind of issues set all red lights to full brightness about a low=20 >level driver issue or a buggy MAC offloader on fragmented IP packets. > >Anyway, basic rule about using fragmented IP packets: avoid (to not say=20 >don't). > >Sylvain >-------------- next part -------------- >A non-text attachment was scrubbed... >Name: signature.asc >Type: application/pgp-signature >Size: 181 bytes >Desc: Digital signature >URL: = > >------------------------------ > >Message: 3 >Date: Fri, 3 Feb 2023 21:49:49 +0000 >From: "Thompson, Jeff" >To: "lwip-users@nongnu.org" >Subject: [lwip-users] lwIP deInit >Message-ID: > = >=09 >Content-Type: text/plain; charset=3D"utf-8" > >As part of a robust network recovery scheme, I need to take down the = TCP/IP stack, reset my Ethernet PHY, then bring it all back up again. I = looked for a de-init function but didn't see one. Is there a graceful way= to accomplish this? Right now, I just reboot to avoid issues with = freeing up any allocated memory and causing fragmentation or other = problems. > >Jeff Thompson | Senior Electrical Engineer - Firmware >+1 704 752 6513 x1394 >www.invue.com > >[cid:image001.gif@01D937EF.62713CC0] > >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: = >-------------- next part -------------- >A non-text attachment was scrubbed... >Name: image001.gif >Type: image/gif >Size: 3596 bytes >Desc: image001.gif >URL: = > >------------------------------ > >Message: 4 >Date: Fri, 3 Feb 2023 14:57:24 -0800 >From: Dan Nygren >To: lwip-users@nongnu.org >Subject: Re: [lwip-users] lwIP UDP echo server fails to send message > lengths of 4385 & 4386 >Message-ID: > >Content-Type: text/plain; charset=3D"utf-8" > >Sylvain wrote > ... Anyway, basic rule about using fragmented IP = packets: >avoid (to not say >don't). > >Thank you for the advice Sylvain. My design is keeping its packets under >the Ethernet 1500 octet MTU. I had made a diagnostic command to have my >design send back arbitrarily sized messages to prove everything was = working >correctly when I ran into the 4385/4386 message size problem. > > Dan > >, > >On Fri, Feb 3, 2023 at 1:24 PM Dan Nygren wrote: > >> Peter wrote: >> >> > 4385/4386 could be 3x MTU ? ... >> >> Peter, thanks for responding! >> Yes, it seems like I've hit some corner case. >> Is this the right place to notify the lwIP maintainers of problems? = This >> is not a current problem for me as my messages are under the MTU size.= I >> just hit this while developing some diagnostics for my board and I = wanted >> to let others know about it. >> >> Dan >> >> , >> On Wed, Feb 1, 2023 at 2:10 PM Dan Nygren = wrote: >> >>> Hello fellow lwIP users. Can anyone point me in the right direction = on >>> how to resolve or report to the right folks the below issue? >>> >>> I'm seeing rather bizarre behavior in that messages of length 4385 = and >>> 4386 I send to a lwIP based UDP echo server are not received back. >>> udp_sendto() appears to be getting called and completing = successfully. >>> Wireshark indicates there are "bogus, payload length" errors with = these >>> lengths. >>> >>> I have a detailed write up showing the behavior here: >>> https://github.com/Xilinx/embeddedsw/issues/212 >>> >>> I can copy the info above into an email for this mailing list if you >>> prefer. >>> >>> Let me know your suggestions on how to proceed. ... Dan Nygren >>> >>> , >>> >> >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: = > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >lwip-users mailing list >lwip-users@nongnu.org >https://lists.nongnu.org/mailman/listinfo/lwip-users > > >------------------------------ > >End of lwip-users Digest, Vol 234, Issue 3 >****************************************** From MAILER-DAEMON Sat Feb 04 07:41:58 2023 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1pOHri-0000P4-OC for mharc-lwip-users@gnu.org; Sat, 04 Feb 2023 07:41:58 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pOHrg-0000Os-58 for lwip-users@nongnu.org; Sat, 04 Feb 2023 07:41:56 -0500 Received: from atreides.gradator.net ([212.85.155.42]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pOHre-00070I-6u for lwip-users@nongnu.org; Sat, 04 Feb 2023 07:41:55 -0500 Received: from gradator by atreides.gradator.net with local (Exim 4.84_2) (envelope-from ) id 1pOHrY-0000O3-Nj for lwip-users@nongnu.org; Sat, 04 Feb 2023 13:41:48 +0100 Date: Sat, 4 Feb 2023 13:41:48 +0100 From: Sylvain Rochet To: Mailing list for lwIP users Message-ID: <20230204124148.GA1397@gradator.net> References: <202302041017.314AHbdw064282@mail.authsmtp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <202302041017.314AHbdw064282@mail.authsmtp.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gradator@atreides.gradator.net X-SA-Exim-Version: 4.2.1 (built Thu, 09 Jan 2020 16:15:24 +0000) X-SA-Exim-Scanned: Yes (on atreides.gradator.net) Received-SPF: none client-ip=212.85.155.42; envelope-from=gradator@atreides.gradator.net; helo=atreides.gradator.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action Subject: Re: [lwip-users] lwIP UDP echo server fails to send message X-BeenThere: lwip-users@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for lwIP users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2023 12:41:56 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Peter, On Sat, Feb 04, 2023 at 10:17:40AM +0000, Peter wrote: > AFAIK there is no support forum or "community" for LWIP today. It is a > project which was at its height about 15 years ago and the devs have > generally moved on long ago. >=20 > This also means that if somebody develops a solution for something, > they have nowhere to post it. >=20 > Googling digs up lots of old stuff, mostly pre-2011. There is also a > lot of clickbait - sites which collate content from other sites. >=20 > I post questions all over the place (EEVBLOG, the ST forum) and > occassionally somebody bites, or I find someone who replies privately. >=20 > I doubt LWIP has any obvious bugs after all these years but there is > certainly some complex behaviour related to how much buffering has > been allocated. Like that business of broadcast packets messing stuff > up. There is a reply from a lwIP developer in the digest below, maybe you should revisit your assumption. And please don't reply to the digest, it breaks threads and makes it=20 impossible to follow up. Sylvain --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAmPeUowACgkQDFub3qtEsS/6HQCfRtTkNsBs+MI43dNHPH/cpeiA JBwAnjju63u5TcPedKKlH7AU0iq8nIB5 =qHtc -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From MAILER-DAEMON Sat Feb 04 07:58:19 2023 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1pOI7X-0003eX-C4 for mharc-lwip-users@gnu.org; Sat, 04 Feb 2023 07:58:19 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pOI7S-0003e6-CJ for lwip-users@nongnu.org; Sat, 04 Feb 2023 07:58:14 -0500 Received: from atreides.gradator.net ([212.85.155.42]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pOI7Q-0000lO-6l for lwip-users@nongnu.org; Sat, 04 Feb 2023 07:58:13 -0500 Received: from gradator by atreides.gradator.net with local (Exim 4.84_2) (envelope-from ) id 1pOI7J-0000Vt-TC for lwip-users@nongnu.org; Sat, 04 Feb 2023 13:58:06 +0100 Date: Sat, 4 Feb 2023 13:58:05 +0100 From: Sylvain Rochet To: Mailing list for lwIP users Message-ID: <20230204125805.GA1579@gradator.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gradator@atreides.gradator.net X-SA-Exim-Version: 4.2.1 (built Thu, 09 Jan 2020 16:15:24 +0000) X-SA-Exim-Scanned: Yes (on atreides.gradator.net) Received-SPF: none client-ip=212.85.155.42; envelope-from=gradator@atreides.gradator.net; helo=atreides.gradator.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action Subject: Re: [lwip-users] lwIP UDP echo server fails to send message lengths of 4385 & 4386 X-BeenThere: lwip-users@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for lwIP users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2023 12:58:14 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Dan, On Fri, Feb 03, 2023 at 02:57:24PM -0800, Dan Nygren wrote: > Sylvain wrote > ... Anyway, basic rule about using fragmented IP packets: > avoid (to not say > don't). >=20 > Thank you for the advice Sylvain. My design is keeping its packets under > the Ethernet 1500 octet MTU. I had made a diagnostic command to have my > design send back arbitrarily sized messages to prove everything was worki= ng > correctly when I ran into the 4385/4386 message size problem. My best guess is a low level driver bug that happen when packets are=20 sent in a short timeframe, which big UDP packets do due to IP=20 fragmentation taking place. Sending small packets at a low rate does not=20 fix the problem, it just hides it. Sylvain --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAmPeVl0ACgkQDFub3qtEsS9S6gCgjQwAEmZJ1vg4KcsEGB4Tm3yF 1nkAn2q+xGAFrrpGvVOw3ddDzbb9Iblt =gZHh -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From MAILER-DAEMON Mon Feb 06 10:49:17 2023 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1pP3k5-0004VP-R8 for mharc-lwip-users@gnu.org; Mon, 06 Feb 2023 10:49:17 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pP3k5-0004V8-0w for lwip-users@nongnu.org; Mon, 06 Feb 2023 10:49:17 -0500 Received: from mail-ej1-x62a.google.com ([2a00:1450:4864:20::62a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pP3k2-0001MS-92 for lwip-users@nongnu.org; Mon, 06 Feb 2023 10:49:16 -0500 Received: by mail-ej1-x62a.google.com with SMTP id hx15so35343380ejc.11 for ; Mon, 06 Feb 2023 07:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=JQ8ljquxoh+tEwouwnMvx67hYvLl4kpce6roGUR1IZA=; b=Hvn5rlRpfDIaJAAVH2i8IZI01DyOad/SxA4w0GIuVFGm5FlQJqWz2Rz3L7h8ZpA1mP gb63++vKBwel2DE/Du36bQh39pz95y7m9nQgrqS6CRicA1Hau3AiI87WAxqPeujGZ1Vo GOMGL/B53TkM2smVFsDhY8hC+PP2tOgeKSJHYSH2IlExoNqNC7NuvVvH2NvMiiJC+/0G iuh4XlNj7/YqxZ7yZwh0ocMag5Pn1Ol8Gs0JnCb1MDv7g+QDVBxBrY3j1bIYChsmVzg+ Bfg+mpWTR5LSnlvZDfHUSsUQ8FWSrcbyayxR6muwyp0pXglay9mmjowfNZYkdoTSG4Z5 X8kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=JQ8ljquxoh+tEwouwnMvx67hYvLl4kpce6roGUR1IZA=; b=aQ6/tq17QV9S8GTyvhQr2t2uwjtY/PKQR3MBlPTK0afwa8Fg5XgxVBNwkjizwo752T hcvPwglaJcJOm0TOykIcE01AmjsdCX1Ubbd8x4SwdYbBgJK+8cuFTww9xreALwe8FV8A 1/dN2Mja+4zoiRyPtAxiM2/z5zwpbb/bXiNe4yVX8hlA+hSoTHrrW3ZiZSVzvuhWRw+7 eEflMKCpi614sPPlbcgfnbTixiXDqw7omCNgKG4DufDybt0x+xDxmK274ziZnTzyqrFs hLpleC3xkXJT5U9iIir+s+uCPThm5id6hzAdktJkEg2SFhVIlzcBKqrWjH5IhIa3xZOS lp5Q== X-Gm-Message-State: AO0yUKXCjM3IaTdjy3vbUTiMB0z/tgeW8rbTwf9ccDHpOJPuE96yK9o8 SzZnXU2fG6cH9+uMT11eS2I/u+OfJxqE9/nS+o3ZfWIs X-Google-Smtp-Source: AK7set/lR3aWGgxdTntjX9ULcAuNZpkFabWDHE8RpAx5L/jqOu3vYD6u+yjLdXTNo4RkdIFN+QZcTZLl1oWXANySfl0= X-Received: by 2002:a17:906:80d1:b0:87b:da77:ffce with SMTP id a17-20020a17090680d100b0087bda77ffcemr5779616ejx.217.1675698551672; Mon, 06 Feb 2023 07:49:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dan Nygren Date: Mon, 6 Feb 2023 07:49:00 -0800 Message-ID: To: lwip-users@nongnu.org Content-Type: multipart/alternative; boundary="000000000000ec51a505f409f892" Received-SPF: pass client-ip=2a00:1450:4864:20::62a; envelope-from=dan.nygren@gmail.com; helo=mail-ej1-x62a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action Subject: Re: [lwip-users] lwIP UDP echo server fails to send message lengths of 4385 & 4386 X-BeenThere: lwip-users@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for lwIP users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2023 15:49:17 -0000 --000000000000ec51a505f409f892 Content-Type: text/plain; charset="UTF-8" Sylvain wrote: > My best guess is a low level driver bug that happen when packets are > sent in a short timeframe, which big UDP packets do due to IP > fragmentation taking place. Sending small packets at a low rate does not > fix the problem, it just hides it. > I've indicated such in the GitLab issue I had open with Xilinix. Thanks again for everyone's responses! Dan , On Fri, Feb 3, 2023 at 2:57 PM Dan Nygren wrote: > Sylvain wrote > ... Anyway, basic rule about using fragmented IP packets: > avoid (to not say > don't). > > Thank you for the advice Sylvain. My design is keeping its packets under > the Ethernet 1500 octet MTU. I had made a diagnostic command to have my > design send back arbitrarily sized messages to prove everything was working > correctly when I ran into the 4385/4386 message size problem. > > Dan > > , > > On Fri, Feb 3, 2023 at 1:24 PM Dan Nygren wrote: > >> Peter wrote: >> >> > 4385/4386 could be 3x MTU ? ... >> >> Peter, thanks for responding! >> Yes, it seems like I've hit some corner case. >> Is this the right place to notify the lwIP maintainers of problems? This >> is not a current problem for me as my messages are under the MTU size. I >> just hit this while developing some diagnostics for my board and I wanted >> to let others know about it. >> >> Dan >> >> , >> On Wed, Feb 1, 2023 at 2:10 PM Dan Nygren wrote: >> >>> Hello fellow lwIP users. Can anyone point me in the right direction on >>> how to resolve or report to the right folks the below issue? >>> >>> I'm seeing rather bizarre behavior in that messages of length 4385 and >>> 4386 I send to a lwIP based UDP echo server are not received back. >>> udp_sendto() appears to be getting called and completing successfully. >>> Wireshark indicates there are "bogus, payload length" errors with these >>> lengths. >>> >>> I have a detailed write up showing the behavior here: >>> https://github.com/Xilinx/embeddedsw/issues/212 >>> >>> I can copy the info above into an email for this mailing list if you >>> prefer. >>> >>> Let me know your suggestions on how to proceed. ... Dan Nygren >>> >>> , >>> >> --000000000000ec51a505f409f892 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sylvain wrote:
My best guess is a low level driver bug that happen w= hen packets are
sent in a short timeframe, which big UDP packets do due= to IP
fragmentation taking place. Sending small packets at a low rate = does not
fix the problem, it just hides it.

=
I've indicated such in the GitLab issue I had open with Xili= nix. Thanks again for everyone's responses!

= =C2=A0=C2=A0 Dan

,=C2=A0

On Fri, Feb 3, = 2023 at 2:57 PM Dan Nygren <dan.nygren@gmail.com> wrote:
Sylvain= wrote > ... Anyway, basic rule about using fragmented IP packets: avoid= (to not say
don't).

Thank you for the adv= ice Sylvain. My design is keeping its packets under the Ethernet 1500 octet= MTU. I had made a diagnostic command to have my design send back arbitrari= ly sized messages to prove everything was working correctly when I ran into= the=20 4385/4386 message size problem.

=C2=A0 Dan

,

On Fri, Feb 3, 2023 at 1:24 PM Dan Nygren= <dan.nygren@g= mail.com> wrote:
Peter wrote:

> 43= 85/4386 could be 3x MTU ? ...

Peter, thanks for re= sponding!
Yes, it seems like I've hit some corner = case.
Is this the right place to notify the lwIP maintainers of proble= ms? This is not a current problem for me as my messages are under the MTU s= ize. I just hit this while developing some diagnostics for my board and I w= anted to let others know about it.

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Dan
,
On Wed, Feb 1, 2023 at 2:10 PM Dan Nygren <dan.nygren@gmail.com= > wrote:
Hello fellow lwIP users. Can anyone point me i= n the right direction on how to resolve or report to the right folks the be= low issue?

I'm seeing rather bizarre behav= ior in that messages of length 4385 and 4386 I send to a lwIP based UDP ech= o server are not received back. udp_sendto() appears to be getting called a= nd completing successfully. Wireshark indicates there are "bogus, payl= oad length" errors with these lengths.

I have= a detailed write up showing the behavior here:

I can copy the info= above into an email for this mailing list if you prefer.
Let me know your suggestions on how to proceed. ... =C2=A0 Dan = Nygren

,
--000000000000ec51a505f409f892-- From MAILER-DAEMON Fri Feb 24 16:28:27 2023 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1pVfcB-0007SG-F2 for mharc-lwip-users@gnu.org; Fri, 24 Feb 2023 16:28:27 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVeVT-000755-4s for lwip-users@nongnu.org; Fri, 24 Feb 2023 15:17:27 -0500 Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pVeVR-0004a6-FK for lwip-users@nongnu.org; Fri, 24 Feb 2023 15:17:26 -0500 Received: by mail-wm1-x334.google.com with SMTP id o38-20020a05600c512600b003e8320d1c11so4545196wms.1 for ; Fri, 24 Feb 2023 12:17:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=E+xcg9wcjQJzL1TBKqaV+Wn8IZo8fwsaPIKXpYRX6iw=; b=ZvUBaxevJXlW/AgSH7x1972JxdRNpkap7DYDCEjUKxyBqhKvhF/8myIueOhRqVRnt7 8aBC2CbuW6MHyRJtn79UcGkun2E2HmtWIctQ4Bpjo2QnQXim/IGGy9hbiFSZxselESXZ S9erHlY76sLZrbAkmn3y2SO0thIHDA7m2GCSsMT8PiPWWfgMdPgvPALUvF7RI7FGDvRL 0uxUN41taqWYcU2qii67O4ZKH3lwaPuTWx3lYSryJinaa3jNd9yLBtxvih4Ztsxrzgh4 jPGtiq92iaAwW3UPeCV2oAl4ZkFD3Rkyuds50rEc3znn8piHeMaYWnPCZbi4i4RyoX+n qJJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=E+xcg9wcjQJzL1TBKqaV+Wn8IZo8fwsaPIKXpYRX6iw=; b=N57sZvS57+WFA6H57Uhyt1YD24wen7UyYgmXDCkT0HgaYSzWefL2NGbdf0cCbTu2Ea 1ZVHDPuX1MfwZbF/CipqHAVfEaI153vtAnYz1IjyTk09KyivRK4mzDJRy4bEchOxCy5+ 9RnMpiw7PRiVXNsyQO/1FXmK5yh39LTEOj/6Ly/RSuVWPJJHV9uMKUBiXgxnm9RE5KXL DfYxGnHJFveO3mnpdrKyEApTtzj9+DDGe0Csc3UZHH23NyufqWSNG+uJuPqfWzrTyxiM qJ0/OIm/Hllkk35CtrmgouWWF1ypVUAZHZTSLl+3ZwOYdMwq2IddggD4RrQUifBJsDgX /bGw== X-Gm-Message-State: AO0yUKWStkUEOgFWrGErf82tq6yhMdTtzmpebM4D6rTmokG1Oq1ypLCk Atugqb6ywv6tVf5G2H4oiwOfHAeHQDybROz8sOIUK+P45PS7uQ== X-Google-Smtp-Source: AK7set9YSToWVvWUNEhyuWx/LXSG2JYY0pnIyVFbuuZiWuXGUaA79wVlf2fpNDG2YnyUvHPCbH9EdHspx9TIHlAvqFo= X-Received: by 2002:a05:600c:1c95:b0:3e9:1b9a:92b9 with SMTP id k21-20020a05600c1c9500b003e91b9a92b9mr1652671wms.8.1677269843067; Fri, 24 Feb 2023 12:17:23 -0800 (PST) MIME-Version: 1.0 From: Phil Cari Date: Fri, 24 Feb 2023 15:17:12 -0500 Message-ID: To: lwip-users@nongnu.org Content-Type: multipart/alternative; boundary="00000000000030483c05f577d1ae" Received-SPF: pass client-ip=2a00:1450:4864:20::334; envelope-from=junk.carip@gmail.com; helo=mail-wm1-x334.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 24 Feb 2023 16:28:26 -0500 Subject: [lwip-users] LwIP Project Question X-BeenThere: lwip-users@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for lwIP users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2023 20:17:27 -0000 --00000000000030483c05f577d1ae Content-Type: text/plain; charset="UTF-8" Hi everyone, I have some trouble compiling the lwIP project and using it in my project because it seems that the lwipopts.h can not be found. Is there something that I miss or don't understand? Thank you in advance for your help! Respectfully, Philippe --00000000000030483c05f577d1ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,
I have some trouble compiling the lwIP pr= oject and using it in my project because it seems that the lwipopts.h can n= ot be found. Is there something that I miss or don't understand?
<= div>Thank you=C2=A0in=C2=A0advance for=C2=A0your help!
Respectful= ly,
Philippe
--00000000000030483c05f577d1ae-- From MAILER-DAEMON Sat Feb 25 08:33:47 2023 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1pVugN-0000g5-IZ for mharc-lwip-users@gnu.org; Sat, 25 Feb 2023 08:33:47 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVugI-0000fO-Bp for lwip-users@nongnu.org; Sat, 25 Feb 2023 08:33:42 -0500 Received: from atreides.gradator.net ([212.85.155.42]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pVugG-0005DJ-L6 for lwip-users@nongnu.org; Sat, 25 Feb 2023 08:33:42 -0500 Received: from gradator by atreides.gradator.net with local (Exim 4.84_2) (envelope-from ) id 1pVug4-0000bq-5L for lwip-users@nongnu.org; Sat, 25 Feb 2023 14:33:28 +0100 Date: Sat, 25 Feb 2023 14:33:28 +0100 From: Sylvain Rochet To: Mailing list for lwIP users Message-ID: <20230225133328.GA1340@gradator.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gradator@atreides.gradator.net X-SA-Exim-Version: 4.2.1 (built Thu, 09 Jan 2020 16:15:24 +0000) X-SA-Exim-Scanned: Yes (on atreides.gradator.net) Received-SPF: none client-ip=212.85.155.42; envelope-from=gradator@atreides.gradator.net; helo=atreides.gradator.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action Subject: Re: [lwip-users] LwIP Project Question X-BeenThere: lwip-users@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for lwIP users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2023 13:33:46 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Phil, On Fri, Feb 24, 2023 at 03:17:12PM -0500, Phil Cari wrote: > Hi everyone, > I have some trouble compiling the lwIP project and using it in my project > because it seems that the lwipopts.h can not be found. Is there something > that I miss or don't understand? > Thank you in advance for your help! > Respectfully, > Philippe lwipopts.h is your configuration file that overwrite default values to=20 suit your needs. Default value can be seen in the src/include/lwip/opt.h=20 file. Some lwipopts.h examples are available in the contrib/ folder. It can=20 probably be empty if all default values are fine for you. Sylvain --ibTvN161/egqYuK8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAmP6DigACgkQDFub3qtEsS/jJwCdFXfH1efZPmybsDqpCuDdSWwG XU8AoJr1ZOoOQ5xgotcqx96JxtgpR1/U =dIWN -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- From MAILER-DAEMON Sat Feb 25 12:53:47 2023 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1pVyjz-0005Fq-M4 for mharc-lwip-users@gnu.org; Sat, 25 Feb 2023 12:53:47 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVyjy-0005Fi-Ju for lwip-users@nongnu.org; Sat, 25 Feb 2023 12:53:46 -0500 Received: from outmail149087.authsmtp.net ([62.13.149.87]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVyjv-0003bx-PU for lwip-users@nongnu.org; Sat, 25 Feb 2023 12:53:46 -0500 Received: from punt23.authsmtp.com (punt23.authsmtp.com [62.13.128.122]) by punt20.authsmtp.com. (8.15.2/8.15.2) with ESMTP id 31PHraNv087823 for ; Sat, 25 Feb 2023 17:53:36 GMT (envelope-from peter@peter2000.co.uk) Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt23.authsmtp.com. (8.15.2/8.15.2) with ESMTP id 31PHra35002570 for ; Sat, 25 Feb 2023 17:53:36 GMT (envelope-from peter@peter2000.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peter2000.co.uk; s=authsmtp; t=1677347616; bh=9BqdHbTtAvMC66vMeBAbCgQzHc2SgrMPKqHnUdNOZ/Q=; h=Date:From:To:Subject; b=G0OkHR5f/eFGS0kdc2lmERGHvELM0wMAjzMT50QCBlsGgh+3lU/r00KC6SAf1tdmu dpElebAfPJi0BgNIxGzowu53i7mQxnhovSofhv8HInRc996i/HNfKjBlrITcnEscAU mLbVPqMQAhjX/MfT0YNLQa9xUiHOgu3Iismz65jc= Received: from PETER-HOME (static-87-75-102-77.vodafonexdsl.co.uk [87.75.102.77]) (authenticated bits=0) by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPA id 31PHrZSW063153 for ; Sat, 25 Feb 2023 17:53:35 GMT (envelope-from peter@peter2000.co.uk) Message-Id: <202302251753.31PHrZSW063153@mail.authsmtp.com> From: Peter To: lwip-users@nongnu.org Date: Sat, 25 Feb 2023 17:53:40 +0000 Organization: - References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Server-Quench: 53b3f803-b535-11ed-9a18-7cd30ad786ce X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd0ZA4dC1ZNQRgX EAscATNNU199fkUK ChhFMAhMJEUITUFM KUtANXJVN1sTQ0wf XCRcFVZRTyskC3x3 awhSfQRaaE9NVQZs HkBOXFVXCgRoAwIG AQEcVwZyOQZHGAYy DyUFXnZYXUF5O0d5 QUZXW2gFN2Q2YGAc TRJddAZJcQIfKgJM O1F3SXReNWYHNy5n T1E4MiYLMGcXLDtU WkQQNl8IWg4nHzEx XAxGVQsoGQVfHHl3 Zz09MUMRVBh5 X-Authentic-SMTP: 61633734363838.1037:8335 X-AuthFastPath: 0 (Was 255) X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. Received-SPF: pass client-ip=62.13.149.87; envelope-from=peter@peter2000.co.uk; helo=outmail149087.authsmtp.net X-Spam_score_int: -28 X-Spam_score: -2.9 X-Spam_bar: -- X-Spam_report: (-2.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.094, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action Subject: Re: [lwip-users] lwip-users Digest, Vol 234, Issue 6 X-BeenThere: lwip-users@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for lwIP users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2023 17:53:47 -0000 >Subject: [lwip-users] LwIP Project Question Here is a sample lwipopts.h which I have spent made days or weeks on. It contains a lot of potentially useful comments. A lot of it won't apply to your project. The values override defaults in opt.h. I am running under FreeRTOS. LWIP has been largely abandoned now. It is very good but it is now over 15 years old and most of the people working on it have moved on, so getting support is hard. You can try e.g. here https://www.eevblog.com/forum/microcontrollers/anyone-here-familiar-with-= lwip/ /** *************************************************************************= ***** * @file LwIP/LwIP_HTTP_Server_Netconn_RTOS/Inc/lwipopts.h * @author MCD Application Team * @brief lwIP Options Configuration. *************************************************************************= ***** * * This sort of explains the memory usage * https://lwip-users.nongnu.narkive.com/dkzkPa8l/lwip-memory-settings * https://www.cnblogs.com/shangdawei/p/3494148.html * https://lwip.fandom.com/wiki/Tuning_TCP * https://groups.google.com/g/osdeve_mirror_tcpip_lwip/c/lFYJ7Fw0Cxg * ST UM1713 document gives an overview of integrating all this. * * * * * * * * */ #ifndef __LWIPOPTS_H__ #define __LWIPOPTS_H__ /** * NO_SYS=3D=3D1: Provides VERY minimal functionality. Otherwise, * use lwIP facilities. */ #define NO_SYS 0 // Flag to make LWIP API thread-safe. The netconn and socket APIs are claimed // to be thread-safe anyway. The raw API is never thread-safe. // A huge amount of online discussion on this topic; most of it unclear, but // ON (1) seems to be recommended, as being more efficient. #define LWIP_TCPIP_CORE_LOCKING 1 // If LWIP_TCPIP_CORE_LOCKING=3D0 then these two need to be 1 // See https://www.nongnu.org/lwip/2_1_x/multithreading.html //#define LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT 1 //#define SYS_LIGHTWEIGHT_PROT 1 // This places more objects into the static block defined by MEM_SIZE. // Uses mem_malloc/mem_free instead of the lwip pool allocator. // MEM_SIZE now needs to be increased by about 10k. // It doesn't magically produce extra memory, and causes crashes. // There is also a performance loss, apparently. AVOID. #define MEMP_MEM_MALLOC 0 //NC: Need for sending PING messages by keepalive #define LWIP_RAW 1 #define DEFAULT_RAW_RECVMBOX_SIZE 4 // For ETHSER #define LWIP_TCP_KEEPALIVE 1 /*-----------------------------------------------------------------------= ------*/ /* LwIP Stack Parameters (modified compared to initialization value in opt.h) -*/ /* Parameters set in STM32CubeMX LwIP Configuration GUI -*/ /*----- Value in opt.h for LWIP_DNS: 0 -----*/ #define LWIP_DNS 1 /* ---------- Memory options ---------- */ /* MEM_ALIGNMENT: should be set to the alignment of the CPU for which lwIP is compiled. 4 byte alignment -> define MEM_ALIGNMENT to 4, 2 byte alignment -> define MEM_ALIGNMENT to 2. */ #define MEM_ALIGNMENT 4 /* * MEM_SIZE: the size of the heap memory. This is a statically allocated block. You can find it * in the .map file as the symbol ram_heap and you can see how much of this RAM gets used. * If MEMP_MEM_MALLOC=3D0, this holds just the PBUF_ stuff. * If MEMP_MEM_MALLOC=3D1 (which is not reliable) this greatly expands and needs 16k+. * Empirically this needs to be big enough for at least 4 x PBUF_POOL_BUFSIZE. * This value also limits the biggest block size sent out by netconn_write. With a MEM_SIZE * of 6k, the biggest block netconn_write (and probably socket write) will send out is 4k. * This setting is mostly related to outgoing data. */ #define MEM_SIZE (6*1024) // MEMP_ structures. Their sizes have been determined experimentally, by // increasing them and seeing free RAM changing. /* MEMP_NUM_PBUF: the number of memp struct pbufs. If the application sends a lot of data out of ROM (or other static memory), this should be set high. */ //NC: Increased to 20 for ethser #define MEMP_NUM_PBUF 20 // each 1 is 20 bytes of static RAM /* MEMP_NUM_UDP_PCB: the number of UDP protocol control blocks. One per active UDP "connection". */ #define MEMP_NUM_UDP_PCB 6 // each 1 is 32 bytes of static RAM /* MEMP_NUM_TCP_PCB: the number of simultaneously active TCP connections. */ //NC: Increased to 20 for ethser #define MEMP_NUM_TCP_PCB 20 // each 1 is 145 bytes of static RAM //NC: Have more sockets available. Is set to 4 in opt.h #define MEMP_NUM_NETCONN 10 /* MEMP_NUM_TCP_PCB_LISTEN: the number of listening TCP connections. */ //NC: Increased to 20 for ethser #define MEMP_NUM_TCP_PCB_LISTEN 20 // each 1 is 28 bytes of static RAM /* MEMP_NUM_TCP_SEG: the number of simultaneously queued TCP segments. */ // Was 8; increased to 16 as it improves ETHSER reliability when running // HTTP server #define MEMP_NUM_TCP_SEG 16 // each 1 is 20 bytes of static RAM /* MEMP_NUM_SYS_TIMEOUT: the number of simulateously active timeouts. */ #define MEMP_NUM_SYS_TIMEOUT 10 // each 1 is 16 bytes of static RAM /* ---------- Pbuf dynamically allocated buffer blocks ---------- * * These settings make little difference to performance, which is dominated by * the low_level_input poll period. These PBUFs relate directly to the netconn API netbufs. * * PBUF_POOL_SIZE: the number of buffers in the pbuf pool. * Statically allocated, so each increment frees up 1.5k of RAM. Any value under 4 slows * down the data rate a lot. * 12/2/23 PH 4 -> 6 fixes TLS blocking of various RTOS tasks (5 almost does). * The most this can go to with TLS still having enough free RAM for its 48k block is ~9. */ #define PBUF_POOL_SIZE 6 /* PBUF_POOL_BUFSIZE: the size of each pbuf in the pbuf pool. ** It is better to use MTU sized bufs than 8 x 512 because in say EditGetData() you are ** ** much more likely to get the whole file header in the first packet. With 512 ** ** byte packets the CRLFCRLF marker is only ~64 bytes before the end of the pkt ** ** Same issue in UploadGetData where we need to get the whole header in. ** ** However the above issue has been largely solved with the 200ms wait in the http svr ** * The +2 is to get a multiple of 4 bytes so the PBUFs are 4-aligned (for memcpy_fast()) * Probably the +2 is not needed because the PBUFs are 4-aligned anyway in the LWIP code. */ #define PBUF_POOL_BUFSIZE 1500 + PBUF_LINK_ENCAPSULATION_HLEN + PBUF_LINK_HLEN + 2 /* ---------- TCP options ---------- */ #define LWIP_TCP 1 #define TCP_TTL 255 /* Controls if TCP should queue segments that arrive out of order. Define to 0 if your device is low on memory. */ #define TCP_QUEUE_OOSEQ 0 /* TCP Maximum segment size. */ #define TCP_MSS (1500 - 40) /* TCP_MSS =3D (Ethernet MTU - IP header size - TCP header size) */ /* TCP sender buffer space (bytes). */ // Reduced from 4*MSS to leave more room for TX packets in the LWIP heap (MEM_SIZE). #define TCP_SND_BUF (2*TCP_MSS) // no effect on static RAM /* TCP_SND_QUEUELEN: TCP sender buffer space (pbufs). This must be at least as much as (2 * TCP_SND_BUF/TCP_MSS) for things to work. */ // Was 2*; increased to 4* as it improves ETHSER reliability when running // HTTP server #define TCP_SND_QUEUELEN (4* TCP_SND_BUF/TCP_MSS) // (2* TCP_SND_BUF/TCP_MSS) /* TCP advertised receive window. */ // Should be less than PBUF_POOL_SIZE * (PBUF_POOL_BUFSIZE - protocol headers) #define TCP_WND (2*TCP_MSS) // no effect on static RAM /* ---------- ICMP options ---------- */ #define LWIP_ICMP 1 /* ---------- DHCP options ---------- */ #define LWIP_DHCP 1 /* ---------- UDP options ---------- */ #define LWIP_UDP 1 #define UDP_TTL 255 // These are build flags which disable the support for the SOF_BROADCAST option on raw and UDP PCBs // Commented-out because changing these requires a recompilation, and an application which receives // broadcast packets may one day be necessary (set g_eth_multi=3Dtrue to disable the packet filter in // ethernetif.c) //#define IP_SOF_BROADCAST 1 //#define IP_SOF_BROADCAST_RECV 1 /* ---------- Statistics options ---------- */ #define LWIP_STATS 0 /* ---------- link callback options ---------- */ /* LWIP_NETIF_LINK_CALLBACK=3D=3D1: Support a callback function from an interface * whenever the link changes (i.e., link down) * 8/2022 this is done from the low_level_input RTOS task. */ #define LWIP_NETIF_LINK_CALLBACK 0 /* -------------------------------------- ---------- Checksum options ---------- -------------------------------------- */ /*=20 The STM32F4xx allows computing and verifying the IP, UDP, TCP and ICMP checksums by hardware: - To use this feature let the following define uncommented. - To disable it and process by CPU comment the the checksum. */ #define CHECKSUM_BY_HARDWARE=20 #ifdef CHECKSUM_BY_HARDWARE /* CHECKSUM_GEN_IP=3D=3D0: Generate checksums by hardware for outgoing IP packets.*/ #define CHECKSUM_GEN_IP 0 /* CHECKSUM_GEN_UDP=3D=3D0: Generate checksums by hardware for outgoing UDP packets.*/ #define CHECKSUM_GEN_UDP 0 /* CHECKSUM_GEN_TCP=3D=3D0: Generate checksums by hardware for outgoing TCP packets.*/ #define CHECKSUM_GEN_TCP 0=20 /* CHECKSUM_CHECK_IP=3D=3D0: Check checksums by hardware for incoming = IP packets.*/ #define CHECKSUM_CHECK_IP 0 /* CHECKSUM_CHECK_UDP=3D=3D0: Check checksums by hardware for incoming UDP packets.*/ #define CHECKSUM_CHECK_UDP 0 /* CHECKSUM_CHECK_TCP=3D=3D0: Check checksums by hardware for incoming TCP packets.*/ #define CHECKSUM_CHECK_TCP 0 /* CHECKSUM_CHECK_ICMP=3D=3D0: Check checksums by hardware for incoming ICMP packets.*/ =20 #define CHECKSUM_GEN_ICMP 0 #else /* CHECKSUM_GEN_IP=3D=3D1: Generate checksums in software for outgoing IP packets.*/ #define CHECKSUM_GEN_IP 1 /* CHECKSUM_GEN_UDP=3D=3D1: Generate checksums in software for outgoing UDP packets.*/ #define CHECKSUM_GEN_UDP 1 /* CHECKSUM_GEN_TCP=3D=3D1: Generate checksums in software for outgoing TCP packets.*/ #define CHECKSUM_GEN_TCP 1 /* CHECKSUM_CHECK_IP=3D=3D1: Check checksums in software for incoming = IP packets.*/ #define CHECKSUM_CHECK_IP 1 /* CHECKSUM_CHECK_UDP=3D=3D1: Check checksums in software for incoming UDP packets.*/ #define CHECKSUM_CHECK_UDP 1 /* CHECKSUM_CHECK_TCP=3D=3D1: Check checksums in software for incoming TCP packets.*/ #define CHECKSUM_CHECK_TCP 1 /* CHECKSUM_CHECK_ICMP=3D=3D1: Check checksums by hardware for incoming ICMP packets.*/ =20 #define CHECKSUM_GEN_ICMP 1 #endif /* ---------------------------------------------- ---------- Sequential layer options ---------- ---------------------------------------------- */ /** * LWIP_NETCONN=3D=3D1: Enable Netconn API (require to use api_lib.c) */ #define LWIP_NETCONN 1 /* ------------------------------------ ---------- Socket options ---------- ------------------------------------ */ /** * LWIP_SOCKET=3D=3D1: Enable Socket API (require to use sockets.c) */ #define LWIP_SOCKET 1 /* ------------------------------------ ---------- httpd options ---------- ------------------------------------ */ /** Set this to 1 to include "fsdata_custom.c" instead of "fsdata.c" for the * file system (to prevent changing the file included in CVS) */ #define HTTPD_USE_CUSTOM_FSDATA 0 /* --------------------------------- ---------- OS options ---------- --------------------------------- */ #define TCPIP_THREAD_NAME "TCP/IP" #define TCPIP_THREAD_STACKSIZE 4096 #define TCPIP_MBOX_SIZE 6 #define DEFAULT_UDP_RECVMBOX_SIZE 6 #define DEFAULT_TCP_RECVMBOX_SIZE 6 #define DEFAULT_ACCEPTMBOX_SIZE 6 #define DEFAULT_THREAD_STACKSIZE 512 #define TCPIP_THREAD_PRIO osPriorityHigh // should be >=3D that of any TCP/IP apps #define LWIP_DEBUG 1 /* #define IP_DEBUG LWIP_DBG_ON #define DHCP_DEBUG LWIP_DBG_OFF #define UDP_DEBUG LWIP_DBG_ON #define SOCKET_DEBUG_LWIP_DBG_ON //#define ICMP_DEBUG LWIP_DBG_ON|LWIP_DBG_TRACE //#define NETIF_DEBUG LWIP_DBG_OFF #define LWIP_DBG_TYPES_ON (LWIP_DBG_TRACE|LWIP_DBG_STATE) */ #define LWIP_SO_RCVTIMEO 1 #define LWIP_NETIF_HOSTNAME 1 #define SO_REUSE 1 // Defining these produces various errors //#define LWIP_IPV6 1 //#define LWIP_IPV6_DHCP6 1 /* // TODO #ifdef LWIP_DEBUG #define MEMP_OVERFLOW_CHECK ( 1 ) #define MEMP_SANITY_CHECK ( 1 ) #define MEM_DEBUG LWIP_DBG_OFF #define MEMP_DEBUG LWIP_DBG_OFF #define PBUF_DEBUG LWIP_DBG_ON #define API_LIB_DEBUG LWIP_DBG_ON #define API_MSG_DEBUG LWIP_DBG_ON #define TCPIP_DEBUG LWIP_DBG_ON #define NETIF_DEBUG LWIP_DBG_ON #define SOCKETS_DEBUG LWIP_DBG_ON #define DEMO_DEBUG LWIP_DBG_ON #define IP_DEBUG LWIP_DBG_ON #define IP6_DEBUG LWIP_DBG_ON #define IP_REASS_DEBUG LWIP_DBG_ON #define RAW_DEBUG LWIP_DBG_ON #define ICMP_DEBUG LWIP_DBG_ON #define UDP_DEBUG LWIP_DBG_ON #define TCP_DEBUG LWIP_DBG_ON #define TCP_INPUT_DEBUG LWIP_DBG_ON #define TCP_OUTPUT_DEBUG LWIP_DBG_ON #define TCP_RTO_DEBUG LWIP_DBG_ON #define TCP_CWND_DEBUG LWIP_DBG_ON #define TCP_WND_DEBUG LWIP_DBG_ON #define TCP_FR_DEBUG LWIP_DBG_ON #define TCP_QLEN_DEBUG LWIP_DBG_ON #define TCP_RST_DEBUG LWIP_DBG_ON #define PPP_DEBUG LWIP_DBG_OFF #define LWIP_DBG_TYPES_ON (LWIP_DBG_ON|LWIP_DBG_TRACE|LWIP_DBG_STATE|LWIP_DBG_FRESH|LWIP_DBG_HALT) #endif */ #endif /* __LWIPOPTS_H__ */ From MAILER-DAEMON Sat Feb 25 13:34:10 2023 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1pVzN4-0005Uo-51 for mharc-lwip-users@gnu.org; Sat, 25 Feb 2023 13:34:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVzN2-0005Uc-Cl for lwip-users@nongnu.org; Sat, 25 Feb 2023 13:34:08 -0500 Received: from atreides.gradator.net ([212.85.155.42]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pVzN0-0000tK-7g for lwip-users@nongnu.org; Sat, 25 Feb 2023 13:34:08 -0500 Received: from gradator by atreides.gradator.net with local (Exim 4.84_2) (envelope-from ) id 1pVzMs-0002HF-Jk; Sat, 25 Feb 2023 19:33:59 +0100 Date: Sat, 25 Feb 2023 19:33:58 +0100 From: Sylvain Rochet To: Mailing list for lwIP users , Peter Message-ID: <20230225183358.GA5513@gradator.net> References: <202302251753.31PHrZSW063153@mail.authsmtp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: <202302251753.31PHrZSW063153@mail.authsmtp.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gradator@atreides.gradator.net X-SA-Exim-Version: 4.2.1 (built Thu, 09 Jan 2020 16:15:24 +0000) X-SA-Exim-Scanned: Yes (on atreides.gradator.net) Received-SPF: none client-ip=212.85.155.42; envelope-from=gradator@atreides.gradator.net; helo=atreides.gradator.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action Subject: Re: [lwip-users] lwip-users Digest, Vol 234, Issue 6 X-BeenThere: lwip-users@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for lwIP users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2023 18:34:08 -0000 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Peter, On Sat, Feb 25, 2023 at 05:53:40PM +0000, Peter wrote: >=20 > >Subject: [lwip-users] LwIP Project Question >=20 > Here is a sample lwipopts.h which I have spent made days or weeks on. > It contains a lot of potentially useful comments. No one should spend days or weeks on their lwipopts.h, embedded=20 documentation in opt.h is pretty good IMHO and most options are self=20 explanatory anyway. > LWIP has been largely abandoned now. It is very good but it is now > over 15 years old and most of the people working on it have moved on, > so getting support is hard. There is actually a reply from a lwIP developer to Phil's question,=20 maybe you should revisit your assumption. And please stop replying to the digest, it breaks mail threads and makes=20 it hard to follow up. Sylvain --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAmP6VJYACgkQDFub3qtEsS9MXACgz7zu8eAChqzPRra1tujkia+4 NF8AoJF/Llp4Bd2j4a3vUCNhUCqtGhKW =YPIs -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- From MAILER-DAEMON Sun Feb 26 11:02:22 2023 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1pWJTb-000571-7U for mharc-lwip-users@gnu.org; Sun, 26 Feb 2023 11:02:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pWDdw-0005aL-DY for lwip-users@nongnu.org; Sun, 26 Feb 2023 04:48:32 -0500 Received: from mail-oi1-x22b.google.com ([2607:f8b0:4864:20::22b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pWDdu-0000Cm-OH for lwip-users@nongnu.org; Sun, 26 Feb 2023 04:48:32 -0500 Received: by mail-oi1-x22b.google.com with SMTP id e21so3084696oie.1 for ; Sun, 26 Feb 2023 01:48:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=6oRaGIHKdOHPcaJNtvtZ0Ko4HjxMfbFDpj0dyGSveEw=; b=CL65ZDqVajV9DTTwFDNvhtdatn3gNVO6uZFXYym4tkUOGGW81zCWyYpdEZTHkYUwsF i0W1VxUV9NUMXQcqjSDbvI81OMlf7dWwgeYdDLt2H06L1gvXBZHWtzrqy8Zpo3hGtg7K H5O1YZpNTzvK7dLPkw3dDj36ae6r2E0TlA9wpmt3SDKZxKhSXKYCJjL9qoQJfwDszXke CLgQtPoRTcNpSjSRXvxhqSMf9uoRG0yjcTe3CUwWR0UW1gv72G6WzvkdNgHXV7MLywwi rgHJ3DPQXYSR48pJdQavTVzuZaPFCBpkDSiW1xVcAPpwaDhRuDuGiT/i4VN1LHQeEyOF g6UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=6oRaGIHKdOHPcaJNtvtZ0Ko4HjxMfbFDpj0dyGSveEw=; b=PWvYw2VQ6Qx8IKc6MNoQO1mzIun2gWufLZZLRzivghvhXLuqV3knW0EIe/SqiQ6qL7 tqS+HG3/M3BzhoSr4IWXIlh6WmiG8LOvXaWox7H4ZdAhnXkg+JOP4HhtORwoWpbGpGMG 7vPLSjgPipEW/Eke5G0lyZFOykTiUn68vV/1E2apHTIZToozGAsn7oZGkk/vV+v+yh+L oT5zrT8Nx0w/JfFox2uF7nZE3M7mGu/lOnR1QrqdEtIhjAi5xgDF//f++9zMs9O33XZr 4cGFKEvFJ3rt5d5XFlRnRUKroprAxr3Xy5QKHeRhDA49MHE/bkz5bfqMovb1sSB0z/PR EI8A== X-Gm-Message-State: AO0yUKUndCwuQMevi1DvdMi8mYRvzEyhXotaiiG82S16b+exgdXWzzBr Wc88230DtaCGR9KShFctwoRmYDRCBL8UTkiPA5/nVa20ooWp/g== X-Google-Smtp-Source: AK7set/nR50r4K64ObeE096gT5pycdXnNVjIWr2eE6414oFr+khrP7nR5b0OdkXyzLV1olSB5Z8KjKM/wYGjVgU5qio= X-Received: by 2002:aca:2418:0:b0:383:f5df:9e85 with SMTP id n24-20020aca2418000000b00383f5df9e85mr1960986oic.4.1677404908709; Sun, 26 Feb 2023 01:48:28 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?B?15PXldeoINeb15TXnw==?= Date: Sun, 26 Feb 2023 11:48:17 +0200 Message-ID: To: lwip-users@nongnu.org Content-Type: multipart/alternative; boundary="000000000000ba6cbe05f597439f" Received-SPF: pass client-ip=2607:f8b0:4864:20::22b; envelope-from=dorafifitcohen@gmail.com; helo=mail-oi1-x22b.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 26 Feb 2023 11:02:11 -0500 Subject: [lwip-users] Multiple IPs and VLAN tagging X-BeenThere: lwip-users@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for lwIP users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2023 09:48:32 -0000 --000000000000ba6cbe05f597439f Content-Type: text/plain; charset="UTF-8" Hello, I am trying to support multiple ips in my embedded application. I have followed what I found out and enabled LWIP_ARP_FILTER_NETIF and implemented LWIP_ARP_FILTER_NETIF_FN as documented. I also want it to work along VLAN. Here is my function hook for LWIP_ARP_FILTER_NETIF_FN: struct netif* find_netif_based_on_dest_ip(struct pbuf *p, u16_t type, struct netif* source_netif){ ip4_addr_t dest; struct netif* netif; s16_t ip_hdr_offset = SIZEOF_ETH_HDR; #if ETHARP_SUPPORT_VLAN struct eth_hdr* ethhdr = (struct eth_hdr *)p->payload; if ( ethhdr->type == PP_HTONS(ETHTYPE_VLAN)) { ip_hdr_offset += SIZEOF_VLAN_HDR; } #endif //ETHARP_SUPPORT_VLAN void* temp_pbuf = (u8_t *)p->payload + ip_hdr_offset; if(type == PP_HTONS(ETHTYPE_ARP)){ struct etharp_hdr *ethhdr = (struct etharp_hdr *)temp_pbuf; IPADDR2_COPY(&dest, ðhdr->dipaddr); } else if(type == PP_HTONS(ETHTYPE_IP)){ struct ip_hdr *iphdr = (struct ip_hdr *)temp_pbuf; ip_addr_copy_from_ip4(dest, iphdr->dest); } else { return source_netif; } for (netif = netif_list; netif != NULL; netif = netif->next) { if (netif_is_up(netif) && netif_is_link_up(netif) && !ip4_addr_isany_val(*netif_ip4_addr(netif))) { u8_t for_us = (u8_t)ip4_addr_cmp(&dest, netif_ip4_addr(netif)); if(for_us){ break; } } } return netif == NULL ? source_netif : netif; } (pastebin link if you want to read it like a normal person: https://pastebin.com/GdzBJYv2). Have I missed anything? It seems to work on my minimal setup, but before we start developing our application I thought a quick check with you might help. Sorry if that is not the right communication method to ask, if not where one might ask? Thank you! Dor --000000000000ba6cbe05f597439f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,=C2=A0
I am t= rying to support multiple ips in my embedded application. I have followed w= hat I found out and enabled=C2=A0LWIP_ARP_FILTER_NETIF and implemented=C2= =A0LWIP_ARP_FILTER_NETIF_FN as documented.
I also wan= t it to work along VLAN.

H= ere is my function hook for=C2=A0LWIP_ARP_FILTER_NETIF_FN:


struct netif* find_netif_based_on_dest= _ip(struct pbuf *p, u16_t type, struct netif* source_netif){ =C2=A0
=C2= =A0 ip4_addr_t dest;
=C2=A0 struct netif* netif;
=C2=A0 s16_t ip_hdr_= offset =3D SIZEOF_ETH_HDR;
=C2=A0
#if ETHARP_SUPPORT_VLAN
=C2=A0 = =C2=A0 struct eth_hdr* ethhdr =3D (struct eth_hdr *)p->payload;
=C2= =A0 =C2=A0 if ( ethhdr->type =3D=3D PP_HTONS(ETHTYPE_VLAN)) {
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 ip_hdr_offset +=3D SIZEOF_VLAN_HDR;
=C2=A0 =C2=A0 }=
#endif //ETHARP_SUPPORT_VLAN
=C2=A0 void* temp_pbuf =3D (u8_t *)p-&g= t;payload + ip_hdr_offset;
=C2=A0 if(type =3D=3D PP_HTONS(ETHTYPE_ARP)){=
=C2=A0 =C2=A0 =C2=A0 struct etharp_hdr *ethhdr =3D (struct etharp_hdr *= )temp_pbuf;
=C2=A0 =C2=A0 =C2=A0 IPADDR2_COPY(&dest, &ethhdr->= ;dipaddr);
=C2=A0 }
=C2=A0 else if(type =3D=3D PP_HTONS(ETHTYPE_IP)){=
=C2=A0 =C2=A0 struct ip_hdr *iphdr =3D (struct ip_hdr *)temp_pbuf;
= =C2=A0 =C2=A0 ip_addr_copy_from_ip4(dest, iphdr->dest);
=C2=A0 }
= =C2=A0 else {
=C2=A0 =C2=A0 return source_netif;
=C2=A0 }
=C2=A0 <= br>=C2=A0 for (netif =3D netif_list; netif !=3D NULL; netif =3D netif->n= ext) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (netif_is_up(netif) && net= if_is_link_up(netif) && !ip4_addr_isany_val(*netif_ip4_addr(netif))= ) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 u8_t for_us =3D (u8_t)ip4_= addr_cmp(&dest, netif_ip4_addr(netif));
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 if(for_us){
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 break;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 return netif =3D= =3D NULL ? source_netif : netif;
}
(pastebin l= ink if you want to read it like a normal person:=C2=A0https://pastebin.com/GdzBJYv2).

Have I missed anything? It seems to work on = my minimal setup, but before we start developing our application I thought = a quick check with you might help.
Sorry if that is n= ot the right communication method to ask, if not where one might ask?

Thank you!

Dor
--000000000000ba6cbe05f597439f--