Are you actually trying to connect to https://www.test.laudian.de/403.html? There is no www, the address is https://test.laudian.de/403.html
@willsdmail btw, you can use the preformatted text option (ctrl+e) so that URLS are not automatically converted to links.
GET https://test.laudian.de/403.html
or
I still get an error from the socket callback after sending that message.
Is it possible this is because the certificate used by your site is different than FR24? I would expect both are Cloudflare, so no.
I’ve set my SSL settings to require TLS 1.3 - does your device maybe not support that?
Edit: I’ve changed that to TLS 1.2 now.
I can’t find anything indicating whether the WiFi module uses either TLS1.2 or TLS 1.3.
I don’t normally debug on the WiFi module as that is more complicated. But I did go back and look. It does appear this is a TLS error. Here are the debug statements:
(Note: This web site does not allow me to put in multiple links. So the links have been broken with ‘*’ in obvious places
(101630)(M2M)Sock created(2)
(101630)(TLS)Creating SSL
(101640)()<- ClientHello
(101650)(TLS)-> ALERT(101650)(TLS) FATAL
(101650)(TLS) TYPE 40
This is a handshake failure. Certificate or TLS?
And just for clarity, below are various debug statements. So you don’t need to peruse them, the results are:
w*ww.flightradar24.*com and test.laudian.de fail for the same handshake reason.
Using the same source code but connecting to the Google Maps API and my own web site work.
*https://w*ww.flightradar24.com
(APP)(INFO)Socket 2 session ID = 3
client socket open.
sin_family = AF_INET, port = 443, IP address = 82311668
client socket connected.
Client send message...
GET https://w*ww.flightradar24.*com
socket_cb: connect error! Socket Error = SOCK_ERR_CONN_ABORTED
(APP)(INFO)Sock to delete <2>
(APP)(INFO)Socket 2 session ID = 3
client socket open.
sin_family = AF_INET, port = 443, IP address = 82301668
client socket connected.
Client send message...
GET test.laudian.de/403.html
socket_cb: connect error! Socket Error = SOCK_ERR_CONN_ABORTED
(APP)(INFO)Sock to delete <2>
h*ttps://test.laudian.de/403.html
(APP)(INFO)Socket 2 session ID = 3
client socket open.
sin_family = AF_INET, port = 443, IP address = 82311668
client socket connected.
Client send message...
GET h*ttps://test.laudian./403.html
socket_cb: connect error! Socket Error = SOCK_ERR_CONN_ABORTED
(APP)(INFO)Sock to delete <2>
(APP)(INFO)Socket 2 session ID = 3
client socket open.
sin_family = AF_INET, port = 443, IP address = ab0fa8e
client socket connected.
Client send message...
GET h*ttps:maps.googleapis.com
socket_cb: transmit success.
socket_cb: receive success.
Client receive message: (contents of html file removed)
(APP)(INFO)Sock to delete <2>
*h*ttps://davewillsinc.com
(APP)(INFO)Socket 2 session ID = 3
client socket open.
sin_family = AF_INET, port = 443, IP address = 48cce7ad
client socket connected.
Client send message...
GET h*ttps://davewillsinc.*com
socket_cb: transmit success.
socket_cb: receive success.
Client receive message: (contents of html file removed)
(APP)(INFO)Sock to delete <2>
I have lowered the settings to TLS 1.0 now.
Results are the same.
Remember, this is an IoT not an O/S. So certificates are not installed automatically as from a browser. What’s odd (to me in my limited knowledge) is that I get the handshake error trying to talk to FR24 home page, but I get the 403 Forbidden if I try to talk to the FR24 playground (which, by the way, is currently inactive.)
And also, I’ve noticed this is TLS 1.2 as shown by the WiFi debugger:
(15520)(M2M)Sock created(2)
(15520)(TLS)Creating SSL
(15520)()<- ClientHello
(15540)()-> ServerHello
(15540)(TLS)CT = 009C
(15540)()-> Certificate
(15550)(TLS)==* X509 ==*
(15550)(TLS) Subject
(15550)(TLS) Issuer
(15550)(TLS) <2024-02-10 00:00:00> to <2024-12-31 23:59:59>
(15560)(TLS)==* X509 ==*
(15560)(TLS) Subject
(15560)(TLS) Issuer
(15560)(TLS) <2020-01-27 12:46:39> to <2024-12-31 23:59:59>
(15560)(TLS)Root Cert
(15560)(TLS) <2000-05-12 18:46:00> to <2025-05-12 23:59:00>
(15560)(TLS)Now <2024-09-04 21:39:01>
(15560)(TLS)Root Valid
(15570)()-> ServerHelloDone
(15660)()<- ClientKeyExchange
(15660)()<- ChangeCipherSpec
(15660)()<- Finished
(15680)()-> ChangeCipherSpec
(15680)()-> ServerFinished
(15690)(TLS)Session () is Established ==> TLSv1.2 ALPN:0
(15790)(M2M)C-S<2>
And I believe this confirms that the traffic is passing SSL encrypt/decrypt.
And that would mean FR24 is blocking my traffic. (It doesn’t explain why I can’t talk to test.laudian though.)
?
The thing is, the TLS handshake failed right after the client hello. So your client didn’t ever see a certificate.
In the Client Hello, your client tells the server what TLS settings it supports. The server then responded and said that it does not support any of the settings that your client supports and the connection is terminated.
It would be helpful to know what TLS settings your device supports exactly. But it doesn’t really matter for the original problem, where you were able to perform a successful TLS handshake.
Btw, what hostname did the playground use?
I believe I have found the problem. I believe FR24 switched servers from an internal one to a Cloudflare one. I’m not trained on web communications, so I can’t say for sure. But it appears my GET command is not being handled by Cloudflare.
If this is the problem, I can fix it easily. But FR24 needs to give me new credentials as their beta test has ended. It will take a few days to work that out because of time differences.
It still does not explain 2 things:
FR24 did not see my IP address even when I was successfully accessing their API server.
Fatal error 40 on handshake with test.laudian and flightradar24.
I post back as soon as I hear from FR24.
Thanks.
Hi Laudian,
It took some time to overcome the API shutdown but I have access again.
SORRY to carry this on so long. 
The 403 Forbidden error is gone, but I’m now getting a 400. This could be my communications with FR24 again, but I’m concerned I’m still not getting through Cloudflare.
Here’s the debug:
socket_cb: FR24 receive success.
FR24 Client receive message: HTTP/1.1 400 Bad Request
Server: cloudflare
Date: Wed, 11 Sep 2024 22:57:31 GMT
Content-Type: text/html
Content-Length: 155
Connection: close
CF-RAY: -
What’s odd is there is no ray ID. How can I determine if this got through Cloudflare to FR24, or it Cloudflare is still in the way? I believe my WiFI debug still indicates encryption is working fine.
Thanks,
Dave
I’m not 100% sure, but I think a 400 Bad Request (cloudflare) means that FR24 are using Cloudflare Workers and they are trying to make a subrequest that fails for some reason - so this would be an error in their code.
This would also explain why they don’t see any traffic on their servers - if they are using Workers, that would mean the app is running on Cloudflare servers, at least partially.
That is indeed weird if the requests are going through Cloudflare. Can you share the URL that you are sending requests to so I can check this for myself?
Here’ the latest attempt, with the private token removed (asterisks inserted to overcome page post error):
htt*ps://fr24api.flightradar24.*com/api/live/flight-positions/full?bounds=50.682,46.218,14.422,22.243
Accept: application/json Accept-Version: v1
Authorization: Bearer
This attempt has “\r\n” after “243” and “v1” but I’ve tried space too.
I could never talk to test*.laudian.de either.
Dave
BTW, that same url formatted in a curl command running on a remote machine works just fine. That would indicate some other problem and I’m afraid I’ve come full circle.
flightradar24 . com
www.flightradar24 . com
https://flightradar24 . com
https://www.flightradar24.com
All result in a 400 Bad Request. I’m back to thinking this is being blocked by Cloudflare (as test.laudian . de is)
?