Canon TS5330 が Aruba Instant に繋がらないのはファームウェアアップデートをすると直る

Canon TS5300 シリーズの TS5330 を自宅の Aruba Instant (6.x系) に繋ごうとしたら、どうやっても繋がらない。
というか SSID を選択した後にパスフレーズの入力を求めてこなくて明らかにおかしい。
試行錯誤の結果、スマフォでテザリングした SSID に接続し、本体メニューからファームウェアアップデートを行ったところ、繋がるようになりました。 1.090 にて動作を確認。

そんなハマりどころはありましたが、 WiFi ネットワークプリンタでよくある BSSID に縛りがあるといった微妙な仕様なども無く*1、 IPv6 リンクローカルアドレスも振られるし、ネットワーク周りの出来は良いように見えます。
最近のプリンタは Mac 対応のためかローエンドでも LPR とかに対応してるのね…。

TS5330 自体はプリンタカートリッジを交換するとヘッドも一緒に交換されるタイプのプリンタです。インク詰まりと無縁なのが地味な特徴です。 TS3330 より上位機種ですが急ぎ必要で TS3330 の在庫がなかったので買っただけ。

ニッチな気もするけれどもインターネット上に情報がなくて試行錯誤したのでここに記す。

*1:同一 SSID で複数 BSSID が見える場合は、 BSSID 指定で接続するか複数 BSSID を許容するか選べる。そもそもプリンタがローミングするのかという話はあるが。

2019-11-07

NB ロードスター 6MT の 2nd ギヤは欠品だが改良品なら出る

NB8C (NB2) ロードスターのトランスミッションオーバーホールに必要な 2nd ギヤ Y601-17-251 が 2019/10 現在、欠品になっているとのこと。そこで、パーツカタログを眺めてみたところ、 Y601-17-251A なる改良品と思われる部品があることを発見。
NB2 と NB3 のパーツカタログを見比べた結果、

NB2 と NB3 の間で部品番号が結構変わっている
2nd ギヤ周辺で変わっているのはクラッチハブスリーブのみ
カウンターシャフトギヤも新しい部品があるが車台番号の指定なし

ということが分かりました。
と言うわけで、下記の部品で代替して行きつけのショップにオーバーホールを依頼したところ、うまくいきました。

品名	before	after
2nd ギヤ	Y601-17-251	Y601-17-251A
クラッチハブスリーブ	Y601-17-262	Y611-17-262

カウンターシャフトギヤも Y601-17-301A なる改良品と思われる部品が出ていますが、交換せずに組みました。 600km ほど走って特に異常は発生していません。
ググって出なかったので、メモを残しておきます。

蛇足

現物を見ると、シンクロの構造がよく分かり興味深かったです。シンクロの気持ちになってシフトレバーを操作しよう。
$f:id:halfrack:20191107203630j:image$
$f:id:halfrack:20191107203605j:image$
慣らしの過程でシフトフィール変わってきておもしろ〜い。

2018-02-27

Amazonベーシックの激安 Type-C Ethernet Adapter

345円だったので迅速にポチり速やかに手元の Linux 端末に刺し dmesg を採取しました。
Realtek RTL8153 である模様です。

[715761.336406] usb 2-3: new SuperSpeed USB device number 2 using xhci_hcd
[715761.357259] usb 2-3: New USB device found, idVendor=0bda, idProduct=8153
[715761.357264] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[715761.357267] usb 2-3: Product: USB 10/100/1000 LAN
[715761.357269] usb 2-3: Manufacturer: Realtek
[715761.357271] usb 2-3: SerialNumber: xxxxxx000000
[715761.400477] usbcore: registered new interface driver r8152
[715761.406816] usbcore: registered new interface driver cdc_ether
[715761.524592] usb 2-3: reset SuperSpeed USB device number 2 using xhci_hcd
[715761.601809] r8152 2-3:1.0 eth0: v1.08.8
[715761.630520] r8152 2-3:1.0 enx3c18a0xxxxxx: renamed from eth0
[715761.670409] IPv6: ADDRCONF(NETDEV_UP): enx3c18a0xxxxxx: link is not ready
[715761.698715] IPv6: ADDRCONF(NETDEV_UP): enx3c18a0xxxxxx: link is not ready

