Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 3 of 3

Thread: Native Ethernet - Connection timeout and reset problems - FNET issue?

  1. #1
    Junior Member
    Join Date
    May 2021
    Posts
    6

    Native Ethernet - Connection timeout and reset problems - FNET issue?

    In Dec. 2020 there was disussion on GiTHub about connection timeout issues limiting the use of NativeEthernet as a webserver. (see https://github.com/vjmuzik/NativeEthernet/issues/7).

    This problem still seems to exist in the latest version of the library and I have been able to consistently reproduce it. Basically, if you use a web browser to poll the server using something like XMLHttpRequest() it will eventually fail and stop serving data, in my case after an hour or so. Having the server running is not the problem but making repeated requests to it is.

    @vjmuzik was looking at what appears to be the same or a related issue but as of the end of last year there wasn't a fix. Does anyone know anything about this - is there a workaround?

    Thanks.

  2. #2
    Member
    Join Date
    Mar 2021
    Location
    Germany
    Posts
    51
    Hi @MartinJR, did you find a solution to this issue?

    I am too heavily struggling from this problem. I have ported now some of my (successfully running for years) Arduino Due programs to Teensy 4.1, as T4.1 has so much more potential. However, having to add a watchdog facility to restart my program, when the Ethernet Server locks up (which can be after a short time or after days), isn't "attractive".

    I found -maybe this was a mere coincidence only - that the locking up seemed to happen much faster, when I connected two Teensy 4.1 by Ethernet (both running as servers and accessing each other from time to time).

    I very much appreciate the hard work @vjmuzik and others have done to make Teensy 4.1 such outstanding product, and I wish I would be an expert on FNET to be able to assist, but it seems to me, that this locking up is a major shortfall for all Teensy 4.1 applications which use and require a stable Ethernet connection.

    I would be most grateful for any assistance in this matter.

  3. #3
    Member
    Join Date
    Mar 2021
    Location
    Germany
    Posts
    51
    I have made some more tests and I believe I can say the following:

    (1) using only EthernetServer with a fixed IP seems stable, since making certain, that always all incoming data have been read, before executing client.close() followed by client.stop()

    (2) HOWEVER, running EthernetServer and making also some contact to other servers using EtheretClient - outside serving any incoming calls! - is consistently failing, sometimes fast, sometimes after many hours.
    In this instance either EthernetServer is no longer accepting incoming requests, or most often, Teensy 4.1 can no longer connect to the outside using EthernetClient. In the latter case, it never gets beyond

    Code:
    if (sockindex >= Ethernet.socket_num) return 0;
    It has, so I assume from this, run out of available sockets, although my code has properly closed all incoming and all outgoing calls always executed "read all incoming data", then client.close() followed by client.stop()

    Above failure description isn't really new. Since Teensy 4.1 & NativeEthernet exists, have similar errors been reported on this forum. Unfortunately, the underlaying cause has not been reliably fixed. I truly appreciate, that the necessary solution might be complex - and yes, I am not an expert in this reqpect - but equally I cannot see the real purpose of Teensy 4.1 (over 4.0) if one of its major advantages isn't considered important enough to provide a stable library with and for it. Arduino Due + EthernetShield might be low in performance but they work, as I have verified for myself over many years. I truly hope the creators of Teensy 4.1 might start to see this equally and assist us users in this matter.

    Going forward from here, I like to ask for advice: is it possible to close all sockets by a command inside my running code or otherwise reset this issue. At present my code can detect the failure and then causes a complete reset (via Watchdog_t4.h), but unfortunately that isn't a suitable solution, as my setup procedure lasts several minutes due to initializing many parameters from the slow KNX home automation bus, and therefore I miss a significant portion of data during this lengthy time.

    Any help or hint is truly appreciated.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •