Re: [lwip-users] Memory leak due to synthesized DDoS

[Stephen Cowell]

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 pb

Re: [lwip-users] Memory leak due to synthesized DDoS

[Stephen Cowell]

Sorry, forgot to add I'm running NO_SYS = 1.  slc

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



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

[lwip-users] Memory leak due to synthesized DDoS

[Stephen Cowell]

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

Re: [lwip-users] Lwip client can't connect to another lwip server

[Stephen Cowell]

I find that Wireshark points to the problem usually.  If you don't 
understand the trace, show it here.

--
Steve
.

On 11/25/2020 11:47 AM, murat palaci wrote:

Hello,

I have two boards that I developed using STM32F1 with PHY

I used standard tcp_echoclient and tcp_echoserver codes in lwip.

That two boards connect and accept all connections coming from PC via 
Hercules Software.


So there is no problem on my codes and hardware.

But when I want to connect tcp_echoclient to tcp_echoserver, 
tcp_echoserver does not accept the request coming from tcp_echoclient.


Client state shows SYN_SENT and
Server state shows nothing

But as I said the client and server can connect to the PC successfully

What can I do in this situation?

Thanks

Murat

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


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

[lwip-users] Can I use two ports at once, on same net_if?

[Stephen Cowell]

I'm trying to use one net_if for two ports at once... sorry if this 
looks dumb.  Using a modified 1.4.1 in raw mode.


I set up two pcb's... I have two different tcp_accept()'s for them. The 
incoming packets appear to go to the proper places, but the connection 
is reset after the other one is opened.  I had to open up 
MEMP_NUM_TCP_PCB_LISTEN to two from one.  Obviously the two _accept()'s 
set up two _receive()'s.


/**
 * \brief HTTP server init.
 */
void httpd_init(void)
{
    struct tcp_pcb *pcb;
    struct tcp_pcb *pcbHttp;

    pcbHttp = tcp_new();
    tcp_bind(pcbHttp, IP_ADDR_ANY, 80);
    pcbHttp = tcp_listen(pcbHttp);
    tcp_accept(pcbHttp, http_accept);

    pcb = tcp_new();
    tcp_bind(pcb, IP_ADDR_ANY, 502);// was 80 slc
    pcb = tcp_listen(pcb);
    tcp_accept(pcb, modBus_accept);
}

Is this possible?  Is this how it's supposed to be done?  Can I do this 
without setting up two different net_if's?  Either one works fine with 
the other commented out.

__
Steve
.

--
Stephen Cowell
Project Manager/Engineer
Plasmability LLC
Office (512) 267-7087
Cell  (512) 632-8593 (best)
www.plasmability.com


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

Re: [lwip-users] LWIP problems

[Stephen Cowell]

We have asked customers to reduce the mask and create a smaller 
subnet... this has worked for us.

--

Stephen Cowell
Project Manager/Engineer
Plasmability LLC
Office (512) 267-7087
Cell  (512) 632-8593
www.plasmability.com

On 6/15/2020 11:05 AM, Trampas Stern wrote:
We finally shipped the product using LWIP and now customers are 
complaining that the network interface is not working properly on 
their network.  They can not load webpages as it appears too slow of a 
connection.


The only thing I can figure out is they have enough broadcast and ARP 
packages that it overwhelms our ability in LWIP to handle the messages 
but I am not sure.


Has anyone encountered these problems before?

Thanks
Trampas

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


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

Re: [lwip-users] connection drops

[Stephen Cowell]

On 3/6/2020 5:23 AM, vrnud wrote:

Hi,

I am using lwip for Modbus and Http application.
I have used raw api for both the application.

I am facing disconnect problem with modbus application while http
application is running.
Web page is auto refeshing at 3 seconds.

kindly let me know what are the reasons and where should i look in firmware
to solve the problem.



First, I'd Wireshark it... WS is brilliant in diagnosing Modbus 
problems.  If your TCP and Modbus stuff is OK there, move into lwIP 
debugging... turn on the trace features etc.

__
Steve
.

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

Re: [lwip-users] Enabling Debugging messages in lwip

[Stephen Cowell]

On 12/31/2019 10:46 AM, samyuktar wrote:

Hi,

I added the --printf_support=full and changed the LWIP_PLATFORM_DEBUG to
printf instead of UARTprintf of System_printf .. I am still not getting any
print statements.

I want also to confirm that I am using the correct method to see these
messages. I am currently using a display handle and using Display.h, opening
the display_handle and using Display_printf to print messages on the PC. I
am not sure if the messages are being printed but to another UART module or
something ...


If you get printf() working with your normal code you'll be there... can 
you printf() outside of lwip?  Divide and conquer!

__
Steve
.

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

Re: [lwip-users] Cable unplugged

[Stephen Cowell]

Top posting is a crime!

Here's how I do it in Atmel-ese... no OS, in the main while(1) loop:
<>
    modCount++;
...
        if (!(modCount%0x0008))// check Ethernet PHY once in a 
