Teensy 4.1 - Adafruit Airlift Featherwing Co-Processor FTP Server not opening Port 21

[mjs513]

HI @mjs513

That's good news. As I suspect, the xfer bug affects 2-ways in WiFiNINA. We already fixed just 1-way, now still have to find out and fix the other way.

Sorry, have no time now. Can you use FTPClient_Generic as Client to test? FileZilla still has elusive issue with FTPServer

Could you test the WiFiNINA_Generic as simple WebServer / WebClient to see if OK to xfer large files? We have to fix from here first.

Had some time so first thing I wanted to check was WiFiNINA_Generic:
1. Running WifiWebServer - does not work can make a connection to the T4.1/Airlift
2. Running the WebClient sketch succeeds:

Starting connection to server...
Connected to server
HTTP/1.1 200 OK
Date: Tue, 24 May 2022 19:20:51 GMT
Content-Type: text/plain
Content-Length: 2263
Connection: close
x-amz-id-2: 5fRMcJZFj9KYfrjUxC5J54aYUZqXBVnOgfRViHoUCej/EEwBXM5AX93GSDOr2v5xRa6wxn6GQTg=
x-amz-request-id: 3PQ556NK58MDDWKY
Last-Modified: Wed, 23 Feb 2022 14:56:42 GMT
ETag: "667cf48afcc12c38c8c1637947a04224"
CF-Cache-Status: DYNAMIC
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=ViUdmpAPdmo0AE8I9vh%2FJ97LZmBG8pmvRmWcA8K7Ai4xffBcQ61Y7pk6EAQzofTeaA0XmwDLxOVCM3OYpV5Qgpmly0M2dxNxJqziEvep5sLoSsrbgsBn255QIeF2LgA%3D"}],"group":"cf-nel","max_age":604800}
NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
Server: cloudflare
CF-RAY: 710864191bb1b0a6-ATL
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400


           `:;;;,`                      .:;;:.           
        .;;;;;;;;;;;`                :;;;;;;;;;;:     TM 
      `;;;;;;;;;;;;;;;`            :;;;;;;;;;;;;;;;      
     :;;;;;;;;;;;;;;;;;;         `;;;;;;;;;;;;;;;;;;     
    ;;;;;;;;;;;;;;;;;;;;;       .;;;;;;;;;;;;;;;;;;;;    
   ;;;;;;;;:`   `;;;;;;;;;     ,;;;;;;;;.`   .;;;;;;;;   
  .;;;;;;,         :;;;;;;;   .;;;;;;;          ;;;;;;;  
  ;;;;;;             ;;;;;;;  ;;;;;;,            ;;;;;;. 
 ,;;;;;               ;;;;;;.;;;;;;`              ;;;;;; 
 ;;;;;.                ;;;;;;;;;;;`      ```       ;;;;;`
 ;;;;;                  ;;;;;;;;;,       ;;;       .;;;;;
`;;;;:                  `;;;;;;;;        ;;;        ;;;;;
,;;;;`    `,,,,,,,,      ;;;;;;;      .,,;;;,,,     ;;;;;
:;;;;`    .;;;;;;;;       ;;;;;,      :;;;;;;;;     ;;;;;
:;;;;`    .;;;;;;;;      `;;;;;;      :;;;;;;;;     ;;;;;
.;;;;.                   ;;;;;;;.        ;;;        ;;;;;
 ;;;;;                  ;;;;;;;;;        ;;;        ;;;;;
 ;;;;;                 .;;;;;;;;;;       ;;;       ;;;;;,
 ;;;;;;               `;;;;;;;;;;;;                ;;;;; 
 `;;;;;,             .;;;;;; ;;;;;;;              ;;;;;; 
  ;;;;;;:           :;;;;;;.  ;;;;;;;            ;;;;;;  
   ;;;;;;;`       .;;;;;;;,    ;;;;;;;;        ;;;;;;;:  
    ;;;;;;;;;:,:;;;;;;;;;:      ;;;;;;;;;;:,;;;;;;;;;;   
    `;;;;;;;;;;;;;;;;;;;.        ;;;;;;;;;;;;;;;;;;;;    
      ;;;;;;;;;;;;;;;;;           :;;;;;;;;;;;;;;;;:     
       ,;;;;;;;;;;;;;,              ;;;;;;;;;;;;;;       
         .;;;;;;;;;`                  ,;;;;;;;;:         
                                                         
                                                         
                                                         
                                                         
    ;;;   ;;;;;`  ;;;;:  .;;  ;; ,;;;;;, ;;. `;,  ;;;;   
    ;;;   ;;:;;;  ;;;;;; .;;  ;; ,;;;;;: ;;; `;, ;;;:;;  
   ,;:;   ;;  ;;  ;;  ;; .;;  ;;   ,;,   ;;;,`;, ;;  ;;  
   ;; ;:  ;;  ;;  ;;  ;; .;;  ;;   ,;,   ;;;;`;, ;;  ;;. 
   ;: ;;  ;;;;;:  ;;  ;; .;;  ;;   ,;,   ;;`;;;, ;;  ;;` 
  ,;;;;;  ;;`;;   ;;  ;; .;;  ;;   ,;,   ;; ;;;, ;;  ;;  
  ;;  ,;, ;; .;;  ;;;;;:  ;;;;;: ,;;;;;: ;;  ;;, ;;;;;;  
  ;;   ;; ;;  ;;` ;;;;.   `;;;:  ,;;;;;, ;;  ;;,  ;;;;

[khoih-prog]

I've some simple tests here and :

1. WiFiNINA and WiFiNINA_Generic are working OK with Nano_33_IoT and Nano_RP2040_Connect (using arduino-pico core) running WiFiWebServer. Using mbed_rp2040 core => Nano_RP2040_Connect crashes while using either WiFiNINA and WiFiNINA_Generic (so terrible unreliable Arduino core now)
2. WiFiWebClientRepeating is running OK with either WiFiNINA or WiFiNINA_Generic and either core mbed_rp2040 or arduino-pico

So, can you check using T4.1 + Featherwing with Adafruit WiFiNINA + WiFiWebServer to see if this is hardware, pin / wiring / config issue. Then we can moving on to locate where the issue is,

My future plan for FTP_Server will be using high level WiFiWebServer library calls, such as send(), etc.

[wwatson]

I've some simple tests here and :

1. WiFiNINA and WiFiNINA_Generic are working OK with Nano_33_IoT and Nano_RP2040_Connect (using arduino-pico core) running WiFiWebServer. Using mbed_rp2040 core => Nano_RP2040_Connect crashes while using either WiFiNINA and WiFiNINA_Generic (so terrible unreliable Arduino core now)
2. WiFiWebClientRepeating is running OK with either WiFiNINA or WiFiNINA_Generic and either core mbed_rp2040 or arduino-pico

So, can you check using T4.1 + Featherwing with Adafruit WiFiNINA + WiFiWebServer to see if this is hardware, pin / wiring / config issue. Then we can moving on to locate where the issue is,

My future plan for FTP_Server will be using high level WiFiWebServer library calls, such as send(), etc.

Just got home and have about an hour to setup and test. Will let you know how it turns out. Thanks for the info. Testing with the WiFiWebServer makes sense to isolate any hardware issues...

[mjs513]

I've some simple tests here and :

1. WiFiNINA and WiFiNINA_Generic are working OK with Nano_33_IoT and Nano_RP2040_Connect (using arduino-pico core) running WiFiWebServer. Using mbed_rp2040 core => Nano_RP2040_Connect crashes while using either WiFiNINA and WiFiNINA_Generic (so terrible unreliable Arduino core now)
2. WiFiWebClientRepeating is running OK with either WiFiNINA or WiFiNINA_Generic and either core mbed_rp2040 or arduino-pico

So, can you check using T4.1 + Featherwing with Adafruit WiFiNINA + WiFiWebServer to see if this is hardware, pin / wiring / config issue. Then we can moving on to locate where the issue is,

My future plan for FTP_Server will be using high level WiFiWebServer library calls, such as send(), etc.

And @wwatson

First I had to modify the advanced webserver sketch to work with the adafruit WiFiNINA library:
AdvancedWebServer-220524a.zip

in the serial monitor after connection I see:

Starting AdvancedWebServer on TEENSY 4.1/4.0 with Custom WiFi using Custom WiFi Library
WiFiWebServer v1.8.0
Connecting to WPA SSID: ......

Connecting to WPA SSID: .....
HTTP server started @ ............
H[WIFI] String Len = 0, extend to 2048

in firefox:


The browser updates about 4 or 5 times then looses the connection and I can not reconnect without reset the Teensy.

[wwatson]

@mjs513, @khoih-prog - Got everything setup in WiFiNINA_Generic as per p#147. Had the same result as Mike did. Connects but hangs waiting for the welcome message. We ran into this before and I will have to look back and see what we did to resolve it. Running out of time to test further tonight. Tomorrow will check it out further. I live for the weekends when I have time to play

[khoih-prog]

@mjs513,

It seems that there is some severe issue when using T4.1 + Featherwing + even Adafruit WiFiNINA; now you have to check if we still have the same issue with any other board you have (SAMD, nRF52, RP2040, etc.) + Featherwing. My wild guess is possibly some conflict / (Teensy core or WiFiNINA library) bug when using T4.1 + Featherwing ???

I believe now we need the help of @PaulStoffregen or somebody having the same hardware to locate the bug.

I'm testing the AdvancedWebServer OK with Nano_33_IoT and Nano_RP2040_Connect using WiFiNINA_Generic

[mjs513]

@mjs513,

It seems that there is some severe issue when using T4.1 + Featherwing + even Adafruit WiFiNINA; now you have to check if we still have the same issue with any other board you have (SAMD, nRF52, RP2040, etc.) + Featherwing. My wild guess is possibly some conflict / (Teensy core or WiFiNINA library) bug when using T4.1 + Featherwing ???

I believe now we need the help of @PaulStoffregen or somebody having the same hardware to locate the bug.

I'm testing the AdvancedWebServer OK with Nano_33_IoT and Nano_RP2040_Connect using WiFiNINA_Generic
...

Understood but I just tried using a Adafruit M0 datalogger with the WiFiNINA library and while it connected and show some life it did not show the graph or even try to update - basically just hung:


Did try and get it working with WiFiNINA Generic but could not make a connection to either the T4.1 or the Adafruit M0 board... sorry

[khoih-prog]

Hi @mjs513

It seems that the issue is wider than expected while using Adafruit WiFiNINA.

Can you check, test to see if this is an SPI conflict / bad SPI-related design (seen with many SD cards) by using SPI1/SPI2 for WiFiNINA with setPins(), such as

#define SPIWIFI       SPI1  // The correct supported SPI port

...

WiFi.setPins(SPIWIFI_SS, SPIWIFI_ACK, ESP32_RESETN, ESP32_GPIO0, &SPIWIFI);

If OK, also try if we have similar SPI conflict issue with T4.1.

Here, Nano_33_IoT has been running AdvancedWebServer for more than 14hrs, and still running

[wwatson]

@mjs513 - @ khoih-prog Well did some more testing after work tonight and SPI is working with WiFiNINA and the T4.1. sendData() and getData() do not have a problem as they are also used for all other file operations with FTP that complete successfully. The only failure is with data.connected(). I can put the same delay(100) in doStore() as in WiFiClient.cpp:

bool FtpServer::doStore()
{
  // This my hack.
/*
  uint32_t tmout = millis();
  int na = 0;
  while((millis() - tmout) != 50) {
    na = data.available();
    if(na != 0) break;
  }
  if(na == 0) {
    closeTransfer();
    return false;
  }
*/
  int na = data.available();

  if ( na == 0 )
  {
    if ( data.connected())
      return true;
    else
    {
      closeTransfer();
      return false;
    }
  }

  if ( na > FTP_BUF_SIZE )
    na = FTP_BUF_SIZE;
delay(100);
  int16_t nb = data.read((uint8_t *) buf, na );
  int16_t rc = 0;

  if ( nb > 0 )
  {
     //FtpDebug << millis() << " " << nb << endl;
    rc = file.write( buf, nb );
    bytesTransfered += nb;
  }

  if ( nb < 0 || rc == nb  )
    return true;

  FtpOutCli << F("552 Probably insufficient storage space") << endl;
  file.close();
  data.stop();
  closeTransfer();
  return false;
}

And get the same result. Fillezilla shows a complete transfer (100%) but the transfer never completes. And at that point the sever on the T4.1 is stuck in an endless loop waiting for data.connected() to change from 1 to 0. Same problem as before with WiFiNINA and WiFiNINA_Generic. The file is never closed so when you reboot the T4.1 and reconnect Filezilla the file that was transfered show 0 bytes. Empty unclosed file. Using NativeEthernet or QNEthernet work perfectly with FTP_Server_Teensy41.

I hope to try and find the problem with WiFiNINA this weekend. This really has me bugged

[mjs513]

@wwatson - @ khoih-prog

Don't think its an SPI issue either since we were able to transfer files in one direction. As for using the AdvancedWebServer - not 100% sure whats going on with that. I just ran the WiFiNINA example WiFiWebServer and it works with out the Browser loosing connection but the interesting thing is how it works:

  // listen for incoming clients
  WiFiClient client = server.available();
  if (client) {
    Serial.println("New client");
    // an http request ends with a blank line
    boolean currentLineIsBlank = true;
    while (client.connected()) {
      if (client.available()) {
        char c = client.read();
        Serial.write(c);
        // if you've gotten to the end of the line (received a newline
        // character) and the line is blank, the http request has ended,
        // so you can send a reply
        if (c == '\n' && currentLineIsBlank) {
          // send a standard http response header
          client.println("HTTP/1.1 200 OK");
          client.println("Content-Type: text/html");
          client.println("Connection: close");  // the connection will be closed after completion of the response
          client.println("Refresh: 5");  // refresh the page automatically every 5 sec
          client.println();
          client.println("<!DOCTYPE HTML>");
          client.println("<html>");
          // output the value of each analog input pin
          for (int analogChannel = 0; analogChannel < 6; analogChannel++) {
            int sensorReading = analogRead(analogChannel);
            client.print("analog input ");
            client.print(analogChannel);
            client.print(" is ");
            client.print(sensorReading);
            client.println("<br />");
          }
          client.println("</html>");
          break;
        }
        if (c == '\n') {
          // you're starting a new line
          currentLineIsBlank = true;
        } else if (c != '\r') {
          // you've gotten a character on the current line
          currentLineIsBlank = false;
        }
      }
    }
    // give the web browser time to receive the data
    delay(1);

    // close the connection:
    client.stop();
    Serial.println("Client disconnected");
  }

It basically checks for the client and if available sends its data and then disconnects over and over and it works with the browser loosing connection


EDIT: @wwatson this may be a hint on how doStor should be working - connect -send data - disconnect - reconnect. Think its forgetting to try to reconnect

[wwatson]

@mjs513 - @ khoih-prog - Something very peculiar going on. In doRetrieve() I have:

  int spaceLeft = data.availableForWrite();

Did a complete grep of WiFiNINA for "availableForWrite". It was not found. Where is it picking it up from??? That is why doRetrieve() is not working because spaceLeft is always 0...

The used libraries listed in Arduino after compiling only shows WiFiNINA library. I put in Serial.prints in all of client and server available() functions and using them failed to print.

I guess I'll start eliminating libraries till FTP_Server_Teensy411 fails to compile...

[khoih-prog]

@wwatson,

I guess you found out the bug when we convert to use WiFiNINA.

The availableForWrite() is defined in QNEthernet, Ethernet_Generic libraries, etc.

But in WiFiNINA + Teensy 4.1, it's still a virtual function, always returning 0, and defined in cores/teensy4/Print.h

virtual int availableForWrite(void)		{ return 0; }

So when you still use availableForWrite() for WiFiNINA, the chain is

WiFiNINA => WiFiClient => Teensy Client in Client.h => Teensy Stream in Stream.h => Teensy Print in Print.h

To fix, we have to use correct function to replace this for WiFiNINA.

Or we can write a new function availableForWrite() for WiFiNINA

[khoih-prog]

@wwatson,

You can also try using the original doRetrieve() (without availableForWrite()) for WiFiNINA

We've already fixed the WiFiNINA_Generic Cilent write() function, and hope it's OK to use now

#if USE_WIFI_NINA

bool FtpServer::doRetrieve()
{
  if ( ! dataConnected())
  {
    file.close();

    return false;
  }

  int16_t nb = file.read( buf, FTP_BUF_SIZE );

  if ( nb > 0 )
  {
    data.write( buf, nb );
    bytesTransfered += nb;
    return true;
  }

  closeTransfer();

  return false;
}

#else

bool FtpServer::doRetrieve()
{
  if ( ! dataConnected())
  {
    file.close();
    
    return false;
  }
  
  // Find available space in data.write() buffer.
  int spaceLeft = data.availableForWrite();
  // Get remaining bytes to read from file.
  int32_t leftToXfer = file.available();

  if (spaceLeft <= 0) 
  {
    return true; // Return true if no space available.
  }

  // Calculate read size.
  // Base the amount to read on the space available in the
  // data.write() buffer. 
  if (leftToXfer) 
  {
    int32_t nb = file.read( buf,(spaceLeft <= FTP_BUF_SIZE) ? spaceLeft : FTP_BUF_SIZE); 
    data.write(buf, nb);
    bytesTransfered += nb;
    
    return true;
  }
  
  closeTransfer();
  
  return false;
}

#endif

[wwatson]

@wwatson,

You can also try using the original doRetrieve() (without availableForWrite()) for WiFiNINA

We've already fixed the WiFiNINA_Generic Cilent write() function, and hope it's OK to use now

#if USE_WIFI_NINA

bool FtpServer::doRetrieve()
{
  if ( ! dataConnected())
  {
    file.close();

    return false;
  }

  int16_t nb = file.read( buf, FTP_BUF_SIZE );

  if ( nb > 0 )
  {
    data.write( buf, nb );
    bytesTransfered += nb;
    return true;
  }

  closeTransfer();

  return false;
}

#else

bool FtpServer::doRetrieve()
{
  if ( ! dataConnected())
  {
    file.close();
    
    return false;
  }
  
  // Find available space in data.write() buffer.
  int spaceLeft = data.availableForWrite();
  // Get remaining bytes to read from file.
  int32_t leftToXfer = file.available();

  if (spaceLeft <= 0) 
  {
    return true; // Return true if no space available.
  }

  // Calculate read size.
  // Base the amount to read on the space available in the
  // data.write() buffer. 
  if (leftToXfer) 
  {
    int32_t nb = file.read( buf,(spaceLeft <= FTP_BUF_SIZE) ? spaceLeft : FTP_BUF_SIZE); 
    data.write(buf, nb);
    bytesTransfered += nb;
    
    return true;
  }
  
  closeTransfer();
  
  return false;
}

#endif

Thank you I did see that it was defined as a virtual function. I am not very good with C++ as you can probably tell or C for that matter. I have run out of time tonight but will regroup this weekend and test...

Edit - I guess that is why NativeEthernet QNEthernet worked.

[mjs513]

@wwatson - @khoih-prog

Think I got doStore working with the following changes - this is with SimpleFTPServer if you can give it a try and let me know if it works for you.

bool FtpServer::doStore()
{
  if( ! dataConnected())
  {
    file.close();
    return false;
  }
	
  int16_t na = data.available();
  if( na == 0 ) {
	  DEBUG_PRINTLN("NO DATA AVAILABLE!");
#if FTP_SERVER_NETWORK_TYPE_SELECTED == NETWORK_SEEED_RTL8720DN || FTP_SERVER_NETWORK_TYPE_SELECTED == NETWORK_WiFiNINA
	  data.stop();
#endif
    if( data.connected()) {
      return true;
    } else
    {
      closeTransfer();
      return false;
    }
  }

  if( na > FTP_BUF_SIZE ) {
    na = FTP_BUF_SIZE;
  }
  int16_t nb = data.read((uint8_t *) buf, na );
  int16_t rc = 0;
  if( nb > 0 )
  {
	    DEBUG_PRINT("NB -> ");
	    DEBUG_PRINTLN(nb);

    rc = file.write( buf, nb );
    DEBUG_PRINT("RC -> ");
    DEBUG_PRINTLN(rc);
    bytesTransfered += nb;

	  if (FtpServer::_transferCallback) {

		  FtpServer::_transferCallback(FTP_UPLOAD, getFileName(&file), bytesTransfered);
	  }
  }
  if( nb < 0 || rc == nb  ) {
    return true;
  }
  client.println(F("552 Probably insufficient storage space") );
  file.close();
  data.stop();
  return false;
}

[mjs513]

@wwatson
Just a followup to my previous post - did some more testing and seems like uploading files >500K fail for the most part. Havent found the issue yet

[wwatson]

@wwatson
Just a followup to my previous post - did some more testing and seems like uploading files >500K fail for the most part. Havent found the issue yet

Hi Mike,

Been working on this all week. Today I have everything working. But to get downloads from the T4.1 to the PC I had to do a hack. The problem is WiFiNINA is not setup to check if a transfer from the T4.1 has completed or not. As stated in an above post, it does not have an 'availableForWrite()' function. The T4.1 keeps overrunning the buffer. 'data.write()' returns the number of bytes actually written. So between that and having to add a delay it's working. The problem with the delay is that it slows down the transfer rate. I can transfer a 32Meg file to completion

I found out that nina-fw is based on the same WiFi library that I was using for the ESP8266:
https://github.com/JiriBilek/WiFiSpiESP

and here:
https://github.com/JiriBilek/WiFiSpi

I will clean up the mess with the code and attach the zip files for testing.

Next is simpleFTPServer. But I need to walk away from this for a bit

[mjs513]

Hi Mike,

Been working on this all week. Today I have everything working. But to get downloads from the T4.1 to the PC I had to do a hack. The problem is WiFiNINA is not setup to check if a transfer from the T4.1 has completed or not. As stated in an above post, it does not have an 'availableForWrite()' function. The T4.1 keeps overrunning the buffer. 'data.write()' returns the number of bytes actually written. So between that and having to add a delay it's working. The problem with the delay is that it slows down the transfer rate. I can transfer a 32Meg file to completion

I found out that nina-fw is based on the same WiFi library that I was using for the ESP8266:
https://github.com/JiriBilek/WiFiSpiESP

and here:
https://github.com/JiriBilek/WiFiSpi

I will clean up the mess with the code and attach the zip files for testing.

Next is simpleFTPServer. But I need to walk away from this for a bit

Thanks for the info. Kind of figure the availableforwrite just now when I was looking at the ESP8266 core. But I have been working on this so long I need a break - about ready to give up.

[wwatson]

@ mjs513 - Well here they are:

Got SimpleFTPServer working as well. Just remember 'doRetrieve() and doStore()' are hacked as a workaround. In Filezilla with FTP_Server_T41 both passive and active modes work. SimpleFTPServer only works in active mode. Also Filezilla needs to have the connection limit set to 1 and the checkbox needs to be checked.
Again when you disconnect from the FTP servers you need to reset the T4.1 or wait for the servers to timeout and disconnect the client. Haven't had time to find out why yet. There is a delay in 'doRetrieve()' function (part of the hack) the is set to 50. This can be played with. Lastley, you need to use a computer with WiFi capabilities. I tried to connect with Ethernet through my router to the T4.1 with the Adafruit Airlift Featherwing and it would not connect. I'm sure there is a way but I don't know how.

I also included my nina firmware bin file.

Hopefully I remembered everything Good luck testing...

EDIT: The transfer speeds are really slow. Running about 240KB/s. With QNEthernet or NativeEthernet it's 1-2 MB/s. Curious to see what you get. I have a fairly old D-Link WiFi router. That could also be a problem. I tried setting FTP_BUF_SIZE to 2048 and 8192 to it helps a little but then the transfers become unstable. The best results are with FTP_BUF_SIZE set to 1500 and the delays set to 45-50. Going to take a break from this and update to the latest USBHost_t36 developments. Then start playing with WiFiNINA_Generic and nina_fw. By the way I am using Arduino 1.8.19 and TD1.57B1 with out the patches to cores or boards.txt.

[mjs513]

EDIT: The transfer speeds are really slow. Running about 240KB/s. With QNEthernet or NativeEthernet it's 1-2 MB/s. Curious to see what you get. I have a fairly old D-Link WiFi router. That could also be a problem. I tried setting FTP_BUF_SIZE to 2048 and 8192 to it helps a little but then the transfers become unstable. The best results are with FTP_BUF_SIZE set to 1500 and the delays set to 45-50. Going to take a break from this and update to the latest USBHost_t36 developments. Then start playing with WiFiNINA_Generic and nina_fw. By the way I am using Arduino 1.8.19 and TD1.57B1 with out the patches to cores or boards.txt.

Started with SimpleFTPServer and seemed to work with files up to about 6MB but then looked at your code changes to doStore and since I can not leave well enough alone changed this

  // This my hack.
  uint32_t tmout = millis();
  int na = 0;
  while((millis() - tmout) != 50) {
    na = data.available();
    if(na != 0) break;
  }

to this

  // This my hack.
  uint32_t tmout = millis();
  int na = 0;
  while((millis() - tmout) != 500) {
    na = data.available();
    if(na != 0) break;
  }

and was able to transfer a 94mb from the T4.1 to the PC. Transfer rates using 1500 was about 310Kbytes/second.

I am using the modified versions of the nina-fw.bin and wifnina libraries that we did earlier and of course using Arduino 1.8.19 and TD1.57B1 with out the patches to cores or boards.txt same as you. Probably will change to 2048 from 1500 though.

EDIT: If you want to DISCONNECT the T4.1 from fileZilla do the following:
Server => Enter Custom Command => type QUIT in the box and it will disconnect

[wwatson]

Started with SimpleFTPServer and seemed to work with files up to about 6MB but then looked at your code changes to doStore and since I can not leave well enough alone changed this

  // This my hack.
  uint32_t tmout = millis();
  int na = 0;
  while((millis() - tmout) != 50) {
    na = data.available();
    if(na != 0) break;
  }

to this

  // This my hack.
  uint32_t tmout = millis();
  int na = 0;
  while((millis() - tmout) != 500) {
    na = data.available();
    if(na != 0) break;
  }

and was able to transfer a 94mb from the T4.1 to the PC. Transfer rates using 1500 was about 310Kbytes/second.

I am using the modified versions of the nina-fw.bin and wifnina libraries that we did earlier and of course using Arduino 1.8.19 and TD1.57B1 with out the patches to cores or boards.txt same as you. Probably will change to 2048 from 1500 though.

EDIT: If you want to DISCONNECT the T4.1 from fileZilla do the following:
Server => Enter Custom Command => type QUIT in the box and it will disconnect

Thanks for testing. Will try out your changes today. At least it is working for now

[mjs513]

Thanks for testing. Will try out your changes today. At least it is working for now

Ditto here - was getting a bit frustrated.

DELETED ORIGINAL

UPDATE:
Was getting really frustrated so glad you got it working.

Anyway, made the same changes to FTP_Server_T41 and configured a new site in Filezilla and seems to working, maybe a bit slower on the transfers but both seem to be working.