FR24 is not working properly and not feeding

[amdjml]

I am using the ultrafeeder docker compose file. all other images working just fine except fr24. I see this in the logs for fr24

[2024-12-04 17:26:49.670][fr24feed] [time][e]Failed to synchronize time
[2024-12-04 17:26:49.670][fr24feed] [main][w]Failed to synchronize time, waiting 16 seconds
[2024-12-04 17:26:50.947][fr24feed] [reader][i]Connecting to unknown receiver via (tcp://ultrafeeder:30005)
[2024-12-04 17:26:50.960][fr24feed] [reader][e]Could not connect to tcp://ultrafeeder:30005
[2024-12-04 17:26:55.960][fr24feed] BeastBase::connectTcp(): Unable go connect, error: Network is unreachable[reader][i]Connecting to unknown receiver via (tcp://ultrafeeder:30005)
[2024-12-04 17:26:55.975][fr24feed] [reader][e]Could not connect to tcp://ultrafeeder:30005
[2024-12-04 17:27:00.975][fr24feed] BeastBase::connectTcp(): Unable go connect, error: Network is unreachable[reader][i]Connecting to unknown receiver via (tcp://ultrafeeder:30005)
[2024-12-04 17:27:00.988][fr24feed] [reader][e]Could not connect to tcp://ultrafeeder:30005
[2024-12-04 17:27:05.719][fr24feed] BeastBase::connectTcp(): Unable go connect, error: Network is unreachable[time][i]Synchronizing time via NTP

I have tried to do docker compose pull and it shows that I have the latest versions. I tried to recreate the docker containers and all other run just fine.

[wiedehopf]

This is some bug in the fr24feed binary that probably has to do with DNS replies.

But i haven't been able to pin it down.
The binary is closed source after all.

If you want to provide some data, could you stop the container, run this:

sudo su -
apt install strace -y
while sleep 0.001; do strace -f -p $(pgrep fr24feed) > /run/fr24trace; done

Then start the container with it running.
After 30 seconds, interrupt it and upload /run/fr24trace using this for example:

curl -F'expires=24' -F"secret=" -F'file=@/run/fr24trace'  https://0x0.st

No clue if i can track this bug down further it's very weird.

[amdjml]

when running the last command, I get this:

root@adsb:~# curl -F'expires=24' -F"secret=" -F'file=@/run/fr24trace'  https://0x0.st
451 Unavailable For Legal Reasonsroot@adsb:~

[wiedehopf]

Heh, interesting, must be geoblocked (or tor).

cat /run/fr24trace | nc termbin.com 9999

This might work.
or you can probably upload it here if you can transfer it to your desktop first.

[amdjml]

Here is the output:

fr24.txt

[wiedehopf]

Just for comparsion, which platform is this on?
amd64 or aarch64?

[amdjml]

root@adsb:~# uname -a
Linux adsb 6.6.51+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.51-1+rpt3 (2024-10-08) aarch64 GNU/Linux

[wiedehopf]

Yeah it's getting an IPv6 address for pool.ntp.org from DNS.

But docker doesn't provide IPv6 afaik.
And instead of trying the other IPs it should have gotten for pool.ntp.org, the program completely fails.
At least that's my guess.

I'm really not sure how to best fix this.
Pretty much needs its own DNS proxy to make sure not IPv6 replies make it through to the app.

Think people had some luck running with network: host or even network: ultrafeeder
This ofc requires changing the beast host to 127.0.0.1
Thank you for the trace.
I'm not sure how network: ultrafeeder would work in regards to NTP though as that should still be an issue.
Anyhow those are maybe an option for you.

[amdjml]

Thank you for looking into this. If I were to change the network to host and/or ultrafeeder, where do I make that change in the docker compose file and also changing the beast host to 127.0.0.1?

[wiedehopf]

- network: host

like this for the service.

[wiedehopf]

Yeah i'm not convinced this has anything to do with DNS / ipv6 anymore.
Just some super weird stuff of the binary not being able to connect.

Not sure how to debug this really without having access to the code.
Also motivation is limited.

Anyhow let me know if the workaround works for you.