while to make sure we're connected

        {
            if (ethernetOK != ERR_OK)// only worried about initial try 
for connection here.

            {
                // test for Ethernet OK
                ethernetOK = init_ethernet();// put skips in place for 
second time through

            }
            else // this handles unplug notification... replug should 
be automatic after first successful init_ethernet()

            {
                static bool alarmLamps = false;

                gmac_enable_management(GMAC, true);    // this is 
necessary for direct access
                gmac_phy_read(GMAC, BOARD_GMAC_PHY_ADDR, GMII_BMSR, 
_stat1);// get status from PHY
                gmac_enable_management(GMAC, false);  // give PHY back 
to GMAC


                if ((ul_stat1 & GMII_LINK_STATUS) == 0)// We are 
unplugged, or something

                {// do something!  blink lamps etc






On 12/11/2019 5:07 PM, Trampas Stern wrote:
Thanks I was wondering about the "Link Status" but was not sure if you 
had to try and auto negotiate first.


Thanks again
Trampas

On Wed, Dec 11, 2019 at 5:14 PM Sergey A. Borshch via Mailing list for 
lwIP users mailto:lwip-users@nongnu.org>> wrote:


On 11.12.2019 23:55, Trampas Stern wrote:
> This is not directly LWIP related but I was wondering if there
was a way to
> detect when cable is unplugged through a GMII/RMII interface?
basic status register (index 1), bit 2.
>
> Specifically my hardware does not have the carrier sense pin
connected to
> microcontroller and I was wondering if there was a way to poll
the GMII/RMII
> registers to see when a cable is connected or not?
>
> I did not see anything in the documentation right off but
thought I would ask,
> as maybe I am not looking at the correct registers.
>
> Thanks
> Trampas
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org 
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>

---
  Regards, Sergey



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


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



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

Re: [lwip-users] Netconn API Server Mode Connection Drope Detection

[Stephen Cowell]

I'm using RAW, not Netconn... I have to poll my PHY for this... about 
once every 10,000 loops.  Read the manual for your PHY... several 
different conditions you can detect... you have to access the status 
register IIRC.

--

Stephen Cowell
Project Manager/Engineer
Plasmability LLC

On 5/16/2019 1:09 AM, Mesut Cömert wrote:
Hi, guys. I have using Netconn API on my system. I want to work as 
server mode. I downloaded and examined netconn server examples and I 
set up my system. I connect to my device with Hercules TCP Client 
section. First section is that i connect to my device, send to message 
and receive message then system is closed. This section to let me send 
to a message and receive. Second option is that i connect to my 
device, send message and receive over and over again. but when i 
pressed disconnect button so i can not to connect my device again. 
Because device has waiting in receive function. I want to detect 
connection drop in receive function. how can i solve this problem, can 
you help me?


--
*Mesut Cömert*
Elektrik Elektronik Mühendisi | Electrical Electronics Engineer

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



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

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

[Stephen Cowell]

On 2/7/2019 11:39 PM, goldsimon wrote:
Am 8. Februar 2019 00:27:58 MEZ schrieb Stephen Cowell 
:

...



> Does everyone have to go through and edit
>the
>header file includes to reflect the new structure?  I can't see why
>this
>is not fixed in the release.

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



In my example, I have replaced the lwIP folder lwip-1.4.1 with 
lwip-2.1.2 as I received it.


OK... I'm compiling along, and I get this error:

"Error        lwip/apps/lwiperf.h: No such file or directory "

This request lies in lwiperf.c, which resides in

lwip/lwip-2.1.2/src/apps/lwiperf

.  The file it wants resides in

lwip/lwip-2.1.2/src/include/lwip/apps

.  Every instance of this (there are dozens) requires me to change the 
header include from


#include "lwip/apps/lwiperf.h"

to

#include "../../include/lwip/apps/lwiperf.h"

Am I doing something wrong?  The Atmel community link below cites the 
same issue... "When compiling, some files needed to change slightly, 
such as knowing where the header files are and such, but nothing major.".

__
Steve
.


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

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

[Stephen Cowell]

I'm attempting to update the SAM4E example project 
THIRDPARTY_LWIP_BASIC_HTTP_EXAMPLE1 from 1.4.1 to 2.1.2.  The dev system 
is Atmel Studio 7 using ARM/GNU Common toolchain.  I have NO_SYS = 1 
this is the bare-metal implementation.


I've partway through the directory problems... it seems that the 
directory structure has changed, but the files I have have not been 
updated.  Is this normal?  Does everyone have to go through and edit the 
header file includes to reflect the new structure?  I can't see why this 
is not fixed in the release.


Now I'm getting #error " not supported".  Does this mean that 
I'll have to go to a different toolchain?  Do I have to have tinydir for 
the stack to work?  My eventual target (we've been selling our product 
with lwip 1.4.1 for years) has FatFS already, I'd rather not do the 
filesystem over as well.  Also getting "#error makefsdata not supported 
on this platform"... how do I carve up lwIP?  I've already deleted the 
'api' folder, referring to this link:


https://www.nongnu.org/lwip/2_0_x/group__lwip__opts__nosys.html

This link was a great help, but I'm not sure if these guys are running 
bare-metal or not...


https://community.atmel.com/forum/upgrading-lwip-141-200-pbuf-issue

Perhaps someone could throw me a bone?  Do I need an RTOS to move 
forward?  Do I need a different toolchain?

__
Steve
.
--

Stephen Cowell
Project Manager/Engineer
Plasmability LLC
Office (512) 267-7087
Cell  (512) 632-8593
www.plasmability.com


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

Re: [lwip-users] Looking for FTP client that uses Raw API

[Stephen Cowell]

So, before I start from the ground and try to design my own library, I would
like to ask here if any of you know of any other FTP client (using Raw API)



We've been happy with FTPS, by Toelke...

https://github.com/toelke/lwip-ftpd

We run bare-metal, it integrates well with lwIP 1.4.1 anyway.
__
Steve
.

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

Re: [lwip-users] Device unresponsive after a while Atmel SAM4E

[Stephen Cowell]

We had to make the subnet smaller... 1024 is about as big as we go... 
255.255.255.252 IOW.  What is your mask set to?

__
Steve Cowell
.

On 10/22/2018 5:23 AM, Markus Pischinger wrote:

Hi everybody,

I'm not sure whether this Issue comes from LwIP or not, but maybe 
someone has experienced something similar already.


The project is based on a Atmel SAM4E Xplained Pro evaluation board 
with the ASF lwIP raw example (originally used 1.4.1 but updated to 
2.0.3). On top of that we've got a Modbus/TCP stack.


A few instances have been brought to my attention where the devices 
become unresponsive after a while, until they've been restarted. 
Unresponsive means, that they are being pinged and most of the pings 
time out.
This happens on a local network, but as soon as you connect directly 
from a laptop to the device the issue is gone and connection works 
perfect again. The local network itself shows no issues as well (if 
you ping a PC at the same end as the device it works flawless).


Since I've never been able to reproduce the issue myself it is hard to 
resolve it. So if anyone has had anything similar i'd really 
appreciate the help.


Kind regards,
Markus


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



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

Re: [lwip-users] lwip crashing, apparently in sys_check_timeouts

[Stephen Cowell]

When presented with problems like this I start by replacing all the 
default handlers with handlers that log a hit.  Since you have NVR that 
you can read and write this should be easy... I use my User Page Flash 
for the same purpose.  This will help you divide-and-conquer.

__
Steve
.

On 8/20/2018 1:13 PM, Keith Rubow wrote:
I am using lwip 2.0.3 with NO_SYS = 1 on a bare metal 386ex processor 
with a Wiznet IIM7010A ethernet interface operating in MAC RAW mode. 
Yes, this hardware is REALLY old, but we have lots of hardware out in 
the field and need to fix a problem, and lwip seems like the best way 
to fix it.


My hardware has a hardware watchdog timer that will reset the 
processor if not refreshed at least every 5 seconds. Since 
implementing lwip I am experiencing extremely infrequent system 
crashes. My debugging indicates that I call sys_check_timeouts, and 
then the watchdog timer times out, resetting the system. Normally the 
watchdog timer is getting refreshed many times per second around the 
main program loop. It appears that sys_check_timeouts is taking at 
least 5 seconds to execute.


This crash (or watchdog timer reset) is happening very infrequently. 
The system will run flawlessly for 2-3 days before crashing. 
Unfortunately I do not have source level debugging capability on this 
old hardware. It is possible a memory exception could be vectoring me 
to a default exception handler that simply hangs in a loop until the 
watchdog timer resets the system (but proper code should never cause a 
memory exception). Or the sys_check_timeouts could simply be taking 
too long to execute. Can it ever take >5 seconds to execute 
sys_check_timeouts?


My IIM7010A ethernet interface is being operated in polled mode. My 
main loop operates as follows:

for (;;) {
  if (received ethernet frame available in wiznet) {
    ethernetif_input();    // this will read and process the 
ethernet frame for this interface

  }
  sys_check_timeouts();
  if (I have data to send) {
    size = size of my data to send; // size is never more than 128 bytes
    if (tcp_sndbuf(userinfo.pcb) >= size) {    // if enough free space 
to send it
  if (tcp_write(userinfo.pcb, mybuffer, size, TCP_WRITE_FLAG_COPY) 
== ERR_OK) { // if send is successful

    tcp_output(userinfo.pcb);    // initiate sending of data
  }
    }
  }
  do other stuff not related to lwip or tcp/ip    // none of it is 
very time consuming, should take only a few 10's of milliseconds

  reset_watchdog_timer();
}

I use ipv4 with fixed ip address. I have a single TCP/IP connection 
up, use callback function for received data, and everything is working 
perfectly except for the occasional crashes. My debugging ability is 
limited to setting debug variables to values in a region of memory 
that is preserved across reboots. My debug variables always show that 
the last thing I did was call sys_check_timeouts before the restart, 
and I never returned from sys_check_timeouts. Any ideas?


Keith



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



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

Re: [lwip-users] Best way for determining if a TCP connection is dead?

[Stephen Cowell]

I had to access my PHY chip to get the status of the line... using 1.4.1 
here on an Atmel SAME4E.


...
      gmac_enable_management(GMAC, true);
      gmac_phy_read(GMAC, BOARD_GMAC_PHY_ADDR, GMII_BMSR, _stat1);// 
get status from PHY

      gmac_enable_management(GMAC, false);

      if ((ul_stat1 & GMII_LINK_STATUS) == 0)
      {
          // do something...
      }
...

I'm using no OS (RAW) and doing this in main loop time... giant PITA.  
Also, it's possible for a bad phy_read() to return all 1's... in which 
case you won't see the disconnect... dealing with that one now.

__
Steve
.

Stephen Cowell
Project Manager/Engineer
Plasmability LLC
Office (512) 267-7087
Cell  (512) 632-8593
www.plasmability.com

On 1/24/2018 10:35 AM, Chris Seto wrote:

I have some code which works great, based on the echo client example.

I'm working on hardening it, and I'm wondering with how best to deal 
with a dead TCP connection as a result of the network link being down 
(ie, Ethernet cable disconnected).


The echo client contains conditions for a software termination of the 
socket (ie, server sends am empty frame), but I don't see anything 
dealing with a more blunt loss of the connection.


Any advice?

Thanks,
Chris


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



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

Re: [lwip-users] LWIP v2.0.0 hangs without Phy

[Stephen Cowell]

We use LWIP l.4.l with RAW (no OS).  I had to query my PHY's 
control/status register to determine the link status... I did this from 
main loop (non-interrupt) time.  There is also a protocol for requesting 
direct PHY access, depending on the uP's interface.  Huge PITA, but 
entirely necessary for our application.  Nothing about LWIP was 
involved.  If you're using OS you'll have to suspend the LWIP thread(s) 
to do this.


--
Stephen Cowell
Project Manager/Engineer
Plasmability LLC
www.plasmability.com

On 10/13/2017 6:48 AM, Gustavo Costa TAP wrote:

Hi Jens,

thank you for your colaboration. Is it possible that you share if me 
your fix? I am trying not to reinvent the wheel.


As I said to Simon, I am trying to use the LWIP_NETIF_LINK_CALLBACK 
and LWIP_NETIF_STATUS_CALLBACK functions to keep track of the Phy 
Link, but these functions never gets called, even if I disconnect the 
cable.


My demicode is as below:

*#if LWIP_NETIF_STATUS_CALLBACK
*
*void status_callback(void) {*
*LED_BLUE_TOGGLE();*
*}*
*#endif /* LWIP_NETIF_STATUS_CALLBACK */*
*#if LWIP_NETIF_LINK_CALLBACK*
*void link_callback(void) {*
*if (netif_is_link_up(_netif0)) {  //DES link up blink fast*
*LED_GREEN_ON();*
*dhcp_start(_netif0);*
*netif_set_up(_netif0);*
*} else {*
*LED_GREEN_OFF();*
*dhcp_stop(_netif0);*
*netif_set_down(_netif0);*
*}*
*}*
*#endif /* LWIP_NETIF_LINK_CALLBACK */*

---

*PRINTF("TCP/IP initializing...\r\n");*
*tcpip_init(NULL, NULL);*
*PRINTF("TCP/IP initialized.\r\n");*
*
*
*xSemaphoreENET = xSemaphoreCreateBinary();*
*
*
*while (netif_add(_netif0, _netif0_ipaddr, _netif0_netmask,*
*_netif0_gw,*
*NULL, ethernetif_init, tcpip_input) == NULL) {*
*
*
*netif_remove(_netif0);*
*vTaskDelay(1000 / portTICK_PERIOD_MS);*
*}*

*WDOG_Refresh(WDOG);*
*
*
*netif_set_default(_netif0);*
*netif_set_up(_netif0);*
*
*
*#if LWIP_NETIF_STATUS_CALLBACK*
*netif_set_status_callback(_netif0, status_callback);*
*#endif /* LWIP_NETIF_STATUS_CALLBACK */*
*#if LWIP_NETIF_LINK_CALLBACK*
*netif_set_link_callback(_netif0, link_callback);*
*#endif /* LWIP_NETIF_LINK_CALLBACK */*
*
*
*err = dhcp_start(_netif0);*
*
*
---

Thank you very much.

Best Regards,



*Gustavo Costa*
/Engenheiro Eletricista/

/Departamento de P/

/Tap Eletro Sistemas Ltda./

/(31) 3395-1180/9 8769-8593 <callto:%2831%29%203395-1180>/

/gustavo.co...@tapeletro.com <mailto:gustavo.co...@tapeletro.com>/










2017-10-12 12:24 GMT-03:00 Jens Nielsen <d...@telia.com 
<mailto:d...@telia.com>>:


Yes I fixed this particular problem in a driver recently, it was
waiting for autonegotiation to complete. 6th parameter to
netif_add is a function pointer to an init function in your code,
that's where you'll find your bug.

On 2017-10-12 10:33, Simon Goldschmidt wrote:

When the "netif_add" api is called without the cable being actually plugged 
the function just hangs and my wdog barks.

Now this can't be an lwIP bug: lwIP knows nothing of phys. That is part of 
your netif driver, which probably needs fixing.




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




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


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

Re: [lwip-users] Subnet too large?

[Stephen Cowell]

Sorry... I was under the impression that the subject line determined the 
thread.  I'm using Thunderbird and I don't see any difference from this end.


I assume to create a new mail I address it to lwip-users@nongnu.org?  
That's what I thought I did.

__
Steve
.

On 3/16/2017 1:12 PM, goldsimon wrote:
Please don't hijack a thread but ensure you create a new one for a new 
topic by creating a new mail instead of hitting the reply button and 
changing the subject.


Thanks,
Simon


Am 16. März 2017 17:15:01 MEZ schrieb Stephen Cowell 
<s.cow...@plasmability.com>:


We're having some problems with a customer... we have over a hundred of
our lwIP 1.4.1 devices out in the field.

Our hardware is the Atmel ATSAME416E with the KSZ8081MNX PHY chip...
same config as the ATSAM4E_EK eval kit.

Project based on the THIRDPARTY_LWIP_RAW_BASIC_HTTP example.. I've added
FTPD, HSMCI, and SNTP to the mix.  The box is an FTP site for an SD card
attached to industrial equipment.

Our customer is experiencing lockup of the processor... the lockup
symptom is the status LED stays BLUE.  At this condition we're supposed
to quit kicking the watchdog, resulting in a reset... obviously this is
not happening, not sure why.

The unusual thing about this customer's installation is that they have a
huge subnet... the mask is FF.FF.F0.00... 4094 hosts.  This appears to
me to be way too much, but our other pieces on this network (Lantronix
Spider-based) appear to be able to take this load.  I'm assuming there's
a lot of horsepower in the Spider, it gets pretty hot in operation,
where our board runs cool.

Should lwIP be able to handle this, given my current hardware?  I
realize this is more a hardware question than a lwIP question, but
perhaps someone can help me.  Thanks for your time.
__
Steve
.



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

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


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

[lwip-users] Subnet too large?

[Stephen Cowell]

We're having some problems with a customer... we have over a hundred of 
our lwIP 1.4.1 devices out in the field.


Our hardware is the Atmel ATSAME416E with the KSZ8081MNX PHY chip... 
same config as the ATSAM4E_EK eval kit.


Project based on the THIRDPARTY_LWIP_RAW_BASIC_HTTP example.. I've added 
FTPD, HSMCI, and SNTP to the mix.  The box is an FTP site for an SD card 
attached to industrial equipment.


Our customer is experiencing lockup of the processor... the lockup 
symptom is the status LED stays BLUE.  At this condition we're supposed 
to quit kicking the watchdog, resulting in a reset... obviously this is 
not happening, not sure why.


The unusual thing about this customer's installation is that they have a 
huge subnet... the mask is FF.FF.F0.00... 4094 hosts.  This appears to 
me to be way too much, but our other pieces on this network (Lantronix 
Spider-based) appear to be able to take this load.  I'm assuming there's 
a lot of horsepower in the Spider, it gets pretty hot in operation, 
where our board runs cool.


Should lwIP be able to handle this, given my current hardware?  I 
realize this is more a hardware question than a lwIP question, but 
perhaps someone can help me.  Thanks for your time.

__
Steve
.

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

Re: [lwip-users] TFTP init

[Stephen Cowell]

Nick... I'm using the same ftp... and the same processor... I wrote sftp 
but it's actually ftpd, from toelke.


Some confusion... your board, your design, is an FTP server?  You are 
pushing files from a PC client to an embedded server.

I'm assuming no OS... raw, in other words.

Do you have the SAM4E-EK?  or the Explained? kit?  Or are you already on 
custom hardware?   Always easiest to start with a kit.


Looking at fatfs's conf_access.h file, I see this entry:

<>

/*! \name Activation of Logical Unit Numbers
 */
//! @{
#ifdef VIRTUAL_MEMORY_ENABLE
#define LUN_0ENABLE   //!< Enable On-Chip Virtual Memory.
#else
#define LUN_0DISABLE  //!< Disable On-Chip Virtual Memory.
#endif



.. so it looks like FatFS will do virtual memory.  I don't expect that 
you'll be able to get on-chip flash working easily... this seems more 
designed for RAM.  How big are the files you're moving? You say 
'image'... these are bitmaps, or iso's?  Using on-chip flash is 
complicated.  Use RAM if at all possible.  Open the fatfs docs (you'll 
have to tell AtmelStudio to use a browser, this is silly of course) and 
find the f_mount() function... follow what it does. They have a user forum,


http://elm-chan.org/fsw/ff/bd/

I created an example project for LWIP using the 
THIRDPARTY_RAW_BASIC_HTTP example, then I created other example projects 
for SD Card, then diffed the projects and added the pieces into my first 
project.  Now I have an SD card that is an FTP server with NTP-based 
clock.  It was not easy... use every cheat you can find.  If you have to 
add a USB stick or an SD card to get it going, do so.

__
Steve
.

On 1/18/2017 9:20 AM, nrichard wrote:

Stephen Cowell wrote

What ftp library are you using?  I successfully used sftp with lwip
1.4.1 and fatFS, no OS needed, to be an FTP server for an SD card.

Are you being a server or a client?  Sounds like client.  Pretty sure
all the ftp things need a file system to work.

Using a file system is going to be easier than hacking an FTP client I
think.  Your goal is to use as much already-done code as possible.
Choose hardware with a rich set of example projects... Atmel SAM4E
helped me a lot.

--
Stephen Cowell

I'm actually using a SAM4E myself (specifically Sam4e16e).  I'm using this
library for FTP: https://github.com/toelke/lwip-ftpd
You are correct, I am the client on my local PC and the board will be the
server running elsewhere.  I would like to avoid using an SD card and have
the FTP server transfer to flash memory.  I only need to transfer 2 image
files to 2 locations in memory, nothing else.
With the library above, FatFs wants to use up all my memory for some reason,
so I need to figure out how I can not use up all my memory, or be able to
modify the vfs files to not use FatFs at all.

-Nick



--
View this message in context: 
http://lwip.100.n7.nabble.com/TFTP-init-tp28231p28409.html
Sent from the lwip-users mailing list archive at Nabble.com.

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



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

Re: [lwip-users] TFTP init

[Stephen Cowell]

What ftp library are you using?  I successfully used sftp with lwip 
1.4.1 and fatFS, no OS needed, to be an FTP server for an SD card.


Are you being a server or a client?  Sounds like client.  Pretty sure 
all the ftp things need a file system to work.


Using a file system is going to be easier than hacking an FTP client I 
think.  Your goal is to use as much already-done code as possible.  
Choose hardware with a rich set of example projects... Atmel SAM4E 
helped me a lot.


--
Stephen Cowell

On 1/18/2017 7:21 AM, nrichard wrote:

Ajay Bhargav wrote

I guess you need to check memory configuration. How much RAM do you have?
Are you using memory pool or malloc?
One thing to note here, I have written modified vfs layer for both my
systems as none of them use FatFS. I don’t know if that will have any
impact as such. You better check your lwIP options for memory settings.

- Ajay B.

Ideally I'd like to not use FatFs, I just don't know how to go about
modifying the vfs layer myself (junior developer, still learning!).  All I
need is the capability to FTP an image file over to a location in flash
memory, so I don't need an entire file system.  Do you mind if I send you a
private email to ask a couple questions? Don't want to get too off topic in
the public mailing list.



--
View this message in context: 
http://lwip.100.n7.nabble.com/TFTP-init-tp28231p28406.html
Sent from the lwip-users mailing list archive at Nabble.com.

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



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

Re: [lwip-users] Need help to configure lwip

[Stephen Cowell]

Thiyagu1989,
If we knew which board it would help.

Here's links I found after a very short search:

https://app.box.com/s/c7b5e316d11245271ec9

https://sourceforge.net/projects/uez/

Good luck.
__
Steve
.



On 4/27/2016 7:01 AM, thiyagu1989 wrote:

Hi Stephen ,

   Thanks for the response.Unfortunately, I have only renesas board in my
hand . I have some basic questions in my mind .

some of the questions may be very basic but it will really help me to
working on lwip .

questions:

1) do i need to edit the ethernetif.c for adapting the lwip to my board?

2)how to proceed with my renesas board ?

2) which Ide and compiler is good to build the lwip with example application
?

