403 on IoT

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.

1 Like

GET https://test.laudian.de/403.html

or

GET test.laudian.de/403.html

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.

1 Like

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>

test.laudian.de/403.html

(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>

maps.googleapis.com

(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. :frowning:

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: -

400 Bad Request

400 Bad Request


cloudflare (APP)(INFO)Sock to delete <2>

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)

?

Just what does it mean when the ray ID field is blank:

FR24 Client receive message: HTTP/1.1 400 Bad Request
Server: cloudflare
Date: Fri, 13 Sep 2024 16:31:03 GMT
Content-Type: text/html
Content-Length: 155
Connection: close
CF-RAY: -

400 Bad Request

400 Bad Request


cloudflare

Is this from Cloudflare or FR24? I can’t get anyone there to answer.

I have no idea what an empty Ray-ID means, I’ve never seen that before.

The Cloudflare support page says to post to this forum and most users get a response within 1 hour. I’ve been fighting this for weeks with still no resolution.

I’ve submitted multiple examples where the Cloudflare servers reply with no ray ID field (which I understand should never happen). And I’ve submitted examples where the ray ID field is “CF-RAY: -” or, empty of any ID. This second type occurs even when trying to go to cloudflare . com.

How can I resolve this?

Here’s a thought…

If I do:

curl fr24api.flightradar24 . com

I get:

301 Moved Permanently

301 Moved Permanently


cloudflare

If I add -L, I get the data I want. Is it possible to do this same thing inside of a GET command?

This tells me the request was flat-out rejected at the edge and not allowed into the system.

I’m thinking that something like Fiddler might help diagnose this issue.

1 Like

Thanks sdayman. Tried Fiddler but don’t see any additional informaion. Maybe I’m not using it right.

Dave

OK, thanks to all who commented or visited.

This post has been active for 3 months, and unfortunately it is still not resolved. Cloudflare IS blocking my IoT and many who have helped have not yet figured out why.

Cloudflare has ignored my requests to help.

So I’m going to close the ticket. If there is any hope that I can learn more, I will start a new thread.

Thanks again.

Regards,

Dave