[新]なんでも日記[新]なんでも日記ジャンル不定の日記です。い合わせ問い合わせ問い合わせsocatでwebsocketサーバーができなかった件socatでwebsocketサーバーを作ろうとしてうまく行かなかったが、わかった。socatに-vオプションつけてターミナルに出力してみたが、なんかバイナリぽいのが出力された。socatから実行するシェルスクリプトではreadで1行ずつ読んでたが、readじゃバイナリが読めずに変数に空文字が入ってた感じぽい。今回はクライアントから"test"をsendしてたんだが、readではなくcatでファイルに出力してバイナリエディタで見てみたが、"8184E4F2CFA39097BCD7"↑こんなデータだった。WebSocketの仕様について調べたが、ハンドシェイクのあとはデータは特殊なフレーム化されて送られるのね。FIN最後のフレームの場合1で、続きがある場合は0byteじゃなくてbitなのね。今回の"8184E4F2CFA39097BCD7"を2進に変換すると、"10000001100001001110010011110010110011111010001110010000100101111011110011010111"1bit目は1なんで1フレームで終わり。2bit目からの3bitは予約bitで、仕様を拡張するのに使うようで、そんなものはないので今回は"000"。5bit目からの4bitはデータの種別を表すようで、テキストデータの場合は"0001"9bit目はマスクの有無クライアントから送るデータはマスク必須で、サーバーから送るデータはマスク不可。いうわけで"1"10bit目からの7bitがデータの長さで単位はbyteなんだが、値が126の場合は続く2byteがデータ長。127の場合は続く8byteがデータ長。125以下の場合は続かずその値がデータ帳となる。今回は"test"と4byteをsendしたんで、"0000100"(4)ここまでbit単位になっているが、合計すると16bitで2byteになる。残りのデータはbyte単位。3byte目からの4byteはマスク用keyで、7byte目から残り全部はペイロードデータ。ペイロードデータは、拡張データとアプリデータを連結したもので、予約bitが"000"で何も拡張されてなければ拡張データは存在しないので、ペイロードデータ=アプリデータになる。アプリデータは単なる平文ではなく、マスク用keyと元のデータをXORしたものになっている。マスク用keyは4byteだが、データが5byte以上ある場合はループして5byte目はマスク用keyの1byte目とXORされる感じ。10100011"になってる。11010111"元のデータにマスク用keyをXORしてアプリデータになったわけだが、XOR演算は再度XORすれば元のデータに戻る。01110100"ASCIIコードの"test"ですね。rx/txが数分おきにシステムログに出力されてたんだが、ケーブル代えてみたら治ったぽい。ついてたのはCAT5の記載があった。R1は100Mbpsだし未開封のケーブル使ったから問題ないのかな。R1の管理用CGI関連を暇な時間にやってて、とりあえずHTTP+CGIでできるのは公開もして一段落してるが、websocketの実験も兼ねてsocat+shでwebsocketサーバー作ってる。s3pPLMBiTxaQ9kYGzzhZRbK+xOo=レスポンスはこんな感じになるみたい。ここで重要なのは、リクエストのSec-WebSocket-Keyを元にSec-WebSocket-Acceptを作る。作り方は、Sec-WebSocket-Keyの値に"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"を追加した文字列のSHA1ハッシュをBase64した文字列がSec-WebSocket-Acceptになる。-sha1|base64s3pPLMBiTxaQ9kYGzzhZRbK+xOo=↑sha1sumを使わずにopensslコマンドを使う。-p|base64s3pPLMBiTxaQ9kYGzzhZRbK+xOo=↑xxdコマンドでsha1sumの16進文字列をバイナリに変換する。base64s3pPLMBiTxaQ9kYGzzhZRbK+xOo=↑sedを使ってるがわけわからんコードwの3種類の方法を発見した。opensslはBuildrootの標準で入ってない。Linuxに無いからBuildrootにもないかと思ったがあった!が、-rオプションに対応していない・・・sed使うコードはわけわからん。いうわけで考えたが、openssl入れてまで実現したくないな・・・なんだが、websocketの実験もしたいし、とりあえず母艦で実験は続けるか。R1関連も一旦落ち着いた感じなんで、届いたまま放置してたSTM32を使ってみようと思った。はんだ付けは苦労したがなんとかできたと思う。手持ちのヘッダーピンが太いようで入らなかったんでソケットを装着した。開発ツールはSTM32CubeIDEというSTM公式のツールが情報多い感じなんで(というか、他の情報が全然ない)それ入れようとした。AURにあったんだが依存パッケージがmakepkgできず諦めて、公式からインストーラーを持ってきて入れた。中華ST-Linkには端子が10本で、RST、GND、SWIM、3.3V、5.0V、SWDIO、GND、SWCLK、3.3V、5.0Vとなってる。このうちSWDIOとSWCLKをつないで、3.3VとGNDで電源供給すればいいぽい。STM32F042K6T6は1番ピンがVDD、32番ピンがVSSとなっているが、VDDが3.3VでVSSがGNDのことみたい。24番ピン(PA14)がSWCLKで、23番ピン(PA13)がSWDIOとのこと。最初、角にあるPA14でLEDを点滅させようかと思ったが、SWCLKは空けておいたほうが良さげだから9番ピン(PA3)に変更した。CubeIDEでプロジェクトを作成して、ICの画面で24番ピンをクリックしてSWCLKにしたら23番ピンもSWDIOに変わった。main.c"の"MX_GPIO_Init"にGPIOの設定が出てきた。As"からビルドしてデバッグができるみたいなんだができなかった。deviceこんな感じで、なんかST-Linkは認識しているがSTM32を認識していないような?これまたわからないんで、最終手段としてWindowsにCubeIDEを入れて試してみたが、Linuxのときと表示内容は違うが同じところでエラー。ST-Linkにデバイスがつながっていないようなエラーが出た。Gatewayになった。./config.txtって感じでロードしてた。Gatewayになる。CGIでpwdコマンド出力してみたら、CGIは/cgi-bin以下にあるんだがドキュメントルートの/var/wwwだった。CGIの設置ディレクトリじゃなくてドキュメントルートでCGIが実行される感じなんだね。絶対PATHで読み込めばいいんだが、設置場所変えたらダメだし、$0の場所にcdしなきゃダメな感じかな。Comment(0)次のページ[AD]rentafree.net。