3) I understood that adding and removing the features based on lwipopts.h .
for example to remove dhcp i need to set #define LWIP_DHCP   0   but how
could i add or remove ipv6 ? because for my application ipv4 is sufficient .

Thanks in advance .



--
View this message in context: 
http://lwip.100.n7.nabble.com/Need-help-to-configure-lwip-tp26221p26250.html
Sent from the lwip-users mailing list archive at Nabble.com.

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



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

Re: [lwip-users] Need help to configure lwip

[Stephen Cowell]

Start with an example project for your hardware... you will struggle
otherwise.  When I start a hardware project I often use an Atmel
hardware eval kit as a basis... this gives you a working place to start.
__
Steve
.

Stephen Cowell
Project Manager/Engineer
Plasmability LLC
Office (512) 267-7087
Cell  (512) 632-8593
www.plasmability.com

On 4/25/2016 9:39 AM, Thiyagu wrote:

Hello All ,

I am very new to embedded and learning to configure lwip stack for my
embedded system . I had downloaded the source code but don't know where to
start . Can anyone please tell me how to configure the downloaded stack ?
any suggestions or good materials will be helpful


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



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

Re: [lwip-users] Problems on Class-B network

[Stephen Cowell]

Should be 172 below... sorry.

Stephen Cowell
Project Manager/Engineer
Plasmability LLC
Office (512) 267-7087
Cell  (512) 632-8593
www.plasmability.com

