Cumulus Support

This started recently, and is happening to me in the current build - 3173. I'm having issues getting the packets uploaded to the web site - receiving the error message in MXDiag:

2022-04-17 21:10:01.946 FTP[Int]: Error connecting ftp - The requested name is valid, but no data of the requested type was found

I switched logging to debug, and there were no obvious errors, except for the above. This has cropped up recently - I had been using the default web site for a around a year now, and it had updated just fine.

The odd thing is if I use the same credentials I have loaded into Cumulus WinSCP, I can get in fine, and then - uploads work for a few hours. This is probably an environmental issue on my part - but the error message is not helping me isolate it.

Thoughts?

Tom

Did you turn FTP logging on? Try that and post the zipped log here please.

Here you go... I turned FTP logging on, bounced the service, let it try a few times, and then bounced the service to complete the file. The web site is at http://www.themarxes.us/weather.

I did a little more digging on my part, and first started seeing this issue on January 12 - 2022, in Build 3159. It was intermittent, which was probably why I didn't notice it.

Again, I'm not for you to fix my issue, but only understand under what conditions this error message will be thrown.

Thanks again,

Tom

FW0314 wrote: ↑Mon 18 Apr 2022 5:47 pm I did a little more digging on my part, and first started seeing this issue on January 12 - 2022, in Build 3159. It was intermittent, which was probably why I didn't notice it.

Again, I'm not for you to fix my issue, but only understand under what conditions this error message will be thrown.

Thanks again,

Tom

Most likely it is something on the server side.

As CMX issues many files to the server and especially the realtime at a certain high frequency, some servers detect it and may qualify it as an attack not looking any further and maybe disable the origin without notifying.

I recently found out by somebody I assisted in an install. Fortunately he was warned.
Try communicate with your provider, ask them what is happening (their logs should tell something) and explain what is going on.
It may help

(if it is the cause try lowering the realtime frequency: some use 3 seconds which is really a bit overdone. 15 or 30 seconds should do)

Otherwise try switch to SFTP or FTPS.

If you are still on version 3159, try the current version (don't forget to update all files).

Mine was working fine, following the latest update the FTP auto uploads have stopped, I can manually trigger the upload and it works fine so no issues with the access details it just seems the automatic part isn't working.
I checked the settings which seem correct (unchanged).

To make a long story short - the primary issues have been resolved by reconfiguring my internal network DNS. For some reason, my server (only the server) wasn't correctly resolving all name requests. This affected FTP transfers for the web site to my hosting provider, CWOP updates, and the program check to Github to check for CumulusMX updates. After reviewing months of logs for the error message noted earlier, I started to see issues logged as early as last January. However, it came to head starting last week when I updated my internet connection, and had a new router installed. That's when the CWOP updates stopped.

The error messaging could be better - but it sort of makes sense now that I know the issue. The one item that really screwed with me was that although CWOP was failing every time, no errors were thrown at all. The data must be using "send and forget" logic, or it may be a limitation with CWOP.

Anyway, thanks for looking into it - and for those that have issues in the future - here you go.

I wish mine was this, but can't see how it is.
Yesterday I rebooted my Pi and it's updated via FTP several times and then just stopped again at 1800.
Doesn't make sense, why doesn't it keep trying until it's successful or let me know what the issue is?

Any help would be appreciated.

When it's in the failed state, can you run ftp from a command line to your server? Can you ping the server using the domain name? Does it work if use the IP address of your FTP server in CumulusMX instead of the domain name?

What I found is if I opened an FTP session via command line, or using SCP, my hosting server kept the session open for my internet facing IP address for 3 hours.

Now that I know what to look for - enable FTP logging, and set your application log level to debug. Bounce your machine and run until you see the error. Bounce the machine again to close the logs - post them. The application logs are in the MXdiags folder, the FTP logs are in the CumulusMX folder.

It might take a day or so for me to get back, but I can throw another set of eyes on them.

Tom

FW0314 wrote: ↑Tue 19 Apr 2022 8:51 pm To make a long story short - the primary issues have been resolved by reconfiguring my internal network DNS. For some reason, my server (only the server) wasn't correctly resolving all name requests.

I changed to the IP of my FTP site and it may have run a little longer but it failed again yesterday at 1800

Hi Tom,
Please see responses below -

FW0314 wrote: ↑Wed 20 Apr 2022 5:30 pm When it's in the failed state, can you run ftp from a command line to your server? Can you ping the server using the domain name? Does it work if use the IP address of your FTP server in CumulusMX instead of the domain name?

Yes and appears to make no difference.

What I found is if I opened an FTP session via command line, or using SCP, my hosting server kept the session open for my internet facing IP address for 3 hours.

Now that I know what to look for - enable FTP logging, and set your application log level to debug. Bounce your machine and run until you see the error. Bounce the machine again to close the logs - post them. The application logs are in the MXdiags folder, the FTP logs are in the CumulusMX folder.

It might take a day or so for me to get back, but I can throw another set of eyes on them.

Tom

I'd imagine if it were a DNS issue it would fail, retry, retry and eventually be successful. However, in my case, it works fine for days then just stops and doesn't start again until I reboot Cumulus.

If it happens again, could you try starting a cmd prompt with Administrator rights, then enter the command...

ipconfig /flushdns

Thanks for reply but this is on a Pi and there's no cache.

Ah, sorry, I just glanced at your profile in the messages which says Windows.