meteohub.de

Can you please give me remote access? Please mail credentials to "info(at)meteobridge.com".
Did you install any packets on your own or did any other changes while exploring from the shell?
As all systems here don't have any problems it is rather obvious that your system differs in some way from the stock.

yes with pleasure,

tell me when you want to proceed

I will send you the credential (not very secure again )

Hi again,

I've moved the RPI to a DMZ in prevision to give remote access to support and it's looks like it's working much better now

here is my setup (Internet)<=>Setup BOX doing SNAT<=>FW doing SNAT<=> RPI

I've moved the RPI like below

(Internet)<=>Setup BOX doing SNAT<=>RPI

I've made 100% successful reboot and time looks to be accurate

I'm now monitoring this new setup and will report back if I found any issues

note: looks like for any reason, the meteobridge does not like to have a double SNAT in from of him

jpouyaud wrote: ↑Sun Nov 14, 2021 5:01 pm Hi again,

I've moved the RPI to a DMZ in prevision to give remote access to support and it's looks like it's working much better now

here is my setup (Internet)<=>Setup BOX doing SNAT<=>FW doing SNAT<=> RPI

I've moved the RPI like below

(Internet)<=>Setup BOX doing SNAT<=>RPI

I've made 100% successful reboot and time looks to be accurate

I'm now monitoring this new setup and will report back if I found any issues

note: looks like for any reason, the meteobridge does not like to have a double SNAT in from of him

So the issue you reported was caused by having it locked behind a firewall that cuts all kinds of standard reach out to the Internet?
And you make that noise while the problem is in your infrastructure setup?

Please don't enable remote access and don't send your credentials to me, when you have security concerns.

The firewall is just allowing a SNAT from IN to OUT same as the iptables is doing on the setup box.

Meteobridge has some issue with random offset time when booting up is certain case which is a really a big problem has it just destroy DB records on the database for ever when the prob occures. It has worked for some month and starting to not after some of your update on your binary.

Someone else has experienced the same issue in the past

At this time, we don't know yet if the problem is because of a double SNAT.

I will keep Meteobridge in a DMZ now as a workaround

Just made a reboot test after some hour and the prb is still here...

impossible to have a working reboot

the RPI is on Internet behind a setup box.

looks like the issue is with something in the image which is downloaded.

I see the download, then the RPI reboot, and lost

Meteobridge Landing Page (FW 1.3)

You got here, because Meteobridge application stack you wanted to access could not be loaded from the Internet. Most common reason for that is a bad network configuration of the Meteobridge device, that keeps the unit in endless fast blinking LED mode. From here you can do one of the following:
Wait: May be Meteobridge is still in the process of loading application stack from the Internet and it just needs a bit more time. You can give it a second try by this link
Cloud Simulator: You can setup a new network configuration for your device via this configurator in the cloud. You find details how to use this servive in the Meteobridge wiki, here.
Back to Defaults: When you have your Meteobridge in a cabled LAN environent with a DHCP server (mostly the router) up and running, you might be able to solve your networking issue by bringing your device back to standard network setup, by pressing the button until LED lights up for the first time. Unit will reboot in standard LAN DHCP client mode.
OpenWrt: As OpenWrt is fully operational in your device's flash storage and does not need to load an application stack from the Internet, you can start OpenWrt operation by this link. As OpenWrt is a very complex router setup, this is only recommended for experts, who are familar with OpenWrt and might be able to solve networking issues on that level.
To give you insight what your current networking setup is, you'll find some more networking details below. If you are not that deep into networking, just ignore.

