From MAILER-DAEMON Thu Nov 03 09:57:14 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oqaiY-0007V5-Hi for mharc-lwip-users@gnu.org; Thu, 03 Nov 2022 09:57:14 -0400 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 1oqY5J-0001cF-U1 for lwip-users@nongnu.org; Thu, 03 Nov 2022 07:08:39 -0400 Received: from mx6.didiglobal.com ([111.202.70.123]) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1oqY5I-0001qx-0y for lwip-users@nongnu.org; Thu, 03 Nov 2022 07:08:33 -0400 Received: from mail.didiglobal.com (unknown [10.79.71.34]) by mx6.didiglobal.com (Maildata Gateway V2.8) with ESMTPS id 130E511009C00B for ; Thu, 3 Nov 2022 19:08:27 +0800 (CST) Received: from ZJY03-ACTMBX-03.didichuxing.com (10.79.71.32) by ZJY03-ACTMBX-04.didichuxing.com (10.79.71.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17; Thu, 3 Nov 2022 19:08:26 +0800 Received: from ZJY03-ACTMBX-03.didichuxing.com ([fe80::75de:288:d217:7e3]) by ZJY03-ACTMBX-03.didichuxing.com ([fe80::75de:288:d217:7e3%3]) with mapi id 15.01.2375.017; Thu, 3 Nov 2022 19:08:26 +0800 X-MD-Sfrom: jeffliuyue@didiglobal.com X-MD-SrcIP: 10.79.71.34 From: =?gb2312?B?wfXUviBKZWZmIExpdQ==?= To: "lwip-users@nongnu.org" Thread-Topic: [lwip-users] About the problem of merging master branch with STABLE-2_1_x. Thread-Index: AdjvdJOE3TPMFN1MTSGbh8TTwnwSZg== Date: Thu, 3 Nov 2022 11:08:26 +0000 Message-ID: <4af0509cbbdc44e89595242a16fd4d7c@didiglobal.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.79.71.102] Content-Type: multipart/alternative; boundary="_000_4af0509cbbdc44e89595242a16fd4d7cdidiglobalcom_" MIME-Version: 1.0 Received-SPF: pass client-ip=111.202.70.123; envelope-from=jeffliuyue@didiglobal.com; helo=mx6.didiglobal.com X-Spam_score_int: 33 X-Spam_score: 3.3 X-Spam_bar: +++ X-Spam_report: (3.3 / 5.0 requ) BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HK_RANDOM_ENVFROM=0.999, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 03 Nov 2022 09:57:12 -0400 Subject: [lwip-users] About the problem of merging master branch with STABLE-2_1_x. 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, 03 Nov 2022 11:08:42 -0000 --_000_4af0509cbbdc44e89595242a16fd4d7cdidiglobalcom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQWxsOw0KSSB3YW50IHRvIGtub3cgdGhlIGdpdCBkZXZlbG9wbWVudCBhbmQgbWVyZ2luZyBz dHJhdGVneSBvZiBsd2lwLiBJIGxlYXJuZWQgZnJvbSBnaXQgdGhhdCBsd2lwIGN1cnJlbnRseSBo YXMgc2V2ZXJhbCBicmFuY2hlcywgb25lIGlzIHRoZSBtYXN0ZXIgYnJhbmNoIGFuZCB0aGUgb3Ro ZXIgaXMgdGhlIFNUQUJMRS0yXzFfeCBicmFuY2gsIGFuZCB0aGVuIEkgc2VsZWN0ZWQgdGhlIFNU QUJMRS0yXzFfMyB0YWcgdG8gY29tcGFyZSB3aXRoIHRoZSBtYXN0ZXIsICBJIGZvdW5kIGFuIGlu dGVyZXN0aW5nIHRoaW5nIGluIHRoZSBzdWJtaXNzaW9uIG9mIHRoZSBicmFuY2guIFRoZSBidWcg b3IgYWRkZWQgZnVuY3Rpb24gb2YgdGhlIG1hc3RlciBicmFuY2ggd2lsbCBiZSBtZXJnZWQgaW50 byB0aGUgcmVsZWFzZSBicmFuY2ggdmVyeSBsYXRlLiBJIHdhbnQgdG8ga25vdyB0aGUgZGlmZmVy ZW5jZSBiZXR3ZWVuIHRoZSBtYXN0ZXIgYnJhbmNoIGFuZCB0aGUgU1RBQkxFLTJfMV94IGJyYW5j aCwgYW5kIGhvdyB0byBtYW5hZ2UgaXQuDQpGb3IgZXhhbXBsZTogdGhpcyBjb21taXQgb2YgbWFz dGVyIGJyYW5jaCAiRml4IGJ1ZyAjNTQ4MDU6IElQIGFkZHJlc3MgY2FuIG5vdCBiZSBvYnRhaW5l ZCBvdmVyIGRoY3AgaWYgUEJVRl9QT09MX0JVRlNJWkUgaXMgdG9vIHNtYWxsIiwgMjAxOC0xMC0x OSBoYXMgYmVlbiBzdWJtaXR0ZWQsIGJ1dCBpbiBTVEFCTEUtMl8xX3ggdW50aWwgMjAyMS0xMC0w MyB3YXMgbWVyZ2VkLCBhbmQgd2h5IGRpZCBtYW55IGNoYW5nZXMgaW4gdGhlIG1hc3RlciBicmFu Y2ggbm90IGVudGVyIHRoZSBTVEFCTEUtMl8xX3ggYnJhbmNoIGluIHRpbWU/DQpJIGFtIGN1cnJl bnRseSBkZXZlbG9waW5nIGJhc2VkIG9uIHRoZSBTVEFCTEUtMl8xXzNfUkVMRUFTRSBicmFuY2gs IGFuZCB0aGVuIEkgd2FudCB0byB1cGRhdGUgc29tZSBidWcgZml4ZXMgZnJvbSB0aGUgbWFzdGVy IGJyYW5jaCwgc28gSSBmb3VuZCB0aGUgYWJvdmUgcHJvYmxlbSwgd2hhdCBzaG91bGQgSSBkbz8N Ck9yIGNhbiBJIG9ubHkgZGV2ZWxvcCBiYXNlZCBvbiBTVEFCTEUtMl8xXzNfUkVMRUFTRSBhbmQg bWFzdGVyIGJyYW5jaCBjYW5ub3QgYmUgbWVyZ2VkIHdpdGggU1RBQkxFLTJfMV94Pw0KDQpUaGFu a3MuDQpKZWZmDQo= --_000_4af0509cbbdc44e89595242a16fd4d7cdidiglobalcom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi All;

I want to k= now the git development and merging strategy of lwip. I learned from git th= at lwip currently has several branches, one is the master branch and the ot= her is the STABLE-2_1_x branch, and then I selected the STABLE-2_1_3 tag to compare with the master, =  I found an interesting thing in the submission of= the branch. The bug or added function of the master branch will be merged into the release branch very late. I want to = know the difference between the master branch and the STABLE-2_1_x branch, = and how to manage it.

For example= : this commit of master branch "Fix bug #54805: IP address can not be = obtained over dhcp if PBUF_POOL_BUFSIZE is too small", 2018-10-19 has = been submitted, but in STABLE-2_1_x until 2021-10-03 was merged, and why did many changes in the master branch not enter the ST= ABLE-2_1_x branch in time?

I am currently developing based on the STABLE-2_1_3_RELEASE b= ranch, and then I want to update some bug fixes from the master branch, so = I found the above problem, what should I do?

Or can I only develop based on STABLE-2_1_3_RELEASE and maste= r branch cannot be merged with STABLE-2_1_x?

 =

Thanks.

Jeff=

