doDesc(HardMAC & SoftMAC);

なんかそれっぽい話題で盛り上がっていたらしい．
[Well, got off?]
livedoor Wirelessのラの字も考えてないWeb屋のネタ帳の誤読記事
livedoor wireless、MACアドレスによる認証を開始--ニンテンドーDSにも対応
セキュリティのセの字も考えてないライブドアの公衆無線LANサービス

何はともあれ，IEEE 802.11を読んでみましょ，話はそれからっす．
['kay, before we start to talk wireless thingy, Get IEEE 802.11.]

で，改訂版．
[BTW, here's improved one.]


無線伝送路として使用する周波数帯域自体が全く別のトコを使うのでIEEE 802.11*準拠*で
特に問題無いけど，現在作成中のこのブツ，ハードウェアの何処にもMACアドレスへの縛りが無い．
完全にソフトウェア側で，強引にやればruntimeや通信中でも変更可能．
かなり反則なハードウェアに仕上っている． :P
[It has no problem b/c it'll be used on not common radio frequency band,
this hardware has no hardware restriction for MAC address.
Its address can be changed even if in runtime.
Say, it really rocks, I thought. :P]

ARPのframe formatの話になるとモノを読んだ訳ではないからなんとも言えないけど，
IEEE 802.11ではAP側はMACアドレスをBSSIDとしてframe format中で使う．
このBSSIDはBSSと呼ばれるAPのサービス範囲に定期的に送信されるbeaconと
STAからのprobe requestに対するprobe responseに付加される事になっている．
これはClass I frameと呼ばれるブツでauthenticationやassociation，
つまり認証や論理接続する以前の段階で送受信が許されている．
[I dunno about ARP's frame format b/c I've not read ARP standard.
But, in IEEE 802.11, AP uses its own MAC address as BSSID.
This BSSID is payloaded on beacon and probe resposne.
These are included in Class I frame, it can be tx/rx-ed before
authentication/association is completed.]

つまり，IEEE 802.11に従う限り，APのMACアドレスを知る為にARPを使う必要は無い．
受信側のSTAをテキトーな周波数で固定して，beaconが捕まえられる通信圏内に入れて，
且つPMD/PLCPが適切な機能を持っていれば，無線伝送路上を行き交うモノはIEEE 802.11の
MACのレイヤーではoctet streamに変換される．
結局，ARPとは異なり，STAがAP側に何も送信せずにAPのMACアドレスが分かる．
これはpassive scan，具体的に言うとMLME-SCAN.requestのScanType==PASSIVEに相当する．
[So, in IEEE 802.11, to get AP's MAC address does not needs to use ARP.
All you have to do is, fixed STA's a channel and move into accress area
where it can grab AP's beacon and proper PMD/PLCP capability, you can
see all frame as octet stream in IEEE 802.11 MAC layer.
So, STA does not needs to transmit any frame to get AP's MAC address.]

更に，IEEE 802.11ではAPのBeaconPeriodを幾つにするかは規定されていない．
が，WiFiなんとかとか言う機関が異なるベンダーから提供されるIEEE 802.11な機器で
相互接続性が保証出来るか否かを検査しているらしい．
一般の消費者が使用するIEEE 802.11なブツがAPとして動作する場合，
100[ms]程度の間隔でbeaconを吐く様になっているらしい．
[And IEEE 802.11 does not specified BeaconPeriod value explicitly.
But WiFi-blah tests their connectivity for different vendor's products.
In general, most of IEEE 802.11 products which can be available for consumer
may transmit beacon every about 100[ms] interval.]

勿論，beacon自体を暗号化してしまう手もあるだろうが，
この辺はまた別でIEEE 802.11[a-z]の内，"せきゅりてぃ"なトコが担当しているので良く知らない．
そもそも暗号化したbeaconに対応しない機器では相互接続性は確立出来無い．
[Of cource, there is a way to encrypt beacon itself.
But it's beyond of IEEE 802.11, it's mentioned in security enhancement group
which is one of IEEE 802.11[a-z].
And you can easy to understand it breaks connectivity.]

単純に，「APがbeaconを吐かなきゃ良いじゃん」とか思ったりするが，それはそれで問題有り．
beaconはAPの存在をSTAに知らせる為のbroadcastなブツであり，
且つTSFタイマと言うAPが刻むBSS毎にuniqueなタイマのtimestampを使用して，
未だBSSに属していないSTAがこのTSFタイマに同期する為のブツとしても使用されている．
これはそもそもIEEE 802.11の規定する無線伝送路での通信手段として，
Ethernetで良く知られる
CSMA/CD == Carrier Sense Multiple Access/Collision Detection
ではなくて，
CSMA/CA == Carrier Sense Multiple Access/Collision Avoidance
を使っているから，BSSに未だ同期していないSTAは自ら無線伝送路にブツを吐けない．
勿論，Collision Avoidanceとは言ってもcollisionする事は考慮されているので，
dot11ShortRetryやらdot11LongRetryってのがIEEE 802.11 MAC MIBには存在する．
[Simply, "No beacon transmit is another way to go", of course no.
Beacon is broadcast one to announce where AP is at all,
and it's for synchronize TSF timer which is unique timer of each
BSS as well.
Well, IEEE 802.11 is based on CSMA/CA, not CSMA/CD AKA which is use
base of Ethernet.
So, STA wouldn't transmit any frame before synchronized BSS.]

それからWEPはその名の通り，Wired Equivalent Privacy．
つまり，有線と同等の"ぷらいばしー"と言う意味．
利用可能な周波数のチャネル数がバカHUBの台数だけしかなくて，
それらのポートが空中に浮いていると思えば良い．
通信路の途中でframeを盗聴するなんて簡単なのがよーく分かるはず．
[BTW, WEP stands for Wired Equivalent Privacy.
Imagine, number of available frequency channel is equal to
number of repeater and everyone can use these repeater.
It's really easy to get other's frame by simply tapping.]

まとめると，リンク先で盛り上がっているMACアドレスによるfilteringって話は，
Frame Control fieldのoctet streamに対する単純なdecoderでしかない
address recognizerの部分をSMEを経由してソフトウェア側で実現しているだけ．
[That MAC address filtering is simple.
It is software implementation of SME of address recognizer
which decode octet stream of one of Frame Control filed stuffs.]

つまり，ハードウェアにヘチョいブツ混じっているのがまず問題なんじゃね？
と言う訳で，みなさんはハードウェアには投資して下さい． :P
[So, the problem is, many dumb hardware are?
Say, pay to get proper/sane hardware, plz. :P]

sanitize(0xBADC0D); hg.commit(tip);

社内のSH7751Rなボードの開発環境が起動しないアリエナイ状況に陥る．
[T3h old SH7751R dev box didn't boot, ZOMG...]

仕方無いので，ThinkPadにGentoo Linux ~x86を突っ込んだ後に，サクっと
sys-devel/crossdevでsh4-unknown-linux-gnuなクロスコンパイル環境を
仕立てて，"ぷろだくとれべる"で仕上がっている2.4.18ベースのkernelから
patchをテキトーに分離して，キレイキレイしてからdev-util/mercurialな
repositoryにcommitしまくる．
[So, I've installed Gentoo Linux ~x86 to ThinkPad and make it dev box of
sh4-unknown-linux-gnu by using sys-devel/crossdev.
Then, pull'n'split patches from t3h productive kernel src was beased on 2.4.18,
and commit them to dev-util/mercurial repository w/ my stupid code sanitizing.]

更に，以前の開発環境が2.9xベースと言う古代の遺物．
これまたテキトーにcompile fixなpatchもでっち上げた．
取り敢えずzImageが作れる所まで直ったらしい．
[But it won't build due to t3h src depends old toolchain behavior.
So, I've poke it and make zImage build.]

あとはボード上に置いてみてdebug'n'fixするだけ．
時間が余ればupstrteamなpatch repositoryもでっち上げたので
仕事をしているフリをしてbackport遊びをするかもしれない． :p
[The last one is to deploy stuffs on the board and debug'n'fix.
Once IT JUST WORKS(tm), it may be time to backport only for fun. :p]

で，新Greg-KH本が出たらしい． :)
[BTW, New Greg-KH's book is now available, I heard. :)]
New book explains how to build Linux 2.6 kernels (LinuxDevices.com)

Draw(SoftMAC & HardMAC);

IEEE 802.11/IEEE 802.11aのMAC/PHYの辺りのイメージ．
SoftMACのフローチャートまで手を付けられなかった．
納期がヤヴァい． :P
[Here's my stupid image of IEEE 802.11/IEEE 802.11a MAC/PHY.
Well, I'd have to stuff completely SoftMAC flow charts, though.
Umm, blah. :P]



修正：
Network SubsystemとかPCI DMAとかも．
Ring BufferとかARP Cache本体とかを書く場所が無いなー． :P
[FIX:
Forgot to add Network Subsystem and PCI DMA or so.
Oh well, there is no space to describe Ring Buffer
and ARP Cache itself. :P]



修正：
変な所に在ったIEEE 802.x LANをIEEE 802.3として分離．
IEEE 802.1 BridgingとIEEE 802.2 LLCを追加．
ねむー． :P
[FIX:
Separated IEEE 802.x LAN as IEEE 802.3 for example was wrong placed.
Added IEEE 802.1 Bridging and IEEE 802.2 LLC.
Well, SIGZZZ. :P]

goto t3h_Y; t3h_Y: doTT4(SoftMAC & HardMAC);

当初はハードウェアな人間だと思われていたらしいが，
何時の間にかソフトウェアな人間だと言われて，
更にそっち系のメンバーが不足していたとの事で
便利屋且つ厄介者として扱われる今日この頃． :P
先週は木曜日にYなトコロで主にハードウェアのレビュー，次の日にP4のミーティング四回目．
[My bosses thought I was hardware-oriented, though I'm now
deemed software-oriented.
To make matters worse, my office lacks software-oriented ones.
So, I act like the handy man, otherwise like nuisance. :P
Last week, the Thursday is a review of hardware specs @ t3h 'Y'.
Then, Friday is 4th meeting of P4.]

レビューにて，お客さんはRadio Frequencyな人らしく，
ハードウェアの方にはAGC/LNAな感じで突っ込みが厳しかった．
逆にソフトウェアの方はお任せな感じだった．
曰く，「聴いてもヨクワカラナイ」からとか． :P
[The reviewer is really Radio Frequency guy, he pointed at AGC/LNA thingy.
But he'd let leave up me about software thingy.
B/c, he said "Well, I'm unprofessional that thingy as you know." :P]

ミーティングにて，結局，自分がSoftMACのフローチャートを書く事になった．
以下，メモ．
[On the meeting, it made me have to design SoftMAC implementation.
The follows are P4 iff SoftMAC.]

 * P4 iif SoftMAC
   + active scanning
   + best-effort hand-off
   + misc MLME ioctl(2)
   + misc PLME ioctl(2)

で，高専の頃，誰かが言っていた事を思い出した． :P
「エラい人の言葉でも専門外の事だったら疑ってかかれ」
[So, I'd have to say a phrase that I heard I was a student of ONCT. :P
"You should doubt what someone said, even if he was your guru,
especially when he mentioned about unprofessional thigy."]

修正： typoとか．
[FIX: Typos or so.]

ISE[8][2][i].karma--;

今日はBPFを弄った．
要求としては16MHzキャリアに乗っている5MHz帯域の信号を
エイリアシング/イメージングから保護する事．
[I've Poked the BPFs.
Requested spec is to attenaute aliasing/imaging
for 5MHz band signal on 16MHz carrier.]

DCと32MHzにアレが出て来るって事を考慮しただけだと20次で良さ気なモノが出来た．
一応，実績のある過去の設計仕様では48次で作っているブツがあったので，
48次を限度に低周波減衰域/高周波減衰域を広く取ったブツも作った．
[Simply to attenaute DC and 32MHz ones required 20 deg.
Some referenced previous designs used 48 deg, so I've tried
to enlarge high/low attenaution band w/ 48 deg as well.]

で，XilinxのISE 8.2iでジェネってみた．
んー，使い方がヨクワカリマセンネー．
ツールの名前だけ見るとFIRをジェネる為のブツが二個有るみたい．
仕方無いので英語なマニュアル約40ページと約60ページを印刷．
明日はYなトコロに出張予定なので行き帰りにでも読むつもり．
[Then, I've tried to generate w/ ISE 8.2i.
Blah, that's really bloated and enough to confuse.
So why does it have 2 FIR code gen?
Well, I'll read about 40+60 page manual written in English,
though on the way to and from t3h 'Y'.]

で，そこそこsys-apps/qingyに人気が出てきたっぽいし，
dev-libs/DirectFBもPV==1.0_rc2なので，
中身はC++だけど，コンパイル時間がそんなに要らない
x11-misc/slim-1.2.6に乗り換えてみた．
その内，自分用のテーマを作る．
[My minor oriented karma force me not to use sys-apps/qingy,
due to dev-libs/DirectFB's PV==1.0_rc2.
The replacement is x11-misc/slim-1.2.6 is written in C++ though,
not takes so long time.
So, I'll make my own theme sooner or later.]
Bug 107526 x11-misc/{slim,slim-themes} - new ebuild

あ，Splashyってのもあるのかー． :P
[Oh well, Splashy is, too. :P]
Splashy

MATLAB.karma--;

SoftMACの部分が一段落しつつあるので，新しいトコに着手．
マルチキャリアの直交変復調近辺のデジタルフィルタの設計．
んー，一年振りのz変換は或る意味，新鮮だったりする． :P
[SoftMAC thingy is mostly DONE, then I'd poke next thingy.
The ones are design digital filter which is implemented
before/after quadrature modulation/demodulation.
Hmm, the "z transform" is much nicer, after an absence of
a year. :P]

ダウンサンプラ/アップサンプラの前段/後段にかますLPFを弄った．
このLPFは，エイリアシング/イメージングを抑制する為のモノで，
前段/後段のサンプラと合わせて，デシメータ/インタポレータと呼んでいる．
[Well, I've poked LPFs before/after down-sampler/up-sampler.
These LPFs attenuate these samplers' aliasing/imaging.
These combined ones are so-called decimator/interpolator.]

MATLABの低品質なUIと自分の巨大なappsを扱えない憶えの悪さが禍して，
フィルタ設計ツールの使い方を理解するまでに一日．
z変換と離散時間制御と離散時間信号処理の復習に半日，
デシメータ/インターポレータの原理とFPGA上での実現方法の勉強に半日．
[Due to MATLAB's suck UI and bloat, it takes 1 day
to realize how to use filter designing tools for me.
And then, restudy about z-transform, control theory and signal
processing of discrete time domain, that takes half of a day.
Studying about functionalities and implementation techs
of decimator/interpolator, that takes another half of a day.]

出来上がったインターポレータ/デシメータは，
インターポレータ
= (2xアップサンプラ + 50次等リプルLPF)
+ (8xアップサンプラ + 14次線形補間LPF)
デシメータ
= (8xダウンサンプラ + 54次等リプルLPF)
+ (2xダウンサンプラ + 6次等リプルLPF)
[Finally, I've designed like this,
Interpolator
= (2x up-sampler + equiripple LPF of 50 deg.)
+ (8x up-sampler + linear interpolation of 14 deg.)
Decimator
= (8x down-sampler + equiripple LPF of 54 deg.)
+ (2x down-sampler + equiripple LPF of 6 deg.)]

で，中ではParks-McClellanアルゴリズムと言うRemezアルゴリズムと
Chebyshev近似を併用したブツを使っているらしい．
IEEE 802.11のMAC部分はLinuxに実装があるけど，
PHY以下は殆んどデバイスの仕事だしRFにも依存するのでソフトウェアで実装するとか
アレな真似をしている人は居ないのかも．
HDL設計/コーディングでは期待値検証に使えそうな感じはするけれど，
控えめに見積もってもシミュレーション程度にしかならないからかな？ :P
[BTW, internal of that designing tools use Parks-McClellan
algorithm which is combined Remez algorithm and Chebychev
approximation, I heard.
Linux has a IEEE 802.11 MAC part implementation though,
these is no implementation one which is under PHY thingy.
Well, I know that "under PHY thingy" is hardware functionalities,
and it depends on RF part.
Their use is only for a expectation collation for HDL, or simply
for its simulation. :P]

明日は直交変復調の前段/後段のBPFを弄る予定．
[Hmm, tomorrow, I'll poke BPFs which is implemented before/after
quadrature modulation/demodulation.]

doTT3(HardMAC & SoftMAC); dosomethings2();

P4のミーティング三回目．
んー，なんか結局，開発に参加してもらう方，約二名に
IEEE 802.11な英文を読んでもらう事になってしまった．
ま，被害者^H^H^H仲間が増えるだけなので問題無し． :P
[P4 meeting 3rd.
Hmm, co-devs will read the IEEE 802.11 one.
Well, they look like victims^H^H^H^H^H^Hambitious. :P]

で，USE="xcb"は鬼門ですねー．
x11-terms/xterm + app-i18n/scimとかjavaのpluginがぶっ壊れるっぽい．
一応言及しておくとXCBが悪い訳ではなくて，twice lock/unlockとかしている
appsの方が阿呆過ぎなだけです．
Momongaでは一時的な対策（？）として，twice lock/unlockをassert(3)で
検出している部分をコメントアウトすると言うパッチまで用意してるし，それはマズくね？ :P
CFLAGS+="-g" + USE="debug"なx11-libs/*をでっち上げて，
upstreamのpatchを幾つか拾ってきたので，暇な時に直す予定，多分． :P
[BTW, USE="xcb" really l^Hrocks.
x11-terms/xterm + app-i18n/scim and java plugins are bombed.
FYI, that isn't XCB's fault b/c some apps try twice lock/unlock itself,
these crappy code shoudl be shot.
OTOH, Momonga ab^H^Huses a patch which deletes assert(3) for invalid
twice lock/unlock. :P
So, I prepared x11-libs/* w/ CFLAGS+="-g" + USE="debug" to fix it.
I'll poke something sooner or later, maybe. :P]

で，net-misc/dhcpcd-3.0.0も鬼門ですねー．
uberlordさんがcomplete rewriteしたのでKEYWORDSが一度外されて，
ちょこちょこ追加されているのだけれど，htonl(3)をサボっている箇所で
little endianなホストが刺さったっぽい．
一応，パッチは公開されているが，今はbugzieが死んでる，新しいのになるっぽい．
[Then, net-misc/dhcpcd-3.0.0, IT JUST WORKS(tm).
uberlord did complete re-write, and droped KEYWORDS.
But, there are some limbos of endian consideration,
so no htonl(3) is IT DOESN'T WORK(tm) on little endian host.
There is byte-order fix patch, but bugzie is now dead, for resurrection.]

で，遂に需要の少なそうなブツを公開． :9
dev-util/mercurialでclone出来ます．
[Yay, a little demanded one is finally out. :9
You can clone it w/ dev-util/mercurial.]
$ hg http://dev.gentoo.gr.jp/~hiyuh/cgi-bin/hgweb.cgi portage
hiyuh's misc Portage Overaly

追記：
bugzie復活したっぽい．
net-misc/dhcpcd-3.0.1が突っ込まれたっぽい．
んー，ねるー． :P
[ADD:
Bugzie is resurrected.
net-misc/dhcpcd-3.0.1 is added.
Well, SIGZZZ. :P]