USB Type-C が刺さる端末をお使いであれば、 345円なら買いましょう。

Amazonベーシック USB 3.1タイプC - イーサネットアダプター Mac/PC両対応ブラック

出版社/メーカー: Amazonベーシック(AmazonBasics)
メディア: Personal Computers
この商品を含むブログ (1件) を見る

追記

Nintendo Switch で認識し無さそうでございました

2017-07-27

YAMAHA ルータと Splatoon 2

結論から言うと、ヤマハルータの Rev.14.01.09 以降ではデフォルトだと Splatoon 2 が動かないが、 nat descriptor backward-compatibility 1 を叩くと動くようになる。

背景

RTX1210 で動いている WiFi に Nintendo Switch を繋いで遊ぼうとしたら、まったく動かない。マッチを始めるとエラーコード 2618-0513 で「相手のゲーム機と通信できませんでした」と表示され失敗するし、 10回に 1回ぐらいはマッチングが始まるが 8人揃わず制限時間を迎える。(制限時間がちょくちょく伸びるので対戦者を追加しようとして失敗してる様子)

調査

マッチングのときに出る問題であることと、NAPT箱が異なる別のネットワークでは正常に動くので、まあ NAPT越え(NAT traversal)まわりやろと当たりをつけた。

Switch の接続テストでは「NATタイプ B」と表示される。

比較的インターネット経由での対戦・協力プレイが行いやすい環境です。
https://support.nintendo.co.jp/app/answers/detail/a_id/34273?a_id=34278

大雑把に RFC 3489 の分類ではどれなの？ということで、https://play.google.com/store/apps/details?id=hu.uszeged.inf.wlab.stunner&hl=jaを動かしてみたところ、 "Network Type: Symmetric cone" とのこと。
Symmetric NAT は UDP hole punching が効かないのでダメそう。

Symmetric NAT になる実装はあんまり多くなく*1、知ってる範囲だと OpenBSD pf(4) のデフォルト(static-port オプション無し)ぐらいなので、不思議に思って RTX のドキュメントを探したところ、そのものずばりのものがあった。*2

NAT動作タイプの違いについて

曰く、ポートセービングIPマスカレードなる機能が Rev.14.01.08 で追加され、これは Symmetric NAT 相当の振る舞いでありデフォルトで有効となっている。

対策

マニュアルどおり nat descriptor backward-compatibility 1 を叩く。

# nat descriptor backward-compatibility 1
NAT backward-compatibility setting has been configured. Please save config and
restart router to enable new setting.
# save
Saving ... CONFIG0 Done .
# restart

STUNner を動かしたところ "Network Type: Port restricted cone" に変化し、 Splatoon 2 も速やかにマッチが終わり問題なく遊べるようになった。やったー！！

未解決の疑問点

2つある。

まず、 Symmetric NAT にもかからず、なんで "NATタイプ B" になるんだろうか？ Nintendo Switch の NATタイプ判定に考慮漏れがありそうだが、そもそも rfc3489 が廃止になっちゃうぐらい NAT traversal は複雑奇っ怪なので、しょうがない気はする。

次に、NAT動作タイプの違いについてによると Rev.14.01 系以降でも TCP 以外のすべてのプロトコルでは従来の(ポートセービングIPマスカレードではない) NAPT になるとあり、 Splatoon 2 は UDP なので、本来はデフォルトのまま動くはずである。が、動かなかった。
もっと言うと nat descriptor backward-compatibility を変更しても変化が無いはずだが、改善した。これはなぜか？実は UDP の挙動も変わってしまっている？

Nintendo Switch の挙動

Nintendo Switch は UPnP に対応していない模様。 UDP 1900 をまったく投げない。 CGN で二重 NAPT になっていることが多いからやめちゃったのだろうか？
また、 Splatoon 2 は UDP フルメッシュで通信し、マッチ中に UDP が届くか相互にパケットを投げて確認しています。サーバが選出されるようなアーキテクチャではないようで、 8台がすべて相互に通信できる必要があります。

