[llcp]InJumpForDEPとATR_REQとSetParameters

NADだ。
以前も、NADとDIDについて考えたことがあったのだが、そこまで深くはなかった。
LLCPをやるにあたって、またその問題を考えねばならぬようだ。

llcp-test-serverでTgInitAsTargetして、llcp-test-clientからinitiatorモードでInJumpForDEPすると、serverは「DEPじゃなくてFeliCaから要求がきた」と判断している。
DEPで接続したいので、このInJumpForDEPを無視して、またTgInitAsTargetしている。
これが、いつまでたってもserverがnfc_target_init()から抜けない理由である。

DEPかどうかをどうやって見ているかというと、ATR_REQのパラメータだ。
InJumpForDEPを投げると、R/WはATR_REQを送信する。
その中に、PPiがあり、bit0が1だとNADを使う、ということになっている。

TgInitAsTargetは戻り値のModeでDEPかどうかがわかる。
bit2が1なら、DEPだ。
このDEPビットが、何を見て立てるのかはわからんかった。
PPiを見てるって感じではなく、無線の設定なんかだろうか。

---

NFC ForumのDIgitalProtocolを読むと、Initiator側のPPiではNADを0にしろ、と書いてある。
ほほぅ。

また、PN533のドキュメントには、NADバイトはInDataExchangeで指定しなさい、とある。
InDataExchangeを使うと、DEP_REQを送信する。
そのDEP_REQにはNADバイトってのが専用にある。InDataExchangeを使うのはそういうわけだ。

ってことは、ATR_REQのPPiに載っているNAD情報は関係がなく、実際にはDEP_REQに出てくるということか？
それなら、現在の動作も納得できるような気がする。
TgInitAsTargetから抜けないのは、InDataExchangeを待っているから、ということだ。
InDataExchangeでNADバイトが指定されていたとき、libnfcのTgInitAsTargetを抜けてlibnfc-llcpに戻ってくるのだ。

さて、そういう動作をしてくれるだろうか？

---

うーん、InJumpForDEPがタイムアウトしている。
ってのは、昨日と一緒だな。
InJumpForDEPはATR_REQだから、ATR_RESを待っている。
SetParametersでATR_RESの自動返信ビットを立てているから、タイムアウトしなくても良さそうなものなのだが・・・。

それと、無線が不安定だ。
PaSoRiの上にRC-S620/Sをぺたっと置いているのだが、どうもそれだと反応が悪い。
間に紙を挟んだりすると、よさそうな感じがする。
よいというか、タイムアウトするというだけなのだが。

PaSoRiはType-Bに対応させるため、無線の調整をしたという話を聞いたことがある。
元々DEPを想定したものではないから、問題があるのかも。

RC-S620/Sがもう１枚あればいいのになぁ。
１枚壊したのが、非常に痛い。。。ACKが返ってこないから、致命的だ。
修理したいけど、無理だろう。情報ないし。せめてTPの情報が欲しいところだ。
開けてみたけど、小さい部品ばっかりでわからん。
しかしこんだけ小さいなら、逆電流なんかに弱いかもしれん。
うぅ、ピンの1～6が逆になってただけなのに・・・。

 

InJumpForDEPがタイムアウトしてないこともあった。
しかし、それでもTgInitAsTargetは終わってない。
何だろうねぇ・・・。