--_000_4af0509cbbdc44e89595242a16fd4d7cdidiglobalcom_-- From MAILER-DAEMON Thu Nov 03 09:57:15 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oqaiZ-0007VW-6x for mharc-lwip-users@gnu.org; Thu, 03 Nov 2022 09:57:15 -0400 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 1oqWeA-0003nY-7m for lwip-users@nongnu.org; Thu, 03 Nov 2022 05:36:29 -0400 Received: from mx6.didiglobal.com ([111.202.70.123]) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1oqWe6-0004Jh-Su for lwip-users@nongnu.org; Thu, 03 Nov 2022 05:36:25 -0400 Received: from mail.didiglobal.com (unknown [10.79.64.14]) by mx6.didiglobal.com (Maildata Gateway V2.8) with ESMTPS id B4C9211009C006 for ; Thu, 3 Nov 2022 17:36:10 +0800 (CST) Received: from ZJY03-ACTMBX-03.didichuxing.com (10.79.71.32) by ZJY01-ACTMBX-04.didichuxing.com (10.79.64.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17; Thu, 3 Nov 2022 17:36:10 +0800 Received: from ZJY03-ACTMBX-03.didichuxing.com ([fe80::75de:288:d217:7e3]) by ZJY03-ACTMBX-03.didichuxing.com ([fe80::75de:288:d217:7e3%3]) with mapi id 15.01.2375.017; Thu, 3 Nov 2022 17:36:10 +0800 X-MD-Sfrom: jeffliuyue@didiglobal.com X-MD-SrcIP: 10.79.64.14 From: =?gb2312?B?wfXUviBKZWZmIExpdQ==?= To: "lwip-users@nongnu.org" Thread-Topic: About the problem of merging master branch with STABLE-2_1_x. Thread-Index: AdjvZ5PUMyJNaUD/RYuJirI8p7ig6Q== Date: Thu, 3 Nov 2022 09:36:10 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.79.71.102] Content-Type: multipart/alternative; boundary="_000_dd08869c38c243e08e3043f227afc57adidiglobalcom_" MIME-Version: 1.0 Received-SPF: pass client-ip=111.202.70.123; envelope-from=jeffliuyue@didiglobal.com; helo=mx6.didiglobal.com X-Spam_score_int: 33 X-Spam_score: 3.3 X-Spam_bar: +++ X-Spam_report: (3.3 / 5.0 requ) BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HK_RANDOM_ENVFROM=0.999, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 03 Nov 2022 09:57:12 -0400 Subject: [lwip-users] About the problem of merging master branch with STABLE-2_1_x. 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, 03 Nov 2022 09:36:29 -0000 --_000_dd08869c38c243e08e3043f227afc57adidiglobalcom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQWxsOw0KSSB3YW50IHRvIGtub3cgdGhlIGdpdCBkZXZlbG9wbWVudCBhbmQgbWVyZ2luZyBz dHJhdGVneSBvZiBsd2lwLiBJIGxlYXJuZWQgZnJvbSBnaXQgdGhhdCBsd2lwIGN1cnJlbnRseSBo YXMgc2V2ZXJhbCBicmFuY2hlcywgb25lIGlzIHRoZSBtYXN0ZXIgYnJhbmNoIGFuZCB0aGUgb3Ro ZXIgaXMgdGhlIFNUQUJMRS0yXzFfeCBicmFuY2gsIGFuZCB0aGVuIEkgc2VsZWN0ZWQgdGhlIFNU QUJMRS0yXzFfMyB0YWcgdG8gY29tcGFyZSB3aXRoIHRoZSBtYXN0ZXIsICBJIGZvdW5kIGFuIGlu dGVyZXN0aW5nIHRoaW5nIGluIHRoZSBzdWJtaXNzaW9uIG9mIHRoZSBicmFuY2guIFRoZSBidWcg b3IgYWRkZWQgZnVuY3Rpb24gb2YgdGhlIG1hc3RlciBicmFuY2ggd2lsbCBiZSBtZXJnZWQgaW50 byB0aGUgcmVsZWFzZSBicmFuY2ggdmVyeSBsYXRlLiBJIHdhbnQgdG8ga25vdyB0aGUgZGlmZmVy ZW5jZSBiZXR3ZWVuIHRoZSBtYXN0ZXIgYnJhbmNoIGFuZCB0aGUgU1RBQkxFLTJfMV94IGJyYW5j aCwgYW5kIGhvdyB0byBtYW5hZ2UgaXQuDQpGb3IgZXhhbXBsZTogdGhpcyBjb21taXQgb2YgbWFz dGVyIGJyYW5jaCAiRml4IGJ1ZyAjNTQ4MDU6IElQIGFkZHJlc3MgY2FuIG5vdCBiZSBvYnRhaW5l ZCBvdmVyIGRoY3AgaWYgUEJVRl9QT09MX0JVRlNJWkUgaXMgdG9vIHNtYWxsIiwgMjAxOC0xMC0x OSBoYXMgYmVlbiBzdWJtaXR0ZWQsIGJ1dCBpbiBTVEFCTEUtMl8xX3ggdW50aWwgMjAyMS0xMC0w MyB3YXMgbWVyZ2VkLCBhbmQgd2h5IGRpZCBtYW55IGNoYW5nZXMgaW4gdGhlIG1hc3RlciBicmFu Y2ggbm90IGVudGVyIHRoZSBTVEFCTEUtMl8xX3ggYnJhbmNoIGluIHRpbWU/DQpJIGFtIGN1cnJl bnRseSBkZXZlbG9waW5nIGJhc2VkIG9uIHRoZSBTVEFCTEUtMl8xXzNfUkVMRUFTRSBicmFuY2gs IGFuZCB0aGVuIEkgd2FudCB0byB1cGRhdGUgc29tZSBidWcgZml4ZXMgZnJvbSB0aGUgbWFzdGVy IGJyYW5jaCwgc28gSSBmb3VuZCB0aGUgYWJvdmUgcHJvYmxlbSwgd2hhdCBzaG91bGQgSSBkbz8N Ck9yIGNhbiBJIG9ubHkgZGV2ZWxvcCBiYXNlZCBvbiBTVEFCTEUtMl8xXzNfUkVMRUFTRSBhbmQg bWFzdGVyIGJyYW5jaCBjYW5ub3QgYmUgbWVyZ2VkIHdpdGggU1RBQkxFLTJfMV94Pw0KDQpUaGFu a3MuDQpKZWZmDQo= --_000_dd08869c38c243e08e3043f227afc57adidiglobalcom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi All;

I want to k= now the git development and merging strategy of lwip. I learned from git th= at lwip currently has several branches, one is the master branch and the ot= her is the STABLE-2_1_x branch, and then I selected the STABLE-2_1_3 tag to compare with the master, =  I found an interesting thing in the submission of= the branch. The bug or added function of the master branch will be merged into the release branch very late. I want to = know the difference between the master branch and the STABLE-2_1_x branch, = and how to manage it.

For example= : this commit of master branch "Fix bug #54805: IP address can not be = obtained over dhcp if PBUF_POOL_BUFSIZE is too small", 2018-10-19 has = been submitted, but in STABLE-2_1_x until 2021-10-03 was merged, and why did many changes in the master branch not enter the ST= ABLE-2_1_x branch in time?

I am currently developing based on the STABLE-2_1_3_RELEASE b= ranch, and then I want to update some bug fixes from the master branch, so = I found the above problem, what should I do?

Or can I only develop based on STABLE-2_1_3_RELEASE and maste= r branch cannot be merged with STABLE-2_1_x?

 =

Thanks.

Jeff=