Symmetric NAT

今回はトラブルに遭遇してしまったけれども、ポートセービングIPマスカレード自体は良い機能だと思う。 * cone NAT だと振る舞い上、変換後の送信元ポート数(16bit)でセッション数が制限されてしまうので、グローバル IPアドレスあたりの集約率に限界がある。
しかし、 Symmetric NAT なら宛先 IPアドレスが異なれば送信元ポートを共有できるので大幅に集約率を向上できる。例えば Webクローラーを含む数千台のサーバを 1 IPアドレスに収容するといった芸当も可能で、事例も知っている。
しかし、 CGN で導入すると今回のように NAT traversal でクレームが上がりそうだし、 abuse 問い合わせで src port だけでなく dest ip まで必要になるので、(Webサービスなどで)サーバ側のグローバル IPアドレスを含むログを取得しているのかといった問題がでてくるので、ちょっと難しそうであった。
RTX1210 の用途を考えると良い機能だな、と思います。

結論

NAPT むづかしい

STUNner

STUNner はこんな感じで大変便利なツールでした。

RTX1210 ポートセービングIPマスカレード
$f:id:halfrack:20170726154254p:image$

RTX1210 nat descriptor backward-compatibility 1
$f:id:halfrack:20170726154249p:image$

*1:正確にはセッション数が数千程度という条件があり、例えば iptables MASQUERADE はセッション数 2^16 以上いけるのでポートが足りなくなると Symmetric NAT になるはず。

*2:話は逸れるけど、こういうの調べる度に YAMAHA はドキュメント良くていいなぁと思います。

2016-12-06

Amazon Dash 2nd Generation を分解

Amazon Dash ボタンが日本上陸！ TELEC 201-160049
amazon.com を見たところ AWS IoT Button 2nd Generation なるものが。これはきっと日本で販売されているボタンは TELEC 通した 2nd Gen に違いない！
ってことで買って分解してみました。
$f:id:halfrack:20161206115452j:image$

もろもろシールを剥がしてみましたが、 1st Gen にはあったネジが見当たらず。
$f:id:halfrack:20161206120302j:image$

超音波溶着と判断して強引に剥がします。
$f:id:halfrack:20161206120642j:image$
$f:id:halfrack:20161206120739j:image$

パカッ。
$f:id:halfrack:20161206120856j:image$

2nd Gen では電池ボックスになっています。
また、付属の電池がリチウムからアルカリ電池へ変更になっています。
$f:id:halfrack:20161206121002j:image$

続いてネジ(T5)を外して基板を外します。
$f:id:halfrack:20161206121044j:image$

パカッ。
$f:id:halfrack:20161206121320j:image$

以上で分解は終了です。丹念に眺めていきましょう。
バッテリー面は 25Q032 13E40 というシリアル接続フラッシュメモリがあります。
もいっこのチップは不明。電源用と思われるコイルとマイクが気になります。マイクはなんで付いてるんでしょう？
J2 というコネクタが付きそうなランドも気になります。
$f:id:halfrack:20161206121652j:image$

裏面はこのようになっています。
目立つ部品は MCU (後述)と WiFi コンパニオンチップです。 ATWINC1500B - "single chip IEEE802.11 b/g/n Radio/Baseband/MAC network controller optimized for low-power mobile applications" でした。
中央の黒いチップにはマーキングがあるのですが、マイクロスコープの手持ちがなく裸眼では読み取り不能でした。 WL-CSP のチップが 4つほどあるのですがこちらも判別不能です。
また、同軸コネクタもありますね。
$f:id:halfrack:20161206121640j:image$

大きな黒いパッケージはスポンジが両面テープでついているだけなので剥がせます。
ATSAMG55J19 SMART SAM G55 - "a series of Flash microcontrollers based on the high-performance 32-bit ARM Cortex-M4 RISC processor with FPU (Floating Point Unit)." が出てきました。これが主役でしょう。
$f:id:halfrack:20161206121828j:image$