On 4/11/2016 3:42 PM, Stephen Cowell wrote:

Hey Simon...
There is also an NTP client running... using
SNTP.  They have it set to 0.0.0.0, so it's disabled.
I've set my unit up same as theirs, with my
PC as the gateway... works fine.  I just don't
have access to a router that will do the 173
block... most of them are tied to the 192 block,
since that's an easy way to limit the possible
number of clients connected.

Here's their full setup, for completeness:
IP  173.31.147.224
GW  173.31.146.1
Mask  255.255.254.0

I don't have a screenshot of the attempted ping.
__
Steve
.

Stephen Cowell
Project Manager/Engineer
Plasmability LLC
Office (512) 267-7087
Cell  (512) 632-8593
www.plasmability.com

On 4/11/2016 3:09 PM, Sg wrote:

Stephen,

As far as I know, class B network should work OK. I'm running devices 
with "strange" subnets, too, and they have no problem.
Can you post an example IP setting of the device, gateway and client 
trying to ping the device?

Does the device have multiple netifs or only one?

Simon


Stephen Cowell wrote:


I've got an embedded FTP product out in the
field built on lwIP 1.4.1... so far so good... but
now a customer has a problem getting one to
work (static IP) on a class-B (172.31.xxx.xxx)
subnet.  Raw API, no OS... running FatFS
and FTPD on Atmel SAM4E16E.

