TLDR – Today’s fun ticket “Curl responds with a P” turns out customer was telling the truth. Then I got to do some fun troubleshooting. The P means the server you are connected to expected an SSL connection / HTTPS and not HTTP
Update / Afterthought –Thinking about this issue. Odd Issues like this are one of the big pluses of hosting things with a cloud provider. Pretty much any issue you have with your instance hosted with a cloud provider you can open a support ticket for, for free, and receive help. This issue could have been network (Oracle) or it could have OS setup (Customer responsibility) even the question of where the issue is enough to open a case to Oracle and ask for help. At that point, it is up to Oracle / Me / Cloud provider to prove the issue is custoemr issue or provider issue. In proving it is not us more times then not we solve the issue for you – for free. // Side bonus.
Getting a P
I like the odd cases from time to time. Today we had a great one. The ticket title was “Getting Character “P” when we access Linux Machine on Public IP” when I read this the first thing that came to my mine was ya right I call BS. Reading the case and running the same command the customer ran I too was receiving a P in the response. I high lighted the P below in the CURL response and scribbled all over the customer’s IP address.
Checking the things
After verifing the P was a real thing the next thing I did was check a few other ports on the server; 80 and 443 to start. 80 and 443 were a bust no one was listening. NMAP the server, and Unfortunately for the trouble shooting, the server was not listening on any other ports with the same web server. – That’s a bust. I guess I could ask the customer to set something up, but there has to be more to check.
Packets are cool; let’s check the stream with Wireshark to see if there is anything else of value. I found the conversation in Wireshark, right clicked the HTTP Response, and seelected Follow conversation. Looking at full conversation, sure enough, there is a P at the end of the HTTP conversation. Notice the two colours in the conversation. Different colours means different packets – Oh something to look at.
Checking out the stream sure enough there two different HTTP response packets. If I run curl a few times and check, the second packet is always the same byte string. I better copy the string out and search the internet. Sure enough searching for the byte string 15:03:03:00:02:02:50″ yields a good of results. Not sure if 7 million or 760k results?? Google says “About 7,65,000 results (0.91 seconds)” –
According to one of the results the Byte string -15:03:03:00:02:02:50 – Translates as follows:
The bytes are:
15 03 03 00 02 02 50
where:
15 == TLS Alert Message Type
03 03 == TLS Protocol version 1.2
00 02 == TLS Frame length
02 == Alert level Fatal
50 == Internal Error
It’s caused by connecting with HTTP to a server thinking you should be connecting with HTTPS and some bits not being set right on the server. Answer to the customer for this one is test with curl https:// vs curl http:// and you will not see the P – Plus search the byte string and check to see if there is something else missing on your server setup.
Now that was some fun troubleshooting.
