しかし、Initiatorを何とかしないと行けませんねぇ。Userlandで動くInitiatorって許かにあるんでしょうかね。ほとんどの実装はkernel moduleだったりDevice Driverだったりするので、NetBSD-Xenでは使えない…

istgtは認証を使うのを優先で、なくてもOKなポリシーなので、
認証を使ってもいいと言われると優先して使っちゃいます。
（イニシエータ側が利用するものを提示します）
認証を切るという考えは想定していなかった為に設定変更できません(汗)

そしてNetBSDのシーケンス番号がistgtの期待しているものと違うらしく、
無修正では、そんな番号は使えません的にリジェクトしちゃいます。

pkgsrcに登録されたからには修正されるのは時間の問題かと思いますけど。
こちらでも時間があるときに調べてみます。

※追記：NetBSDのイニシエータはオーバーフローもアンダーフローも対応できていないようです。

内容は理解出来ました。
今まで、iscsifsで認証しか使ったことがないんですが、認証を使わずに接続する時のコマンドライン引数をご存知でしたら教えてください。

# もしかして、authsを削除するだけとかだったら情けないなぁ :-(

1番は不明ですが、2番についてはお察しの通りで認証ができません。
理由はNetBSDの実装(イニシエータ)が長いパラメータ(CHAP認証の乱数)
を受取らないので認証ありでは接続が無理なのです。
istgtに限らず、認証データなどに長いものを要求するイニシエータと
NetBSDのターゲット間でも同様に接続できません。
NetBSDのターゲットとイニシエータしか使わないなら表面化しないから
きっと他の用途に使っている人が少ないのでしょうね。

ついでに質問です。

前提
　istgtはMacOS-X (Leopard|snowLeopard) (Intel/PPC) とNetBSD 5.0(amd64)で動かしている
　initiatorには、Global SAN iSCSI (MacOS-X snow Leopard(Intel))と、NetBSDのiscsifs(NetBSD/amd64) で動かした。症状は共通

1) どうもGlobal SAN iSCSIで認証がうまくいきません。うまくいっている人居ますか？
自分の設定を疑っていますが、どう直したものやら…
2) NetBSDのiscsifsでうまく接続出来ません。うまくいっている人居ますか？
これは本当に謎です。
ちなみに、-u を指定しないと、ユーザー名を指定しろと怒られます。
根は同じで、認証がうまくいっていないんじゃないかと思いますが。

>>>>> NetBSD 側 <<<< 256.
pid 1324:initiator.c:1980: ***ERROR*** param_text_parse_offer() failed
pid 1324:initiator.c:1813: ***ERROR*** initiator_cmd_t failed
pid 1324:initiator.c:642: ***ERROR*** login_phase_i() failed
pid 1324:initiator.c:1160: ***ERROR*** enqueue_worker: discovery_phase() failed (ignoring command)

>>>>> istgt側(istgt -D) /Console <<<<>>>> syslogには何も出てませんでした <<<<<

Bye the way, both 5008 and 5024 will have folder permission prooblem, when AD
ever been ebabled! i.e. Although disable AD, folder permission problem will still exist.

Thanks in advance!

今晩、MacOS-X Leopard Server(PowerPC)で動作確認する予定です。

Thank you for reporting.
Please give me more detail. When samba hang? read/write?
Did it appear on the previous version(5008)?
If possible, please send full log by e-mail to aoyama at peach.ne.jp.

My Hardware:
MB:Intel S5520HC
CPU:Intel Xeon X5550 2.66GHz * 2
MEM:Kingston DDR3-1333 ECC Register 24G
HD:WD Caviar Black7200rpm 2TB with 64MB Cache * 16 for ZFS
INTEL X25-M 80GB SATA SSD * 2 For System
RAID Card:Areca Raid Card with 4GB ECC Cache RAM and battery backup module (BBM)
NIC:On-Board INTEL Dual-Gigabit with 82575EB Controller
Power:800W Redundant Power
My Raid Comfiguration:
8 * Raid-0 logic disk as zpool disk (with double-parity raid-5 zpool)
SSD with Raid-1 as System

ABORT_TASKが発生するのは20091222版の時点での既知の問題になります。
いまのところZFS上のターゲットでのみ、この現象がみられます。

以下メールでの提供ログの調査によりコメントに追加：
処理が正しく動いていれば、イニシエータ側のコマンド再試行により
すぐに復帰できるのですが、再試行でさらなるエラーが発生した場合に
セッションリカバリー自体が復帰不能な状態（エラーと再試行を交互に
繰り返す無限循環）に陥る可能性があるようです。

なお、この問題が発生するのはQueueDepthを指定してコマンドキューイングを
有効にした場合のみとなります。万が一この現象に陥った場合は
iSCSIターゲットサービスの再起動によりエラー状態を破棄すれば
復帰できるようになる可能性が高いです。

現在この問題に対応するためのパッチを作成中です。

自分の環境ではESXi4.0で試すとやっぱり負荷が上がるとエラーがでちゃいます
今回のバージョンでは「かなり」負荷をかけると下のようなエラーが出ます
QueueDepthを32以上(64とか128とか)にしても、症状が変わりません
エラーがちょっと長いので、本当はメールでご連絡したいのですが短縮して数行だけ書くと

「ログ」-「デーモン」の項
Jan 16 04:05:37 freenas istgt[2934]: ABORT_TASK
Jan 16 04:05:57 freenas istgt[2934]: ABORT_TASK
Jan 16 04:05:57 freenas istgt[2934]: CmdSN(411020), OP=0×2a, ElapsedTime=2 cleared

という感じです

試験環境は、ESXi側Express5800/110GeでCPUがQ9650(3.0GHz)のメモリ8GB
FreeNAS側もExpress5800/110Geでメモリ2GB(カーネルに1.5GB割当設定済)
SATAのHDD4発をZFSのraidz2で使用

できれば、メールでご返信いただければ詳細な環境とエラーをご連絡したいと思っています
このエラーメッセージがistgtのより一層の安定化が図られるために
役立つのならと思っています
よろしくです

というわけで、今少し追いかけていますが、PPCだとうまく動いていないと言う症状です。Endianもんだいでしょうか？