I have not been able to obtain/set up a similar
situation here yet... I have attached my PC to
my device with a crossover cable and set it to
the customer's Gateway IP... the mask is
255.255.254.0, so it's not the full 1mib address
space.  My sim FTP works fine... but at the customer's
site (overseas, of course) when they set this IP/etc
they can't even ping the device.  For me, it seems
unusual that for every static IP the customer sets,
they also set a unique gateway... not sure why.
The gateway is pingable from the drop to the device,
or at least that's what I've been assured.

We are sending a replacement unit now... I just want
to confirm that this should work no problem on
the class-B subnet.
__
Steve
.

Stephen Cowell
Project Manager/Engineer
Plasmability LLC
Office (512) 267-7087
Cell  (512) 632-8593
www.plasmability.com



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



Gesendet mit AquaMail für Android
http://www.aqua-mail.com



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





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

Re: [lwip-users] Problems on Class-B network

[Stephen Cowell]

Hey Sergio...
Yes, I'm aware we are 'classless' now, but the
nomenclature was the easiest way to describe/
google it.  I understand /23... much the same as
class-B.

I assume that they have a virtual gateway devoted
to each drop... not sure why, but the gateway is
ping-able.

We are shipping the replacement now... if it still has
problems, perhaps I'll get to visit sunny Austria!
__
Steve
.