以上、楽しいボタングラビアでございました。リチウム電池からアルカリ電池に変わったのに 2000回持つようになったのが面白いところですかね？
ケース構造だけでなく、基板構成もだいぶ変わっているようです。 WiFi コンパニオンのシールドがなくなったのも目立つところだけど、 STMicroelectronics, Broadcom の組み合わせから両方とも Atmel になったってのも興味深い。
カメラ忘れてスマフォにてお粗末様でした。

2016-10-25

Debian で NIC offload を無効にする方法

rc.local に書くみたいな雑な手法ではない王道はなにか？
結論から言うと interfaces に offload-lro off とか書ける。

# grep -A3 eth2 /etc/network/interfaces
auto eth2
iface eth2 inet manual
  offload-lro off
  bond-master bond0

#

Debian のお作法として、 rc まわりの情報は /usr/share/doc/${該当機能を操作するコマンド名}/README.Debian に置いておくものらしい。
例えば /usr/share/doc/ifenslave/README.Debian.gz には、 bonding をやりたいとき interfaces にどう書けば良いかドキュメンテーションされている。
検証環境は Debian 8 Jessie です。他ディストロから来て *NIX お作法の範囲で探すんでは気づきようがなかったので、せめてポインタぐらいは man interfaces に書いといてくれとは思いました。

なお今回は、別のアプローチでググっている時に、たまたま下記が引っかかったからヒントになって発見できた。

ethtool for Debian
------------------

Most settings that can be controlled through ethtool can be specified
in /etc/network/interfaces.  They will then be applied to interfaces
that are brought up automatically at boot time or using the 'ifup'
command.  The following settings are supported:

Link mode (--change):
	link-speed <speed>
	link-duplex half|full

Ethernet settings (--change):
	ethernet-autoneg on|off|<mask>
	ethernet-port <port>
	ethernet-wol <mode> [<pass-key>]

Driver control (--change):
	driver-message-level <level>

Ethernet flow control (--pause):
	ethernet-pause-rx on|off
	ethernet-pause-tx on|off
	ethernet-pause-autoneg on|off

Protocol offload (--offload):
	offload-rx on|off
	offload-tx on|off
	offload-sg on|off
	offload-tso on|off
	offload-ufo on|off
	offload-gso on|off
	offload-lro on|off
	(etc.)

Hardware tuning (--coalesce, --ring):
	hardware-irq-coalesce-adaptive-rx on|off
	hardware-irq-coalesce-adaptive-tx on|off
	hardware-irq-coalesce-rx-usecs <n>
	hardware-irq-coalesce-rx-frames <n>
	(etc.)
	hardware-dma-ring-rx <size>
	hardware-dma-ring-rx-mini <size>
	hardware-dma-ring-rx-jumbo <size>
	hardware-dma-ring-tx <size>

Example:

iface eth0 inet dhcp
	link-speed 100
	link-duplex full
	ethernet-autoneg off
	ethernet-wol s 46:65:62:69:61:6e

 -- Ben Hutchings <ben@decadent.org.uk>, Sat,  4 Jun 2011 20:37:08 +0100

http://metadata.ftp-master.debian.org/changelogs/main/e/ethtool/stable_README.Debian

些細な内容だけど、ググってロクにドキュメント出てこなかったのでここに記す。

2016-02-02

雑な LVS/TUN の解説図

LVS で IPIP と DR(DSR) を用いる場合のパケット解釈フローについて、雑に図を起こしたので Web へ放流しておきます。
リンク先にオリジナルサイズもあります。
ホワイトボードを写真に撮ったレベルでツッコミどころもありますが、新人に聞かれて説明するときのお供に便利かもしれません。
$f:id:halfrack:20160202204212p:image$
keepalived + ipvs + tunl0 + lo0 の構成は文章で説明するにはややこしすぎるので、解説するためにこういう図を何度もホワイトボードに書いた覚えがあります。