meteohub.de

Meteobridge RPi on 3b+ running Meteobridge 5.2 (Nov 20 2021, build 2449), FW 1.3.

My Meteobridge has been doing an ftp upload to another RPi on my local network for several years. The receiving RPi merged the weather data onto a camera image and sent it on to several sites. That RPi that was receiving the data had not been updated since and early Jessie release. I was finally forced to upgrade it so I went up 1 release to Buster.

Since then the ftp from Meteobridge has been failing with : "2022-03-28 13:46:52 Error: 2022-03-28 13:46:51 Invalid reply: "SSH-2.0-OpenSSH_7.9p1 Raspbian-10+deb10u2+rpt1" ncftpput: cannot open 192.168.254.25: invalid reply from server. (no more tries):"

The Events tab in Meteobridge has the correct settings and can successfully reload the template with the 'Info (Event #01): Download of template went fine".

On the "Service Settings" tab, the FTP/SFTP setup is correct and the test button will successfully transfer the "test-upload" file.

Is there a Meteobridge log file that will show me what is the 'invalid reply from server.' ?

Have you defined a FTP or a SFTP upload event? Does your new FTP server installation support plain FTP uploads?

New OS versions try to reduce older, less secure options because they think the other side is also a PC where are no limitations in upgrading in terms of CPU, storage, etc. Embedded devices are something often not taken into account by the linux developers that are on a ride for their next latest and greatest playground and don't have any experience and interest on something smaller than a laptop.

Have you defined a FTP or a SFTP upload event?
YES:
Template = http://192.168.254.25/WebCam/WeatherStats.html
Path = ftp://pi:raspberry@192.168.254.25:22/We ... eoData.asc


Does your new FTP server installation support plain FTP uploads?
Yes - it supports ftp and sftp. Wouldn't the "Service Settings" FTP/SFTP test buttons have failed if the destination machine did not support ftp?

TO make certain, I have verified that the destination machine will accept a file by transferring a file onto it and into the desired directory from a Windows10 desktop (using a DOS window) and also from another RPI (also using command line).

I have verified from a command line that Meteobridge can find and connect to the server that it is trying to reach. I have not tried to delete the ftp event in Meteobridge add it back as a new event. I was hoping to find a log/debug file that showed the commands that were generating the error.

You did not get what I was asking for. I try again.

1) I asked which kind of event you used. There are two options, FTP or STFP. When you use the wrong one it will not work whatever the path is you specify or what your generic settings tell. YES is not a useful answer when being asked if you did a) or b)

2) Did you test a plain FTP upload to your RPI server? Please do with a client that does not automatically switch to SFTP when the server asks to do so.

When you look at the error message you posted you can see "SSH-2.0-OpenSSH_7.9p1 Raspbian-10+deb10u2+rpt1" which is a clear indication that SFTP is tried. My questions 1) and 2) tried to resolve if the MB event is configured incorrectly or your server is trying to force into SFTP.
As you can see, my questions had a thought behind and should not trigger you into the "what stupid questions, I know myself best"-mode.

I am sorry that my reply sounded like that, It was not meant that way. I was reading your question as "Are you sure it is a ftp event instead of a http, html, or any of the other events?"

I did not realize that I had CAPS on. I worked many years in data systems and my cardinal rule was "Do NOT screw up a working system while trying to debug a system with a problem." This Meteobridge has transferred this file for at least 5 years I was not looking for the problem there.


I did find the problem by creating another event, entering exactly the same steup manually and not a copy & paste. I used a different RPi running the same OS version. It also failed, but gave a different error message about 'path doesn't exist'. It was a simple fix with that message.

In my situation with the pi user, when setting up the FTP/SFTP Event, the Path(File) setting always includes '/home/pi' in front of the specified location and file. Apparently, years ago I put a symbolic link in that directory to make sure the sent file got to the correct location. And that link got removed in the upgrade.