Stephen Cowell
Project Manager/Engineer
Plasmability LLC
Office (512) 267-7087
Cell  (512) 632-8593
www.plasmability.com

On 4/11/2016 3:28 PM, Sergio R. Caprile wrote:

Stephen,
there is no concept of IP class in lwIP, and the IP addressing scheme 
you mention is a /23; closer to a class-C than a B ;^)
What you describe sounds pretty strange to me too, looks like your 
customer is not well versed in networking or doing some tricky stuff. 
Either way, you should be able to replicate a problem given the 
network configuration, if you don't... there is a high likelihood that 
they are not doing things right.


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



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

[lwip-users] Problems on Class-B network

[Stephen Cowell]

I've got an embedded FTP product out in the
field built on lwIP 1.4.1... so far so good... but
now a customer has a problem getting one to
work (static IP) on a class-B (172.31.xxx.xxx)
subnet.  Raw API, no OS... running FatFS
and FTPD on Atmel SAM4E16E.

I have not been able to obtain/set up a similar
situation here yet... I have attached my PC to
my device with a crossover cable and set it to
the customer's Gateway IP... the mask is
255.255.254.0, so it's not the full 1mib address
space.  My sim FTP works fine... but at the customer's
site (overseas, of course) when they set this IP/etc
they can't even ping the device.  For me, it seems
unusual that for every static IP the customer sets,
they also set a unique gateway... not sure why.
The gateway is pingable from the drop to the device,
or at least that's what I've been assured.

