Simon Goldschmidt via lwip-users 於 2024年4月9日
週二 下午2:18寫道:
>
> Am 8. April 2024 18:46:50 MESZ schrieb Javier Tia :
> >Hi,
> >
> >I was trying to build LWIP with mbedTLS (development branch), but got some
> >build errors; not with the mbedTLS LTS branch. I like to confirm if LWIP is
> >only
Oliver Hitz 於 2020年10月27日 週二 下午7:33寫道:
>
> On 27 Oct 2020, Oliver Hitz wrote:
> > I have found the problem: It seems that lwip_listen() creates a new pcb
> > but doesn't copy the netbuf_idx field from the original pcb. If
>
> Sorry, this should read "netif_idx" of course.
I'm wondering if
Simon Goldschmidt 於 2019年2月18日 週一 下午8:51寫道:
>
> Hi all,
>
> the 2.1.x branch [1] just got about 20 or so bugfix cherry-picks.
> This means I'd like to release 2.1.3 shortly. Please test :-)
Hi Simon,
The 2.1.2 was released 7 months ago and there are a bunch fixes in
current STABLE-2_1_x tree.
Simon Goldschmidt 於 2019年2月18日 週一 下午8:51寫道:
>
> Hi all,
>
> the 2.1.x branch [1] just got about 20 or so bugfix cherry-picks.
> This means I'd like to release 2.1.3 shortly. Please test :-)
Hi Simon,
Is below commit also required for stable-2.1.x?
2018-08-16 3:40 GMT+08:00 Patrick Klos :
> On 8/15/2018 11:25 AM, Axel Lin wrote:
>
> Hi list,
>
> I'm testing a LTE module with lwIP and found always got bad fcs as below.
> I dump the received data below:
> Is there anything wrong in the received data?
>
> sent [IPC
2017-03-04 14:47 GMT+08:00 Axel Lin :
> 2017-03-03 22:44 GMT+08:00 Patrick Klos :
>> On 3/3/2017 5:59 AM, Axel Lin wrote:
>>>>
>>>> Axel Lin" wrote:
>>>> LTE or not doesn't matter much: TCP should rearrange the stream based on
>>>>
2017-12-19 9:17 GMT+08:00 Louis Demers :
>
>> On Dec 16, 2017, at 09:15, Dirk Ziegelmeier wrote:
>>
>> Did you configure your netif to receive broadcasts?
>
> I followed all the steps in the mDNS documentation,
>
> what api call should I do to explicitly
2017-10-26 4:03 GMT+08:00 goldsi...@gmx.de :
> Joel Cunningham wrote:
>>
>>
>> I've updated the remaining comments to mention the same priority on git
>> master
>>
>
> Hmm, thinking about this, shouldn't we instead change the killing scheme to
> not kill active connections? It's
2017-10-24 16:37 GMT+08:00 Axel Lin <axel@ingics.com>:
> 2017-10-24 1:13 GMT+08:00 Mattia Settin <mattia.set...@gmail.com>:
>> Dear all
>> After a week of debugging I finally find the issue. The problem is related
>> to priority in pcb.
>> Tak
2017-10-24 1:13 GMT+08:00 Mattia Settin :
> Dear all
> After a week of debugging I finally find the issue. The problem is related to
> priority in pcb.
> Taking a deep look I saw that the priority in the stack 1.4.1 is change, in
> particular:
> Tcp_alloc return e pcb
2017-08-28 21:58 GMT+08:00 Sergio R. Caprile :
> Looks like memory trashing, I guess you are not using DMA on your serial,
> are you ?
Hi Sergio,
I have DMA enabled for the serial driver.
But I don't underandnd why enable DMA or not has impact on the issue.
I thought DMA is
Hi,
I'm using lwIP git tree (47f55b02bf9f889eb38379a68de9d765c163b89a).
Sometimes I found the connection will be reset, and I found a couple
of TCP Out-Of-Order/Retransmission before connection reset.
Many dup-ack e.g. No110, 112, 190, 191, 330,...
Below is the log can be opened by wireshark.
2017-07-27 13:47 GMT+08:00 frognidie :
> Hi
> Thanks a lot for your reply!
> But I still do not know how to "up".
> I used the fixed IP not the DHCP.
> The code is like this :
> setup the ip,netmask,gw
> 1)netif_add(netif,ip,netmask,gw,...);
> 2)netif_set_default(netif);
>
Hi Patrick,
2017-07-16 9:20 GMT+08:00 Patrick Klos <patr...@klos.com>:
> On 7/15/2017 10:45 AM, Axel Lin wrote:
>>
>> Hi Patrick,
>> I found a strange pattern (it happens 3 times)
>
>
> Does it always involve the loss of 63 bytes each time? (you'll under
2017-07-11 21:50 GMT+08:00 Patrick Klos <patr...@klos.com>:
> On 7/10/2017 5:23 AM, Axel Lin wrote:
>
> I got a dump of the data when bad fcs happened. (This time is "IP&q
2017-07-01 0:47 GMT+08:00 Patrick Klos <patr...@klos.com>:
> On 6/30/2017 11:18 AM, Axel Lin wrote:
>>
>> It's not easy to hit this issue, usually it needs to run for a couple
>> hours or more than one day.
>> But the symptom seems to be the same.
>>
>
2017-07-01 12:28 GMT+08:00 Axel Lin <axel@ingics.com>:
> 2017-07-01 0:47 GMT+08:00 Patrick Klos <patr...@klos.com>:
>> On 6/30/2017 11:18 AM, Axel Lin wrote:
>>>
>>> It's not easy to hit this issue, usually it needs to run for a couple
>>> hours
2017-07-01 0:47 GMT+08:00 Patrick Klos <patr...@klos.com>:
> On 6/30/2017 11:18 AM, Axel Lin wrote:
>>
>> It's not easy to hit this issue, usually it needs to run for a couple
>> hours or more than one day.
>> But the symptom seems to be the same.
>>
>
2017-07-01 0:18 GMT+08:00 Sylvain Rochet <grada...@gradator.net>:
> Hi Axel,
>
> On Fri, Jun 30, 2017 at 11:18:52PM +0800, Axel Lin wrote:
>>
>> BTW, my device always keep sending data to LTE through pppos.
>> I'm wondering why the bad fcs usually happened
Hi,
I hit a strange issue regarding PPP disconnect.
I use below setting to enable sending LCP echo request:
#define LCP_ECHOINTERVAL 2
#define LCP_MAXECHOFAILS 20
I found if I hit bad fcs case for LCP packet in pppos_input(), the PPP
session closed soon.
This seems
Hi,
While reading the code and the comment, I don't quite understanding
how to config proper PPP_MAXIDLEFLAG.
The comment says "If the link has been idle, we'll send a fresh flag
character to flush any noise".
I'm curious in what kind of situation a user needs to change PPP_MAXIDLEFLAG
and how to
2017-04-07 23:35 GMT+08:00 Axel Lin <axel@ingics.com>:
> 2017-04-06 21:18 GMT+08:00 Sylvain Rochet <grada...@gradator.net>:
>> Hi Axel,
>>
>> On Thu, Apr 06, 2017 at 08:58:10PM +0800, Axel Lin wrote:
>>>
>>> Below is what I do to start PP
2017-04-13 17:19 GMT+08:00 Sylvain Rochet <grada...@gradator.net>:
> Hi,
>
> On Thu, Apr 13, 2017 at 04:40:53PM +0800, Axel Lin wrote:
>> Hi,
>> After my device join an AP and get the ip (e.g. 192.168.0.102).
>> My device can ping the gateway ip and other devi
Hi,
After my device join an AP and get the ip (e.g. 192.168.0.102).
My device can ping the gateway ip and other devices in the same network.
Other devices can ping my test device running lwip.
But if I try to ping my own ip (192.168.0.102), it always timeout.
This seems strange. is this a normal
2017-04-06 21:18 GMT+08:00 Sylvain Rochet <grada...@gradator.net>:
> Hi Axel,
>
> On Thu, Apr 06, 2017 at 08:58:10PM +0800, Axel Lin wrote:
>>
>> Below is what I do to start PPP:
>>
>> Send "AT+CGDCONT=,,"
>> Send &qu
2017-04-06 20:15 GMT+08:00 Sylvain Rochet <grada...@gradator.net>:
> Hi Axel,
>
> On Thu, Apr 06, 2017 at 05:08:12PM +0800, Axel Lin wrote:
>> Hi list,
>> My device sometimes got status_cb: err_code=PPPERR_CONNECT (Connection lost).
>> To reconnect, I
2017-04-06 17:08 GMT+08:00 Axel Lin <axel@ingics.com>:
> Hi list,
> My device sometimes got status_cb: err_code=PPPERR_CONNECT (Connection lost).
> To reconnect, I call ppp_connect(pcb, 30); if got PPPERR_CONNECT but
> it seems never success.
>
> Initially, I can connec
Hi list,
My device sometimes got status_cb: err_code=PPPERR_CONNECT (Connection lost).
To reconnect, I call ppp_connect(pcb, 30); if got PPPERR_CONNECT but
it seems never success.
Initially, I can connect to internet after boot.
I usually got below phases:
PPP_PHASE_DEAD
cc -g -Wall -DLWIP_DEBUG -pedantic -Werror -Wparentheses
-Wsequence-point -Wswitch-default -Wextra -Wundef -Wshadow
-Wpointer-arith -Wcast-qual -Wc++-compat -Wwrite-strings
-Wold-style-definition -Wcast-align -Wmissing-prototypes
-Wredundant-decls -Wnested-externs -Wno-address -Wunreachable-code
Hi,
I'm using netconn API and running with FreeRTOS.
When test my application with current lwip git tree.
I recently found it's easy to get connection abort when I test
connecting web server.
(test by just repeating send http request)
It's easy to get below debug message:
tcp_slowtmr: max SYN
Hi,
I have 2 devices running lwip with mdns responder enabled.
My mdns setup code:
mdns_resp_init();
mdns_resp_add_netif(my_netif, "BGW", 255);
// the name is "BGW [xx:xx:xx:xx:xx]" (xx:xx... is MAC address)
// my_get_txt just call mdns_resp_add_service_txtitem(service, ip_str,
strlen(ip_str));
2017-03-14 23:08 GMT+08:00 Sylvain Rochet <grada...@gradator.net>:
> Hi Axel,
>
> On Tue, Mar 14, 2017 at 10:22:58PM +0800, Axel Lin wrote:
>> Hi,
>> Now I tried some different SIM cards on my device.
>> One of the SIM card always fails and I got PPPERR_CON
Hi,
Now I tried some different SIM cards on my device.
One of the SIM card always fails and I got PPPERR_CONNECT.
I double checked my code and settings but still don't figure out which
part is wrong.
(It works if using other SIM cards.)
Now I'm not sure which part needs to be checked.
Appreciate
2017-03-08 21:48 GMT+08:00 Sylvain Rochet <grada...@gradator.net>:
> Hi Axel,
>
>
> On Wed, Mar 08, 2017 at 09:08:01PM +0800, Axel Lin wrote:
>> Hi,
>> In my test, sometimes ppp_connect() success
>
> ppp_connect() should always succeed because it is just an i
2017-03-08 21:08 GMT+08:00 Axel Lin <axel@ingics.com>:
> Hi,
> In my test, sometimes ppp_connect() success but status_callback
> returns PPPERR_USER.
> In such case, I cannot connect to internet.
> What is the meaning of PPPERR_USER?
I should mention that when I hit
Hi,
In my test, sometimes ppp_connect() success but status_callback
returns PPPERR_USER.
In such case, I cannot connect to internet.
What is the meaning of PPPERR_USER?
Regards,
Axel
___
lwip-users mailing list
lwip-users@nongnu.org
2017-03-03 22:44 GMT+08:00 Patrick Klos <patr...@klos.com>:
> On 3/3/2017 5:59 AM, Axel Lin wrote:
>>>
>>> Axel Lin" wrote:
>>> LTE or not doesn't matter much: TCP should rearrange the stream based on
>>> good checksums and sequence numbers.
&g
2017-03-02 23:16 GMT+08:00 Simon Goldschmidt <goldsi...@gmx.de>:
> Axel Lin" wrote:
>> Only compare the download size then I know it's incorrect.
>> (and sometimes it's correct)
>
> LTE or not doesn't matter much: TCP should rearrange the stream based on good
Hi Patrick,
2017-03-02 21:21 GMT+08:00 Patrick Klos <patr...@klos.com>:
> On 3/2/2017 8:10 AM, Sylvain Rochet wrote:
>>
>> Hi Axel,
>>
>> On Thu, Mar 02, 2017 at 08:55:15PM +0800, Axel Lin wrote:
>>>
>>> Hi,
>>> I'm using current lwIP
2017-03-02 21:10 GMT+08:00 Sylvain Rochet <grada...@gradator.net>:
> Hi Axel,
>
> On Thu, Mar 02, 2017 at 08:55:15PM +0800, Axel Lin wrote:
>> Hi,
>> I'm using current lwIP master tree.
>>
>> I got my device connect to internet via 4G/LTE module now (b
Hi,
I'm using current lwIP master tree.
I got my device connect to internet via 4G/LTE module now (by PPPoS).
However, I found sometimes download file size mismatch when
try to download some files (about 100KB) from http server.
I tried enable PPP_DEBUG / PRINTPKT_SUPPORT / PPP_PROTOCOLNAME /
2017-02-20 1:02 GMT+08:00 Sylvain Rochet <grada...@gradator.net>:
> Hi Axel,
>
>
> On Mon, Feb 20, 2017 at 12:40:47AM +0800, Axel Lin wrote:
>> 2017-02-20 0:34 GMT+08:00 Sylvain Rochet <grada...@gradator.net>:
>> >
>> > It looks like your modem is no
2017-02-20 0:34 GMT+08:00 Sylvain Rochet <grada...@gradator.net>:
> Hi Axel,
>
> On Mon, Feb 20, 2017 at 12:24:29AM +0800, Axel Lin wrote:
>> Hi,
>> I got below log after ppp_connect() success:
>
> (...)
>
>> [00:14:29:361] status_cb: Connected␍␊
&g
Hi,
I got below log after ppp_connect() success:
[00:14:27:457] AT+CEREG?␍␍␊
[00:14:27:461] +CEREG: 0,1␍␊
[00:14:27:461] ␍␊
[00:14:27:461] OK␍␊
[00:14:27:688] AT+CGDCONT=1,"IP","internet"␍␍␊
[00:14:27:692] OK␍␊
[00:14:28:504] AT+CGAUTH=1,1,"us","pw@sim"␍␍␊
[00:14:28:508] OK␍␊
[00:14:28:969]
2017-02-03 3:41 GMT+08:00 goldsi...@gmx.de :
> Sandra Gilge (ADATIS) wrote:
>>>
>>> Simon wrote
>>> I'm not sure I get it. You checked that sockets are used from only one
>>> thread? The thing to check >would be to ensure that *every* core function
>>> (not sockets) is only
2017-01-31 20:11 GMT+08:00 Sandra Gilge :
> Hallo,
>
> since I have some problems with ASSERTS where it was suspected these are
> threading issues I added some debug code which check if tcpip functions are
> called from another thread than the tcpip thread.
> For this I added a
2017-01-15 23:20 GMT+08:00 Axel Lin <axel@ingics.com>:
> 2017-01-09 21:56 GMT+08:00 Sergio R. Caprile <scapr...@gmail.com>:
>> Your sequence number is jumping backwards.
>> Most common causes are either one of your apps is trashing memory of you
>> hav
2017-01-09 21:56 GMT+08:00 Sergio R. Caprile :
> Your sequence number is jumping backwards.
> Most common causes are either one of your apps is trashing memory of you
> have a bad DMA driver.
Hi Sergio,
Thanks for your comments.
It seems every time before run into
Hi,
I'm using netconn API.
While testing lwIPv2.0.1, I found my device seems stuck after running
for a couple minutes.
My device running lwIP (192.168.0.103) as a tcp client.
A Linux laptop (192.168.0.104) running "netcat -l 8088" to receive data.
In my use case, it's one-direction data transfer
49 matches
Mail list logo