IFCONFIG:
eth0 Link encap:Ethernet HWaddr B8:27:EB:AD:D4:EB
inet addr:192.168.1.12 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::ba27:ebff:fead:d4eb/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1512 (1.4 KiB) TX bytes:4233 (4.1 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:15 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2145 (2.0 KiB) TX bytes:2145 (2.0 KiB)


RESOLV.CONF:
# Interface lan
nameserver 192.168.1.1
search home

ROUTE:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

NSLOOKUP:
Server: 192.168.1.1
Address: 192.168.1.1#53

Name: connect.meteobridge.com
connect.meteobridge.com canonical name = tau.meteobridge.com
Name: tau.meteobridge.com
Address 1: 162.55.245.30
connect.meteobridge.com canonical name = tau.meteobridge.com
Address 2: 2a01:4f8:272:5216::4711

IMAGE LOAD PROTOCOL:
--2021-11-14 15:52:28-- http://download.meteobridge.com/cgi-bin ... offuscated
Resolving download.meteobridge.com... 162.55.245.30, 2a01:4f8:272:5216::4711
Connecting to download.meteobridge.com|162.55.245.30|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4331291 (4.1M) [application/octet-stream]
Saving to: '/tmp/image.tgz'

0K .......... .......... .......... .......... .......... 1% 689K 6s
50K .......... .......... .......... .......... .......... 2% 1.37M 4s
100K .......... .......... .......... .......... .......... 3% 9.23M 3s
150K .......... .......... .......... .......... .......... 4% 9.37M 2s
200K .......... .......... .......... .......... .......... 5% 1.16M 3s
250K .......... .......... .......... .......... .......... 7% 93.9M 2s
300K .......... .......... .......... .......... .......... 8% 99.0M 2s
350K .......... .......... .......... .......... .......... 9% 1.98M 2s
400K .......... .......... .......... .......... .......... 10% 5.70M 2s
450K .......... .......... .......... .......... .......... 11% 1.85M 2s
500K .......... .......... .......... .......... .......... 13% 6.04M 2s
550K .......... .......... .......... .......... .......... 14% 1.82M 2s
600K .......... .......... .......... .......... .......... 15% 6.78M 1s
650K .......... .......... .......... .......... .......... 16% 1.87M 1s
700K .......... .......... .......... .......... .......... 17% 5.83M 1s
750K .......... .......... .......... .......... .......... 18% 6.47M 1s
800K .......... .......... .......... .......... .......... 20% 1.81M 1s
850K .......... .......... .......... .......... .......... 21% 6.73M 1s
900K .......... .......... .......... .......... .......... 22% 1.78M 1s
950K .......... .......... .......... .......... .......... 23% 7.49M 1s
1000K .......... .......... .......... .......... .......... 24% 1.81M 1s
1050K .......... .......... .......... .......... .......... 26% 6.01M 1s
1100K .......... .......... .......... .......... .......... 27% 8.32M 1s
1150K .......... .......... .......... .......... .......... 28% 1.79M 1s
1200K .......... .......... .......... .......... .......... 29% 7.10M 1s
1250K .......... .......... .......... .......... .......... 30% 1.76M 1s
1300K .......... .......... .......... .......... .......... 31% 7.38M 1s
1350K .......... .......... .......... .......... .......... 33% 1.94M 1s
1400K .......... .......... .......... .......... .......... 34% 5.77M 1s
1450K .......... .......... .......... .......... .......... 35% 8.39M 1s
1500K .......... .......... .......... .......... .......... 36% 1.73M 1s
1550K .......... .......... .......... .......... .......... 37% 8.33M 1s
1600K .......... .......... .......... .......... .......... 39% 1.86M 1s
1650K .......... .......... .......... .......... .......... 40% 6.30M 1s
1700K .......... .......... .......... .......... .......... 41% 8.90M 1s
1750K .......... .......... .......... .......... .......... 42% 1.74M 1s
1800K .......... .......... .......... .......... .......... 43% 8.01M 1s
1850K .......... .......... .......... .......... .......... 44% 1.90M 1s
1900K .......... .......... .......... .......... .......... 46% 6.12M 1s
1950K .......... .......... .......... .......... .......... 47% 2.08M 1s
2000K .......... .......... .......... .......... .......... 48% 5.11M 1s
2050K .......... .......... .......... .......... .......... 49% 7.50M 1s
2100K .......... .......... .......... .......... .......... 50% 1.91M 1s
2150K .......... .......... .......... .......... .......... 52% 6.58M 1s
2200K .......... .......... .......... .......... .......... 53% 2.07M 1s
2250K .......... .......... .......... .......... .......... 54% 4.98M 1s
2300K .......... .......... .......... .......... .......... 55% 7.78M 1s
2350K .......... .......... .......... .......... .......... 56% 1.91M 1s
2400K .......... .......... .......... .......... .......... 57% 6.70M 1s
2450K .......... .......... .......... .......... .......... 59% 2.09M 1s
2500K .......... .......... .......... .......... .......... 60% 4.97M 1s
2550K .......... .......... .......... .......... .......... 61% 8.83M 1s
2600K .......... .......... .......... .......... .......... 62% 1.86M 1s
2650K .......... .......... .......... .......... .......... 63% 6.88M 0s
2700K .......... .......... .......... .......... .......... 65% 8.79M 0s
2750K .......... .......... .......... .......... .......... 66% 1.78M 0s
2800K .......... .......... .......... .......... .......... 67% 8.76M 0s
2850K .......... .......... .......... .......... .......... 68% 1.91M 0s
2900K .......... .......... .......... .......... .......... 69% 6.27M 0s
2950K .......... .......... .......... .......... .......... 70% 9.16M 0s
3000K .......... .......... .......... .......... .......... 72% 1.81M 0s
3050K .......... .......... .......... .......... .......... 73% 7.46M 0s
3100K .......... .......... .......... .......... .......... 74% 2.20M 0s
3150K .......... .......... .......... .......... .......... 75% 4.61M 0s
3200K .......... .......... .......... .......... .......... 76% 8.67M 0s
3250K .......... .......... .......... .......... .......... 78% 1.93M 0s
3300K .......... .......... .......... .......... .......... 79% 6.49M 0s
3350K .......... .......... .......... .......... .......... 80% 2.28M 0s
3400K .......... .......... .......... .......... .......... 81% 4.93M 0s
3450K .......... .......... .......... .......... .......... 82% 6.81M 0s
3500K .......... .......... .......... .......... .......... 83% 2.25M 0s
3550K .......... .......... .......... .......... .......... 85% 4.45M 0s
3600K .......... .......... .......... .......... .......... 86% 8.35M 0s
3650K .......... .......... .......... .......... .......... 87% 1.98M 0s
3700K .......... .......... .......... .......... .......... 88% 6.16M 0s
3750K .......... .......... .......... .......... .......... 89% 2.35M 0s
3800K .......... .......... .......... .......... .......... 91% 4.89M 0s
3850K .......... .......... .......... .......... .......... 92% 6.67M 0s
3900K .......... .......... .......... .......... .......... 93% 2.11M 0s
3950K .......... .......... .......... .......... .......... 94% 5.17M 0s
4000K .......... .......... .......... .......... .......... 95% 8.15M 0s
4050K .......... .......... .......... .......... .......... 96% 2.08M 0s
4100K .......... .......... .......... .......... .......... 98% 5.55M 0s
4150K .......... .......... .......... .......... .......... 99% 2.48M 0s
4200K .......... .......... ......... 100% 4.27M=1.3s

2021-11-14 15:52:30 (3.16 MB/s) - '/tmp/image.tgz' saved [4331291/4331291]


ssh to the RPI

BusyBox v1.31.1 () built-in shell (ash)

_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt SNAPSHOT, r14089-1bfba18a36
-----------------------------------------------------
root@MeteoBridge:~# date
Sun Nov 14 15:55:42 CET 2021
root@MeteoBridge:~#

the date is know in the past (the one of the last successful reboot in the afternoon)

Metobridge is know detroying the DB

the prb is still here

after having waited 5 minutes, the date is finally set to the correct one (it was not happening with the previous release some weeks ago...)

looks like something has been added in the code as a patch to mask the main issue with the clock during the network bootup.

what about the DB during the wrong time set ?

we have the answer below
the DB has been impacted ...

tried a new reboot, and same behavior

Summary:
the RPI download the image in the cloud
start with a date of today 15:55 (date of the previous working start)
the DB is erased again (corrupted, wrong record)
after 5 minutes exactly, Meteobridge setup the time correctly

The patch to set the time one time again after 5 mns is the tree which hide the forrest

during those 5 mns, we destroy the database

so please, change the code, and make MB to record sample only after this 5 mns delay

THANKS

another side effect of this bug:

the vantage console see its clock to be wrongly updated by meteobridge at the boot up time...

Can you explain why you are the only one apparently having this issue?

if I was able to answer this question, then we will not be here to talk about that

the RPI is a RPI3 with a Sandisk SDSDQED-064G-XI.

the configuration is a stock one, I means I've changed absolutely nothing from the SSH console. (I've just used the date command 3 weeks ago like sprante did )

only a few people are rebooting their device.

I've noticed something wrong some week ago, and I've investigated much deeper to reach the current result

this is an insidious bug which occurs only in certain condition: I suspect the wrong reboot to occurs with a medium interval between the two reboot

This is all I can say now has MB is like a black box for me with this is perpetual online image booting which hide a lot

potential network issues can be removed from the equation, I practice a little bit with network stuff

Sorry, all you write here are symptoms no one else has and you draw tons of wild and false conclusions.
Meteobridge does not delete databases or parts of it. That is complete nonsense!

Please return your license and do anything else with your RPI and leave the forum. Thanks.

thank you for the ban, very keen from you...

when a metobridge has a wrong date in the past, then it will erase good data by overriding

this is why this is a big problem

fly safe...

Mate, Nobody else is obviously having this issue so exactly why is it apparently only you?

And again the question is WHY only you? What are YOU doing that is different?

Maybe I have the same problem?
viewtopic.php?f=61&t=16155