FirebaseのデータをPOSTするやり方がわかったので、あとはESP8266でやるだけだ。
TLS/SSLのサンプルをまねしてやってみよう。
NONOS SDK v1.5.3だ。
client handshake start.
client handshake ok!
うん、接続はうまくいっている。
が、espconn_secure_send()して、送信完了コールバックの後くらいにESP8266がエラーログを吐いている。
client's data invalid protocol
Error: SSL error 3
うーん。
ESP8266でたまに困るのだが、ESP8266自体がログを出すけれども、それが何なのかよくわからないことがしばしばある。
今回も「SSL error 3」と情報は出ているのだが、3が何なのかよくわからん。
ESP8266のTLS/SSLライブラリはaxTLS Embedded SSLのはずだから、ここを見ることにする。
「invalid protocol」で検索したが、出てくるのは「invalid protocol message」の方だった。
ということは、メッセージ自体はaxTLSではなく、アプリ側で出力させているということか。
一応、ライブラリの方も見ておこう。
$ find ./ -name "*.a" | xargs strings -f | grep "invalid protocol"
./libssl.a: client's data invalid protocol
./libssl.a: server's data invalid protocol
./libssl.a: invalid protocol message
あー、これじゃわからんではないか。
では、もう片方のメッセージ「SSL error」で検索しよう。
こちらは、tls1.cで、ssl_display_error()に渡されたエラー値をマイナスしているだけだ。
SSL_OKなどと比較していることからすると、エラー値の3はこれか。
#define SSL_CLOSE_NOTIFY -3
クローズされたっていう通知で、その理由を示すものではないのね。。。
サーバに切断されて、その理由が「invalid protocol」ということか。
Handshakeはうまくいっているから、証明書とかの問題ではないと思うのだが。。。
まさか、TLSのバージョンとかか？
でも、それだとHandshakeがうまくいかないと思う。
一応Wiresharkで見ることにした。
Windowsだと見えないので、VirtualBox上で確認。。。
ネットの情報を見ながらやってみたが、そんなに悪くない気がする。
curlに、--tlsv1.1を付けても成功するし、--tlsv1.0でもいけた。
Cipher SuiteもESP8266で対応しているTLS_RSA_WITH_AES_256_CBC_SHAを指定したが、ちゃんと動いた。
curl --tlsv1.0 --ciphers AES256-SHA -X POST -d '{"test1":{"now":{".sv":"timestamp"},"name":"hiro","date":"06/03"}}' 'https://xxxx.firebaseio.com/rest/saving-data/test.json?auth=ごにょごにょ'
まあ、Handshakeできてるからねぇ。
ここまでやっておいてなんだが、JSONとしてPOSTしているつもりなのだが、ヘッダが足りないとか、単純なところでサーバがはじいているだけじゃなかろうか？
あ、Content-Lengthを指定してないや。。。
POST /rest/saving-data/test.json?auth=ごにょごにょ HTTP/1.1
Host: xxxx.firebaseio.com
Accept: */*
Content-Type: application/json
Content-Length: 68
{"test1":{"now":{".sv":"timestamp"},"name":"hiro","date":"06/03"}}
はい、OKです。。。
今回の反省
- もっと自分を疑ってよい！
以上でございます。
まあ、ESP8266がSSLエラー3を出してきたときはサーバ側で切断されているから、送信しているフォーマットが間違っていないかどうかを確認するといいんじゃないの、というところかね。
ソースは、こんなのです。
hirokuma/esp8266_firebase_post: ESP8266 NONSDK v1.5.3 Firebase POST
