RAM/LUT over mappingをIFFT/FFT部のRAMをシフトレジスタ化して解決，
PCIバスロックの原因になっていた内部バス変換アダプタの非同期トリガを修正，
トップレベルの対向STAのテストベンチの中身にピンアサインを反映，
PLLからのクロック入力のピンアサインを忘れていたっぽいので追加，
D/A変換部が二の補数表現ではなくオフセットバイナリだったので修正，
RF部の抜けていた仕様からの要求でIF出力のオフセットをパラメータに追加．
[Fix RAM/LUT over mapping by using shifter in IFFT/FFT instead of RAM.
Fix PCI bus lock by purging async triggers of internal bus adapter.
Back port real pin assigned entity to top test bench of STA to/from STA.
Fix a pin assign constrain of clock input from PLL.
Fix D/A semantics part, it can only recognize offset binary representation,
not 2's complement's.
Add IF output offset paramter entity and functionalities for a missing RF spec.]
帰宅してから，最後の変更で必要になったパラメータを上位階層から与える
機能を追加し忘れた事に気付いて萎える． :(((
[Returned my home, the last commit is mandatory to add the semantics in upper
layer to specify the parameter, I realized it just now, ZOMG... :(((]
2007/02/24
2007/02/20
Crash(&Xilinx.ISE[8][2][i]);
VHDLのファイルを追加するとたまーに死ぬISE． :(((
なので，そーっと，そーっと．．．:DDD
[When it was added a VHDL file, it did *sometimes* crash.
ZOMG, retarded ISE. :(((
'Kay, I'll do more softly... it should be a overdelicate crap. :DDD]
なので，そーっと，そーっと．．．:DDD
[When it was added a VHDL file, it did *sometimes* crash.
ZOMG, retarded ISE. :(((
'Kay, I'll do more softly... it should be a overdelicate crap. :DDD]
2007/02/18
Xilinx.ISE[8][2][i].karma--; /* XC3S500 */
楽しい楽しい休日出勤． :p
[Hmm, it's a delightful holiday work. :p]
鬼コードした約500モジュールのVHDLをISEでムニャる．
Optimize GoalをSpeedにしてムニョるとBlock RAMが足りない．
Optimize GoalをAreaにしてヘニャるとLUTが足りない．
と言うか，top levelでしかOptimimze *やら* Styleって指定出来ない構造？
つーか，Over mappingしているの分かっているのに次のstageに進むのって
build systemが低品質過ぎね？ :p
これだからbloatなIDEはだめだめなんじゃよ．
[I've poking about 500 momdules of VHDL w/ suck0rz Xilinx ISE.
When specified Optimize Goal to Speed or so, it sez exceeded Block RAM resource.
When specified Optimize Goal to Area or so, it sez exceeded LUT resource.
Well, it can not handle Optimize * or * Style feature at non-top level?
Blah, although it was already over mapped, t3h blob forces to go to next stage,
ZOMG... :p
That's why I hate bloated IDE.]
教訓：IDEは高校生まで．
[L: To use a IDE can be applicable, if U R a HS kid.]
[Hmm, it's a delightful holiday work. :p]
鬼コードした約500モジュールのVHDLをISEでムニャる．
Optimize GoalをSpeedにしてムニョるとBlock RAMが足りない．
Optimize GoalをAreaにしてヘニャるとLUTが足りない．
と言うか，top levelでしかOptimimze *やら* Styleって指定出来ない構造？
つーか，Over mappingしているの分かっているのに次のstageに進むのって
build systemが低品質過ぎね？ :p
これだからbloatなIDEはだめだめなんじゃよ．
[I've poking about 500 momdules of VHDL w/ suck0rz Xilinx ISE.
When specified Optimize Goal to Speed or so, it sez exceeded Block RAM resource.
When specified Optimize Goal to Area or so, it sez exceeded LUT resource.
Well, it can not handle Optimize * or * Style feature at non-top level?
Blah, although it was already over mapped, t3h blob forces to go to next stage,
ZOMG... :p
That's why I hate bloated IDE.]
教訓：IDEは高校生まで．
[L: To use a IDE can be applicable, if U R a HS kid.]
2007/02/16
suspend(&SimHDL);
シミュレーションを一時保留し，先行インプリを開始．
何気に一次納入カチカチな気配． :p
[Suspend HDL simulations, launching pre-implementation test.
Hmm, makin' 1st delivery kinda subtle, though. :p]
で，
Gmailのアクセス禁止を回避するユーザを検知する5つの方法
参照先のpop * crap^H^H^Hopはどーでもいーとして，
trombikせんせーにおこられないよーにしなければ！ :(((
[BTW,
Detecting malicious GMail users
We'd have to reconsider ourselves. :(((]
何気に一次納入カチカチな気配． :p
[Suspend HDL simulations, launching pre-implementation test.
Hmm, makin' 1st delivery kinda subtle, though. :p]
で，
Gmailのアクセス禁止を回避するユーザを検知する5つの方法
参照先のpop * crap^H^H^Hopはどーでもいーとして，
trombikせんせーにおこられないよーにしなければ！ :(((
[BTW,
Detecting malicious GMail users
We'd have to reconsider ourselves. :(((]
2007/02/15
setTrap(&Chocolate);
全男性社員のデスクにチョコが光臨．
同じ階の上司さん（女）曰く，
「期待してるよー」
[Manifestation of chocolate on my desk,
then my bosses (female) sez,
"we're looking forward to your quid pro quo."]
罠か！？ :(((
[WTF on the earth did they trap us!? :(((]
同じ階の上司さん（女）曰く，
「期待してるよー」
[Manifestation of chocolate on my desk,
then my bosses (female) sez,
"we're looking forward to your quid pro quo."]
罠か！？ :(((
[WTF on the earth did they trap us!? :(((]
2007/02/11
doEMail(&nwccDev, Engrish);
Eng'r'ishでめーるの返事を書くのにけっこー時間がかかってる．
まだまだぜよ．
[Replying e-mail w/ my bad Eng'r'ish takes me a bit
of long time, Hmm...]
と言うかpatchを書いた方が早かったんじゃないかと今更気づいたり． :P
[Oh, wait...
To code a patch is better way to go ? :p]
まだまだぜよ．
[Replying e-mail w/ my bad Eng'r'ish takes me a bit
of long time, Hmm...]
と言うかpatchを書いた方が早かったんじゃないかと今更気づいたり． :P
[Oh, wait...
To code a patch is better way to go ? :p]
2007/02/10
doEbuild(&nwcc[0][7][1]);
sys-devel/nwcc-0.7.1を突っ込んだ．
昨日のmedia-gfx/exact-imageと同じく
configure/build/install scriptがアレ気． :p
jabberwocky上で"Hello, world!"を作ると
nwccの方がgccの二倍程デカいバイナリが出来る．
が，コンパイラそのもののbuildはちょー早い． :DDD
コンパイラは60kSLOC弱，プリプロセッサは10kSLOC強．
[Add sys-devel/nwcc-0.7.1.
Its configure/build/install script is bit of funny. :p
T3h "Hello, world!" of nwcc is bigger than gcc's about x2 or so.
But, required time to build nwcc is faster than gcc's, of cource.
Well, about 1/10 or so? :DDD
The compiler is 60kSLOC, preprocessor is 10kSLOC.]
Nils Weller's C compiler
昨日のmedia-gfx/exact-imageと同じく
configure/build/install scriptがアレ気． :p
jabberwocky上で"Hello, world!"を作ると
nwccの方がgccの二倍程デカいバイナリが出来る．
が，コンパイラそのもののbuildはちょー早い． :DDD
コンパイラは60kSLOC弱，プリプロセッサは10kSLOC強．
[Add sys-devel/nwcc-0.7.1.
Its configure/build/install script is bit of funny. :p
T3h "Hello, world!" of nwcc is bigger than gcc's about x2 or so.
But, required time to build nwcc is faster than gcc's, of cource.
Well, about 1/10 or so? :DDD
The compiler is 60kSLOC, preprocessor is 10kSLOC.]
Nils Weller's C compiler
2007/02/09
doEbuild(&ExactImage[0][3][4]);
media-gfx/exact-image-0.3.4を突っ込んだ．
configure/build/install scriptがアレ気． :p
[Added media-gfx/exact-image-0.3.4.
Its configure/build/install script is a bit of funny. :p]
ExactImage
configure/build/install scriptがアレ気． :p
[Added media-gfx/exact-image-0.3.4.
Its configure/build/install script is a bit of funny. :p]
ExactImage
2007/02/07
delta_delay.mess(&me);
今日は何故か，昨日動いたと思ったPCIMSがHardMACの上に
突っ込んだヤツだけ動かなくてハマった．
原因はtest bench内でのclockの接続が或る条件を満たす時のみ
再現するシミュレーション上でしか発生しないPCIMS内部に
存在するbug． :(((
[Today, t3h dumb PCIMS is dead again where top of
HardMAC, though top of memory did work.
b/c t3h PCIMS has silly rarely reproducible bug
only when it's in simulation phase, ZOMG! :(((]
で，教訓．
例えtest benchでもclockをsignalとして使うと何気に死ねる． :P
[L: So don't use clock as signal even if in test bench,
otherwise you will be *stabbed*. :p]
で，午前二時半ですがoverlay掃除中． :p
[Here is about 2:30 AM, /me pokes /me 's overlay. :p]
追記：
GGI 2.2.2を突っ込んだ．
[ADD:
Stuff GGI 2.2.2 ebuilds to overlay.]
[SIGZZZ :p]
突っ込んだヤツだけ動かなくてハマった．
原因はtest bench内でのclockの接続が或る条件を満たす時のみ
再現するシミュレーション上でしか発生しないPCIMS内部に
存在するbug． :(((
[Today, t3h dumb PCIMS is dead again where top of
HardMAC, though top of memory did work.
b/c t3h PCIMS has silly rarely reproducible bug
only when it's in simulation phase, ZOMG! :(((]
で，教訓．
例えtest benchでもclockをsignalとして使うと何気に死ねる． :P
[L: So don't use clock as signal even if in test bench,
otherwise you will be *stabbed*. :p]
で，午前二時半ですがoverlay掃除中． :p
[Here is about 2:30 AM, /me pokes /me 's overlay. :p]
追記：
GGI 2.2.2を突っ込んだ．
[ADD:
Stuff GGI 2.2.2 ebuilds to overlay.]
2007/02/07 04:36:04 MooZねむー． :p
hy
2007/02/07 04:37:04 hiyuh
yo :)
2007/02/07 04:37:34 MooZ
hey hiyuh ! what's up?
2007/02/07 04:38:06 hiyuh
poking 2.2.2 release on 64 bit userland :)
2007/02/07 04:38:14 MooZ
:)
2007/02/07 04:39:12 hiyuh
so some stuffs warn me like "no 64 bit safe", though. it needs
to fix?
2007/02/07 04:39:24 MooZ
yep!
2007/02/07 04:39:39 MooZ
there're pointer to 32 bits int casts?
2007/02/07 04:41:12 hiyuh
maybe, these are marked w/ ton of #warning. :p
2007/02/07 04:41:54 MooZ
:)
2007/02/07 04:42:05 CIA-21
cegger * ggi-core/libggi/programs/demos/cube3d.c: add newline in
usage output.
2007/02/07 04:44:23 hiyuh
hmm, this? http://devmanual.gentoo.org/archs/amd64/index.html
2007/02/07 04:45:39 MooZ
arg
2007/02/07 04:45:55 MooZ
sigsev : not enough brain left
2007/02/07 04:45:56 MooZ
:)
2007/02/07 04:46:41 hiyuh
muhehe
2007/02/07 06:02:52 hiyuh
:) http://dev.gentoo.gr.jp/~hiyuh/cgi-bin/hgweb.cgi
2007/02/07 06:04:27 MooZ
hehe nice :p
2007/02/07 06:04:37 hiyuh
and the previous misc dir has now GGI 2.2.2 build logs on 64 bit
userland w/ 2.6.20 headers.
2007/02/07 06:07:07 hiyuh
umm, 6:00 AM...
2007/02/07 06:08:06 MooZ
it's 6:00 am in Japan?
2007/02/07 06:09:06 hiyuh
yup
2007/02/07 06:09:45 MooZ
you are insomniac?
2007/02/07 06:09:51 hiyuh
lol
[SIGZZZ :p]
2007/02/06
PCI_MODEL_REQ.oxGNT.karma--;
PCI LBがやっと動いた． :p
[Pwnt, PCI LB WORKS FOR ME(tm). :p]
犯人はCPUとbus arbiterのモデルとして使っていたPCI_MODEL_REQ.vhd.
こいつのGNT#が他のbus masterからREQ#が入らないと不定だったと言うオチ．
PCI LBにぶら下がっているメモリモデルがbus master disableだったので，
PCI masterの内部マクロがイイ感じに暴走していた． :(((
サクっと*stab*して終了．
[It did not work b/c suck0rz PCI_MODEL_REQ.vhd as CPU + bus arbiter.
pre-fixed one can not determine its GNT# if REQ# from other bus mster
havenot been inputed, ZOMG...
The memory model at PCI LB is disabled PCI master functionalities.
Then, the master sub-macro did overide. :(((
The fix is simply *stab* '1' to its GNT# as initial value, PERIOD. ]
MOS-FETで言う所のゲートが浮いていたってトコか？ :p
[cf. the case of MOS-FET w/ floating gate. :p]
[Pwnt, PCI LB WORKS FOR ME(tm). :p]
犯人はCPUとbus arbiterのモデルとして使っていたPCI_MODEL_REQ.vhd.
こいつのGNT#が他のbus masterからREQ#が入らないと不定だったと言うオチ．
PCI LBにぶら下がっているメモリモデルがbus master disableだったので，
PCI masterの内部マクロがイイ感じに暴走していた． :(((
サクっと*stab*して終了．
[It did not work b/c suck0rz PCI_MODEL_REQ.vhd as CPU + bus arbiter.
pre-fixed one can not determine its GNT# if REQ# from other bus mster
havenot been inputed, ZOMG...
The memory model at PCI LB is disabled PCI master functionalities.
Then, the master sub-macro did overide. :(((
The fix is simply *stab* '1' to its GNT# as initial value, PERIOD. ]
MOS-FETで言う所のゲートが浮いていたってトコか？ :p
[cf. the case of MOS-FET w/ floating gate. :p]
2007/02/02
ModelSim[XE][III][6][1][e].karma--;
ModelSim XE III 6.1e，イイ感じに低品質，
Spartan-3 x 4個程度のシミュレーション程度で遅くなるとか，
シミュレーション中，たまにbacktraceを吐いて刺さるとか． :(((
[ModelSim XE III 6.1e really suck0rz.
It's getting slow when a simulation w/ Spartan-3 x 4,
then finally, it vomits rock0rz backtrace, ZOMG... :(((]
で，最近，標準仕様の後方互換性が非常に邪魔に感じる．
マイナーでも構わないのでまともなBUS仕様は無いもんかな？．
取り敢えず，Power ISAを読んで現実逃避． :p
[All backward compat is really eyesore for me, think that should be shot.
Plz let me know, if you know sane bus specification.
Minor ones are really welcome.
Now, I'm poking Power ISA, though. :p]
Spartan-3 x 4個程度のシミュレーション程度で遅くなるとか，
シミュレーション中，たまにbacktraceを吐いて刺さるとか． :(((
[ModelSim XE III 6.1e really suck0rz.
It's getting slow when a simulation w/ Spartan-3 x 4,
then finally, it vomits rock0rz backtrace, ZOMG... :(((]
で，最近，標準仕様の後方互換性が非常に邪魔に感じる．
マイナーでも構わないのでまともなBUS仕様は無いもんかな？．
取り敢えず，Power ISAを読んで現実逃避． :p
[All backward compat is really eyesore for me, think that should be shot.
Plz let me know, if you know sane bus specification.
Minor ones are really welcome.
Now, I'm poking Power ISA, though. :p]
2007/02/01
PCI_LB[3][0].karma--;
やっとHardMACから脱出して，一時的にPCI local busな感じ．
例によってちゃんと分かっている訳ではないので，PCI SIGの原文をムニャる．
二日間ムニャったが，PCI LB 3.0はダメダメ． :p
そしてPCI LB 2.xの時に作ったと言うPCI Master/SlaveのVHDLとかも
かなりアレ気で萎える． :(((
[Now, it's time to PCI local bus instead of t3h HardMAC.
I've poked PCI LB 3.0 specification from PCI SIG, though.
Well, my feeling is just "BLAH". :p
Hmm, t3h VHDL stuff was coded w/ PCI LB 2.x is "BLAH"-er. :(((]
ま，取り敢えず，納期も有るので機能的に問題の無い部分は保留して，
仕様書と整合性の取れていないブツに関して言及した上司へのメールに
以下のメッセージを追加．
[Meanwhile, the suck0rz thingy are now pending.
But, I had to try e-mail about inconsistencies of code and doc
w/ those message to my bosses.]
# WE NEED MORE AND SANE CONSISTENCIES.
# OTHERWISE, JUST ABANDON THESE CRAPS.
返事には「お前の言いたい事はよーくわかった」と書いてあった． :DDD
[The reply was "I know, but STFU n00b..." :DDD]
例によってちゃんと分かっている訳ではないので，PCI SIGの原文をムニャる．
二日間ムニャったが，PCI LB 3.0はダメダメ． :p
そしてPCI LB 2.xの時に作ったと言うPCI Master/SlaveのVHDLとかも
かなりアレ気で萎える． :(((
[Now, it's time to PCI local bus instead of t3h HardMAC.
I've poked PCI LB 3.0 specification from PCI SIG, though.
Well, my feeling is just "BLAH". :p
Hmm, t3h VHDL stuff was coded w/ PCI LB 2.x is "BLAH"-er. :(((]
ま，取り敢えず，納期も有るので機能的に問題の無い部分は保留して，
仕様書と整合性の取れていないブツに関して言及した上司へのメールに
以下のメッセージを追加．
[Meanwhile, the suck0rz thingy are now pending.
But, I had to try e-mail about inconsistencies of code and doc
w/ those message to my bosses.]
# WE NEED MORE AND SANE CONSISTENCIES.
# OTHERWISE, JUST ABANDON THESE CRAPS.
返事には「お前の言いたい事はよーくわかった」と書いてあった． :DDD
[The reply was "I know, but STFU n00b..." :DDD]
2007/01/30
GentooJP.NomiKai++; /* First of 2007 */
飲み会でした． :)
trombik先生に教育的指導をして頂きました．
ほんとうにありがとうございます． :p
[NomiKai is over. :)
trombik's inquisition is really interesting for me, though.
Thanks a lot. :p]
何か飲んでいるうちに"びすた"が出てたっぽい．
[Hmm, when we were talking about spam'n'ham, vista seems to be out?]
!google vista 1/29
やっとglibc-2.4 fixでリリースされました． :)
[Finally, official glibc-2.4 fix is out, as well. :)]
[ggi-develop] [ANNOUNCEMENT] GGI 2.2.2 available
trombik先生に教育的指導をして頂きました．
ほんとうにありがとうございます． :p
[NomiKai is over. :)
trombik's inquisition is really interesting for me, though.
Thanks a lot. :p]
何か飲んでいるうちに"びすた"が出てたっぽい．
[Hmm, when we were talking about spam'n'ham, vista seems to be out?]
!google vista 1/29
やっとglibc-2.4 fixでリリースされました． :)
[Finally, official glibc-2.4 fix is out, as well. :)]
[ggi-develop] [ANNOUNCEMENT] GGI 2.2.2 available
2007/01/27
doInst(&iMac20, &Gentoo, ~amd64);
そうそう，年が変わってから20" iMacを買った．
特に理由は無いが，jabberwockeyと命名．
勿論，既にGentoo Linux ~amd64を突っ込んである． :DDD
emergeのlogがすげー早さで1680x1050の画面で流れていくなー． :p
[Oh, yeah, I've got 20" iMac for the new year dev env.
Well, the host name is jabberwockey.
Of cource, it was already installed Gentoo ~amd64. :DDD
LOL, the emerge log scrolls w/ amaging speed in 1680x1050 world! :p]
で，今日は恒例の月末飲み会@某C社．
寿司ごち！ :9
[BTW, today was NomiKai@certain-C for end of this month.
SIGSUSHI, yum-yum! :9]
今週日曜日にはGentooJP新年会がある．
今度は寝過ごさない様にしよう． :D
[Sunday of this week is NomiKai of New Year for GentooJP.
Hmm, I won't oversleep again. :D]
特に理由は無いが，jabberwockeyと命名．
勿論，既にGentoo Linux ~amd64を突っ込んである． :DDD
emergeのlogがすげー早さで1680x1050の画面で流れていくなー． :p
[Oh, yeah, I've got 20" iMac for the new year dev env.
Well, the host name is jabberwockey.
Of cource, it was already installed Gentoo ~amd64. :DDD
LOL, the emerge log scrolls w/ amaging speed in 1680x1050 world! :p]
で，今日は恒例の月末飲み会@某C社．
寿司ごち！ :9
[BTW, today was NomiKai@certain-C for end of this month.
SIGSUSHI, yum-yum! :9]
今週日曜日にはGentooJP新年会がある．
今度は寝過ごさない様にしよう． :D
[Sunday of this week is NomiKai of New Year for GentooJP.
Hmm, I won't oversleep again. :D]
2007/01/25
vec_doc = sub_vec(vec_const, vec_code);
イツノマニカ，アケマシテオメデトウゴザイマス． :DDD
[Well, @ Inappy n3vv y3ar. :DDD]
一通りドライバの仕様書が書き終わったので，
久しぶりにVHDLを鬼codingしていたら，
こっちが大分疎かになって仕舞った． :P
[That spec of SoftMAC is almost marked down,
so I've stuffed ton of VHDL code.
Then, I forgot to post my craps here. :P]
教訓：documentationとcodingはトレードオフな関係にあるっぽい．
[L: documentation and coding are traded-off, at least for me ATM.]
[Well, @ Inappy n3vv y3ar. :DDD]
一通りドライバの仕様書が書き終わったので，
久しぶりにVHDLを鬼codingしていたら，
こっちが大分疎かになって仕舞った． :P
[That spec of SoftMAC is almost marked down,
so I've stuffed ton of VHDL code.
Then, I forgot to post my craps here. :P]
教訓：documentationとcodingはトレードオフな関係にあるっぽい．
[L: documentation and coding are traded-off, at least for me ATM.]
2006/12/27
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]
[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]
2006/12/20
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)
[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)
2006/12/12
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]
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]
2006/12/11
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.]
「エラい人の言葉でも専門外の事だったら疑ってかかれ」
[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.]
何時の間にかソフトウェアな人間だと言われて，
更にそっち系のメンバーが不足していたとの事で
便利屋且つ厄介者として扱われる今日この頃． :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で，高専の頃，誰かが言っていた事を思い出した． :P
+ active scanning
+ best-effort hand-off
+ misc MLME ioctl(2)
+ misc PLME ioctl(2)
「エラい人の言葉でも専門外の事だったら疑ってかかれ」
[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.]
2006/12/06
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
要求としては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
登録:
投稿 (Atom)
![[FSF Associate Member]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_s_AaaJ8sJVUMVbNlwnpyYojd7BcbVqUesoB5DoHumCe4AXK0vaB1BbgKUia9Ml33WulM97e4jbgwwWgrJcues-08HX3W6vNlJjgwUO0xmSJV0wto86ag=s0-d)