We are sending a replacement unit now... I just want
to confirm that this should work no problem on
the class-B subnet.
__
Steve
.

Stephen Cowell
Project Manager/Engineer
Plasmability LLC
Office (512) 267-7087
Cell  (512) 632-8593
www.plasmability.com



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

Re: [lwip-users] HTTP Auth, LWIP connection management and FIN packets

[Stephen Cowell]

He didn't stutter... don't call lwip from
anything but main loop code.  Side-effects
are hard to diagnose when you don't follow
directions.
__
Steve
.

On 2/18/2016 1:00 PM, Gustavo Pinho Oliveira wrote:

I have checked my code and I do call lwip from interrupt callbacks.
But my problem is with the receiver and that one isn't using lwip 
within interrupts.

The system was working like this before and we had no problems.

I control both sides of the system (A and B).

I have to thank you for the hub idea.
I configured my switch with port mirroring and it's much easier to 
debug now.


I attached a pcap.
The flow is changed but it should work nonetheless.
My problem of not getting tcp_recv callback still exists.

On 17 February 2016 at 16:36, Sergio R. Caprile > wrote:


your system is single threaded if you don't call lwIP functions from
within interrupt code. You can't. Please make sure you don't do that.

The applications you mention do not belong to the contrib tree, so I
don't really know if they do work OK. It is just my user opinion,
I only
trust contrib tree apps and (sometimes) my own.
In fact, lighttpd is not (afaik) a RAW API application...

You say you are just trying to implement Digest Auth but you mention a
communication flow problem. If you expect some help, I would like to
actually see that communication flow. Maybe you are fiddling the wrong
way with your application, I added HTTP AUTH to my own web server,
which
is a fork of the contrib tree official web server for RAW API.
You are welcomed to see if it fits your needs here:

http://scaprile.ldir.com.ar/cms/el-ingeniero/open-source-projects-im-working-on/lwhttpd/

Besides that,
"B connects to A": what is the application running in A, who wrote
that,
why do you think it works OK ? OK, it connects, but...
"B tries to make the 2nd connection to A": so, your application is
listening and should have bind to a port and receive.
Before B receives a callback to tcp_connect(), A must receive a
callback
to tcp_accept(), and the callback must do its internal magic and
return
ERR_OK to lwIP.

You should be able to see why tcp_connect() is not called in B by
following the frame flow in A and/or B, putting a breakpoint at
ethernet_input() [assuming you did see the SYN and/or SYN ACK in the
wire, what you could do by attaching a PC running wireshark to a hub
(not a swith, a hub) where you connect the three Ethernets], which
should be called via netif->input inside your driver, if correctly
initialized by your call to netif_add():
netif_add(, , , , NULL, yourdriver_init,
ethernet_input)

Please attach a capture file so we can see the comm flow and the
requests and responses.


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




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



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

Re: [lwip-users] Infinite hang in tcp_slowtmr()

[Stephen Cowell]

Hey Enrico,
I'm using GNU toolchain/compiler, supplied with Atmel Studio 6.1.
Since I've added the code I've had no other problems; I really don't
have much time to research this, what with other pressures at work.

It seems the issue is not unknown... sometimes the pdb ends up pointing
to itself.  These times appear to be correlated to high-stress I/O.