--_000_dd08869c38c243e08e3043f227afc57adidiglobalcom_-- From MAILER-DAEMON Thu Nov 03 10:18:33 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oqb3B-0002k3-Qc for mharc-lwip-users@gnu.org; Thu, 03 Nov 2022 10:18:33 -0400 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 1oqb3A-0002jw-EA for lwip-users@nongnu.org; Thu, 03 Nov 2022 10:18:32 -0400 Received: from vps19.webwerkers.nl ([136.144.231.178]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqb38-0007Vf-MX for lwip-users@nongnu.org; Thu, 03 Nov 2022 10:18:32 -0400 Received: from [89.255.59.226] (helo=server.mep) by vps19.webwerkers.nl with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1oqb2v-0000xQ-Bg; Thu, 03 Nov 2022 15:18:17 +0100 Received: from _ (localhost [127.0.0.1]) by server.mep (Postfix) with ESMTPA id BDA9460042; Thu, 3 Nov 2022 15:17:21 +0100 (CET) MIME-Version: 1.0 Date: Thu, 03 Nov 2022 15:17:21 +0100 From: Indan Zupancic To: Mailing list for lwIP users Cc: =?UTF-8?Q?=E5=88=98=E8=B7=83_Jeff_Liu?= In-Reply-To: <4af0509cbbdc44e89595242a16fd4d7c@didiglobal.com> References: <4af0509cbbdc44e89595242a16fd4d7c@didiglobal.com> Message-ID: <954b9e8a0f8a12dd5bbf0338588799e5@mep-info.com> X-Sender: indan.zupancic@mep-info.com User-Agent: Roundcube Webmail/1.3.16 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-Id: meptelco Received-SPF: pass client-ip=136.144.231.178; envelope-from=indan.zupancic@mep-info.com; helo=vps19.webwerkers.nl 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_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action Subject: Re: [lwip-users] About the problem of merging master branch with STABLE-2_1_x. 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, 03 Nov 2022 14:18:33 -0000 Hello Jeff, On 2022-11-03 12:08, 刘跃 Jeff Liu wrote: > I want to know the git development and merging strategy of lwip. Releases are made when one of the maintainers have time, but they didn't get to it for a while. > I am currently developing based on the STABLE-2_1_3_RELEASE branch, and > then I want to update > some bug fixes from the master branch, so I found the above problem, > what should I do? > > Or can I only develop based on STABLE-2_1_3_RELEASE and master branch > cannot be merged with STABLE-2_1_x? Just use master, as you noticed it's in better shape than the release. Greetings, Indan From MAILER-DAEMON Thu Nov 03 23:21:02 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oqnGQ-0000sL-3h for mharc-lwip-users@gnu.org; Thu, 03 Nov 2022 23:21:02 -0400 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 1oqnGN-0000s6-QA for lwip-users@nongnu.org; Thu, 03 Nov 2022 23:20:59 -0400 Received: from mx6.didiglobal.com ([111.202.70.123]) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1oqnGL-0004Be-V2 for lwip-users@nongnu.org; Thu, 03 Nov 2022 23:20:59 -0400 Received: from mail.didiglobal.com (unknown [10.79.65.14]) by mx6.didiglobal.com (Maildata Gateway V2.8) with ESMTPS id 1B50F11009C02A; Fri, 4 Nov 2022 11:20:52 +0800 (CST) Received: from ZJY03-ACTMBX-03.didichuxing.com (10.79.71.32) by ZJY02-ACTMBX-04.didichuxing.com (10.79.65.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17; Fri, 4 Nov 2022 11:20:51 +0800 Received: from ZJY03-ACTMBX-03.didichuxing.com ([fe80::75de:288:d217:7e3]) by ZJY03-ACTMBX-03.didichuxing.com ([fe80::75de:288:d217:7e3%3]) with mapi id 15.01.2375.017; Fri, 4 Nov 2022 11:20:51 +0800 X-MD-Sfrom: jeffliuyue@didiglobal.com X-MD-SrcIP: 10.79.65.14 From: =?utf-8?B?5YiY6LeDIEplZmYgTGl1?= To: Indan Zupancic , Mailing list for lwIP users Thread-Topic: [lwip-users] About the problem of merging master branch with STABLE-2_1_x. Thread-Index: Adjv/Esi3TPMFN1MTSGbh8TTwnwSZg== Date: Fri, 4 Nov 2022 03:20:51 +0000 Message-ID: <8090e2eb93e54f0789156525a718dea0@didiglobal.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.79.71.102] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Received-SPF: pass client-ip=111.202.70.123; envelope-from=jeffliuyue@didiglobal.com; helo=mx6.didiglobal.com X-Spam_score_int: 1 X-Spam_score: 0.1 X-Spam_bar: / X-Spam_report: (0.1 / 5.0 requ) BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.999, HK_RANDOM_FROM=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action Subject: Re: [lwip-users] About the problem of merging master branch with STABLE-2_1_x. 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, 04 Nov 2022 03:21:00 -0000 SGkgSW5kYW4sDQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXBseS4gSSBoYXZlIGFub3RoZXIgcXVl c3Rpb24uIER1cmluZyB0aGUgc2FtZSBwZXJpb2Qgb2YgdGltZSwgdGhlcmUgd2VyZSBtYW55IGJ1 ZyBmaXhlcyBpbiB0aGUgbWFzdGVyIGJyYW5jaCwgd2h5IHNvbWUgYnVnIGZpeGVzIHdlcmUgbm90 IG1lcmdlZCBpbnRvIHRoZSByZWxlYXNlIGJyYW5jaCwgYnV0IHNvbWUgZml4ZXMgY29tbWl0cyB3 ZXJlIG1lcmdlZCBpbnRvIGl0LiBXaGF0IGlzIHRoZSBiYXNpcyBmb3IgZG9pbmcgdGhpcywgZm9y IGV4YW1wbGU6ICIyMDE4LTExLTEzIEZpeCBidWcgIzU1MDE3OiBXcm9uZyByZXR1cm4gdmFsdWUg aW4gc3lzX2FyY2hfbWJveF90cnlmZXRjaCgpIGluIEZyZWVSVE9TIHBvcnQiLCB0aGlzIGNvbW1p dCBvbmx5IGV4aXN0cyBpbiB0aGUgbWFzdGVyIGJyYW5jaCwgYnV0IG5vdCBpbiB0aGUgcmVsZWFz ZSBicmFuY2guDQpBbmQgSSBmb3VuZCB0aGF0IHNpbmNlIFNUQUJMRS0yXzFfMF9SRUxFQVNFLCB0 aGUgdHdvIGJyYW5jaGVzIG9mIFNUQUJMRS0yXzFfeCBhbmQgbWFzdGVyIGFyZSB2ZXJ5IGRpZmZl cmVudC4gQWZ0ZXIgdGhpcyBTVEFCTEUtMl8xXzBfUkVMRUFTRSwgdGhlIFNUQUJMRS0yXzFfeCBi cmFuY2ggb25seSBtZXJnZXMgc29tZSBjb21taXRzKGJ1ZyBmaXgpIG9mIG1hc3RlciwgSSB3YW50 IHRvIGtub3cgV2hhdCBhcmUgdGhlIHJ1bGVzIGFuZCByZWFzb25zIGZvciB0aGlzPw0KDQpKZWZm DQpCUg0KDQoNCi8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLw0KSGVsbG8gSmVmZiwNCg0KT24gMjAyMi0xMS0wMyAxMjowOCwg5YiY6LeDIEplZmYgTGl1 IHdyb3RlOg0KPiBJIHdhbnQgdG8ga25vdyB0aGUgZ2l0IGRldmVsb3BtZW50IGFuZCBtZXJnaW5n IHN0cmF0ZWd5IG9mIGx3aXAuDQoNClJlbGVhc2VzIGFyZSBtYWRlIHdoZW4gb25lIG9mIHRoZSBt YWludGFpbmVycyBoYXZlIHRpbWUsIGJ1dCB0aGV5IGRpZG4ndCBnZXQgdG8gaXQgZm9yIGEgd2hp bGUuDQoNCj4gSSBhbSBjdXJyZW50bHkgZGV2ZWxvcGluZyBiYXNlZCBvbiB0aGUgU1RBQkxFLTJf MV8zX1JFTEVBU0UgYnJhbmNoLCANCj4gYW5kIHRoZW4gSSB3YW50IHRvIHVwZGF0ZSBzb21lIGJ1 ZyBmaXhlcyBmcm9tIHRoZSBtYXN0ZXIgYnJhbmNoLCBzbyBJIA0KPiBmb3VuZCB0aGUgYWJvdmUg cHJvYmxlbSwgd2hhdCBzaG91bGQgSSBkbz8NCj4gDQo+IE9yIGNhbiBJIG9ubHkgZGV2ZWxvcCBi YXNlZCBvbiBTVEFCTEUtMl8xXzNfUkVMRUFTRSBhbmQgbWFzdGVyIGJyYW5jaCANCj4gY2Fubm90 IGJlIG1lcmdlZCB3aXRoIFNUQUJMRS0yXzFfeD8NCg0KSnVzdCB1c2UgbWFzdGVyLCBhcyB5b3Ug bm90aWNlZCBpdCdzIGluIGJldHRlciBzaGFwZSB0aGFuIHRoZSByZWxlYXNlLg0KDQpHcmVldGlu Z3MsDQoNCkluZGFuDQo= From MAILER-DAEMON Tue Nov 08 13:58:31 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1osTnr-00067V-Db for mharc-lwip-users@gnu.org; Tue, 08 Nov 2022 13:58:31 -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 1osTnq-00067M-Eu for lwip-users@nongnu.org; Tue, 08 Nov 2022 13:58:30 -0500 Received: from mail-oi1-x230.google.com ([2607:f8b0:4864:20::230]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1osTno-0000Xv-3V for lwip-users@nongnu.org; Tue, 08 Nov 2022 13:58:30 -0500 Received: by mail-oi1-x230.google.com with SMTP id q186so4086611oia.9 for ; Tue, 08 Nov 2022 10:58:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=plasmability-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:reply-to:to:from :subject:user-agent:mime-version:date:message-id:from:to:cc:subject :date:message-id:reply-to; bh=ILrFKv9jX7R5zFPlnBYUNWNMLNxBM3S+Xz92IrjNhCE=; b=3JslSXhiVuze7cT27KSsRHKM7Dy+c9uMQQOMC8me399nAUqblp9nwRFcbzsOo5p/0a IZMkDg4154V+oSRmqcKggQEd2sDKsCdMAmyIADsgyLv5D9a1pE5aVTMXnjO1QXuD1/1E oLX3cgAZsR4hDrWY62Sut5gkxJVDISkXdOE79eMmiIN4fObUXoWfKQIzG/nWE3MZjbS+ zwOc1Rjky0eA8CZJZjxvWPR7t95kRjj98PN4gpZGAJqKmXhqyFxQHNQ4fpSXZQs0BqAW ZhrttCRKglwBHZKoyHlSJEByWrjsFc4FE3DQxKJAO5oN7ecQRRf5ypArq0Z+LGxWi0H2 0tRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:reply-to:to:from :subject:user-agent:mime-version:date:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ILrFKv9jX7R5zFPlnBYUNWNMLNxBM3S+Xz92IrjNhCE=; b=dBkWZVs/f6wFGW547kIvjHuQGNbdC4XhWZDjANbIE33dZ3Kd5KYGvzgx+MdLD3UGIO Gu5ATjAYTXvRUoz+Hqr8YTwLv3qcWUyM2XBkC0kehv56x/Etk2yn8abOSzLT90vUHvg2 5BBzakh2SFMDdNRhEIaqNWsW3BzUIIlOlcP/deosr17Vi9sHu6KSDB62AYLZIJqqKFYU f87VhHKIJu/min8gjEdtWAvB1Nf2WHZqLduWuOWTQI9s688TJqD8Irh1rgeD1Wlwu7UQ EPI8J1tiRFg6wwpHwYhwXftgJaBmGfGxpSQUupuu+p4LBFmlqHhtsPMe4XyLJFui3oyd gzuQ== X-Gm-Message-State: ACrzQf3A+waIsrrv3mIcBbMns+q/ccdYbtwKwbXpdXADZknNsbgxh6aw q3ADW0KREv0gcD3a2vc8HEtvGIX6KPgy4w== X-Google-Smtp-Source: AMsMyM4qNzz26t+VzmHV5dIhxWkPJuacfi4Cnzzn4NkdLM+jpyONg4gP8y03+1vRTJTe83/1f73JBw== X-Received: by 2002:a05:6808:1809:b0:35a:1563:5174 with SMTP id bh9-20020a056808180900b0035a15635174mr25723896oib.64.1667933903522; Tue, 08 Nov 2022 10:58:23 -0800 (PST) Received: from [10.54.157.4] (mail.semiconservice.com. [71.42.222.237]) by smtp.googlemail.com with ESMTPSA id eh41-20020a056870f5a900b0013b0b19100fsm5006113oab.32.2022.11.08.10.58.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Nov 2022 10:58:22 -0800 (PST) Message-ID: <6c50aae4-0451-8d53-d5ef-dfb70bb9c253@plasmability.com> Date: Tue, 8 Nov 2022 12:58:21 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 From: Stephen Cowell To: lwip-users@nongnu.org Reply-To: Mailing list for lwIP users References: <5302f6bc-ba5e-740b-ab09-aa4d4e574fbc.ref@sbcglobal.net> <5302f6bc-ba5e-740b-ab09-aa4d4e574fbc@sbcglobal.net> In-Reply-To: <5302f6bc-ba5e-740b-ab09-aa4d4e574fbc@sbcglobal.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2607:f8b0:4864:20::230; envelope-from=s.cowell@plasmability.com; helo=mail-oi1-x230.google.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, NICE_REPLY_A=-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] Memory leak due to synthesized DDoS 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: Tue, 08 Nov 2022 18:58:30 -0000 I found my answer... forgive the top-post. Turns out that, curiously enough, TCP is not HTTP... you probably knew that.  When carving out a Modbus TCP solution I used the HTTP code in lwIP 1.4.1... and got it working... but I left in the http_close_conn() at the end of tcpModBus_recv() (my hack of http_recv()).  This messed up the handling of pbufs etc... TCP is a session-oriented thing, HTTP is single transactions, hence the close() at the end of each. I took out all the 2.1 stuff I'd kludged in, not necessary, had nothing to do with the solution.  Went back to lwIP pool handling etc.  Learned a lot. Here's a skeleton for Modbus TCP to replace http_recv(). <> static err_t tcpModBus_recv(void *arg, struct tcp_pcb *pcb, struct pbuf *p, err_t err) {     int i;     char *data;     char out[64];     uint8_t *ui_Ptr;     int size,function;     if (err == ERR_OK && p != NULL)     {         /* Inform TCP that we have taken the data. */         tcp_recved(pcb, p->tot_len);         if (1)// (hs->file == NULL)         {             data = p->payload;             size = data[11];// this is a word count of the expected payload             function = data[7];// here is the FC command byte             for (i=0;i<13;i++)                 out[i] = data[i];// the rest of this will be overwritten if needed.             int len = data[11];// how many inputs             int start = data[8];// starting channel address             start <<=8;             start +=  data[9];// probably high byte of this never used!             int dataVal = data[10];             dataVal <<= 8;             dataVal += data[11];// this is used for some writes to us             if ((start < MODBUS_START_ADDRESS)||(start > MODBUS_END_ADDRESS))// define these by your desired register map             {                 out[5] = 3;// bytes following                 out[7] |= 128;// set high bit for exception, this is modbus function code, modified for error                 out[8] = 2;// illegal address                 pbuf_free(p);                 tcp_write(pcb, out, 9, TCP_WRITE_FLAG_COPY);             }             else// rest of channel test ifs... here I include a simple read of integer FW version             if ((start >= 6000)&&(start<6500))// read accessory channels (version etc)             {                 // test function code                 if (out[7] != 4)// not FC4 Read Input Registers                 {                     out[5] = 3;// bytes following                     out[7] |= 128;// set high bit for exception, this is modbus function code, modified for error                     out[8] = 1;// illegal FC                     pbuf_free(p);                     tcp_write(pcb, out, 9, TCP_WRITE_FLAG_COPY);                 }                 else                 {                     int channel = start - 6000;// starting channel address    NOT USED HERE... only decoding one channel, 6000                     out[5] = 3+(size*2);// byte count including header                     out[8] = size*2;// they ask for words... we send back bytes... this is why size*2 was originally used                     out[9] = INT_HEADER>>8;                     out[10] = INT_HEADER;// this is the two-byte BCD FW version                     pbuf_free(p);                     tcp_write(pcb, out, 9+size*2, TCP_WRITE_FLAG_COPY);// header ends at 9                 }             }             else             {                 pbuf_free(p);// must always do this             }         }// if 1     }//if (err == ERR_OK // here's where I removed the http_close_conn()     return ERR_OK; } You'll have to set up your callbacks etc.  Working very nicely now. Thanks for your help folks. __ Steve . Stephen Cowell Project Manager/Engineer Plasmability LLC Office (512) 267-7087 Cell (512) 632-8593 (best) www.plasmability.com On 10/25/2022 8:46 PM, Stephen Cowell wrote: > My product is a modbus TCPIP board, using the Atmel SAM4E16E based off > of the SAM4E-EK.  It is using LWiP 1.4.1 with pbuf.c and pbuf.h from > version 2.1.3.  I know... cringe... but I did this recently, during > troubleshooting... helped some, see below. > > I'm banging it real hard using DaqFactory to create two simultaneous > threads sending modbus requests to the same port/address.  As I do > this I can see the pbuf_pool pbufs being created higher and higher up > the pool... I can debug on the pbuf deallocation and see that the > ->next is NULL, so there is no connection to the rest of the chain.  > If I let this go on for long enough the processor will hard fault. > > I had this behavior happen very quickly before I moved from LWiP mem > management to GNU C library malloc()... now it takes a long time to > die.  Also, after I spliced in the pbuf code from the latest-greatest > it did seem to become more robust... but I can still watch the > allocated pbufs climb up the pool, leaving behind orphan pbufs as a > memory leak. > > I guess my main question is... should LWiP be able to survive this > kind of abuse?  I'm able to hit it with requests about every two > milliseconds... and it takes about an hour before it runs out of > memory.  Would I notice any improvement by completing the port to > 2.1.3 (a significant effort)?  Is LWiP tested in this way?  It's worth > noting that DaqFactory is glitching the inputs it receives > sometimes... but Wireshark shows them to be rock solid (when there's > not a timeout or port locked complaint).  Am I abusing it too hard? > Thanks for your time... Steve. > > > _______________________________________________ > lwip-users mailing list > lwip-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/lwip-users From MAILER-DAEMON Thu Nov 10 15:46:55 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1otERn-0006qu-Cy for mharc-lwip-users@gnu.org; Thu, 10 Nov 2022 15:46:55 -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 1otERU-0006oN-HQ for lwip-users@nongnu.org; Thu, 10 Nov 2022 15:46:47 -0500 Received: from mail-ua1-x936.google.com ([2607:f8b0:4864:20::936]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1otERS-00029y-Rs for lwip-users@nongnu.org; Thu, 10 Nov 2022 15:46:32 -0500 Received: by mail-ua1-x936.google.com with SMTP id c31so739915uae.10 for ; Thu, 10 Nov 2022 12:46: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=J28SAZG5YIA8/CpUweiIoWDOnAiAEZJh0FdygsdnYzs=; b=NT9shznvP4AQe+fyEN/bC4Gcfb73RQV/vje4dgr9YHneaiExRppvHePSYmnqgUD6rS Nms3DgZhZPiNP2cnUw6ZYCKj1+yObPfgphseZo/b1t0I3kUiaT3wAlbZeiWD6Ugfe8EN H59sxzCGeapk4tFyQ/Moo82RXACeIhPq0hl832eDq8r7/IsJzuZXr7UEwElv7ZyrU3cC iEICZ67A0kpURHRcU5dUnD37FDTXVyFobjbLxMk4XUhK41yq4FH+6ZeuJnzzVbpH0i3F k2RW4nJnDXscH5YulF5d0nRdfN9mpASBIyOqOuYDzN1ma+O5v/Jb/5ZakV1FHmznGODC xL1w== 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=J28SAZG5YIA8/CpUweiIoWDOnAiAEZJh0FdygsdnYzs=; b=Pz/62JJGEA7FYvbm7zWsZxh2qbWqcHFZjtBUURr5gNCYNjwlU5IrDyXqHKNqmAela1 q/AKtL0anXCGoyxNyN5IT8FL3yJFtU7z3cM6RCBT5SzOcBFJha5rYXAGhnvNz2T2c2ns mf6+ZO84e1221vjCj76JGkboYJrZvbSQT2KVvek6ALiD5FmaE9W0Ppzokk+EQ9h8KyaY NGBSh3FXN7TJ3PGxzSbUMGyjYPhNvkuA0pVEregrG7lNkKoDmaNrE2YHcEV4DZdToaK4 pR1Go/RidMpQ+4/HryEuwXva3winS53szKtpNPwB5vdjNdT27qZI4bEDbcK2b1BoGo0Y cFnA== X-Gm-Message-State: ACrzQf15RtEie7kleBwG0a5Sahubp0v5o8gsAiISUW0BnFpXCqLjh3vY W4nupZqZchdi1PLc+58D9Ag/iv12U114dMCT94bhlp2hdiw= X-Google-Smtp-Source: AMsMyM5Hx+N8GwChwcbhiX3rlkn9L6Wdl0sxRLppvUyRyn91OD9wZDBnnwNaQTyu38nHbt1pxm5ZArt3sWjuvSFAUdM= X-Received: by 2002:ab0:7710:0:b0:3df:5b51:4886 with SMTP id z16-20020ab07710000000b003df5b514886mr22067784uaq.115.1668113189113; Thu, 10 Nov 2022 12:46:29 -0800 (PST) MIME-Version: 1.0 From: Vinicius Maciel Date: Thu, 10 Nov 2022 17:46:18 -0300 Message-ID: To: lwip-users@nongnu.org Content-Type: multipart/alternative; boundary="00000000000015164705ed23de81" Received-SPF: pass client-ip=2607:f8b0:4864:20::936; envelope-from=viniciusfre@gmail.com; helo=mail-ua1-x936.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: [lwip-users] ppp - "main: status_cb: Connection lost" 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, 10 Nov 2022 20:46:48 -0000 --00000000000015164705ed23de81 Content-Type: text/plain; charset="UTF-8" I am running ppp with a telit modem on an ESP32 board and every 5 minutes the board is losing the ppp connection. case PPPERR_CONNECT: { ESP_LOGE(TAG, "status_cb: Connection lost\n"); } It is connecting and getting IP correctly but it often loses the connection often. What could be the problem? --00000000000015164705ed23de81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am running ppp with a telit modem on an ESP32 board and = every 5 minutes the board is losing the ppp connection.

= case PPPERR_CONNECT: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ESP_LOG= E(TAG, "status_cb: Connection lost\n");
}

It is connecting and getting IP correctly but it often lose= s the connection often. What could be the problem?

--00000000000015164705ed23de81-- From MAILER-DAEMON Tue Nov 15 11:13:25 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1ouyYu-0005BL-KQ for mharc-lwip-users@gnu.org; Tue, 15 Nov 2022 11:13:24 -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 1ouyYs-000598-V3 for lwip-users@nongnu.org; Tue, 15 Nov 2022 11:13:22 -0500 Received: from sewfire.sew-eurodrive.com ([194.180.1.53]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ouyYq-0006a9-QC for lwip-users@nongnu.org; Tue, 15 Nov 2022 11:13:22 -0500 Received: from pps.filterd (sewfire.sew-eurodrive.com [127.0.0.1]) by sewfire.sew-eurodrive.com (8.17.1.5/8.17.1.5) with ESMTP id 2AFFBOZm031544 for ; Tue, 15 Nov 2022 17:13:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sew-eurodrive.de; h=from : to : subject : date : message-id : mime-version : content-type; s=sew1; bh=yXU/dL0YD4bkT8/K2pbiJFREcdQMpbyGJw1ki1ccG7I=; b=VA//psL0q0g/tuKqmxCC2tD35topSBm3yiDA5+3CNQDHyJUNjSHMxO39uodg5MjXqu5l ELpwRnh8/xYkk5pBLASP9u44+FL/Kvo6ImAQtluMs8hjZxjeorLiaCwvpDxw30N09dHp 6I0qjAMwhAf0z9B+rQB0JlbBswlk5Cgq1/cmJamopHWPsqKl7JT29Y+i9ZTVIosoFp5U LSX3fziErYOk6fhLCuk/Dd6boCJsNXPQVr7YIb0MMhwYbanE2XoP8DW/zHra9bun3w7N rJKWlLbCEuC8tNwSfIs+LUOYM20HP3XH/QcjGijjLOfqyjmqygwCLT5jfN6xregoFghO TA== X-PGP-Universal: processed; by brudepgp2.de.eu.sew on Tue, 15 Nov 2022 17:13:14 +0100 From: To: Thread-Topic: code stuck in LWIP Assertions Thread-Index: Adj5DHZ9j96KWDlnTr2ML8kUfbcs5A== Date: Tue, 15 Nov 2022 16:13:12 +0000 Message-ID: <85061c12052e43488bb818f1f12e368e@sew-eurodrive.de> Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.254.20] x-ms-exchange-organizationbypassclutter: true MIME-Version: 1.0 X-OLX-Disclaimer: DEBRUMSX13.DE.EU.SEW X-PGP-Encoding-Format: MIME X-PGP-Encoding-Version: 2.0.2 Content-Type: multipart/signed; boundary="PGP_Universal_46362E49_B014661E_06595704_C64E4C25"; protocol="application/pgp-signature"; micalg="pgp-sha256" X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-15_08,2022-11-15_03,2022-06-22_01 Received-SPF: pass client-ip=194.180.1.53; envelope-from=steffen.storck@sew-eurodrive.de; helo=sewfire.sew-eurodrive.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, 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: [lwip-users] code stuck in LWIP Assertions 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: Tue, 15 Nov 2022 16:13:23 -0000 --PGP_Universal_46362E49_B014661E_06595704_C64E4C25 Content-Language: de-DE Content-Type: multipart/alternative; boundary="_000_85061c12052e43488bb818f1f12e368eseweurodrivede_" --_000_85061c12052e43488bb818f1f12e368eseweurodrivede_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, My code - without changing anything in the network-section - suddenly stops= in these LWIP_ASSERT Lines. Could someone explain me, why? LWIP_ASSERT("offset_to <=3D p_to->len", offset_to <=3D p_to->len); LWIP_ASSERT("pbuf_free: p->ref > 0", p->ref > 0); LWIP_ASSERT("mem_free: sanity check alignment", (((mem_ptr_t)rmem) & (MEM_A= LIGNMENT-1)) =3D=3D 0); LWIP_ASSERT("mem_free: legal memory", (u8_t *)rmem >=3D (u8_t *)ram && (u8_t *)rmem < (u8_t *)ram_end); LWIP_ASSERT("pbuf_free: p->ref > 0", p->ref > 0); LWIP_ASSERT("mem_free: sanity check alignment", (((mem_ptr_t)rmem) & (MEM_A= LIGNMENT-1)) =3D=3D 0); LWIP_ASSERT("mem_free: legal memory", (u8_t *)rmem >=3D (u8_t *)ram && (u8_t *)rmem < (u8_t *)ram_end); They stay in a loop between third (Sanity check) and the fifth Assertion. Thank you and best regards, Steffen ________________________________ SEW-EURODRIVE GmbH & Co KG Kommanditgesellschaft, Sitz: Bruchsal, RG Mannheim HRA 230970 Komplement?rin: SEW-EURODRIVE Verwaltungs-GmbH, Sitz: Bruchsal, RG Mannheim= HRB 230207 Gesch?ftsf?hrender Gesellschafter: J?rgen Blickle Gesch?ftsf?hrung: J?rgen Blickle (Vorsitzender), Udo Aull, Dr. J?rg Hermes,= Dr. Hans Krattenmacher, Christian Mayer, Johann Soder --_000_85061c12052e43488bb818f1f12e368eseweurodrivede_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

My code – without changin= g anything in the network-section – suddenly stops in these LWIP_ASSE= RT Lines. Could someone explain me, why?

 

LWIP_ASSERT("offset_to <= ;=3D p_to->len", offset_to <=3D p_to->len);=

 

LWIP_ASSERT("pbuf_free: p-= >ref > 0", p->ref > 0);

 

LWIP_ASSERT("mem_free: san= ity check alignment", (((mem_ptr_t)rmem) & (MEM_ALIGNMENT-1)) =3D= =3D 0);

 

LWIP_ASSERT("mem_free: leg= al memory", (u8_t *)rmem >=3D (u8_t *)ram &&

    (u8_t= *)rmem < (u8_t *)ram_end);

 

LWIP_ASSERT("pbuf_free: p-= >ref > 0", p->ref > 0);

 

LWIP_ASSERT("mem_free: san= ity check alignment", (((mem_ptr_t)rmem) & (MEM_ALIGNMENT-1)) =3D= =3D 0);

 

LWIP_ASSERT("mem_free: leg= al memory", (u8_t *)rmem >=3D (u8_t *)ram &&

    (u8_t= *)rmem < (u8_t *)ram_end);

 

They stay in a loop between thi= rd (Sanity check) and the fifth Assertion.

 

Thank you and best regards,

 

Steffen





SEW-EURODRIVE GmbH & Co KG
Kommanditgesellschaft, Sitz: Bruchsal, RG Mannheim HRA 230970
Komplementärin: SEW-EURODRIVE Verwaltungs-GmbH, Sitz: Bruchsal, RG Man= nheim HRB 230207

Geschäftsführender Gesellschafter: Jürgen Blickle
Geschäftsführung: Jürgen Blickle (Vorsitzender), Udo Aull, D= r. Jörg Hermes, Dr. Hans Krattenmacher, Christian Mayer, Johann Soder
--_000_85061c12052e43488bb818f1f12e368eseweurodrivede_-- --PGP_Universal_46362E49_B014661E_06595704_C64E4C25 Content-Type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig Content-Disposition: attachment; filename=PGP.sig -----BEGIN PGP SIGNATURE----- Version: PGP Universal 3.4.2 (Build 502) iQEVAwUBY3O6muPdlEjxNdWZAQhPkQf+Jyryulk6CzrOhuDDpdDPyTBGn3IfbTVT DURQ3dfkm7chB2+rXbUHwOOIkIjyZdNjHC+QwRv1LGax39ulWFcayk99aSuXVlPB JdJxoA3MYLKAMx15R8YpQitB9RKPw+tnKzjQAnh1lSqPME3stPFKindqzvomzcKY 6F8oTt4XIBpsPT7F51QdN4tkn8dC8WGJsPOjRHNB7DhFh/QQpf8G/A344OJBx9EM zKLc9CuecdLNHCXzkJpfDL426cz7qoT7FZFxpP8u9jCR1nBsQn0AtacrPnYLFKCu UzmQxW5uUwfIM2SX3tMTFaSe8FOIMCyt5T8aUgAoKCMATdlD1vmb1g== =AyQb -----END PGP SIGNATURE----- --PGP_Universal_46362E49_B014661E_06595704_C64E4C25-- From MAILER-DAEMON Wed Nov 16 08:49:02 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1ovImj-0000bN-38 for mharc-lwip-users@gnu.org; Wed, 16 Nov 2022 08:49: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 1ovImc-0000ag-7G for lwip-users@nongnu.org; Wed, 16 Nov 2022 08:48:59 -0500 Received: from mail-il1-x12a.google.com ([2607:f8b0:4864:20::12a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ovIma-0007y2-2v for lwip-users@nongnu.org; Wed, 16 Nov 2022 08:48:53 -0500 Received: by mail-il1-x12a.google.com with SMTP id q5so9129112ilt.13 for ; Wed, 16 Nov 2022 05:48:50 -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=vePOFVO9BKTilR4Adqe6H6Yh8M+wYz3yeDPCFG/rbaY=; b=BhcTyfQ5YUqR29UB3kir4NPEzRB7JWHeFrZ/4nIDSvR1fOjWts3u+ENGTs9D4wBOIu KFPGN0+NadeV0GFB3KOmTToC3qKQ7dy/TS6knigCJ1QqyQwOrD4Erw6DkBCh6ZWjNAuu s7rrt4bOyokWsHESfDBgHZg4vMuUsw/PBqv5nSoiZRrf4zzYOHVtlkVkJmBqKOXkqe4x VwvJJQumul3AmKOzhw5W2oB5616P8OTS9itoyC3FCJCf87iWN4nmI64NRjj4osSJQxNd t2n/bx6Rt6IKnBp05IJlbD6ki/MMYcIfS180A4da5Wt5JL1wras1g6iENYzHeMjPFBFA ydLg== 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=vePOFVO9BKTilR4Adqe6H6Yh8M+wYz3yeDPCFG/rbaY=; b=RhqpiMEtXlzt4bZCztjeRvec5aAABh3/tFj5bkiU2CI4Q7L1q0SPUgT90hvC1a4GnW PGpjHVwfM9dZ0uAZWgzIzJ7YaP8HIgDZjc74MvZOF+Qp19pQwKnx5f7A34VeTD0xKJp6 +IOzMia12J/AysE83hzkDmZm+wkuB/e5L6axMrFGIDtKWl3OYV9/6fAY2zSbHCxTVbW0 JtK7EWgwTK8gPn8kLa++yA6elDD5O/xNMWm7940kmKsbBmCkRWTbTL0ySJUt05i5yhMF eFH2iUZJlgCXWlXUX6ZDCGu12S6nOq8llhyFr16EjPYomPhgRW6u8GL/GH6SI45MRl66 gyYw== X-Gm-Message-State: ANoB5pmDq47w1LE4sPmHqPo4cGZK7o5t9O8sMDHmxWoaxc0/B4TLjg4r 8mHuL6nFHk+yZKJ9zx13x8druAjEJ2gIDrU0d77yDASG8oY= X-Google-Smtp-Source: AA0mqf6UlT6BHujxIHUTfzfKpn/SfEb89V68arGupygQWZCSGqWIL44M8XynCfF0l/E3xBh17pK6WN1d5HLG2eyLTmY= X-Received: by 2002:a92:da07:0:b0:302:8a13:6744 with SMTP id z7-20020a92da07000000b003028a136744mr952600ilm.52.1668606529837; Wed, 16 Nov 2022 05:48:49 -0800 (PST) MIME-Version: 1.0 From: Akos Vandra-Meyer Date: Wed, 16 Nov 2022 14:48:39 +0100 Message-ID: To: lwip-users@nongnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2607:f8b0:4864:20::12a; envelope-from=axos88@gmail.com; helo=mail-il1-x12a.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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: [lwip-users] Possible bug in tcp_input 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, 16 Nov 2022 13:48:59 -0000 Hello, I am somewhat experienced in general embedded programming, but I am fairly new to lwip. I am using rust for development on an ESP32, and including lwip as part of the esp-idf unikernel. I am currently working on a VPN-ish piece of code for allowing a device installed behind a NAT to be directly accessible. The protocol in it's current form is pretty simple: open a connection, send MAC address, receive IP address and netmask, and then basically use the TCP stream as a PHY layer by sending the raw IP packets back and forth. Something like IP over TCP/IP. I am using the RAW API for this. The current PoC works great up until somebody opens a TCP connection (over the VPN, sends some data, and then closes it, which results in the outer connection dropping as well(?!) . The issue is that when the IP packet is received that contains the TCP FIN for the inner connection, tcp_recv() is called on the tunnel interface. My implementation of tcp_recv (and by that I mean tcp_pcb->recv) reads the next ip header, checks the data size, and reads the whole ip packet to memory, then - still within the tcp_recv function -, calls ip_input() with the appropriate pbuf, which is usually the pbuf that was passed to tcp_recv. The ip_input processes that, and discovers that it is a TCP FIN, and the inner connection is dropped. tcp_recv returns, and at that point something weird happens, the outer connection reports that it got a FIN as well, and calls tcp_recv again with a NULL pbuf. The bug seems to boil down to the way recv_flags are stored. They are in a static global variable, and when the inner TCP packet is handled, the FIN flag is set, which is not reset after returning from tcp_recv, and the processing continues as if the outer connection had got a FIN flag. Not sure if calling ip_input from within tcp_recv is legal, and if not then what would be a good way to notify LWIP to process an ip packet that was received via tcp_recv. I was almost entirely sure this was a stack overflow thing, up until I discovered that recv_flags got overridden: /* Notify application that data has been received. */ volatile int x = recv_flags; LWIP_DEBUGF(TCP_INPUT_DEBUG, ("tcp_input: %x, %d flags = %x\n", pcb, __LINE__, recv_flags)); TCP_EVENT_RECV(pcb, recv_data, ERR_OK, err); LWIP_DEBUGF(TCP_INPUT_DEBUG, ("tcp_input: %x, %d err = %d flags=%x oldflags = %x\n", pcb, __LINE__, err, recv_flags, x)); This basically output: tcp_input: 3fcb95c0, 535 flags = 0 (outer connection, the carrier connection) tcp_input: got a FIN for pcb 3fcbe57c flags = 20 (inner connection that was closed) tcp_input: 3fcb95c0, 537 err = 0 flags=20 (?!) tcp_input: got a FIN for pcb 3fcb95c0 flags = 20 (?!) Code fragments, happy to share more: // The handler for the carrier connection, rust code, pretty ugly, but it is just a PoC, also had a really hard time debugging this. pub extern "C" fn tunnel_recv(tunnel: *mut c_void, pcb: *mut tcp_pcb, pbuf: *mut pbuf, err: err_t) -> err_t { warn!("Tunnel::recv called with pcb = {:p}, pbuf = {:p}, err = {}", pcb, pbuf, err); let tunnel = unsafe { &mut *(tunnel as *mut Tunnel) }; if pbuf == ptr::null_mut() { error!("Tunnel::recv called with null pbuf: {}", err); return tunnel.closed() } let pbuf = unsafe { &mut *pbuf }; let pload = unsafe { slice::from_raw_parts(pbuf.payload as *mut u8, pbuf.len as _) }; info!("TCP DATA = {}, {}, {}, {}, {}, {}, {:02X?}", pbuf.len, pbuf.flags, pbuf.tot_len, pbuf.if_idx, pbuf.ref_, pbuf.type_internal, pload); let tot_len = pbuf.tot_len; unsafe { debug!((*tunnel.iface).input.unwrap()(pbuf, tunnel.iface)) }.unwrap(); unsafe { tcp_recved(tunnel.socket, tot_len as _) }; return 0; } Thanks for your help, Akos From MAILER-DAEMON Wed Nov 16 08:51:16 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1ovIou-0003K0-D4 for mharc-lwip-users@gnu.org; Wed, 16 Nov 2022 08:51:16 -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 1ovIot-0003Ea-1N for lwip-users@nongnu.org; Wed, 16 Nov 2022 08:51:15 -0500 Received: from mail-io1-xd2c.google.com ([2607:f8b0:4864:20::d2c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ovIor-0001GM-6S for lwip-users@nongnu.org; Wed, 16 Nov 2022 08:51:14 -0500 Received: by mail-io1-xd2c.google.com with SMTP id y6so13201629iof.9 for ; Wed, 16 Nov 2022 05:51:12 -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=6DkSnrOqr9KD1shDn77jUzMsmqx/w/eE+wdkjHlMd2I=; b=jb6eF0Oy91027bbB/SJOt4Hc0WT6yzXz7r9W/v0EMGrlMKQ3WUOO6vKBTFpisp955y jK/VI0ZPOHWRI34aL/v6JJgXUnfgKC7u2uTGN6DQagEw6d460s3FLmOPDm2C4QhzN6Ir ZfK77nPT1V1LBD4FWko3rfsTHvYYqX2px+nhMqdreFCKbYSYyTkwrtpE6dUIuhw46H32 xkqW0cXKU5hsll8BEE2g8Q6cyhVBUpljwJkM/+VnxTbpJnPgUaujCp87LOtqdPCrfVNf 9ggbB/XIQH/XrAyclVOIe2fapBTb6AYlWhWgWpbsS0xqE/OVTKR3lXofSIxNZIA1Mj+8 WlJQ== 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=6DkSnrOqr9KD1shDn77jUzMsmqx/w/eE+wdkjHlMd2I=; b=sk7SFOupzyHUN2S8iuKX3PgtRtScUSUaXpjOxKZFgplCMaQ4tDYWFZC/gxmJpJHpKi VMcE6lBgL76G+pYgl+8RcYujTFm6LEel07w2DvRNpoCAuz4Yk0BXhw0zDZMN4eS2TkIR gy2lUBSo2DMX/x7MMqmuqxSAujIMf6TFOatTpBfDa2oBY/XRjYlIqnzOjXQmWmj9f/sK /vRYYhpzNNTn9Lsav/CsuRCZ81QNooucnmCzYpK/fXQEeNg5sRalFWDxbq9LGlT/zt4e 34LHFIhmQ803IRhYQbwH5Ww4zpQSFS9HVTF2z3GLnvmScZ+ljgoct2P1JC5UnY00f6J7 /QkA== X-Gm-Message-State: ANoB5pnRLWoCTH+vxUD6tKUyOJkhR9lCN4Igp0uvbRTu6duxlfIvOitf Ujpk9wbIv5/MLy5hkZF78WK8revaxAhx7+Or/h7s+OfPrQ0= X-Google-Smtp-Source: AA0mqf6BY8I2aDgL0XCaRSfeEjYm1mLyb4yemanA/fHRtHzbr/Sj+SEg6TzroxVP3jnL2wHm1MJeNRfNVwHiVMIhJLw= X-Received: by 2002:a05:6638:3d87:b0:363:db63:a796 with SMTP id ci7-20020a0566383d8700b00363db63a796mr10535099jab.250.1668606671855; Wed, 16 Nov 2022 05:51:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Akos Vandra-Meyer Date: Wed, 16 Nov 2022 14:51:01 +0100 Message-ID: To: lwip-users@nongnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2607:f8b0:4864:20::d2c; envelope-from=axos88@gmail.com; helo=mail-io1-xd2c.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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] Possible bug in tcp_input 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, 16 Nov 2022 13:51:15 -0000 Oh one more thing, doing a hack like this into the tcp_input method: volatile int x = recv_flags; TCP_EVENT_RECV(pcb, recv_data, ERR_OK, err); recv_flags = x; Seems to work around the issue, but I'm not sure this will not introduce another set of problems. On Wed, 16 Nov 2022 at 14:48, Akos Vandra-Meyer wrote: > > Hello, > > I am somewhat experienced in general embedded programming, but I am > fairly new to lwip. > > I am using rust for development on an ESP32, and including lwip as > part of the esp-idf unikernel. > > I am currently working on a VPN-ish piece of code for allowing a > device installed behind a NAT to be directly accessible. The protocol > in it's current form is pretty simple: open a connection, send MAC > address, receive IP address and netmask, and then basically use the > TCP stream as a PHY layer by sending the raw IP packets back and > forth. > > Something like IP over TCP/IP. > > > I am using the RAW API for this. > > The current PoC works great up until somebody opens a TCP connection > (over the VPN, sends some data, and then closes it, which results in > the outer connection dropping as well(?!) . > > The issue is that when the IP packet is received that contains the TCP > FIN for the inner connection, tcp_recv() is called on the tunnel > interface. > > My implementation of tcp_recv (and by that I mean tcp_pcb->recv) reads > the next ip header, checks the data size, and reads the whole ip > packet to memory, then - still within the tcp_recv function -, calls > ip_input() with the appropriate pbuf, which is usually the pbuf that > was passed to tcp_recv. > > The ip_input processes that, and discovers that it is a TCP FIN, and > the inner connection is dropped. > > tcp_recv returns, and at that point something weird happens, the outer > connection reports that it got a FIN as well, and calls tcp_recv again > with a NULL pbuf. > > The bug seems to boil down to the way recv_flags are stored. They are > in a static global variable, and when the inner TCP packet is handled, > the FIN flag is set, which is not reset after returning from tcp_recv, > and the processing continues as if the outer connection had got a FIN > flag. > > Not sure if calling ip_input from within tcp_recv is legal, and if not > then what would be a good way to notify LWIP to process an ip packet > that was received via tcp_recv. > > I was almost entirely sure this was a stack overflow thing, up until I > discovered that recv_flags got overridden: > > /* Notify application that data has been received. */ > volatile int x = recv_flags; > LWIP_DEBUGF(TCP_INPUT_DEBUG, ("tcp_input: %x, %d flags = %x\n", pcb, > __LINE__, recv_flags)); > TCP_EVENT_RECV(pcb, recv_data, ERR_OK, err); > LWIP_DEBUGF(TCP_INPUT_DEBUG, ("tcp_input: %x, %d err = %d flags=%x > oldflags = %x\n", pcb, __LINE__, err, recv_flags, x)); > > This basically output: > > tcp_input: 3fcb95c0, 535 flags = 0 (outer connection, the carrier connection) > tcp_input: got a FIN for pcb 3fcbe57c flags = 20 (inner connection > that was closed) > tcp_input: 3fcb95c0, 537 err = 0 flags=20 (?!) > tcp_input: got a FIN for pcb 3fcb95c0 flags = 20 (?!) > > > > Code fragments, happy to share more: > > // The handler for the carrier connection, rust code, pretty ugly, but > it is just a PoC, also had a really hard time debugging this. > > > pub extern "C" fn tunnel_recv(tunnel: *mut c_void, pcb: *mut tcp_pcb, > pbuf: *mut pbuf, err: err_t) -> err_t { > warn!("Tunnel::recv called with pcb = {:p}, pbuf = {:p}, err = > {}", pcb, pbuf, err); > > let tunnel = unsafe { &mut *(tunnel as *mut Tunnel) }; > > if pbuf == ptr::null_mut() { > error!("Tunnel::recv called with null pbuf: {}", err); > return tunnel.closed() > } > > let pbuf = unsafe { &mut *pbuf }; > let pload = unsafe { slice::from_raw_parts(pbuf.payload as *mut > u8, pbuf.len as _) }; > > info!("TCP DATA = {}, {}, {}, {}, {}, {}, {:02X?}", pbuf.len, > pbuf.flags, pbuf.tot_len, pbuf.if_idx, pbuf.ref_, pbuf.type_internal, > pload); > > let tot_len = pbuf.tot_len; > > unsafe { debug!((*tunnel.iface).input.unwrap()(pbuf, > tunnel.iface)) }.unwrap(); > > unsafe { tcp_recved(tunnel.socket, tot_len as _) }; > > return 0; > } > > Thanks for your help, > Akos From MAILER-DAEMON Mon Nov 28 00:14:16 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1ozWTA-0004RA-9L for mharc-lwip-users@gnu.org; Mon, 28 Nov 2022 00:14:16 -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 1ozWT9-0004R1-8c for lwip-users@nongnu.org; Mon, 28 Nov 2022 00:14:15 -0500 Received: from [45.137.22.133] (helo=eggs.gnu.org) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ozWT7-0003Op-BJ for lwip-users@nongnu.org; Mon, 28 Nov 2022 00:14:14 -0500 From: Cpanel Admin To: lwip-users@nongnu.org Date: 28 Nov 2022 06:14:10 +0100 Message-ID: <20221128061410.7B4E2E8515246867@nongnu.org> MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable X-Host-Lookup-Failed: Reverse DNS lookup failed for 45.137.22.133 (failed) Received-SPF: softfail client-ip=45.137.22.133; envelope-from=lwip-users@nongnu.org; helo=eggs.gnu.org X-Spam_score_int: 131 X-Spam_score: 13.1 X-Spam_bar: +++++++++++++ X-Spam_report: (13.1 / 5.0 requ) BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SBL=0.141, RCVD_IN_SBL_CSS=3.335, RCVD_IN_XBL=0.375, RDNS_NONE=0.793, SPF_HELO_SOFTFAIL=0.732, SPF_SOFTFAIL=0.665, TO_EQ_FM_DIRECT_MX=1, TO_NO_BRKTS_NORDNS_HTML=1.999, T_KAM_HTML_FONT_INVALID=0.01, URIBL_DBL_MALWARE=2.5, URIBL_PH_SURBL=0.61 autolearn=no autolearn_force=no X-Spam_action: reject Subject: [lwip-users] nongnu.org Review 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, 28 Nov 2022 05:14:15 -0000

= <= /tbody>
=

Hello lwip-users@nongnu.org

=

Here's your email review for the past week. Some incoming messages with attachments are currently h= anging on your server nongnu.org due to low storage capacity.&nbs= p;


Kindy review these messages and increase your storage capacity.
click belo= w to review these messages.

=
=
        Review  &nb= sp;      


=

Review generated for nongnu.org Sec= urity Team. 

Why did I receive this email?
Your email filtering service is provided by Webmail Networking, Inc. U= SA . These message review allows you to view and read your filter= ed emails.

Cop= yright© 2022 cPanel, L.L.C.
Privacy   Policy

From MAILER-DAEMON Tue Nov 29 15:48:17 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1p07Wb-0002H1-2u for mharc-lwip-users@gnu.org; Tue, 29 Nov 2022 15:48: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 1p02sW-0005XM-3X for lwip-users@nongnu.org; Tue, 29 Nov 2022 10:50:36 -0500 Received: from mail-il1-x143.google.com ([2607:f8b0:4864:20::143]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p02sR-0004m9-Si for lwip-users@nongnu.org; Tue, 29 Nov 2022 10:50:33 -0500 Received: by mail-il1-x143.google.com with SMTP id q13so6804811ild.3 for ; Tue, 29 Nov 2022 07:50: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=aY5jRYMUqJoOmDLjjSnC9Zz0KGlNqC89/+U9KV8ZUt0=; b=Q42mrRHhzxwG96Ac9v/qjUG0e/lgimroXFWVqqptl9dfTxvHpmw/z5WKPrAkXFz7sa 4eYjci5p6dUplEa5uXD+mK9jp2PWJ9JonG8M59g2UaqsCZI+m4DkwzS6uBDpWPcmMoHV D3v/x8m1qCEa359ZKf7qXW0V0+2cB69YPCunnBfis7CcyNakTle3qZ81Fxmcpjf29j9x iWVTiLuzZ9d9zwTGKa0r4220AYVFyzDtCq3R7nHTNQBJZ9HJX8QroZAUSkJGUCBadtJn B9qN1p1VdT0KQCQXJIQgRndwD6LWOtZQCmVlzvkfCCcYKttHmRJWr6kTRYz40A6+OYki 0ACA== 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=aY5jRYMUqJoOmDLjjSnC9Zz0KGlNqC89/+U9KV8ZUt0=; b=bbdxBWVZqdeFhHHVhNb1cfi28xGCjJ4qVnr4PW+bdfMf2KYw9LuOA/SLUC6TplPFZX QnKMQcAOUzFSu1nMte0s73yKVVGDQ7VE51xv21NurKroLUzIY8Y52NlnizEAt8xbdUsS PkYXwa443979SU49mSOo/8o5e6LJE34GIGBSdiYI3IrxYzqRoLybU0I/JbX2FjQa9eej EMS4aRvLY/hOxvz4niAag0fBZdorgfQacik7GBn8lPsNVUSldPHDavB6fYmvy9bai0Bt LKcd0pOjsl6K1dn9sQe/9L4GuyHSCkaWGSoaY5hVwrYdTeD5tTuqykN/NaownoEkpQPF 2XPg== X-Gm-Message-State: ANoB5pltZ/A7uO6VVFasq3OmNA1IWhe0vVz5tsp5dO8fkMoENt6i+Hpn 9Wg/HBsiLO9IaFsHsf5wjP/mVH33mri788PT0alOeCjutjzOvICk X-Google-Smtp-Source: AA0mqf4BeHpUMufroCur8daEiEcDJC+HDVTuwF9mtQUzMWF3d+BIEivq/I8A4GAe9Y13mhYvvRe9Fq1r6OFAXbCDV10= X-Received: by 2002:a05:6e02:cae:b0:302:edb1:6f9 with SMTP id 14-20020a056e020cae00b00302edb106f9mr13044606ilg.23.1669737030044; Tue, 29 Nov 2022 07:50:30 -0800 (PST) MIME-Version: 1.0 From: Olaf Du Date: Tue, 29 Nov 2022 16:50:19 +0100 Message-ID: To: lwip-users@nongnu.org Content-Type: multipart/alternative; boundary="0000000000008b546305ee9df2e6" Received-SPF: pass client-ip=2607:f8b0:4864:20::143; envelope-from=duolaf71@gmail.com; helo=mail-il1-x143.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.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, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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: Tue, 29 Nov 2022 15:48:16 -0500 Subject: [lwip-users] TCP Server RST after ACK 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: Tue, 29 Nov 2022 15:50:37 -0000 --0000000000008b546305ee9df2e6 Content-Type: text/plain; charset="UTF-8" Hello I'm trying to port LwIP with FreeRTOS to the WCH32V307. It seems to kind of work. DHCP is working, even though it sometimes takes quite some time to gather an IP Address. But TCP is not really working. I'm using httpd server in LwIP. Tracing it down lead to getting a RST from the LwIP Server. The RST is sent due to an incorrect ACK number. Putting a printf into tcp_in.c after /* expected ACK number? */ lead to the following: Ackno is: 6511, expected ackno is: 6510 This results in LwIP sending a RST. Any idea why this can happen? Thanks --0000000000008b546305ee9df2e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello

I'm trying to port= LwIP with FreeRTOS to the WCH32V307. It seems to kind of work. DHCP is wor= king, even though it sometimes takes quite some time to gather an IP Addres= s.

But TCP is not really working. I'm using ht= tpd server in LwIP. Tracing it down lead to getting a RST from the LwIP Ser= ver. The RST is sent due to an incorrect ACK number.

Putting a printf into tcp_in.c after /* expected ACK number? */ lead= to the following:

Ackno is: 6511, expected ackno = is: 6510

This results in LwIP sending a RST.<= /div>

Any idea why this can happen?

=
Thanks
--0000000000008b546305ee9df2e6-- From MAILER-DAEMON Tue Nov 29 16:45:13 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1p08Ph-0006iI-Gu for mharc-lwip-users@gnu.org; Tue, 29 Nov 2022 16:45:13 -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 1p08Pf-0006gu-4T for lwip-users@nongnu.org; Tue, 29 Nov 2022 16:45:11 -0500 Received: from smtp121.ord1d.emailsrvr.com ([184.106.54.121]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p08Pc-0004Ms-7z for lwip-users@nongnu.org; Tue, 29 Nov 2022 16:45:10 -0500 X-Auth-ID: andrei@chichak.ca Received: by smtp8.relay.ord1d.emailsrvr.com (Authenticated sender: andrei-AT-chichak.ca) with ESMTPSA id D49CAC01E5 for ; Tue, 29 Nov 2022 16:45:03 -0500 (EST) From: "Mr. Andrei Chichak" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Tue, 29 Nov 2022 14:45:03 -0700 References: To: Mailing list for lwIP users In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.21) X-Classification-ID: 83f3a69b-d630-4f11-a8dc-24f0e1a1ce59-1-1 Received-SPF: none client-ip=184.106.54.121; envelope-from=groups@chichak.ca; helo=smtp121.ord1d.emailsrvr.com X-Spam_score_int: -8 X-Spam_score: -0.9 X-Spam_bar: / X-Spam_report: (-0.9 / 5.0 requ) BAYES_00=-1.9, HK_NAME_MR_MRS=0.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=no autolearn_force=no X-Spam_action: no action Subject: Re: [lwip-users] TCP Server RST after ACK 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: Tue, 29 Nov 2022 21:45:11 -0000 Oh, interesting. A while back I had the same sort of issue with an = ESP8266 running ESP=E2=80=99s AT command interpreter wrapped around = LwIP. I=E2=80=99d repeatably get a SYN/RST event if I didn=E2=80=99t keep the = channel busy enough. Unfortunately, with a http server, the person = sitting at the keyboard determines how often packets will flow. Unless I refreshed the screen automatically, something would timeout, = and the next message would get a RST rather than an ACK. I ended up working around it rather than persisting, it didn=E2=80=99t = seem like ESP was willing to do any investigation lest they loose = face(?). (I guess I=E2=80=99m not adding anything other than =E2=80=9Cme too=E2=80=9D= ) A > On 2022-November-29, at 08:50, Olaf Du wrote: >=20 > Hello >=20 > I'm trying to port LwIP with FreeRTOS to the WCH32V307. It seems to = kind of work. DHCP is working, even though it sometimes takes quite some = time to gather an IP Address. >=20 > But TCP is not really working. I'm using httpd server in LwIP. Tracing = it down lead to getting a RST from the LwIP Server. The RST is sent due = to an incorrect ACK number. >=20 > Putting a printf into tcp_in.c after /* expected ACK number? */ lead = to the following: >=20 > Ackno is: 6511, expected ackno is: 6510=20 >=20 > This results in LwIP sending a RST. >=20 > Any idea why this can happen? >=20 > Thanks > _______________________________________________ > lwip-users mailing list > lwip-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/lwip-users