New Install Not Serving http ?

[ziplockk]

Hi,

Have been running meteohub for many years and want to update my old pi b to a pi 3 b, so I bought a pi 3 b and downloaded the recommended image (5.0s). This boots to a command line login as expected. I can log in as root. The machine has acquired 192.168.20.16 as it's IP address from a hard wired ethernet connection, and for some reason has created 192.168.1.77 as a sub interface (quite why is beyond me - that can never work). Regardless the machine is not listening on port 80 on it's primary IP address. as evidenced by netstat :

root@meteohub-rpi:~# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:45068 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5554 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5555 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5556 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5557 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5558 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5559 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:5558 127.0.0.1:50978 TIME_WAIT
tcp 0 0 127.0.0.1:5558 127.0.0.1:50980 TIME_WAIT
tcp 0 208 192.168.20.16:22 192.168.10.227:53014 ESTABLISHED
tcp 0 0 127.0.0.1:5558 127.0.0.1:50976 TIME_WAIT
tcp6 0 0 :::445 :::* LISTEN
tcp6 0 0 :::7777 :::* LISTEN
tcp6 0 0 :::45190 :::* LISTEN
tcp6 0 0 :::139 :::* LISTEN
tcp6 0 0 :::111 :::* LISTEN
tcp6 0 0 :::80 :::* LISTEN
tcp6 0 0 :::22 :::* LISTEN
udp 0 0 0.0.0.0:958 0.0.0.0:*
udp 0 0 127.0.0.1:990 0.0.0.0:*
udp 0 0 0.0.0.0:35825 0.0.0.0:*
udp 0 0 0.0.0.0:68 0.0.0.0:*
udp 0 0 0.0.0.0:111 0.0.0.0:*
udp 0 0 192.168.1.77:123 0.0.0.0:*
udp 0 0 192.168.20.16:123 0.0.0.0:*
udp 0 0 127.0.0.1:123 0.0.0.0:*
udp 0 0 0.0.0.0:123 0.0.0.0:*
udp 0 0 192.168.1.255:137 0.0.0.0:*
udp 0 0 192.168.1.77:137 0.0.0.0:*
udp 0 0 192.168.20.255:137 0.0.0.0:*
udp 0 0 192.168.20.16:137 0.0.0.0:*
udp 0 0 0.0.0.0:137 0.0.0.0:*
udp 0 0 192.168.1.255:138 0.0.0.0:*
udp 0 0 192.168.1.77:138 0.0.0.0:*
udp 0 0 192.168.20.255:138 0.0.0.0:*
udp 0 0 192.168.20.16:138 0.0.0.0:*
udp 0 0 0.0.0.0:138 0.0.0.0:*
udp 0 0 0.0.0.0:57728 0.0.0.0:*
udp6 0 0 :::958 :::*
udp6 0 0 :::42058 :::*
udp6 0 0 :::111 :::*
udp6 0 0 fe80::ba27:ebff:fe7:123 :::*
udp6 0 0 ::1:123 :::*
udp6 0 0 :::123 :::*
udp6 0 0 :::44722 :::*

So I guess the question is . . . why ? . . .

As expected I can ssh into the machine without issue, just no admin page being served.

Whay am I doing wrong and does any kind of setup guide exist ? . . . It used to be simple . . . not so any more.

TIA

Fd

[BigAlT]

The online manual says the sub address you mention is
“ Meteohub has a backup IP 192.168.1.77 where you should be able to connect to in any case (needs your browsing PC being in the same subnet)

Here’s a link to the online manual

https://www.meteohub.de/files/meteohub-v4.7en.pdf

And the link to the online setup guide

https://www.meteohub.de/files/first-ste ... -steps.pdf

[ziplockk]

Hi, indeed it does.

I have updated to the latest build (5.1d) with no change in the immediate issue, but at least the demo period is functioning to allow me to port the data.

There seems to be something fundamentally broken about the use of wired ethernet connections, probably on non common subnets, because I assume someone has tested this on the 192.168.1.0/24 subnet . . . right ?

I can connect using the 192.168.1.0/24 subnet for 'emergency access' on 192.168.1.77 but no matter what I do I cannot get any http response from the DHCP or STATICALLY allocated address on the 192.168.20.0/24 subnet which my 'untrusted' subnet uses, The webserver is not listening (the netstat output shows this to be the case in all cases). Other services such as ping and ssh work normally on all subnets.

This appears to be a bug, perhaps it only works on common router subnets (like 192.168.1.0/24).

I have plugged in a WLAN adapter and hey presto, it works and pages are served from THE SAME SUBNET that are not served from the wired port. Netstat shows that the webserver is now listening to the WLAN IP address.

Further evidence that there is something wrong with the way wired connections are managed.

Disappointing, but all software has bugs, some more and some less.

I am 'fairly familiar' with networking and linux . . . and have used meteohub on pi for many years . . . all without any hassle I might add.

May be worth fixing if things are still being fixed.

Fd

[BigAlT]

I’m not sure why you would have a problem with a wired Ethernet connection.
I had a PI 3B running Meteohub v5.1a connected to my router via Ethernet and had no problems Bringing up the browser interface.
I’m not using meteohub any longer due to Boris not really supporting the software any longer ( the 5.1d upgrade just extended the trial period and changed the license fee payment method ).
The Meteohub PI software is based on the Linux Debian Wheezy OS Version which has been end of life for several years. You cannot update wheezy under Putty any longer and an update of Meteohub would apparently require a significant update to use the current Debian Jessie OS.
Boris is currently devoting his energies to the Meteobridge System which makes much more economic sense for him as it requires a paid license renewal every two years. I’ve switched to using it myself and have switched my PI to using Weewx ( a free open source system that requires some knowledge of Linux and Putty to get it installed and running ).

[ziplockk]

I'n not sure why it doesn't work either, but it doesn't, what I am sure about is that it's the meteohub software that is the problem.

It's also clear to me that this is now a dead and unsupported product, I use it as a backup system only these days, I wrote my own system some years ago and have scripts which import data from the meteohub system data store.

I'm not really a fan of paid software which then ends up obsolete as is the case here, hence creating my own system which will never be obsolete for me, from hardware to integrate with my VP2 station to the underlying database and graphing. Equally uploading my data to someone elses system to then be reamed for the privelage of accessing it doesn't float my boat either . . .

Just for info in case anybody else ends up in the same position . . . the rsync stuff as defined in the manual also doesn't work, you are better off using ssh, rsync not enabled, rsync incorrect permissions, etc, etc, etc . . .

Ah well