Obviously the last pdb should point to null... and it should never point
to itself.  It is easy enough to catch it pointing to itself and make that
null.  I verified that this was the first pdb, that we weren't going to
have a memory leak when we just terminated the list.  I did not have
the resources to chase down when the pointer to self happened...
I only know that it does, and that the pdb that this happens to is
at the first allocated pdb address.  The obvious thing to do was to
correct the pointer to break the endless loop... seems to work.

As Sylvain wrote, the Atmel port has some serious differences from
what he's used to seeing... I'm assuming this has something to do
with it.  As I get more time (the product ships soon) I'll be able to
spend some more time on this issue.  I'm just glad to get it out there
and let others know it's happening.
__
Steve
.

On 10/14/2015 3:22 AM, Enrico Murador - Research & Development - CET wrote:

Hi Stephen,
Maybe your workaround is not a safe way to overcome the problem: at 
that point the pcb chain is already corrupted (and probably 
unrecoverable?).


What compiler/toolchain are you using?

Enrico

On 13/10/2015 11:48, Sylvain Rochet wrote:

Hi Stephen,

On Tue, Oct 13, 2015 at 10:15:42AM +0200, Sylvain Rochet wrote:

On Mon, Oct 12, 2015 at 04:59:19PM -0500, Stephen Cowell wrote:

On 10/12/2015 3:41 PM, Sylvain Rochet wrote:

On Mon, Oct 12, 2015 at 02:51:14PM -0500, Stephen Cowell wrote:

I find that I sometimes get an infinite loop when stepping to
pcb->next...

I didn't have to read further. As usual, it looks like a broken port or
usage which violate lwIP threading model.

Summary:

- Do *NOT* call anything in interrupt context, nothing, never,
absolutely never, use your OS semaphore signaling to an
Ethernet/serial/… RX thread

I don't think I'm doing that, Sylvain... this is non-OS, so there
are no 'threads'.   Atmel wrote the port.  I'm running sntp and ftpd, they
hook in using their own _init() routines that have not been
modified.

But there are probably interrupts, which is even worse. Could you first
check that no lwIP functions are called in interrupts contexts ?
Probably around the macb driver.

If I have time I will fetch the Atmel port for SAM4E/bare-metal and
take a short look at it.

It looks sane from a quick look. I don't really understand why there are
not using sys_check_timeouts() and rewrote everything in the ethernet.c
"static timers_info_t gs_timers_table[]" stuff. Since you are having
issue in timers context could you check this part is ok ? Removing all
the Atmel timers stuff and calling sys_check_timeouts() in the main loop
could be an easy check.

Sylvain

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


--
Enrico Murador
R

CET Electronics logo <http://www.cet-electronics.com/> 	*CET 
Electronics snc*

via E. Fermi, 1
31050 Zenson di Piave (TV) Italy
Phone: +39 0421 344100
Fax: +39 0421 464042
PI/VAT IT01780330260
Web: http://www.cet-electronics.com/






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


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

[lwip-users] Infinite hang in tcp_slowtmr()

[Stephen Cowell]

Using 1.4.1, no OS, in a ftpd application.
Atmel SAM4E, based on THIRDPARTY_LWIP_RAW_BASIC_HTTP
example, ASF 3.25.

I find that I sometimes get an infinite loop when stepping to
pcb->next... if it is not a new pcb but the same old one, the
system hangs.  In order to get out of this I put the following
two lines of 'if' code at the end:

<>
} else {
  prev = pcb;
  pcb = pcb->next;
  if (prev == pcb)
pcb->next = NULL;// hack to escape infinite loop slc degub
}
  }
}


In talking on other forums I understand that this problem is
related to I/O stress.  Has this issue been dealt with before?
Is there a better solution?
__
Steve


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

Re: [lwip-users] Infinite hang in tcp_slowtmr()

[Stephen Cowell]

On 10/12/2015 3:41 PM, Sylvain Rochet wrote:

Hi Stephen,

On Mon, Oct 12, 2015 at 02:51:14PM -0500, Stephen Cowell wrote:

I find that I sometimes get an infinite loop when stepping to
pcb->next...

I didn't have to read further. As usual, it looks like a broken port or
usage which violate lwIP threading model.

Summary:

- Do *NOT* call anything in interrupt context, nothing, never,
absolutely never, use your OS semaphore signaling to an
Ethernet/serial/… RX thread


I don't think I'm doing that, Sylvain... this is non-OS, so there
are no 'threads'.   Atmel wrote the port.  I'm running sntp and ftpd, they
hook in using their own _init() routines that have not been
modified.

Here's more links describing the problem:

http://savannah.nongnu.org/bugs/?45433
https://lists.gnu.org/archive/html/lwip-users/2004-10/msg00033.html

"

Why would a pcb->next pointer end up pointing to itself (pcb)?

"

Indeed... that's the whole problem.  I solved my problem with a hack that
nobody gets to see here... not sure why.

It looks like this code has had many bugs and problems... I'm glad I could
at least fix my issue.  I won't bother you with any more, since obviously
I'm not making it to the main list.
__
Steve
.



- memp_*, pbuf_*, functions are thread-safe if SYS_LIGHTWEIGHT_PROT is
set, and again, thread safe does not mean it is interrupt safe

- Do *NOT* call any function from the RAW API outside lwIP thread

- Use Netconn or Socket API in others threads, but keep in mind you
should not share a Netconn/Socket control block between threads, (or use
proper locking if you really have to, of course).

- Please read doc/rawapi.txt from the lwIP source which explain that
more comprehensively

Sylvain


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



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