時間がたつとサーバーがダウン

選択で並び順が替わります

いくつかスレッドが立っていますが、あまりメジャーな不具合では無いのでしょうか?
今回のファームアップでも解決しないので報告。

症状:本体起動(再起動)後、数時間経つと急にアクセス(※)できなくなる。
  ※WEB、メディア、SMB、AFPなど全部
   電源は入っており、pingは飛ばすと帰ってくる。
   固定IPにしても変わらず。
   DISKを様々な形式でフォーマット、マウントしても同様。
   再起動(電源ON-OFF)すると回復する。
   
はぁ・・・捨てようかな。

投稿者:たく  投稿日時:2014/05/29 21:13 親投稿 - 子投稿なし No.2

HDDをフォーマットしただけじゃ、原因の切分けにはならないと思います。
情報少ないので、こんなことしかアドバイスできません。
(今回のFWで修正されましたが、以前のFWだとHDDによっては電源管理の制御にバグがあり、このような症状がでます。)

本体背面のResetボタンで、設定クリアしてみる(下記Q&A参照)
設定消えるので、再設定してください。
http://www.iodata.jp/support/qanda/answer/s18163.htm

変わらず不安定な場合は、プリファレンスから一旦ほとんどの機能をOFFします。
・システム情報:Portal Server ⇒OFF 、ファームウェア ⇒ 自動更新OFF
・サービス: すべてOFF
・アプリケーション: すべてOFF
・システム: 電源管理 ⇒ 0分

同一ネットワークからのWEBからしか接続できませんが
これでも不具合が出る場合は、本体故障かHDD故障の可能性が考えられますね。
1年以内なら保証期間中だから修理してもらえるのでは?

問題ない場合は1個ずつ機能をONにして、何が不具合の元か切分け出来ると思います。
(ダウンローダーか電源管理かとは思ってはいるのですが)

ちなみにHDDの型番は判りますか?(新品ですか?)

投稿者:たく  投稿日時:2014/05/29 21:15 親投稿 - 子投稿.1 No.3

追伸

設定後は、念のため本体の再起動をしてください。

投稿者:cavitation  投稿日時:2014/06/06 18:22 親投稿 - 子投稿なし No.4

返信ありがとうございます。

あえて書かなかったのですが、できる事はすべてやってました。
なんでユーザがここまでしなきゃならんのだ!とね。普通に使える製品だしとくれ。
本体リセットなんぞ何回やった事か('◇')ゞ

各機能のON-OFFはもちろん、新FWが出た時は「あー、やっと使えるぞい」と思いきやさっぱり症状は変わらず。

ほいでもって最後にHDのフォーマットを散々試したわけです。
もちろん新FW上でも上記の繰り返し。工数返せ。

んで、すいません。修理に出しました。内容についてはわからないのですが本日「修理が終わりましたので発送しました」とさ。
再現したんだね。
ちなみに修理は2回目。1回目はFWのUp後まったくつながらなくなった件にて。

これでまたダメだったらこの機種だけでなくアイオーは使わん。
あ、役に立ちそうなら帰ってきたら型番書きますが。

投稿者:たく  投稿日時:2014/06/06 22:19 親投稿 - 子投稿.1 No.5

なるほど… 全てやられてたのですね…
無事治ってるといいですね。

おそらく、基板ごと交換だと思いますよ~
NANDが壊れかけてて動作不良してたんではないかと思います。
起動時にチェックされてるので、私は時々ですが 再起動後にシステムログ保存して
「Scanning device for bad blocks」で検索して、
「Bad eraseblock ~」が多発してないか確認してます。

> なんでユーザがここまでしなきゃならんのだ!とね。普通に使える製品だしとくれ。
この辺チェック出来るツールをIOが提供してくれれば、楽なんですがね~
気がねなく使える日は来るのだろうか。。。

> あ、役に立ちそうなら帰ってきたら型番書きますが。
時間ありましたら、是非 参考までに教えてください。

投稿者:ゲスト  投稿日時:2014/06/15 17:16 親投稿 - 子投稿なし No.6

スミマセン、お返事遅れました。
アイオーの素晴らしい対応をお知らせします。

帰ってきた修理品がなんと!まったく直っておりませんでした。
同症状のまま。
しかも修理報告書が入ってないので何をどう修理したのかもわからず。
そもそも修理したのかも不明。
そのままUターンで再修理に出しました。
これで送付費用だけで2500円オーバー。なんのこっちゃ。

今度ダメだったらサポートではなく社長に送ります。

ちなみに型番はCL2-005LD/2A、S/N最初の5桁はCL20Z1です。

投稿者:たく  投稿日時:2014/06/17 20:12 親投稿 - 子投稿.1 No.7

このBBS内でも、修理出したけど治ってない! というのを何件か見かけましたが、
まだサポートの体制はあまり良くないみたいですね。
症状の再現テストしたのかな?

しかし律儀に元払いで送ったのですね…
私だったら、着払いで送って前回の経緯含め報告書を請求しますね。

納得のいく対応がされなかった場合は 法人でないならば、
消費生活センターに相談するのが、社長宛に送るより まだ効果的ですね。
この手のメーカはそんな事なれてて 社長も、もう麻痺して気にもしてないでしょうから。
公平な立場から見て意見、是正してもらうのが良いでしょう。

次こそ治ってるといいですね。

投稿者:cavitation  投稿日時:2014/06/20 18:24 親投稿 - 子投稿なし No.8

なるほど。着払いで送ればよかったなー。
着払いで送ろうかとも思ったのですが受け取り拒否されても面倒かなぁ、と。

そうですね、消費生活センターがいいかもしれませんね。
無い事を祈りますが次回があれば送り先を考えてみます。

実は今日修理品が届きました。
修理品と言っても結局、「ON/OFF、起動、認識、通信動作OK」という事で再現せず、製品交換と相成りました。
「数時間後にアクセス不能」と言っているのに起動時のみのテストしかしていないようで、日本語通じてるのか?と。

今、立ち上げて様子を見ているところです。
これで良くなったとしても「なんだかなぁ・・・」と言う感じですが。

投稿者:たく  投稿日時:2014/06/21 02:03 親投稿 - 子投稿なし No.9

一般的に、再修理時にユーザー側が費用負担するのはナンセンスですから
先にメーカーに一報しとけば問題ないと思いますよ。

今回は、必要な動作確認をしなかったメーカー側に非があるのですから
メールか電話で今回の送料分返金請求するとか手はあるのですが面倒ですよね。。。

あと、データーコピー後にサムネイルとメディアサーバーの処理があるので
しばらく、放置した方がいいですね。
サムネイルはONでも、samaba経由だと即時作成されないので
再起動して、しばらく放置するといいと思います。(起動24時間後にもチェック走りますが)

今回の件でメーカも対応の不備を考えてくれると良いのですがね…
結構な時間使わされましたね…
とにかく、今度こそ治ってるといいですね。

投稿者:れみ  投稿日時:2014/06/22 10:27 親投稿 - 子投稿なし No.10

うちのも同じ症状。もうあきらめてるが。
これメーカはどんなテストしてるんだろ。
どうせ負荷テストしてないんだろうなぁ。
画像ファイルをめいっぱい入れてやればすぐ再現するのに。

投稿者:たく  投稿日時:2014/06/23 01:41 親投稿 - 子投稿なし No.11

処理が終わって、使えるならそれは仕様って事なんでしょう。
ファイルの追加とか、何も作業してないのにアクセス出来ないのならば
他の要因、つまり他のバグや故障の可能性が考えられるのですが。

その辺の説明などがメーカーから無いから、判断に困るのでしょうね。
CPUは2コアで800BogoMipsで、大分昔ののCeleronぐらいと思えば
この遅さは、しょうがないのかなぁと思います。

スマホ等からアクセスしないんだったら、過去のスレッド参考に
サムネイル作成を完全停止すればいいと思いますよ。

投稿者:cavitation  投稿日時:2014/06/27 17:44 親投稿 - 子投稿.1 No.12

こんにちは。

製品を交換してようやく直りました。
無事一週間ほど動作しています。
交換なので「直った」と言うのは正しい日本語じゃありませんが(-_-;)

すっかり同じ状況であれば「こんな情報もあった」って事でれみさんも交換してもらった方がいいかもしれませんね・・・着払いで。

同様の症状の方!修理方法は「交換」です(笑)。

投稿者:cavitation  投稿日時:2014/10/23 17:49 親投稿 - 子投稿.1 No.13

と、思ったら1週間ほどでまた同じ症状です。
疲れて、呆れて何も言えんです。

NASNE買ったからもういいや。

使えている人が羨ましいです。

投稿者:Takeshich  投稿日時:2014/10/27 21:33 親投稿 - 子投稿.1 No.14

http://RDNのローカルアドレス:8200/

出るものをコピペしていただければ、もしかすると
問題かなくなるアドバイスが出来るかもしれません。
あくまでももしかするとですがw

投稿者:ゲスト  投稿日時:2014/10/28 06:20 親投稿 - 子投稿.1 No.15

確認不足で、変な書き込みをしてしまったようです。すみません。

> http://RDNのローカルアドレス:8200/
> で
> 出るものをコピペしていただければ、もしかすると
> 問題かなくなるアドバイスが出来るかもしれません。
> あくまでももしかするとですがw

サムネイルでは?とおもったのですが、
今までのやりとりですでにサムネイルの件については話題が出ていたのですね。
大変失礼しました。





投稿者:たく  投稿日時:2014/10/31 20:55 親投稿 - 子投稿なし No.20

個体差なのか私の方は、何のトラブルもない。(少しソースいじってるが…)
ファイル処理の周辺にバグがあるのかもしれませんね。

NASNE買われたのですね。これがあれば十分だと思いますよ。
たぶんRDNのシステムログにはエラーが出てると思いますが
探すのも大変ですからね。

とにかく残念ですね。。。

投稿者:cavitation  投稿日時:2014/11/09 17:15 親投稿 - 子投稿.1 No.16

いやいや、ご助言ありがとうございます。

そうなんです。サムネイル作成の停止も視野に入れてたのですが
今回のFWからrootパスワードが変わってしまったようで・・・
なんもできません(ノД`)・゜・。

投稿者:ゲスト  投稿日時:2014/11/15 13:44 親投稿 - 子投稿.1 No.17

他のQ&Aの投稿があったようにpytonコマンドでゲットできました。
サムネイル等止めてみたいと思います。
ちなみにpasswdコマンド入ってないんですね(*_*)

投稿者:cavitation  投稿日時:2014/11/18 18:33 親投稿 - 子投稿.1 No.18

サムネイル作成を切ってもダメですねー。
同じ状況です。

ちなみにログを見ると時間が明日のものがある(!?)ので/etc/ntp.conf内でnictにサーバーを変更・・・でもログに明日の日付が出る!?
ツボりそうなのでヤメ!

投稿者:cavitation  投稿日時:2014/11/18 18:42 親投稿 - 子投稿なし No.19

#一人相撲してますが

時間がズレるとサービスが止まる場合があるのでかなり疑ってます。
なのでntpdをkillして様子見中。

明日動いていたらまた報告します!

投稿者:たく  投稿日時:2014/11/18 20:40 親投稿 - 子投稿.1 No.21

時間ずれるのが再起動時の時のログだけでしたら気にする必要はないと思いますよ
たぶん、9時間ちょうどでしょう。
起動後に戻るから、問題視してないですね。

他のBBSであったみたいに、原因になるファイルとかあるのでは?
何も入れてない状態だとどうなんでしょう?

あとrootパスワード変更はrootではいって
下記コマンドのpassのところに好きなパスワードいれてやってみてください。
python -c "from nas.users import changepass; changepass('root', 'pass')"

投稿者:ゲスト  投稿日時:2014/11/19 13:01 親投稿 - 子投稿なし No.22

ありがとうございます!
確かに今日もちゃんとアクセスできなくなりました(笑)

rootパスワードの件、なるほど。ありがとうございます!

ファイルの件はどうせ使えてないので全部消してから、というかHDフォーマットしてから様子見したいと思います。
それで落ちないようであればファイルを徐々に増やして原因ファイルを特定する・・・うーん、メンドイな

投稿者:たく  投稿日時:2014/11/19 15:56 親投稿 - 子投稿.1 No.23

そういえばSMBもダメでしたね。

なんか、ここまで来るとHDDが初期不良だったのでは…
いまさらながらですが、他のHDDは試されてましたか?

中身はWD GREEN系だと思うのでWDのツールで検査したらNGかもしれませんね。
あと、今どれくらいファイル数あります?

投稿者:ゲスト  投稿日時:2014/11/19 18:02 親投稿 - 子投稿なし No.24

そうなんですよ。
ただ一度本体を交換しているのでその時にHDDも交換してると思います。
あれ?HDDは同じだったりして???

そうですね、一度HDDを取り出して単体の検査をしてみるのも一興(?)ですよね。

ファイル数は1000程度です。
今フォーマット、空にしたところです。しばらく放置してみます。

投稿者:Takeshich  投稿日時:2014/11/19 22:25 親投稿 - 子投稿なし No.25

syslogの出力先にHDDのどこかを追加して、再起動後に確認できるようにしてみるとかいかがですか?

pingは帰ってくるけど、アプリケーション層からの応答はないように見えるので、何らかのエラーが出力されるんじゃないかという予想です。

投稿者:たく  投稿日時:2014/11/20 21:07 親投稿 - 子投稿.1 No.26

もしsyslog見る事ありましたら
  kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
  kernel: ata1.00: cmd e0/00:00:00:00:00/00:00:00:00:00/40 tag 0
  kernel: res 40/00:00:00:f0:00/00:00:00:00:00/40 Emask 0x4 (timeout)

みたいのが出てたら、RDN側のI/Oの処理がまだおかしいかもしれません。
去年くれに同様の症状で苦しめられた時のログからです。。。
普段はでませんので、参考までに。

投稿者:ゲスト  投稿日時:2014/11/22 15:41 親投稿 - 子投稿.1 No.27

ありがとうございます!

syslog見てもそれらしい(timeout,error,ignore等)のは吐いてないんですよね~。

smb経由とmyisharing経由でコピーした物のパーミッションが違っていたのでコピー後全部777にしてみたのですがやっぱダメでした。
安いHDD買ってシステムコピーして試してみようかな。

投稿者:ゲスト  投稿日時:2014/11/22 15:49 親投稿 - 子投稿.1 No.28

あ、ちなみにログはwarn以上吐くようにしてました。
info見てみたほうがいいんでしょうかね~?
膨大ですが(-_-;)

投稿者:たく  投稿日時:2014/11/22 19:17 親投稿 - 子投稿なし No.30

ん~原因の糸口が見つかりませんね…
私のRDNの標準との変更は、HDD AFT(4kセクタ)向けフォーマット、SMART設定変更、サムネ無効、SAMBA追加設定、ダウンローダー(mldonkey)OFF ぐらいで
特にコレといった事はしてないんですが…
多分、logに出てこない部分が原因なのかな?

windows PCからsamba経由でコピーでなく移動でファイルを渡すとパーミッションが狂う事あったんで、コピーして確認後に消すって感じで私はやってます。

あとRDNのOS(システム)はNANDのなかなので、HDDの中はデータしかないので、取替えてフォーマットすればそのままの設定環境で使えますよ。

投稿者:たく  投稿日時:2014/11/22 21:48 親投稿 - 子投稿.1 No.31

HDD周りが原因かと思いましたが、ちょっと他の要因もあるのかもしれませんね。

シリアルコンソールを使えば調べやすいのですが
とりあえず、
telnet から top コマンドでプロセス監視する
sambaやブラウザの応答が遅くなった時点で、%CPUの数値が継続してあがってるものとかがないか確認できると思います。(ksoftirqdなど)
その後、ps -ax でSTAT(ステータス)確認してDとZのものが無いか確認。
そのプロセスから原因の糸口が見つかると思います。

あとIPv6関係が原因でネットワークが混乱してるのかもしれません。
クライアント側のIPv6を無効にしてみてIPv4だけで症状が変わるかもしれません。
クライアントが複数ある場合は、ルータやHUBとの相性、設定、故障も考えられます。

何にしても根気というか、時間がかかりますね…

投稿者:Takeshich  投稿日時:2014/11/23 11:55 親投稿 - 子投稿なし No.29

ログに出ないのですね。
一番早いのはやっぱりtelnetでつなげなくなった時にシリアルでつないで状況を確認してみるってことなのかなぁ。

私の環境では、繋げなくなるってことはないのですが、ログに
page allocation failure. order:1, mode:0x20
と結構出てて、NICの割り込みが失敗している感じ(SYNが受け取れない)のダンプが頻繁(週に何度か)に吐かれることがあって気持ち悪いなぁと思っていました。

これは、おそらくサムネイルの処理が走っている時によく出ていました。なので、今はサムネイル止めていて、ほぼ出なくなりました。minidlnaのdb再構築をすると出たりします。

NICのドライバが変にこけて、システムは生きていて、ICMPには応答するけど、TCPより上には応答できていないのかなと思ったけど、どうやら違うみたいですね。
エラーログでそうですしね。


投稿者:ゲスト  投稿日時:2014/11/23 13:59 親投稿 - 子投稿なし No.32

毎度毎度スミマセン。
助言ありがとうございます。UNIXに詳しそうなので助かります。

確かに別のシステムでIpv6が邪魔をしてつながらないことがあったので、今、/etc/sysctl.confでipv6を切ってみました。
ipconfigで見ると確かに切れてるようなのでまた一日様子を見てみます。

なるほど、OSはNANDにあるのですね。上記でダメだったら今度は500円くらいの中古HDDに替えてみます。

投稿者:たく  投稿日時:2014/11/23 20:54 親投稿 - 子投稿.1 No.33

> page allocation failure. order:1, mode:0x20
物理メモリ足りなくて、キャッシュやSWAPの処理追いつかないんですよ
RDNの機能を安定して使うには、負荷の高い処理は切るか、使うタイミングを考えないと…
/proc/sys/vm/min_free_kbytes この辺大きくしたらマシになるかな?

たしかHDDを物理的に外しても、Web管理画面は開けたと思います。
思い出すのが遅くて申し訳ないのですが、HDDが原因かどうか確認するには
これが一番早かったかもしれません。

telnetはSAMBAやhttpがNGの時でも、比較的つながる事がありましたので
何回かトライしてみるのも手かもしれません。
あと、繋がらなくなった時、arpテーブルを一応確認してみてください。
ひとつの手掛かりになるかもしれません。

投稿者:cavitation  投稿日時:2014/11/28 18:35 親投稿 - 子投稿なし No.34

IPv6を切る+MediaServerを切る
の双方で今のところ動いています。
どちらか一方ではダメ。
なんじゃこりゃ?
SMB経由だけで使おうかな???

投稿者:たく  投稿日時:2014/11/28 19:31 親投稿 - 子投稿なし No.35

ハブが許容量を超えてるか、三段以上とか
マルチキャストあたりが正しく届いてないのでは?
それでリトライ繰り返して処理まちになって
ネットワークが飽和してしまってるのでは?
ルータを単なるゲートウェイとして
少し処理能力の高いハブを中心にネットワークを構築してみるのはどうでしょう?

投稿者:kens  投稿日時:2015/01/17 12:39 親投稿 - 子投稿なし No.36

RockDiskNextキットモデルを立ち上げて半月程経ちますが、タイトル同様の症状が発生して困っていました。
キットに組み込んだ2TBのHDDには10000曲強の音楽ファイルを転送しています。

RockDiskNext起動後、数分から数時間でdlna、samba、telnet接続できなくなっていました。
/tmpをシンボリックリンクでHDDに移してみましたが、改善には至りませんでした。
そこで、cavitationさんの書き込みの通り、

ntp.confのIPv6を切る+MediaServerを切る

を試したところ、5日以上経過してもダウンすることがなくなりました。

メディアプレーヤーはPC/AndroidのソフトなのでsambaでもRockDiskNextに転送した楽曲を聴くことはできますが、
IO-DATAさんにはMediaServerが原因と思われる接続ダウン不具合を修正していただきたいですね。

投稿者:Takeshich  投稿日時:2015/01/19 19:21 親投稿 - 子投稿なし No.37

IPv4/IPv6デュアルスタックな環境も影響しているようにも見えます。
もしかするとIPv4では通信できなくても、IPv6では通信できたりするんじゃないでしょうか?

ネットワーク関連はあんまり詳しくなので、ふと思った程度なのですが、もし可能ならルータの設定でIPv4のみの環境にして切り分けてみるのもありかも。

投稿者:kens  投稿日時:2015/02/01 20:19 親投稿 - 子投稿.1 No.38

しばらく試行錯誤を繰返し、ようやくネットワーク接続できなくなる不具合が解消されました。

"ntp.confのIPv6を切る"をせずに"MediaServerを切る"のみでしばらく様子を見たところ不具合は発生しませんでした。
その後、MediaServerを有効にしても以下の設定を行うことでネットワーク接続できなくなる不具合を解消することができました。
-----
telnetでrootでloginして下記設定を行います。
■ /tmpをシンボリックリンクでHDD(/home/tmp)に移す→/ あふれ対策

# rm -rf /tmp
# mkdir /home/tmp
# ln -s /home/tmp /tmp
# chmod 777 /home/tmp

■ /etc/sysctl.conf に下記一行を加える→inotifyを使う場合のエラー回避のためのカーネルパラメータ設定(デフォルト値の10倍)

fs.inotify.max_user_watches = 81920
-----
設定後RockDiskNextを再起動してから一週間、不具合発生無く連続稼働中です。

どうやらファイルが多すぎてMediaServerのデータベース更新の際に不具合を引き起こしていたようなので、データベース自動更新を無効にする設定でも効果があると思います。
/etc/minidlna.conf の下記設定を編集
inotify=no
notify_interval=0

投稿者:Takeshich  投稿日時:2015/02/01 23:36 親投稿 - 子投稿なし No.39

ネットワーク接続に問題がないようで、なによりです。
設定がちょっと気になったので確認させてください。

>/tmpをシンボリックリンクでHDD(/home/tmp)に移す→/ あふれ対策

これは、おそらく私が指摘しているminidlnaにおいてdsf,dffが2GB以上の場合、バグがあり、/が100%な状態でnmbdやsmbdがcoreを吐いて死ぬ場合があることへの対策と思います。

ただ、私が確認しているのはnmbdやsmbdが死ぬだけであって、sshでログインして起動させることが可能なので、気休め程度かもしれません。

>/etc/sysctl.conf に下記一行を加える→inotifyを使う場合のエラー回避のためのカーネルパラメータ設定(デフォルト値の10倍)
>fs.inotify.max_user_watches = 81920

minidlnaでは
/proc/sys/fs/inotify/max_user_watches
を適当な値に書き換えています。デフォルトでは65536となっており、
minidlnaで扱っているファイル数が49152以下なら、65536です。

/proc/sys/fs/inotify/max_user_watchesが書き込めない場合は、上記の設定は有効だと思います。
cat /proc/sys/fs/inotify/max_user_watches
で、どのように表示されるのでしょうか?

また、
>/etc/minidlna.conf の下記設定を編集
>inotify=no
>notify_interval=0

とありますが、どうやらnotify_intervalについては、UpnpのNOTIFYメソッドの間隔の設定のようです。そのため、データベースの更新には関係ありません。


投稿者:kens  投稿日時:2015/02/03 00:24 親投稿 - 子投稿.1 No.40

Takeshichさん、お世話になります。
/tmpをHDDに移す件をはじめ、貴重な情報をいただき、ありがとうございます。

現状、対策した状態での
cat /proc/sys/fs/inotify/max_user_watches
の結果は
81920
でした。
デフォルト設定に戻すと幾つになるかは試していません。

現状、ファイル数は

MiniDLNA status
Audio files: 11122
Video files: 2
Image files: 0

です。2日間だけ inotify=no で様子を見たときも不具合は発生しなかったので fs.inotify.max_user_watches の設定に当りをつけて対応してみました。
ともかく、ようやく安定したようで一安心です。

投稿者:Takeshich  投稿日時:2015/02/03 21:07 親投稿 - 子投稿なし No.41

kensさん

>現状、対策した状態での
>cat /proc/sys/fs/inotify/max_user_watches
>の結果は
>81920
>でした。
>デフォルト設定に戻すと幾つになるかは試していません。

私の環境では、65536でした。
おそらくカーネルパラメータ設定のデフォルトは、8192だろうけど、minidlnaが書き換えるので、デフォルトは65536だと思います。

なので、
/etc/sysctl.confにfs.inotify.max_user_watches = 81920
を加えても、それがサーバがダウンする(接続できなくなる)のに対して有効かどうかについては個人的には否定的な見解を持っています。

ただ、
>ともかく、ようやく安定したようで一安心です。

安定されているようですので、そこを否定するつもりはありません。


投稿者:たく  投稿日時:2015/02/04 02:49 親投稿 - 子投稿.1 No.42

>おそらくカーネルパラメータ設定のデフォルトは、8192だろうけど、minidlnaが書き換えるので、デフォルトは65536だと思います。
たしかにメディアサーバーβ版の時には65536になってましたね。

minidlnaのdbが正常に更新されないまま再起動すると、作り直しになるので、
1万ファイルあるので時間かかってただけじゃないかと…
2GB越えdsf,dffファイルがあったら、個数にもよるけど終わるのに1日以上かかるのでは?
シリアル+topで状況見ていればもう少し原因特定できたかと思います。
毎回書いてるのですが、FWアップ後は1回シャットダウンした方が良いと思います。(再起動で設定反映されてない場合もあるので)

inotify/max_user_watchesは65536以上設定して問題なかったか少し心配ですが、65536ファイル超えた時メモリーリークとか大丈夫かな?

投稿者:Takeshich  投稿日時:2015/02/04 13:35 親投稿 - 子投稿なし No.43

たくさん

>2GB越えdsf,dffファイルがあったら、個数にもよるけど終わるのに1日以上かかるのでは?

私の環境で対象がネットワーク以外の場合は、2GB程度だと1ファイルで2分ぐらいです。ネットワークでマウントしてたりすると回線速度がボトルネックになります。

ちなみに、2GBを超えるDSDファイルは、曲の長さで

DSD64で2chだと50分43秒
DSD64で5chだと20分17秒
DSD64で6ch(5.1ch)だと16分54秒

DSD128で2chだと25分22秒
DSD128で5chだと10分09秒
DSD128で6ch(5.1ch)だと8分27秒

DSD256で2chだと12分41秒
DSD256で5chだと5分04秒
DSD256で6ch(5.1ch)だと4分14秒

を超えるファイルです。DSD64の5,6chとDSD128の2ch,DSD256の2chあたりが現実的にクラシックなどでひっかかってきます。

サポートには、脆弱性の対応はもちろんするべきだけど、バグ修正もして欲しいですね。
他のサービスに影響を与えるのはすぐに修正するべきだと思うのですが。。。
修正自体もほんのちょっとなのに。。。
http://takeshich.hatenablog.com/entry/2014/09/15/193759

>inotify/max_user_watchesは65536以上設定して問題なかったか少し心配ですが、65536ファイル超えた時メモリーリークとか大丈夫かな?

上限値の設定だから大丈夫じゃないかなぁ。
minidlnaでは、対象としているファイル数が、max_user_watchesの3/4の値を超えたら、max_user_watchesを書き換えているようなので、そこの処理は問題ないとおもいます。

投稿者:kens  投稿日時:2015/02/04 23:19 親投稿 - 子投稿なし No.44

たくさん

設定変更後の再起動やリセット作業は何度か試みましたが、いずれの場合もネット接続できなる不具合は解消できませんでした。
SMB/minidlna/telnet/myisharingでの接続すべて接続不可となりました。
たまにpingだけ通ることがありました。

ファイル数は10000を超えていますが、データベースの作成は約15分程かかっているようです。
(HDDアクセスが静かになってDLNAクライアントから接続したときに全アルバムが表示されている)
2GB越えdsf,dffファイルは所有しておりません。
files.dbのサイズは37MB強です。


Takeshichさん

fs.inotify.max_user_watches = 81920追加に対する見解はごもっともです。
元に戻して確認したいところですが、現在安定している状態で敢えて弄るのは勇気がいります。
理屈が合わないことで安定して、また理屈が会わないことで不安定になるのが嫌なのです。(ビビリ ^^;)
設定を変更してから再起動後、かれこれ10日程経っていますが、以前の不具合発生頻度がウソのように安定しています。
musicフォルダにいくつかファイルを追加しましたが、自動でちゃんと反映してくれます。(当たり前ですが)

# 本日、rootでloginできなくなっておりびっくりしましたが、ファームウェアが更新されて初期化されていただけでした。

投稿者:え?  投稿日時:2015/02/05 18:15 親投稿 - 子投稿.1 No.45

 一応「何をしたのか履歴は残した上で」作業はしたほうが良いかもしれませんね。
 アップデートファイルもいくつかに分割されているようですし、LANDISKの様に、発売直後からのすべての更新ファイルを無条件にアップデートするのとは違うようです。
 これは、「あっちが変更したつもりが無いものは更新されない」ということで、場合によっては不整合を引き起こす可能性もあるということです。
 下手をすると、不整合を起こす形にファイルを変更された上に、パスワードが変更され、ログインできなくて詰む。しかし、明示的に許可してない作業と変更だから、保障外で突っぱねる…なんてことも、ワーストケースではありえます。

 しかし、ソースの一件以外も仕事そのものが適当で…。
> ■ファームウェア20141231 (2014年2月4日公開)
>※ お客様のご使用環境によりオンラインでのアップデート配信が出来ない
>場合があります。その場合は手動アップデートをご利用ください。
 公開日、どう見てもおかしい。
 自分で「できない場合がある」って書いてあるのにファイルは出さない。
 別に買う人がみんなあの触込みでメディアサーバとして買うわけでもない機能と価格設定なんですがねぇ。

 有無を言わさず自動更新。それも不定期って怖い仕様っすねぇ。
 あの会社とかその会社のNASもアップデートしたらぎゃふんってことまれにあるようですが。

投稿者:たく  投稿日時:2015/02/05 19:55 親投稿 - 子投稿.1 No.47

え?さん

>下手をすると、不整合を起こす形にファイルを変更された上に、パスワードが変更され、ログインできなくて詰む。しかし、明示的に許可してない作業と変更だから、保障外で突っぱねる…なんてことも、ワーストケースではありえます。
 このBBSの他スレッド見てれば、修理にそこまで見てないのが判るかと思います。
 適当に当たりをつけて、基板交換ぐらいしかやってなさそうに思えますね。
 ソースの改変なんか気にもしてなんじゃないでしょうか。

>自分で「できない場合がある」って書いてあるのにファイルは出さない。
http://www.ioplaza.jp/shop/contents/rdnext.aspx#farm
今朝みたら更新されてましたよ。
(ファームウェア20141231 って時点で判ってる人はDL先も判ってる)

自動更新はプリファレンスでOFFに出来ますよ。
差分調べてからじゃないと、私はアップしませんし
設定バックアップして、アップデート後リストアすることにしてます。

投稿者:Takeshich  投稿日時:2015/02/05 20:22 親投稿 - 子投稿なし No.46

え?さん

スレッドの内容とずれてきてしまっているのですが、気にせずコメントします^^;

>下手をすると、不整合を起こす形にファイルを変更された上に、パスワードが変更され、ログインできなくて詰む。しかし、明示的に許可してない作業と変更だから、保障外で突っぱねる…なんてことも、ワーストケースではありえます。

パスワードの変更も前回のファームウェアの更新で、事前通知なしですからね。
zipになっている中身にrpmがあるので、自分に必要なものを自分で入れるというのもありです。

http://www.ioplaza.jp/shop/contents/rdnext.aspx#farm
を見てみたら、すごい。。。

なにこれ。突っ込みどころ満載。一応アーカイブ。
http://archive.today/YqEjM#selection-2561.0-2561.6

文章がおかしいです。
頑張れば理解できるかもしれないけど、正確を期すために公開前にチェックしたほうがいいんじゃないの?対応している人は理解していないのかなぁ。
ntpの脆弱性対応とかもしているようだけど。。。

サポートもこんな質のお仕事だったのを思い出しました。恥ずかしくないのかな?

投稿者:Takeshich  投稿日時:2015/02/05 20:56 親投稿 - 子投稿なし No.48

たくさん

>>自分で「できない場合がある」って書いてあるのにファイルは出さない。
>http://www.ioplaza.jp/shop/contents/rdnext.aspx#farm
>今朝みたら更新されてましたよ。
>(ファームウェア20141231 って時点で判ってる人はDL先も判ってる)

1/30の夕方にはすでにありました。
これはこれで、2/2から公開って言っているのに問題もあるかも。
昔、IRを同じ感じで公開してしまっていて、問題視された企業もありましたよね。

運用側の見方をすると休日を挟んでいるので、月曜や金曜のリリースって嫌うと思うんだけど。。。

投稿者:え?  投稿日時:2015/02/05 21:32 親投稿 - 子投稿なし No.49

 いや、「2014年2月4日」になってんですよ。去年更新って話になってるうえに、名前も間違ってんです。
 リンクも名前も違ってるのはそもそも論外なんです。いつまで御屠蘇飲んでるんでしょ。
 わかるでしょ?ってのは、サポートなしで野良で配られてるファイルなら別ですが、「リリースされたもの」の公開ページとしては「問題がある」といえます。

 まぁ、「少々のミスはしょうがない」ですが、「気をつけましょう」よという話。もしかすると人数少ないのかもしれませんが、似非科学っぽい広告を外部の旧世代のおじーさんと捏造してる暇があったら、日々の仕事誠実にしましょうって思います。

 法人相手の部署があるからか、基本事なかれというか、グダグダやり取りするより交換ですむならそれでいいよねっていうのが方針だとは思います。
 が、問い合わせのときにうっかり正直に口を滑らせた場合にどうなるかは未知数ですし、この掲示板は「DOSプロンプトすら使ったことが無い」人が見て、Tipsとして何も考えずに実行する可能性もあります。
 ですから「安易にrootとして操作を行い、システムの挙動に関わる変更を行う」のは、その手間と比較し、「危険な可能性がある」ことは周知されていたほうがよさそうな気がしますという話でもあります。

 というか、履歴っぽい履歴が無いな。適当に追記しているから、ほかのファイルとの相関関係とか説明も怪しくなってきていますねぇ。
 まぁ、「ファイルがサーバにあること」は秘匿されるべき情報というわけではないですから、そういう意味では問題は無いと思います。今回はw
 でも、日付や、ファイル名は確認し、周囲の説明も見た上で掲載しないとよろしくないのではないかとは思います。

投稿者:たく  投稿日時:2015/02/05 21:54 親投稿 - 子投稿.1 No.50

Takeshichさん

詳細ありがとうございます。
>サポートには、脆弱性の対応はもちろんするべきだけど、バグ修正もして欲しいですね。
他のサービスに影響を与えるのはすぐに修正するべきだと思うのですが。。。
 たしかに、せめて何らかのアナウンスはしてもらいたい所ですね。
 
 Takeshichさんがここまで解決策を提示してるのですから、IO DATAは何らかのアクションをすべきではと思いますね。
 
 ブログの方は10月頃には拝見してたのですが、REGZAの件とかあってソースの一部修正して
 バイナリでどっかアップしてあげれば、まだ ましなのかと思って
 コンパイル環境ずくりとかしてたのですが、ここ最近忙しくて進まないです…

 自己責任でなんとか出来る人は良いのですが、出来ない人もいるという事をIO DATAには判って頂きたい。
 保障外とされる事は、勧めたくは無いですから。

kensさん

そうですか…
minidlnaがらみなのかもしれませんが、根幹がネットワークの処理系にありそうと思っていたのですが
とりあえず現状落ち着いているようで、よかったです。
何か判ったら、お知らせしますね。

投稿者:たく  投稿日時:2015/02/05 22:38 親投稿 - 子投稿なし No.52

冷静に

>RockDiskNextの最新ファームウェアを配布開始いたします。
>「現在のバージョン」をご確認ください。20141231になっていれば完了です。
 2015年2月2日から、バージョン「20141231」を配布開始予定。
 特定のユーザーのみ対象なので、公開という意味にはあたらないのでは?

>ファームウェア20141231 (2014年2月4日公開)
 公にしたのが2014年2月4日ということでしょ?

お知らせには、今回は手動アップデートファイルの公開については触れられていなかった。
20141231はバージョンと書いてるので、イコール公開日、配布開始日と関連してるとは言えないと思います。ファイル名についても
でも2014年12月31日には出来てたのかよと、つっこみたくはなります。

>ですから「安易にrootとして操作を行い、システムの挙動に関わる変更を行う」のは、その手間と比較し、「危険な可能性がある」ことは周知されていたほうがよさそうな気がしますという話でもあります。
 たしかに安易すぎたかもしれませんね、相手のスキルは判りませんから
 今後は注意する事にします。

あと、判っていると思いますが名前をださなくても他人を中傷するのは
誠実さに欠けている行為だと思いますよ。
相手が不誠実だったとしても。

投稿者:Takeshich  投稿日時:2015/02/06 00:15 親投稿 - 子投稿なし No.51

たくさん

>バイナリでどっかアップしてあげれば、まだ ましなのかと思って
>コンパイル環境ずくりとかしてたのですが、ここ最近忙しくて進まないです…

当初は私もそう思っていて、クロスコンパイル出来る環境をつくろうと思っていたのですが、ソース開示の件でいろいろあって、環境構築の意義を見出せずにいるところです。
購入前はソース開示されるとのことで、USBのNICを指してブリッジにしようとかカーネルを更新しようとかminidlna更新しようとかいろいろ考えていたのですが。。。

検証環境の構築テストとして、ddしたのをQEMUで動かしてみることは試してみようかなぁとは思っています。やる気が出れば。。。

>自己責任でなんとか出来る人は良いのですが、出来ない人もいるという事をIO DATAには判って頂きたい。
>保障外とされる事は、勧めたくは無いですから。

同意見です。

あくまでも個人的な感想ですが、
保証つけるならrootでいじれるような製品にしなければいいし、保証なしならrootでガンガンいじれるような製品にすればいいのにとも思うのです。
この製品はいろいろなところにおいて、いいとこ取りが見受けられ、すごい中途半端な状態になってしまっていて、そのことで生じる弊害がしわ寄せとしてユーザに行っている感じがします。

>あと、判っていると思いますが名前をださなくても他人を中傷するのは
>誠実さに欠けている行為だと思いますよ。
>相手が不誠実だったとしても。

これは、今後、気をつけるようにしたいと思います。

投稿者:え?  投稿日時:2015/02/06 01:23 親投稿 - 子投稿なし No.53

おや。冷静だと、その数字が正常に見えるのでしょうか。
http://web.archive.org/web/2014040813 ... shop/contents/rdnext.aspx
>■ファームウェア20140119 (2014年3月22日公開)
ロールバックされた事実はありますか?古い日付に今なっているわけですが。
文字が読めないお馬鹿さん扱いされてしまってますけど、そこまでぼーっと物言っては居ないんです。
確認をしてみようともしないで、大本営が正しいことを前提に無理に解釈するのは誠実ですか?

素直に見れば、テキストを確認しないで上げちゃっただけなんですよ。で、人的な間違いは仕方ないとしてるのが譲歩なんですが、「今回だけではないので」きちんと確認してから、公開したほうが良いんじゃないですかね?って話をしただけですが、「繰り返す人たちへの話として」でもきつい物言いでしたでしょうか?リリースしたときなんて仕様すらデタラメだったんですよ?このページw
ものすごく婉曲に書いてるつもりだったのですが。
仮にまちがってるんだろうなぁであっても、無理に擁護したり歪曲したり、捏造しなくても、問題は無いですよね。「直せばいいんですから」。まぁ、いずれにしても「数字はおかしい」と思います。そして、可笑しいものをむりにおかしくないと言い張ることは擁護にも援護にもなりません。

名前は出していませんが、流石に「あってはいけない」ことを理由として「だから音が変わるんだ」は「公的機関に怒られても仕方が無い広告」だと思うのです。個人サイトだったらいいかって言うと、あの表現でリンクしててそれは微妙だと思います。外部サイトだと更に凄いのがあります。いや、むしろ「自分で気がついてこっそりどうにかしてね」という意味で婉曲に「消えてしまえばなにいってんだ?で済むように」してあるんです。機能性を商品にしている企業が「恥ずかしくないのなら」仕方がありませんが。
これ以上はもう踏み込まないけど、そういう話です。

ただ、一度親ブランドで「サポートと修理から戻ってきた案件で」後日「リコールになった」ものがありますし、「問題にならないと何もしないなら」火はつけちゃうしかないのかなぁと迷う自分も居ます。
その迷いが「気がついてこっそり直してくれれば大丈夫ですよ」「なんなら該当部分を規約を盾に消しちゃっても」くらいの婉曲な表現にあったりするのです。ちゃんと調べてねって渡したものを「火がつかなければ握りつぶす」って実績を目の当たりにはしてるのです。ですから、ちょっと踏み込み気味な表現も含め「理由はあります」。
「もっと良い方法があるのならそうしますが思いつかないだけ」です。

尚、最初の此処の記事に書いた意図としては、「覚悟や理解があることを当事者なら確認」「情報の記述なら、ワーストケースでは問題が発生する可能性もある行為だということだけ周知」すれば、「やってくれないんだから仕方ない」とは思います。ですから、可能性があって、やってくれないなら、ユーザーでどうにかする道を探ることを「抑制しようとは思いません」。ただ、当たり前のように標準UI以外の作業が書かれているので、「リスクは明示したほうが良いだろうな」という話です。

別に謝らなくても、直接の反応が無くても、「ちゃんとしようとしてくれる姿勢が見えれば」「人間間違えるんだからしょーがないよね」で良いと思うのですが、「ボヤだったらどうせみえないから良いだろ」って態度だと、どうしようかなぁと思ってしまうことも悪いことでしょうか?

機能が正常に動作するように維持され、ライセンスがきちんと遵守されていれば、マニュアルに無いような操作は保証外。言わなくても何かできる人は「やっても良いけど知らないよ」でも良いと思います。
そのままでも使えるし、「わかるならおもちゃにもなる」ってのは中途半端でもない遊び心のある製品だと思います。問題は、通常使用において、ちょっとバグっぽい挙動があることであって。正常な動作と、機能の維持は、その利便性を売ってるわけですから、「自己責任」ではチャラにならないと思うのですがねぇ。

出来れば「何も言わないで済むくらい堅実に」お仕事していただけるとうれしいです。別に「普通の仕事をしてる人に何でもクレームつけようって根性悪じゃない」んで。これくらいはあるあるってレベルの間違いなら、スルーするんですが…そうすべきレベルでしょうかねぇ?

投稿者:たく  投稿日時:2015/02/07 02:03 親投稿 - 子投稿.1 No.54

え? さん

>ファームウェア20141231 (2014年2月4日公開)
失礼しました。公開は2015年が正しいはずですよね。
私もボーとしてたみたいです。

ここ見てて、他の方が混乱しないようにと思いまとめまてみます。

2015/2/7 0:30時点での
http://www.ioplaza.jp/shop/contents/rdnext.aspx#farm
空欄の行はカウントしてません。

・1行目
誤)最新アップデート「20141023」を11/6よりネットワークアップデートで配信開始しました。
正)最新アップデート「20141231」を2/2よりネットワークアップデートで配信開始しました。
補足)最新アップデートは、バージョン「20141231」になります。

・4行目
誤)■ファームウェア20141231 (2014年2月4日公開)
正)■ファームウェア20141231 (2015年2月4日公開)
補足)公開日は2015年2月4日になります。

・10行目
誤)ファームウェア【20141023】は、バージョン20141023適用済みRockdiskNext専用ファームウェアです。
正)ファームウェア【20141231】は、バージョン20141023適用済みRockdiskNext専用ファームウェアです。

・17行目
誤)<③:201411231 かならず現在のバージョンが②20141023であることを確認してからご利用ください>
正)<③:20141231 かならず現在のバージョンが②20141023であることを確認してからご利用ください>
補足)「201411231」というバージョンはありません。(あるのかな?)

私が現時点で気がついたのはコレぐらいです。
正確な情報を確認されたい方は製品サポートに問い合わせください。
http://bbs.ioplaza.jp/forum/index.php?topic_id=1692

他の部分に気づかれた方は、補足をお願いします。

投稿者:Takeshich  投稿日時:2015/02/10 20:38 親投稿 - 子投稿なし No.55

たくさん え? さん

どうやら、ここを見て気づいていただけたようで、修正されていますね。
機種依存文字も治ってる。
http://www.ioplaza.jp/shop/contents/rdnext.aspx#farm

変更前
http://archive.today/YqEjM#selection-2561.0-2561.6

変更後
http://archive.today/I7Cqc#selection-2561.0-2561.6

正しくなかったら、直すということは、真摯にやっていただきたいなと思います。

投稿者:Takeshich  投稿日時:2015/02/22 23:45 親投稿 - 子投稿なし No.56

ファームウェアを更新してから、プロセスとかを落とさず、そのままにしていたら、
時間がたつとサーバーがダウンという現象が現在絶賛再現中です。。。

シリアルケーブルを持っていなかったので、Amazonでポチりました。
ログとかは到着後おそらく確認できると思います。流れてないことを期待したいです。

現状、pingへの応答はあります。
nmapにてポートスキャンをかけたところ、開いているポートは確認できましたし、OSも読み取ることは出来ました。

明日辺りにwiresharkの使い方調べつつ、パケットキャプチャしながら、TCPのシーケンスについて確認したいと思います。

これまでにnmbdが2度ほど落ちていました。ルータ側でIPv6をブリッジする設定にしていたのですが、再現しないので、無効にし、RDN再起動後5時間程度で発生しました。発生時はtelnetでアクセス中でした。

とりあえず、いろいろやってみます。

投稿者:たく  投稿日時:2015/02/23 00:18 親投稿 - 子投稿.1 No.57

Takeshichさん

私はシリアルは、スイッチサイエンスのSSCI-010320使ってます、3.3Vですよ

まだ使ってないけど、wireshark向けにNETGEAR GS105E-200JPS
安くなったな~

私はIPv6ルータで切ってるから使用してないけど、なんか変だね。

投稿者:Takeshich  投稿日時:2015/02/23 22:57 親投稿 - 子投稿なし No.58

たくさん

とりあえず、wiresharkでPCのNICのRockDiskNextとの通信をのぞいてみました。

TCPレベルでは応答があるようで、3wayハンドシェイクはできているようです。
その後PCからRockDiskNextへ上位プロトコル(HTTPとかtelnetとか)でデータを送るのですが、RockDiskNextからはTCPレベルでACKがPCに送られるだけで、上位プロトコルのデータはない。
という状況でした。

>NICのドライバが変にこけて、システムは生きていて、ICMPには応答するけど、TCPより上には応答できていないのかなと思ったけど

以前に予想していたのだけど、結構当たっていたっぽく、
状況からは、TCPレベルでは通信はできているけど、その上位に不具合が起きているようで、おそらくカーネル(NICのドライバを含む?)とアプリケーションとのデータのやり取りがうまく行っていないように思えます。

詳しくはログを見てみないとなんとも言えないです。ログに出ないって言ってた気が。。。

なにかわかったら、また書き込みます。

投稿者:たく  投稿日時:2015/02/24 21:40 親投稿 - 子投稿.1 .2 No.59

Takeshichさん

>page allocation failure. order:1, mode:0x20
とログに残ってたと以前書かれてましたが

Takeshichさんの、現在のネットワーク構成が判らないので何ともいいがたいのですが
もしかしたら、なにかしらRDNのメモリを圧迫してるのではないでしょうか?
TIME_WAIT とか( netstat -anp|grep TIME_WAIT )

RDN再起動しても再発しました?
ログに痕跡残ってなかったら、かなり厄介ですね。

投稿者:Takeshich  投稿日時:2015/02/24 22:48 親投稿 - 子投稿なし No.60

たくさん

>もしかしたら、なにかしらRDNのメモリを圧迫してるのではないでしょうか?
>TIME_WAIT とか( netstat -anp|grep TIME_WAIT )

これは心当たりがあって、サーバがダウンするような症状を再現させるするためにあえてダウンローダーを動かしてました。
以前確認した時は結構な数TIME_WAITはありました。

ダウンローダーを起動しなければ、TIME_WAITはほぼなかったと思います。

さて、シリアル接続しました。。。

>ログに痕跡残ってなかったら、かなり厄介ですね。

流れていなくて、発生したと思われる時間のログはあったのですが、直接の痕跡はありませんでした。
ただ、発生したと思われる時間以降にアプリケーションではデータ受信し、送信したつもりになっているのに
データが送られていない状態のようで、通信に齟齬が生じ、
アプリケーションレベルで通信を確立する際のエラーが大量に出ているようでした。

webアクセスやsambaでつながるかを確かめてみて、PC側からはつながらないと判断した際のログは以下のようになっていました。

Feb 22 22:51:09 iwa lighttpd[1175]: (connections.c.299) SSL: 1 error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
Feb 22 22:51:19 iwa smbd[18658]: [2015/02/22 22:51:19, 0] smbd/process.c:362(init_smb_request)
Feb 22 22:51:19 iwa smbd[18658]: init_smb_request: invalid request size 10


その後、翌日にWiresharkでPC側の通信を見た際には、
アプリケーション側でのデータ受信もできなくなったようで、上記のログは出力されなくなっていました。

RockdiskNextの通信の状況ですが、
RockdiskNextから外部宛にPingを打つと応答を拾えました。
ただ、wgetをしてみたら、名前が引けないようで
やはりアプリケーションレベルとカーネル(NIC?)でのやりとりができていないようです。

シリアルUSB変換のドライバがあまり良くないようでPCが何度も再起動するので、早めに通信を回復させたいなと思い
NICを再起動しようと

ifdown eth0
ifup eth0
したら、アプリケーションレベルでの通信が回復しました。普通に使える状態になりました。

本来であれば、NICの再起動前にifconfig -aとかをしておくべきだったのでしょうが、すっかり忘れていました。

プロセスを確認しても、特におかしい感じもなかったです。
メモリも
free
total used free shared buffers cached
Mem: 253980 237460 16520 0 96 37376
-/+ buffers/cache: 199988 53992
Swap: 4096564 4916 4091648

な感じでした。

NICを再起動したら、問題なくなったことから考えて、NICかカーネルに関する問題のようです。
原因は追えないですね。。。

NICの状況を確認するのを忘れてしまったので、もう一度なんとか頑張って再現させてみます。
条件わかんないけど。

それと直接関係するか不明なのですが、HUBの電源を落とすと
http://pastebin.com/Ye6WAT5G
な感じなログがHUBの電源を落としている間、ずっと出力されてる場合があります。
これが出力されているとnmbdが落ちやすい傾向にあったりします。
NICがらみだから気持ち悪いです。これもファームウェアを更新後出るようになった感じです。

出力されなくなる時もあって、これも条件は不明です。

投稿者:たく  投稿日時:2015/02/28 02:08 親投稿 - 子投稿.1 No.62

Takeshichさん

>それと直接関係するか不明なのですが、HUBの電源を落とすと
同じように試してみました、一時間ほどでnmbd落ちますね。

nmbd[1361]: [2015/02/27 20:15:17, 0] lib/fault.c:41(fault_report)
nmbd[1361]: ===============================================================
nmbd[1361]: [2015/02/27 20:15:17, 0] lib/fault.c:42(fault_report)
nmbd[1361]: INTERNAL ERROR: Signal 6 in pid 1361 (3.4.2-47.fc12)
nmbd[1361]: Please read the Trouble-Shooting section of the Samba3-HOWTO
nmbd[1361]: [2015/02/27 20:15:17, 0] lib/fault.c:44(fault_report)
nmbd[1361]:
nmbd[1361]: From: http://www.samba.org/samba/docs/Samba3-HOWTO.pdf
nmbd[1361]: [2015/02/27 20:15:17, 0] lib/fault.c:45(fault_report)
nmbd[1361]: ===============================================================
nmbd[1361]: [2015/02/27 20:15:17, 0] lib/util.c:1480(smb_panic)
nmbd[1361]: PANIC (pid 1361): internal error
nmbd[1361]: [2015/02/27 20:15:17, 0] lib/util.c:1584(log_stack_trace)
nmbd[1361]: BACKTRACE: 5 stack frames:
nmbd[1361]: #0 nmbd(log_stack_trace+0x14) [0x2a16edd0]
nmbd[1361]: #1 nmbd(smb_panic+0x30) [0x2a16eee4]
nmbd[1361]: #2 nmbd(+0x15e878) [0x2a15e878]
nmbd[1361]: #3 /lib/libc.so.6(__default_sa_restorer_v2+0) [0x40275120]
nmbd[1361]: #4 /lib/libc.so.6(gsignal+0x40) [0x40273cac]
nmbd[1361]: [2015/02/27 20:15:17, 0] ../lib/util/talloc_stack.c:126(talloc_tos)
nmbd[1361]: no talloc stackframe around, leaking memory
nmbd[1361]: [2015/02/27 20:15:17, 0] lib/fault.c:307(dump_core)
nmbd[1361]: Can not dump core: corepath not set up

「no talloc stackframe around, leaking memory」
tallocの処理にバグがあってメモリーリークして終了したのかな?

NIC(GMAC)もメモリ管理周りで、変な挙動をする様なレポートもありましたが、この件に該当するかは、判りませんでした。

発生条件が特定出来れば良いのですが、なかなか判らないですね…

投稿者:え?  投稿日時:2015/02/28 11:14 親投稿 - 子投稿なし No.64

もしファイルが残ってるようなら、バイナリで比較。
変更点があるようなら、少なくとも初期化絡みで後一回はアップデートがあるでしょうし(既に投げたかもしれませんが)、連絡は入れておいたほうが良いかもしれません。
「変更履歴が正直で正しく書いてあるなら」ファームのアップデートに起因する筈がなさそうなんですが、言わないとエンバグしても放置ですから、言うだけは言ったほうがよさそうです。
別件っぽいですが、
http://community.phileweb.com/mypage/entry/2182/20140324/41803/
こんなケースもあって、
http://www.iodata.jp/support/qanda/answer/s18592.htm
タイムスタンプをみると、ファームのリリース時期よりあとでも発生しているようですし。
再現性が無いとスルーされそうな気もしますが、既にへんなログが残ってることがおかしいといえばおかしいんですよね。

ちゃんとソースやその設定ファイルがあるわけじゃないんで、そっちからは追えないですし、ロールバックで改善するなら、それこそマシなほうのファイルにしておいたほうがユーザーの利便性は高いはずなんですけども。

投稿者:Takeshich  投稿日時:2015/02/28 20:57 親投稿 - 子投稿なし No.63

たくさん

>発生条件が特定出来れば良いのですが、なかなか判らないですね…

そうなんですよね。

ただ、このnmbdが落ちやすいのは、
http://pastebin.com/Ye6WAT5G
のログが出てしまう時だけです。
当方が認識では、このログは20141231にあげてから発生なのですが、それまでは、不必要なプロセスはあげず、管理画面のプロセスなどは立ち上げないなどの運用をしてたので、20141231にしてから出た始めたのかは判断がつきません。

また、
http://bbs.ioplaza.jp/forum/index.php?topic_id=2672#post_id9984

ntpのおかしいログを出さないようにして(ntpdの再起動)からは、でなくなったのですが、一度再起動したら、また復活して、ログに出力されているavahiとntpdを止めてもnmbdは落ちるようです。また、ntpdを再起動してもnmbdは落ちるようです。

ログを見ていたら、
NET[512]: /etc/sysconfig/network-scripts/ifup-post : updated /etc/resolv.conf
NET[616]: /etc/sysconfig/network-scripts/ifdown-post : updated /etc/resolv.conf

とあったので、インターフェースがup,downをしていないのになぜか検知するようになっているのかもしれません。

投稿者:Takeshich  投稿日時:2015/03/02 23:28 親投稿 - 子投稿なし No.61

たくさん

>RDN再起動しても再発しました?

ifdown,ifupして数日様子を見ましたが、再発しないため、rebootしました。
reboot後、数日経ちましたが、再発しません。

この現象(時間が経つとサーバがダウンしたように見える問題)を再現させるための、条件がわからない。。。

投稿者:たく  投稿日時:2015/03/05 22:10 親投稿 - 子投稿.1 No.65

Takeshichさん

ある程度SAMBA使って、LANケーブル抜くと再現はしましたけど
通常ではありえない状況だから参考にしかならないな…

XBMCでSAMBA経由で適当に再生させといて、XBMC止めてからLANケーブル抜いたら
30分~1時間ぐらいでnmbdがcoreはいてくれました。
coreの設定小さすぎて、gdbでバックトレースしきれなかったので
また時間ある時に設定変えてやってみます。

色々設定変えてみて判ったんですが
DHCPに設定して、LANケーブル刺さってない状態で PowerOff → PowerOn
起動後にLANケーブル刺しても認識しません。(NICがリセットされないから…)

ルータはIO DATA WN-AC1167DGRを使ってるのですが
無線設定の「マルチキャスト変換」あやしいので最初から切ってたんですが、有効にしてみたら
Win8.1 PCで暫くしたら、RDN見えなくなりました…
WN-AC1167DGRはデフォルトで有効らしいです。まぎらわしいので切りました。

今のところ、samba、メモリ管理、NIC、avahi への処理に何か問題が有りそうな気がします。

投稿者:Takeshich  投稿日時:2015/03/06 22:16 親投稿 - 子投稿なし No.66

たくさん

>ある程度SAMBA使って、LANケーブル抜くと再現はしましたけど
>通常ではありえない状況だから参考にしかならないな…

ごめんなさい、説明が下手だったようで
HUBの電源を落とすとnmbdが落ちる現象は再現性はあります。
ただ、必ずというわけではないようです。9割は落ちますが、落ちない時もあります。

当方の使い方としてはHUBのあるAVアンプにRDNを繋いでいるので、AVアンプの電源を切ると普通に起きます。ただ、普通に使っていてログに現れたのが最近ではあります。
が、バージョン20141231からかというのが判断はできない状況です。ルータでエコモードとかで有線LANポートをオフしたりしても発生すると思われるので、結構遭遇しそうではあります。

言いたかったのは、RDNに全く繋がらなくなる、つまり本スレッドでメインで言及されているRDNにつながらない状態については再現はしていない状況ということです。

>ルータはIO DATA WN-AC1167DGRを使ってるのですが
>無線設定の「マルチキャスト変換」あやしいので最初から切ってたんですが、有効にしてみたら
>Win8.1 PCで暫くしたら、RDN見えなくなりました…

本スレッドでは言及されていないけれども、
http://bbs.ioplaza.jp/forum/index.php?topic_id=2669
で触れられている状況については、再現性はあるように思えます。

>今のところ、samba、メモリ管理、NIC、avahi への処理に何か問題が有りそうな気がします。

そうですね。
UDPで1900をListenしているので、minidlnaも加えてもいいのかもしれないと考えるのですが、いかがでしょうか?


投稿者:たく  投稿日時:2015/03/07 00:17 親投稿 - 子投稿.1 No.67

Takeshichさん

>当方の使い方としてはHUBのあるAVアンプにRDNを繋いでいるので、…
 なるほど、そういう使い方もありですね。

>が、バージョン20141231からかというのが判断はできない状況です。ルータでエコモードとかで有線LANポートをオフしたりしても発生すると思われるので、結構遭遇しそうではあります。
 HUBにもエコモード付のもありますし、たしかに遭遇しそうな問題ですね。
 
>UDPで1900をListenしているので、minidlnaも加えてもいいのかもしれないと考えるのですが、いかがでしょうか?
 sambaばかり見てて、minidlna忘れてしまってました…
 これも、問題ありそうですものね。追加ですね。

>言いたかったのは、RDNに全く繋がらなくなる、つまり本スレッドでメインで言及されているRDNにつながらない状態については再現はしていない状況ということです。
 すみません、私も説明不足でした。通常稼働での再現についてではなく
 HUBの電源落とした時のnmbd落ちは再現できたという事だけだったんです。

本題の件も含め、複数の要因がからみあってると思っていて
HUBの電源落とした時の挙動の原因が判れば、他の件への一つのヒントになるかと思っています。

投稿者:Takeshich  投稿日時:2015/03/13 12:54 親投稿 - 子投稿なし No.68

たくさん

HUBの電源落とした時のnmbd落ちの原因はどうやら/usr/bin/nas-serviceのようです。

「もーいろいろ面倒だな」と思って、初期化してみました。
初期化後、HUBの電源落とした時に/var/log/messagesに出るNICとavahi-daemonのログ
http://pastebin.com/Ye6WAT5G
は出ませんでした。

IPアドレスを手動(dhcpを使わない)にしたところ、再度、ログが出て、nmbdが落ちるるようになりました。
以前は同じ使い方をしていても出ていなかったのにといろいろ考えて、気づいたのが
「あ、/usr/bin/nas-serviceあげてなかったんだ。」
ということ。

通常だと/usr/bin/nas-serviceを起動していると、プロセスを殺してもゾンビのように立ち上がってくる。
(zombieプロセスってわけではなく。)
そのため、/etc/init.d/nasledの中で、コメントアウトしていました。

再度、/etc/init.d/nasledの中で
#echo -n ' nas-service'
#/usr/bin/nas-service >/dev/null 2>&1

として、rebootしたところ、ログも出ず、nmbdも落ちませんでした。
戻して、rebootしたところ、ログが出て、nmbdは数時間後に落ちました。

/usr/bin/nas-serviceの中身を見ると

if (restart or network_down) and servicerunning('dhclient', 68, 'udp') != SERVICE_RUNNING:
logger.fatal('[%s] No Network' % gettime())
pipe = nas.system.lock('/var/tmp/network', False)
if pipe:
(error, status) = nas.system.POPEN('service network restart')
status.close()
nas.system.unlock(pipe)

とあり、HUBの電源を落としてlinkupしていない状態で、dhcpを使用していない場合は、
ネットワークのインターフェイスを再起動しているようでした。
そして、NICの再起動の影響で
おそらく、インターフェイスをupしてからtimeoutになるまでの間は、
アプリケーションでの認識は、linkupになっていると考えられ、
そのようなログも出るし、nmbdもタイミングが悪いと何らかの原因によって落ちているようでした。

私が気づかなかったのは、これまで/usr/bin/nas-serviceを起動していなかったからでした。。。

投稿者:たく  投稿日時:2015/03/14 01:48 親投稿 - 子投稿.1 No.69

Takeshichさん

>「あ、/usr/bin/nas-serviceあげてなかったんだ。」
 なるほど、nas-serviceごと落としてたんですね。
 
ちなみに
>pipe = nas.system.lock('/var/tmp/network', False)

「/var/tmp/network」は一回でもリンクアップしないと作られないみたいです。
NIC未接続+DHCPの状態で PowerOFF → PowerON するとつくられないので
起動直後から、「んなファイルね~よぉ」と怒られ、以降リセットすらしてくれなくなります。
この状態で放置しても、smbd,nmbd共に当たり前ですが落ちませんでした。

この辺は初期の頃から変更されてないようだから、今までの不具合に隠れて判らなかったのかもしれません。

sambaやdlnaを使用してるとメモリが断片化(でいいのかな?)して使用してるメモリ空間が密接してくるので、メモリリークを起こしやすくなってるのではと思います。

sambaとか他がそれの影響を受けてしまってるので、原因は「nas-service」の処理のどこかに問題があるという事かと思います。

投稿者:Takeshich  投稿日時:2015/03/17 12:50 親投稿 - 子投稿.1 No.70

話を本スレッドのメインに戻していきたいと思います。

同様の症状(時間がたつとサーバーがダウン)でお悩みの方に確認したいことがあります。
私が遭遇した症状と同じ症状なのかどうかを確認したいです。

1)同様の症状(時間がたつとサーバーがダウン)が発生した場合、RDNに刺さっているネットワークケーブルを抜いて、15秒程度待って、再度挿してみてください。メディアサーバやsambaなどと接続できるようになりませんか?

私が遭遇した症状と

>症状:本体起動(再起動)後、数時間経つと急にアクセス(※)できなくなる。
>  ※WEB、メディア、SMB、AFPなど全部
>   電源は入っており、pingは飛ばすと帰ってくる。

が出た場合の症状が同じであるならば、NICを再起動すれば電源をOFF/ONすることなく症状が解消するはずです。
NICを再起動するには、IPアドレスを固定にしている場合は、RDNに刺さっているネットワークケーブルを抜いて、15秒程度待って、再度挿せば/usr/bin/nas-serviceによってNICが再起動し、sambaやメディアサーバなどに接続できるはずです。

2) 1)で接続が回復した場合、管理画面にadminでログインして、プリファレンス->システムログを確認してみてください。
sambaの接続確認をして、接続できなかった際に
Feb 22 22:51:19 iwa smbd[18658]: [2015/02/22 22:51:19, 0] smbd/process.c:362(init_smb_request)
Feb 22 22:51:19 iwa smbd[18658]: init_smb_request: invalid request size 10
と同様なものが出ていませんか?

管理画面(webアクセス)に接続してみて、接続できなかった際に
Feb 22 22:51:09 iwa lighttpd[1175]: (connections.c.299) SSL: 1 error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
と同様なものが出ていませんか?

その他、怪しいログが出ている場合もあるかもしれません。
情報の提供をお待ちしております。

投稿者:たく  投稿日時:2015/03/18 00:55 親投稿 - 子投稿.1 No.74

要因となるものが複数あると、問題の本質にたどり着けなくなる。

nmbd落ちた時に /var/log/messagesに残ってた。
*** glibc detected *** nmbd: free(): invalid next size (fast): 0x2a2dd3a0 ***

たぶん原因はコレなんだろうなと思う。
「CVE-2015-0235」
[root@RockDisk01 Public]# ./ghost.sh
Installed glibc version(s)
- glibc-2.11-2.fa3.armv5tel: vulnerable

This system is vulnerable to CVE-2015-0235. <https://access.redhat.com/security/cve/CVE-2015-0235>
Please refer to <https://access.redhat.com/articles/1332213> for remediation steps

redhatのテストスクリプトだけど、結果は同じだと思う。

投稿者:T.K.  投稿日時:2015/03/18 17:12 親投稿 - 子投稿.1 No.71

Takeshichさん

(時間がたつとサーバーがダウン)ではないのですが、

スレッド(止まる原因)http://bbs.ioplaza.jp/forum/index.php?topic_id=2669
これによって止まった場合
1)の方法でNICを再起動すれば、すぐにつながるようになりました。
2)は確認できません。

関連があればと思い、書き込みます。

投稿者:Takeshich  投稿日時:2015/03/18 23:42 親投稿 - 子投稿なし No.75

たくさん

>nmbd落ちた時に /var/log/messagesに残ってた。
>*** glibc detected *** nmbd: free(): invalid next size (fast): 0x2a2dd3a0 ***

/var/log/samba/log.nmbdに残るやつですよね。

>たぶん原因はコレなんだろうなと思う。
>「CVE-2015-0235」

私としては、この脆弱性が原因な可能性は低いなと思った記憶があります。

確かにRDNで使われているglibcは当該脆弱性があります。

1月ぐらい前のことなので、ちょっと定かではないのですが、
nmbdでもたぶんgethostbynameは使われているけれども、linkdownしている最中には
呼ばれないよなと考えて、たぶんこの脆弱性が原因な可能性は低いなと思ったような気はします。

また、悪用が確認されなかったとされるリストにもsambaが入っていたので、そのように判断した
と思います。
http://seclists.org/oss-sec/2015/q1/283

heap overflowを検知してのログだとは思いますが、nmbdも古いのでソースを見るのも
あんまり気乗りしない感じです。

投稿者:Takeshich  投稿日時:2015/03/18 23:54 親投稿 - 子投稿.1 No.72

T.K.さん

情報提供ありがとうございます。

>スレッド(止まる原因)http://bbs.ioplaza.jp/forum/index.php?topic_id=2669

これは、T.K.さんの環境では、止まるということを再現することが可能なのでしょうか?
もし簡単に再現できるのであれば、次のことをお願いしたいのですが、可能でしょうか?

止まったかな?と思った時に、ブラウザでRockDiskNextの管理画面にアクセスしてみて欲しいです。
そして、その時刻も把握しておいてください。(*)
おそらく、ブラウザも「おや?」っと考え込んだ感じになって何も表示されない状態がちょっとあると思います。

その後、
1)の方法でNICを再起動して、接続可能にして、
RockDiskNextの管理画面にアクセスして、adminでログイン。
プリファレンス->システムログ->システムログ
で表示されるログに*でアクセスした時刻にlighttpdを含む文字列が出ているかを確認していただけますか?

急ぎではないので、できるときにでかまいません。

投稿者:T.K.  投稿日時:2015/03/19 18:20 親投稿 - 子投稿なし No.73

Takeshichさん

再現可能なので早速試してみました。

止まった時には、ログが全然残っておらず、NICのみフリーズ状態?のようでした。
lighttpdを含む文字列も、見当たりませんでした。


【外部操作及び症状】
50:30 WEB管理画面にてログをクリア、ログオフ
50:45 NotoPCをシャットダウン開始
51:30 NotoPCを電源オン
51:46 DLNAサーバーが切断(DLNAで流していた音楽が切れる)
   その後PCが立ち上がるがSAMBAに接続できず
53:15 WEB管理画面にアクセス(ブラウザは非表示)
54:15 lanケーブルを抜く
54:35 lanケーブルを接続


***【ログ】*********************************************
Mar 19 17:50:30 isharing nas[1189]: admin logout!
Mar 19 17:50:30 isharing nas[1189]: admin logout!
Mar 19 17:54:16 isharing kernel: eth0: link down
Mar 19 17:54:16 isharing kernel: eth0: link down
Mar 19 17:54:20 isharing kernel: ........
Mar 19 17:54:20 isharing kernel: ........
Mar 19 17:54:20 isharing kernel: Timed-out of wait
Mar 19 17:54:20 isharing kernel: Timed-out of wait
Mar 19 17:54:20 isharing kernel: eth0: PHY is Realtek RTL8211D, type 0x001cc914
Mar 19 17:54:20 isharing kernel: eth0: PHY is Realtek RTL8211D, type 0x001cc914
Mar 19 17:54:33 isharing avahi-daemon[1049]: Withdrawing address record for 192.168.11.20 on eth0.
Mar 19 17:54:33 isharing avahi-daemon[1049]: Withdrawing address record for 192.168.11.20 on eth0.


以下省略 全182行

投稿者:たく  投稿日時:2015/03/23 01:31 親投稿 - 子投稿.1 No.76

Takeshichさん

>また、悪用が確認されなかったとされるリストにもsambaが入っていたので、そのように判断したと思います。
 私も外部からは問題無いとは思うんですが、gethostbynameを内部の処理で呼ばれた場合でもSIGABRTされるんじゃないかな~と安易に思ってしまったところです。

nmbdがはいたcore(以前とは別の)をgdbで見てみたんですが
(gdb)bt full
~省 略~
#17 0x40275318 in abort () at abort.c:92
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x54524154,
sa_sigaction = 0x54524154}, sa_mask = {__val = {1163281759,
1916621902, 1701604981, 7103862, 1196310860, 1398753363,
1129469263, 826098757, 1146572800, 1275080509, 1028083265,
1432317541, 1414868563, 3681606, 1986359920, 1937076073,
1342197309, 1280722258, 1279612485, 1124093501, 1330859599,
1498694988, 1933395280, 1634300517, 1213399148, 1028413004,
1347747891, 1380013139, 1330274132, 1668431170, 1347747891,
1380013139}}, sa_flags = 1330274132, sa_restorer = 0x44495f42}
sigs = Cannot access memory at address 0xbe895fd8

gdb使いこなせてないのと、glibc-2.11-2.fa4のdebuginfoが見つからなくここまででお手上げ状態です。

nas-serviceがNIC LinkDown時に約30秒間隔でリセットするのも原因の一つだと思うので、LinkUpするまでリセットしないようにnas-serviceを少しいじってみた。
現在NIC抜いてから3時間程ですがlog.nmbdは更新されてるのでnmbdは落ちてはいないようです。

/usr/bin/nas-service
def _service()内 439行目(FW:20131231)

====elif not status:
========network_down = True
========logger.fatal('[%s] link down' % gettime())
========if not link_status: #追加(先頭スペース:8)
============network_down = False #追加(先頭スペース:12)

※このBBSでは投稿時に無駄な空白が消されるみたいですので
 行頭の=を半角スペースに置換えてください。

投稿者:Takeshich  投稿日時:2015/03/24 00:22 親投稿 - 子投稿なし No.77

たくさん

>nas-serviceがNIC LinkDown時に約30秒間隔でリセットするのも原因の一つだと思う

私もそう思います。
coreを吐いて落ちるときだけではなくて、ログにも

Feb 22 03:18:48 iwa nmbd[25935]: [2015/02/22 03:18:48, 0] libsmb/nmblib.c:834(send_udp)
Feb 22 03:18:48 iwa nmbd[25935]: Packet send failed to 192.168.11.255(138) ERRNO=Invalid argument

Feb 22 03:23:19 iwa nmbd[25935]: [2015/02/22 03:23:19, 0] libsmb/nmblib.c:834(send_udp)
Feb 22 03:23:19 iwa nmbd[25935]: Packet send failed to 192.168.11.255(137) ERRNO=Network is unreachable
Feb 22 03:23:19 iwa nmbd[25935]: [2015/02/22 03:23:19, 0] nmbd/nmbd_packets.c:158(send_netbios_packet)
Feb 22 03:23:19 iwa nmbd[25935]: send_netbios_packet: send_packet() to IP 192.168.11.255 port 137 failed
Feb 22 03:23:19 iwa nmbd[25935]: [2015/02/22 03:23:19, 0] nmbd/nmbd_namequery.c:244(query_name)
Feb 22 03:23:19 iwa nmbd[25935]: query_name: Failed to send packet trying to query name WORKGROUP<1d>

Feb 22 03:28:20 iwa nmbd[25935]: [2015/02/22 03:28:20, 0] libsmb/nmblib.c:834(send_udp)
Feb 22 03:28:20 iwa nmbd[25935]: Packet send failed to 192.168.11.255(137) ERRNO=Network is unreachable
Feb 22 03:28:20 iwa nmbd[25935]: [2015/02/22 03:28:20, 0] nmbd/nmbd_packets.c:158(send_netbios_packet)
Feb 22 03:28:20 iwa nmbd[25935]: send_netbios_packet: send_packet() to IP 192.168.11.255 port 137 failed
Feb 22 03:28:20 iwa nmbd[25935]: [2015/02/22 03:28:20, 0] nmbd/nmbd_namequery.c:244(query_name)
Feb 22 03:28:20 iwa nmbd[25935]: query_name: Failed to send packet trying to query name WORKGROUP<1d>

Feb 22 20:34:22 iwa nmbd[1257]: [2015/02/22 20:34:22, 0] nmbd/nmbd.c:330(reload_interfaces)
Feb 22 20:34:22 iwa nmbd[1257]: reload_interfaces: No subnets to listen to. Waiting..

エラーなどが出力されてはいます。ここらへんも何かしら影響があるのかもという感じです。
loglevelをdebugなどに変更して、追っていくのもありだとは思います。
気が向いたらやってみようと思います。
もしくは、nmbdが落ちるのは再現性があるので、サポートに一旦振ってしまうのもありかもしれませんね。

今のところ、このHUBの電源を落として、数時間後にnmbdが落ちる件については、
このスレッドのメインで言われている件と、あんまり関係性がないのではないかと思っています。関係性がないと否定しきれるわけではないので、片隅においておく感じなのですが。
あんまり関係性がない考える理由は、1点だけで合理的だと思わせるほどでもないのです。

1点とは、以前、スレッドのメインで言われている件と思われる症状に出くわした時のパケットキャプチャなのですが、


TCP Previous segment not capturedとか出ていて、RDNにおいては、Kernelからのエラーも出ていないことを考えるとTCP Segment OffloadでNICに渡した時におかしくなっているように思える点です。

この症状が頻発するのであれば、ethtoolでTSOをoffにしたり試してみるのもありだとは思います。

[root@iwa ~]# ethtool -k eth0
Offload parameters for eth0:
Cannot get device flags: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off

デフォルトでは、tcp-segmentation-offload: onのようです。

このスレッドのメインで言われている件については、再現性が低いので究明するのも限界近いなのかなとも思いつつあります。

投稿者:kens  投稿日時:2015/03/25 00:37 親投稿 - 子投稿.1 No.78

Takeshichさん

以前、不具合に悩まされていたときに比べ発生頻度は減っていますが、
今でも1週間に一度程度、RDNに接続できなることがあります。

今回、接続できなくなったときに
1)RDNに刺さっているネットワークケーブル抜(15秒)挿
を試したところRDNへの接続が回復しました。

2)のログに関しては特に該当箇所は見当たりませんでした。
/var/log/messages

投稿者:たく  投稿日時:2015/03/25 01:05 親投稿 - 子投稿なし No.80

kensさん

差し支えなければ、下記情報を頂けないでしょうか。
1.PC(OS)
2.ルーター
3.回線(NTT光など)
4.接続出来なかったサービス(http,DLNA,SAMBA,telnetなど)
5.何か気が付いた点など

お手数ですが、ご協力頂けると助かります。

投稿者:Takeshich  投稿日時:2015/03/25 22:34 親投稿 - 子投稿なし No.79

kensさん

情報ありがとうございます。
症状はその後も出てたのですね。

TSOをoffにするのを試されたら如何でしょうか?
試してみたところGigaな構成だとRDNのoutboundでパフォーマンスの低下は見られます。
nicを再起動することでデフォルトに戻ってしまいます。

方法はethtool tsoなどで検索すればみつかると思います。

投稿者:kens  投稿日時:2015/03/26 00:20 親投稿 - 子投稿.1 No.81

RDN本体をリセットしたのが運の尽き。
↓で表示されるパスワードでrootでのログインができなくなってしまいました。

od -j 0xa3f006 -N 16 --string /dev/mtd1|awk '{print $2}'
od -j 0xa3f806 -N 16 --string /dev/mtd1|awk '{print $2}'

パトラッシュ、ボクはもう疲れたよ

投稿者:たく  投稿日時:2015/03/26 00:59 親投稿 - 子投稿なし No.83

kensさん

お疲れさまです…
前回と同じパスワードなので、メモとか残っていませんか?

投稿者:え?  投稿日時:2015/03/26 01:26 親投稿 - 子投稿なし No.84

本家の履歴だと、前回パス変わったときと同じ文言が変更履歴にあるのですよね。
あと、元から、「リセットすると」確かパス変わってた気がします。

ですから、差分を取って追わないとダメなんじゃないかと。
そもそも、表示されなくなったって人も居て、挙動にバラつきがあるなら、アップデートがきちんと各々の元で出来てるのかが微妙な雰囲気もあります。

作業したい人は「リセット」はちょっと気をつけたほうがいいかもしれませんね。

一応「以前の」アレとかも試してみるのは手かもしれませんが…試しましたよね。やっぱり。

投稿者:たく  投稿日時:2015/03/26 01:44 親投稿 - 子投稿なし No.85

リセットって本体後部でのリセットの事だったのかな?
再起動と勘違いしてしまった。

FWアップデート時にパスワードはリセットされるので、もう一度上書きアップデートすれば前回と同じ初期パスワードにリセットされるんじゃないかな?

ちなみに、Pythonの権限が変更されたので、rootでないと表示されません。

投稿者:Takeshich  投稿日時:2015/03/26 09:15 親投稿 - 子投稿なし No.82

kens さん

>RDN本体をリセットしたのが運の尽き。
>↓で表示されるパスワードでrootでのログインができなくなってしまいました。
>od -j 0xa3f006 -N 16 --string /dev/mtd1|awk '{print $2}'

ログインできるかできないかは、
openssl passwd -1 -salt "ソルト" "出力された文字列"
で生成されるハッシュ値と
/etc/shadowにあるハッシュ値が同一になるかならないかで判断できます。

同一にならないのであれば、設定されたパスワードと出力された文字列は違うということはわかります。

更新前にさらっと確認した時は、パスワードは前と同じになるように見えていました。
rootのパスワードを変更するところは、
echo root:hogehoge |chpasswd
な感じに変わっていたなぁという記憶です。

telnetでrootな状態なままファームウェアを更新して、更新後にrootのパスワードを変更してしまっているので、どういう動きだったのかは追えていません。残念ながら。

投稿者:kens  投稿日時:2015/03/26 23:35 親投稿 - 子投稿なし No.86

たくさん

FWの上書きアップデートでrootでログインできるようになりました。
ありがとうございました。助かりました。

遅ればせながら前回の質問の回答をいたします。

1.PC(OS) Windows7 Pro64 SP1、Windows8は有線接続(GbE)
その他、スマホ、PlayStation3、プリンタ等が無線で接続されます。
2.ルーター NEC AtermWR8700N
3.回線 JCOM(ケーブル)
4.接続出来なかったサービス http,DLNA,SAMBA,telnet 次回起きたときに詳しく見てみます
5.何か気が付いた点など ログは流れていませんでしたが、知識不足で内容はよくわからないです。

頻度的には1週間程度で起こるので、次回起きたときにまた色々試してみます。

投稿者:たく  投稿日時:2015/03/28 08:02 親投稿 - 子投稿.1 No.87

kensさん

情報ありがとうございます。

こちらのスレッドでもkensさんと同様な症状が起こっています。
http://bbs.ioplaza.jp/forum/index.php?topic_id=2669
kensさんの情報も併せて検証してみますね。

次回起きた時には、nas-service.logも見てみてもらえますか?
cat /var/log/nas-service.log

投稿者:Takeshich  投稿日時:2015/03/29 15:16 親投稿 - 子投稿なし No.88

たくさん

>次回起きた時には、nas-service.logも見てみてもらえますか?

そういえば、見てなかったと思って、問題が起きた時のを保存してあったで見てみました。
問題が起きたと思われる時間には、何も出てませんでした。

エラーはあったのですが、シリアル接続して、ifdown eth0 ;ifup eth0したタイミングで
Exception: [Errno 22] Invalid argument
Traceback (most recent call last):
File "/usr/bin/nas-service", line 336, in service
_service()
File "/usr/bin/nas-service", line 422, in _service
ns.link_status = link_status = getlinkstatus()
File "/usr/bin/nas-service", line 398, in getlinkstatus
line = pi.readline()
IOError: [Errno 22] Invalid argument

というのは出ていました。
linkstatusを得るために参照する/sys/class/net/eth0/carrierが参照できなかったためだと思います。

シリアルで接続して、NICを再起動すると出ると思いますが、検証はしていません。

投稿者:たく  投稿日時:2015/03/29 17:13 親投稿 - 子投稿.1 No.89

Takeshichさん

>linkstatusを得るために参照する/sys/class/net/eth0/carrierが参照できなかったためだと思います。

もしかして、この時のネットワークの設定はDHCPでしたか?
以前No.65でDHCP Power OFF → ON でnas-service.log に同様のLogが残っていました。
この後はnas-serviceも止まってるみたいなのでNICのリセットもかからないので、ケーブル抜き差しでも回復しないかもしれません。

Power OFF時にcarrierファイルが消えてしまうのですが、ファイル有無確認しないでreadlineするというのは…(本家は知ってるみたいだけど…)
一度でもリンクアップしていたら、消えることはないと思ったのですが
消える、アクセス出来ない様なケースが存在すると通信が不安定になるのかな?

投稿者:Takeshich  投稿日時:2015/03/29 20:11 親投稿 - 子投稿なし No.90

たく さん

>もしかして、この時のネットワークの設定はDHCPでしたか?

いえ、固定IPアドレスですね。

>一度でもリンクアップしていたら、消えることはないと思ったのですが
>消える、アクセス出来ない様なケースが存在すると通信が不安定になるのかな?

シリアル接続して、ifdown eth0してみました。
エラーは出ました。
その時に
cat /sys/class/net/eth0/carrier
したら、
cat: /sys/class/net/eth0/carrier: Invalid argument
と帰ってきました。ファイルはあります。

再度ifup eth0をして、
今度は、ケーブルだけ抜いてみました。
その時に
cat /sys/class/net/eth0/carrier
したら、
0
と帰ってきました。

つまり、/sys/class/net/eth0/carrier
は、活線というか通電?の状態を示し、当たり前ですが、インターフェイスがダウンしている状態では、そもそも参照できないもののようです。初めて知りました。

/usr/bin/nas-serviceのエラーが出るところの処理は、どういう状態になるのを想定して、何のためにしているのか、よくわからないですね。

投稿者:たく  投稿日時:2015/04/01 12:15 親投稿 - 子投稿.1 No.91

Takeshichさん

最近、私の方でも以下メッセージがLogに出るようになったので…
sockproxy-daemo: page allocation failure. order:1, mode:0x20

「nas-sockproxy」なのかな~と軽い気持ちで見てみたら
[root@ROCKDISK01 ~]# rpm -qa |grep nas-sockproxy
nas-sockproxy-20120530-1.noarch

古い… 「nas-sockproxy-20121026-1.noarch」のはずじゃ。。。
この1号機は、2013年末に購入して随時バージョンアップして来たんですが
確認出来る範囲では、このパッケージを含むものがみつからなかった。

Ver20121206 あたりで更新されたんではと思うけど「Portal Server」が使えなくなるぐらいだから、killして様子見る事にしました。

>/usr/bin/nas-serviceのエラーが出るところの処理は、どういう状態になるのを想定して、何のためにしているのか、よくわからないですね。
 /sys/class/net/eth0/carrier の情報は活線状況の確認で
 NICからの情報(def getlink)で実際の通信状況見てると思われる。
 NICが調子悪かったらリセットする仕組みのようだけど、ケーブル刺さってないのにリセットしても意味が無いと思うのは私だけだろうか…
 HUBやケーブルに異常がないのに、リセットを繰返す場合は何か他の要因があるのかもしれませんね。

投稿者:Takeshich  投稿日時:2015/04/01 20:52 親投稿 - 子投稿.1 No.92

たくさん

>NICが調子悪かったらリセットする仕組みのようだけど、ケーブル刺さってないのにリセットしても意味が無いと思うのは私だけだろうか…

たくさんと同じ疑問だったので、
「何のためにしているのか、よくわからない」というコメントをしました。

週末にNICのドライバ関連なのかなぁと当たりをつけて、それっぽいソースとか探して
軽くのぞいてみました。

兄弟?製品と思われるDC01の開示している情報をあたってみると

http://silverstone-usa.com/download/D ... NAND_SDK_20110609.tar.bz2
の中にNICのドライバ(gmac)のソースと思われるものがありました。
また、
Documentation->NAS 7820 SDK Release Note 13-8-2010.docx

KNOWN BUGS
Limitation - Under heavy load with multiple clients and some 100Mbit switches occasional connection errors occur on 100Mbit
とありました。

RDNでは、これが改修されているNICのドライバを使用しているかについては不明です。
これとの関連性はGigaなネットワークにして検証してみても良いかもしれません。

また、
kernelにgmacとして、NICのドライバが組み込まれているようです。(lsmodしても出てこない)

入っているのは、
[takeshich@iwa ~]$ ls -ls /lib/firmware/2.6.31-INXTRON/gmac_copro_firmware
24 -r--r--r-- 1 root root 21490 2010-07-23 08:43 /lib/firmware/2.6.31-INXTRON/gmac_copro_firmware

サイズは、DC01のNAS_AP_Team_NAND_SDK_20110609.tar.bz2にあるのと同サイズのようです。
更にタイムスタンプもNAS 7820 SDK Release Noteより古いです。

また、RockDiskNextでは、SDKは、DC01のとちょっと違ってNAS_AP_Team_NAND_SDK_20110801が使われているようです。

[takeshich@iwa ~]$ ls -la /lib/modules/2.6.31.14-fast-20110801-fan/
total 60
drwxr-xr-x 3 1003 users 1480 2011-08-29 12:56 .
dr-xr-xr-x 3 root root 248 2011-09-16 14:25 ..
lrwxrwxrwx 1 1003 users 66 2014-05-05 10:18 build -> /mnt/hdd/plx7821/NAS_AP_Team_NAND_SDK_20110801/SDK_3.0.0-sources/b
drwxr-xr-x 5 root root 352 2011-08-29 12:56 kernel
-rw-r--r-- 1 root root 398 2011-08-29 12:56 modules.alias
-rw-r--r-- 1 root root 370 2011-08-29 12:56 modules.alias.bin
-rw-r--r-- 1 root root 69 2011-08-29 12:56 modules.ccwmap
-rw-r--r-- 1 root root 499 2011-08-29 12:56 modules.dep
-rw-r--r-- 1 root root 996 2011-08-29 12:56 modules.dep.bin
-rw-r--r-- 1 root root 73 2011-08-29 12:56 modules.ieee1394map
-rw-r--r-- 1 root root 141 2011-08-29 12:56 modules.inputmap
-rw-r--r-- 1 root root 81 2011-08-29 12:56 modules.isapnpmap
-rw-r--r-- 1 root root 74 2011-08-29 12:56 modules.ofmap
-rw-r--r-- 1 root root 318 2011-08-29 12:56 modules.order
-rw-r--r-- 1 root root 99 2011-08-29 12:56 modules.pcimap
-rw-r--r-- 1 root root 43 2011-08-29 12:56 modules.seriomap
-rw-r--r-- 1 root root 896 2011-08-29 12:56 modules.symbols
-rw-r--r-- 1 root root 1578 2011-08-29 12:56 modules.symbols.bin
-rw-r--r-- 1 root root 1456 2011-08-29 12:56 modules.usbmap
lrwxrwxrwx 1 root root 66 2014-05-05 10:18 source -> /mnt/hdd/plx7821/NAS_AP_Team_NAND_SDK_20110801/SDK_3.0.0-sources/b

gmac自体はGPLなので、当該ドライバのソースをIO-Dataがライセンスに従う意思があれば、開示請求し、開示はしてもらえるはずです。
NAS_AP_Team_NAND_SDK_20110609.tar.bz2の中のgmacのソースを見ると他のところで公開されているソースとは違う箇所があり、
その違う箇所は、TCPのtxのみoffloadをするようにしていると思われます。
私の環境で問題が発生した際は、ログよりUDPの受信は可能だったように思える点などから、ここらへんが怪しいようにも思えます。

ただ、「ドライバのデバッグをユーザがするのか?」という疑問も浮かんでもいます。。。
「メーカー(PLXとかinXtron)がする範囲ではないか?」

また、DC01の開示している情報でクロスコンパイル環境も作れました。
debianで作ってしまったので、rpmbuildとかはできないので、そのうちfedoraとかでやってみようかなとも思っています。

投稿者:え?  投稿日時:2015/04/01 22:01 親投稿 - 子投稿なし No.93

基本的には「メーカー側は仕様として明示した性能維持がされていれば」責は負わない形なのが普通なので、「実際に再現する瑕疵」という形にしないと、直してくれる可能性はないかもしれませんし、直せないなら、返金返品くらいは受けてくれる可能性があるかもしれません。
たぶん「こう直せ」といわれても、知らないっていわれてしまいます。

デバッグをユーザーがする必要はないでしょうね。

開示した情報が本来正しければ、ドライバもLinuxカーネルに含まれる形になっていそうなのですが。

ただ、再現性があって問題があっても、もう作るだけ作ってしまって在庫限りの商品の為にはがんばってくれるとは思えませんね。

というか、このシステム、アップデート漏れとか、破損とか大丈夫なんだろうか。まさかとはおもうけどもその辺りの不整合で困ってる人が居るかもしれない気がしなくもないのだけども。

ARMV5のパッケージじゃなくて、リビルドしたら、少しは最適化利く要素ないのかなぁとおもうけども、VFPはこの石なさそうですしねぇ。

投稿者:たく  投稿日時:2015/04/02 02:21 親投稿 - 子投稿なし No.94

Takeshichさん

>Limitation - Under heavy load with multiple clients and some 100Mbit switches occasional connection errors occur on 100Mbit
 これには気がつかなかった…
 100BASEの環境だと起こるのかな?どの程度のエラーなのか書いてあれば助かったんだけど…
 少し100BASEのみの環境でみてみます。

>ただ、「ドライバのデバッグをユーザがするのか?」という疑問も浮かんでもいます。。。
>「メーカー(PLXとかinXtron)がする範囲ではないか?」
 私もそう思いますよ。
 メーカー側が途中経過なり情報を出してくれれば良いのですが、認識してるのかどうかも判らないので、つい出来る範囲でと思って…
 
>また、DC01の開示している情報でクロスコンパイル環境も作れました。
 私もubuntu(VirtualBox)にて、テストでuImageとか一通り作ってはみたのですが、ちょっと面倒でした。

投稿者:kens  投稿日時:2015/04/03 00:04 親投稿 - 子投稿.1 No.95

前回の投稿から1週間が経ち、やはり症状が再現しましたので報告します。
今回は残念ながらネットワークケーブル抜挿で復帰しませんでした。

■PC (問題が発生した時の構成)
Windows7 Pro64 SP1 自作 有線GbE接続 IP固定(ルータによるDHCP固定割当、PC側はDHCP)
Windows8 自作 有線GbE接続 IP固定(ルータによるDHCP固定割当、PC側はDHCP)

■RockDiskNext (問題が発生した時の構成)
 起動サービス:
 ・Portal Server ON
 ・SAMBA ON
 ・メディアサーバー ON
 ・AFP ,NFS ,FTP,iTunes 全てOFF
 ・E-mail ,ダウンローダー ,サムネイル 全てOFF

 IPアドレス設定(自動(DHCP)):但しルータによるDHCP固定割当
 通信速度: 未測定

 問題発生時の状況(問題が発生する時、確認したサービスの状況):
 ・myisharing Web:Device offline, Androidアプリ:ログイン不可
 ・SAMBA 接続不可
 ・メディアサーバ 接続不可
 ・telnet 接続不可
 ・ping 通ったり、通らなかったり(確立約50%)

■Network
 使用ルータ:NEC AtermWR8700N (FW 1.0.17)
 上位網:CATV(JCOM)
 利用プロトコル:IPv4のみ(IPv6ブリッジ OFF)
 
 RockDiskNext接続経路情報:ルーター -> RockDiskNext
 PC接続経路情報:ルーター ->スイッチングHUB(GbE)-> PC
 
 ネットワークに接続している機器(差し支えない範囲で):
 ルータとIEEE802.11a接続しているNEC WL300NE-AG(イーサネットコンバータ)
 にスイッチングHUBを介してPlayStation3、nasneを接続
 無線で不定期にスマホ、プリンタ、デジカメ等が接続されます

■問題の症状
 問題の再現頻度:約1週間
 RockDiskNextの電源ONから問題の再現まで経過時間:約1週間程度
 主な症状:
  ・各種サービスに接続できない
 問題の再現条件:
  ・電源ONからの放置

■復旧方法
 RDNに刺さっているネットワークケーブル抜(15秒)挿:症状変わらず(pingのみ50%通る)
 電源OFF(電源ボタン5秒押)→ON:不具合解消

■復旧後のログ
/var/log/messages:ログ流れ

/home/.nas/minidlna.log
[2015/04/01 22:46:00] upnphttp.c:997: warn: HTTP Connection closed unexpectedly ←接続できていた
[2015/04/02 23:47:27] minidlna.c:154: warn: received signal 15, good-bye ←復旧のため電源OFF

/var/log/nas-service.log
INFO:nas-service:WAN IP changed, updating dyndns IP address: 42.xxx.xxx.xxx
INFO:nas-service:LAN IP changed, reporting it to server

■その他
TSO offは未実施
rx-checksumming: on
tx-checksumming: on
tcp-segmentation-offload: on

投稿者:Takeshich  投稿日時:2015/04/03 09:02 親投稿 - 子投稿なし No.96

kensさん

情報ありがとうございます。

>今回は残念ながらネットワークケーブル抜挿で復帰しませんでした。

RockDiskNextで、
>IPアドレス設定(自動(DHCP)):但しルータによるDHCP固定割当

と設定されているので、nas-serviceによるNICの再起動は行われないはずです。(dhclientが起動している)
そのためケーブル抜挿では通信が回復しなかったものと思われます。
以前、ケーブル抜挿で通信が回復したのは、IPアドレスをDHCPではなく、
手動で固定IPアドレスに設定していたのではないでしょうか?

ケーブル抜挿で通信が回復する状態にしないと再起動で/var/log/のログがクリアされてしまって、
症状が起きている時のログが残念ながら確認できないです。。。
nas-service.logも再起動後のログだと思います。

お手数おかけしますが、RockDiskNextのIPアドレス設定を手動で設定して、
症状が出た場合にケーブル抜挿で通信が回復させ、ログを確認ください。
その際に
症状が出たと確認した後にPCを再起動してみてください。その時に/var/log/messagesに
avahi-daemon[938]: Invalid query packet.
avahi-daemon[938]: Invalid query packet.
avahi-daemon[938]: Invalid query packet.
のようなものが出力されるか確認いただきたいです。

今後、TSO offも協力いただきたいのですが、可能でしょうか?

あと、もう一点確認させてください。
私のところで症状は、PCを1台起動し、さらにもう一台起動
その後最初に起動した1台をシャットダウンし、あとから起動したPCを使用している際に
発生しました。同じようにしても症状は再現しないのですが、
kensさんの環境では、おそらくその症状が発生したと思われる頃に複数台のPCを
起動しているとかありますか?

投稿者:たく  投稿日時:2015/04/04 08:50 親投稿 - 子投稿.1 No.97

「sockproxy-daemo」の後 「/var/log/messages」に「swapper」と「kswapd0」でも「page allocation failure」が出ていました。
あまり詳しく理解はしていないのだけど、「tcp_v4_syn_recv_sock」があることから受信したパケットをNICからカーネルに渡す処理の途中かな?
メモリの割当に失敗してる様に見えるから、この受信した「SYN」は見た目ドロップされた事になるのかな?
これが続くと止まる現象が顕著になるかもしれないので暫くこのまま稼働させてみようと思う。

swapper: page allocation failure. order:1, mode:0x20
[<c0035ce8>] (unwind_backtrace+0x0/0xe8) from [<c0088598>] (__alloc_pages_nodemask+0x468/0x558)
[<c0088598>] (__alloc_pages_nodemask+0x468/0x558) from [<c00a7dfc>] (cache_alloc_refill+0x2f4/0x58c)
[<c00a7dfc>] (cache_alloc_refill+0x2f4/0x58c) from [<c00a824c>] (kmem_cache_alloc+0xb4/0xc0)
[<c00a824c>] (kmem_cache_alloc+0xb4/0xc0) from [<c0322568>] (sk_prot_alloc+0x28/0xec)
[<c0322568>] (sk_prot_alloc+0x28/0xec) from [<c0322cd0>] (sk_clone+0x18/0x298)
[<c0322cd0>] (sk_clone+0x18/0x298) from [<c0355810>] (inet_csk_clone+0x14/0x90)
[<c0355810>] (inet_csk_clone+0x14/0x90) from [<c036a694>] (tcp_create_openreq_child+0x18/0x344)
[<c036a694>] (tcp_create_openreq_child+0x18/0x344) from [<c0368f10>] (tcp_v4_syn_recv_sock+0x3c/0x1ac)
[<c0368f10>] (tcp_v4_syn_recv_sock+0x3c/0x1ac) from [<c036ac8c>] (tcp_check_req+0x2cc/0x444)
[<c036ac8c>] (tcp_check_req+0x2cc/0x444) from [<c0368648>] (tcp_v4_do_rcv+0x120/0x228)
[<c0368648>] (tcp_v4_do_rcv+0x120/0x228) from [<c036a3e0>] (tcp_v4_rcv+0x630/0x7f4)
[<c036a3e0>] (tcp_v4_rcv+0x630/0x7f4) from [<c034b3d8>] (ip_local_deliver_finish+0x70/0x1ec)
[<c034b3d8>] (ip_local_deliver_finish+0x70/0x1ec) from [<c034b108>] (ip_rcv_finish+0x144/0x3a4)
[<c034b108>] (ip_rcv_finish+0x144/0x3a4) from [<c032e50c>] (netif_receive_skb+0x274/0x334)
[<c032e50c>] (netif_receive_skb+0x274/0x334) from [<c02ce5d4>] (poll+0x3fc/0xa04)
[<c02ce5d4>] (poll+0x3fc/0xa04) from [<c0331434>] (net_rx_action+0x90/0x1a4)
[<c0331434>] (net_rx_action+0x90/0x1a4) from [<c0057900>] (__do_softirq+0xa8/0x13c)
[<c0057900>] (__do_softirq+0xa8/0x13c) from [<c0057c3c>] (irq_exit+0x7c/0x98)
[<c0057c3c>] (irq_exit+0x7c/0x98) from [<c0030060>] (asm_do_IRQ+0x60/0xb0)
[<c0030060>] (asm_do_IRQ+0x60/0xb0) from [<c0030bd8>] (__irq_svc+0x38/0xc0)
Exception stack(0xc0593f60 to 0xc0593fa8)
3f60: 60000013 00000000 00000000 c0592000 c0592000 c05b9ad0 c0598080 00004000
3f80: c05c7ae8 c0597e4c c0028000 c00297a0 00000000 c0593fa8 c0032124 c0032128
3fa0: 60000013 ffffffff
[<c0030bd8>] (__irq_svc+0x38/0xc0) from [<c0032128>] (default_idle+0x24/0x2c)
[<c0032128>] (default_idle+0x24/0x2c) from [<c0031f9c>] (cpu_idle+0x60/0x94)
[<c0031f9c>] (cpu_idle+0x60/0x94) from [<c0008c20>] (start_kernel+0x2c8/0x3b8)
[<c0008c20>] (start_kernel+0x2c8/0x3b8) from [<60008084>] (0x60008084)
~以下 省略~

「order:1」なので割当てたかったのは、1ページらしい
[root@ROCKDISK01 ~]# getconf PAGE_SIZE
4096

1ページ=4kバイト なので、最小の4kバイトも割当てられない状況だった…?
このメッセージの続きにMem-infoがあり
Normal free:2708kB min:2036kB low:2544kB high:3052kB active_anon:17628kB inactive_anon:18260kB active_file:22960kB inactive_file:141024kB unevictable:13388kB present:260096kB pages_scanned:0 all_unreclaimable? no

「free:2708kB」と4k以上あるけど、瞬間的に4k以下になってたと思われる。
本当に足りなかったら、Out Of MemoryになりOOM Killerが働くと思うので、キャッシュからの割当てが間に合わなかったのかな?

色々、検索してみたところ「vm.min_free_kbytes」を少し増やしてクッションにしてみるのが妥当と思えた。
2日ほどテストしてみてエラーは出なかったのでメモリ管理設定の問題ではないかと思います。
高いビットレートのものをストリーミング再生したりしてると、発生しやすいそうです。
発生時は、平均8M程度のビデオをSAMBA経由でエンドレス再生させてました。


以下、検証中の環境です。
■PC (問題が発生した時の構成)
 OS(使用OSとバージョン): Windows 8.1 with Bing
 機器(メーカー名・型番): ECS LIVA-BLACK64GB(LIVA-C0-2G-64G-W-OS)
 ネットワーク接続(有線・無線): 有線
 ネットワークアダプター(デバイス名): Realtek 8111GS ギガビットLAN(Realtek PCIe GBE Family Controller)
 IPアドレス設定(自動(DHCP)・固定): DHCP
通信速度(判るなら): 100Mbps
 
■RockDiskNext (問題が発生した時の構成)
 起動サービス:
 ・Portal Server
 ・SAMBA ,NFS ,FTP ,メディアサーバー ,iTunes
 ・設定を明示的にしないデフォルトサービス

 IPアドレス設定(自動(DHCP)・手動): DHCP
 通信速度(判るなら): 100Mbps

 問題発生時の状況(問題が発生する時、確認したサービスの状況):
  ・pingの疎通確認: 応答あり
  ・管理画面: 応答あり
  ・Sambaサーバ: 応答あり
  ・メディアサーバ: 応答あり

■Network(検証環境)
 使用ルータ(メーカー名・型番): BUFFALO WHR-G301N(MODE:ルータ,WAN:DHCP)
 上位網(通信網 例:フレッツ光,CATV): アイ・オー・データ WN-AC1167DGR -> フレッツ光ネクスト
 利用プロトコル(ひかりTVなどを使用している場合は、IPv4/IPv6): IPv4のみ
 
 RockDiskNext 経路情報: ルーター -> RockDiskNext
 PC 経路情報: ルーター -> PC
 
 ネットワークに接続している機器(差し支えない範囲で):
  ・なし

投稿者:Takeshich  投稿日時:2015/04/04 11:37 親投稿 - 子投稿なし No.98

たくさん

>「sockproxy-daemo」の後 「/var/log/messages」に「swapper」と>「kswapd0」でも「page allocation failure」が出ていました。
>あまり詳しく理解はしていないのだけど、「tcp_v4_syn_recv_sock」があることから受信したパケットをNICからカーネルに渡す処理の途中かな?
>メモリの割当に失敗してる様に見えるから、この受信した「SYN」は見た目ドロップされた事になるのかな?
>これが続くと止まる現象が顕著になるかもしれないので暫くこのまま稼働させてみようと思う。

たぶん、NICのRXの割り込み処理の際にメモリの割当に失敗しているんでしょう。
だいぶ前にいろいろ調べたけど、メモってなかったのできちんと説明できない^^;
去年の11月ぐらいにすごく気になって、いろいろやってみたのですが、結局その時点では止まる現象の発生には至りませんでした。

なお、今年の2月に止まる現象が再現した際のログにはこのエラーはありませんでした。
ただ、だからと言って関連性がないと否定するわけではないです。
ホント、よくわからないって感じです。

>色々、検索してみたところ「vm.min_free_kbytes」を少し増やしてクッションにしてみるのが妥当と思えた。
>2日ほどテストしてみてエラーは出なかったのでメモリ管理設定の問題ではないかと思います。
>高いビットレートのものをストリーミング再生したりしてると、発生しやすいそうです。
>発生時は、平均8M程度のビデオをSAMBA経由でエンドレス再生させてました。

私もエラーを出さないようにするには、vm.min_free_kbytesを増やしました。
そもそも物理メモリが少ないので、難しい問題でもありますね。
発生しやすさの点は、thumnailやダウンローダーを使用し、minidlnaのスキャンを繰り返したりしていると結構な頻度(2時間に1度ぐらいだったと思う。)でpage allocation failureが出ていました。おそらくメモリを多めに使う処理を繰り返し行うと発生しやすいように思えました。

投稿者:たく  投稿日時:2015/04/04 12:59 親投稿 - 子投稿なし No.99

Takeshichさん

私も書いてるうちに、ちょっと違うかなと思ってきたんですが
とりあえず情報までって事で…

やはり同じような状態にならないと、原因は判らないですね。

投稿者:kens  投稿日時:2015/04/04 17:26 親投稿 - 子投稿.1 No.100

Takeshichさん

すみません。私の場合、前提として問題発生した時点での状況は把握できておりません。
いつから問題が発生しているのかは不明ですが、ほぼ毎日DLNAで音楽を聴いたり
外出先からのmyisharingで接続したりしていますので、接続できなくなってから気付くというパターンです。
RDN接続中に突然接続できなくなるというようなことはありません。

PCはWindows7の方は平日毎朝ラジオ番組を録音するためにスケジュール起動(休止状態からの復帰)しています。
Windows8の方は毎日起動しています(休止状態からの復帰)。

IPアドレスについては前回症状が発生したときからRDNとルータのDHCP設定は変えていません。
本日よりルータのDHCP固定割当からRDNを外し、RDN側でIP固定(手動)設定して様子を見てみます。

> 今後、TSO offも協力いただきたいのですが、可能でしょうか?

詳しくないので具体的なやり方(戻し方含む)を教えていただければ協力できます。

投稿者:Takeshich  投稿日時:2015/04/04 20:30 親投稿 - 子投稿なし No.101

kensさん

>すみません。私の場合、前提として問題発生した時点での状況は把握できておりません。

いろいろと無理を言ってしまい、こちらこそすみません。
明示的にRDN接続中に問題が発生したことはなく、気づいたらつながらない状態になっていることに気づくということ理解しました。

>IPアドレスについては前回症状が発生したときからRDNとルータのDHCP設定は変えていません。

確認なのですが、以前ケーブルを抜挿して、通信が回復した際には
RDN側でIP固定(手動)設定ではなかったということでしょうか?
DHCPの設定でケーブルを抜挿して、通信が回復したということであれば、違う症状なのかもしれません。
念のため確認ですが、LANケーブルは付属のをお使いですか?
(付属のケーブル以外にしても発生するか切り分けたいという考えです)

>詳しくないので具体的なやり方(戻し方含む)を教えていただければ協力できます。

ありがとうございます。
もしかすると違う症状かもしれないので、方法は以下に記述しますが、すぐに行わなくても構わないです。
余裕があるときでかまいません。

注意点としては、tsoをoffにするとRDNからsambaでファイルを取得する際にGigaなネットワークだと少々パフォーマンスが下がります。大きいファイルを取得する際に若干時間がかかるかもという程度です。

telnetでrootでログインして頂いて、

ethtool -k eth0

Offload parameters for eth0:
Cannot get device flags: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off

とすると現状が表示されます。

以下のコマンドを実行するとtsoがoffになります。
ethtool -K eth0 tso off

設定がされたか確認するには、
ethtool -k eth0

として、以下のように表示されると思います。

Offload parameters for eth0:
Cannot get device flags: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off

再起動すると設定はデフォルトに戻ると思います。
また、再起動せずに設定を戻すには、
ethtool -K eth0 tso on

設定が元になったか確認するには、
ethtool -k eth0

として、以下のように表示されると思います。
Offload parameters for eth0:
Cannot get device flags: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off

-Kが設定で
-kが確認です。
大文字と小文字に注意してください。

よろしくお願いします。

投稿者:kens  投稿日時:2015/04/04 22:27 親投稿 - 子投稿.1 No.102

Takeshichさん

> 確認なのですが、以前ケーブルを抜挿して、通信が回復した際には
> RDN側でIP固定(手動)設定ではなかったということでしょうか?

はい、LANケーブル抜挿で復帰できたときも
IPアドレス設定(自動(DHCP)):但しルータによるDHCP固定割当 にしていました。

LANケーブルは付属のケーブルを使用しています。

前回はLANケーブル抜挿1回目で復帰できました。
今回はLANケーブル抜挿3回試してみましたが、pingのみ50%通り、他のサービスには接続不可でした。

TSO off設定について詳細に説明してくださり、ありがとうございます。
TSO offの設定については今回のRDN側IP固定(手動)設定で接続できず不具合が発生したら、次回試してみようと思います。

投稿者:Takeshich  投稿日時:2015/04/04 23:06 親投稿 - 子投稿なし No.103

kensさん

>LANケーブルは付属のケーブルを使用しています。
>前回はLANケーブル抜挿1回目で復帰できました。
>今回はLANケーブル抜挿3回試してみましたが、pingのみ50%通り、他のサービスには接続不可でした。

私見ですが、本スレッドの症状とは別で、物理的なことが原因もありうるような気がします。
RDN側でIP固定(手動)設定にして、症状が出た際にケーブルの抜挿でも通信が回復しないのであれば、
・ケーブルを別のものと交換してみる。
・ルーターのHUBの有線LANポートを別のところに変えてみる。
また、念のため、
・IPアドレスがかぶっているのがないか調べてみてる。

上記を試してみることをおすすめします。

投稿者:kens  投稿日時:2015/05/04 21:04 親投稿 - 子投稿.1 No.104

Takeshichさん

前回の投稿から1ヵ月経ちました。
どうやら当方で起きていた接続できなくなる不具合は解消できたようです。
結論から申しますと、Takeshichさんのアドバイスのうち、

・ケーブルを別のものと交換してみる。

により解決したと思われます。
付属のLANケーブルの使用を止め、初期型PS3に付属してきたCAT6のケーブルに
交換てからは、この1ヵ月で接続できなくなる不具合は全く起きていません。

なんだ、原因はケーブルか。ということになりますが、ここに至るまでが長かった。
他の機器との相性もあるとは思いますが、最初から全く接続できないという状況ではなかったので、付属品であるLANケーブルを疑うに至りませんでした。

このスレではTakeshichさんをはじめ多くの方々にアドバイスをいただき、大変感謝しています。
ありがとうございました。

投稿者:Takeshich  投稿日時:2015/05/04 23:24 親投稿 - 子投稿なし No.105

kensさん

>どうやら当方で起きていた接続できなくなる不具合は解消できたようです。

お疲れ様でした。

>最初から全く接続できないという状況ではなかったので、付属品であるLANケーブルを疑うに至りませんでした。

中途半端な状態だと切り分けるのに時間がかかるので
切り分けに至るまで、大変でしたね。
解決したようで何よりです。

苦情入れてもいいかもしれませんね。

投稿者:たく  投稿日時:2015/05/04 23:43 親投稿 - 子投稿なし No.106

kensさん

付属のLANケーブルでしたか…
私は1か月ぐらいテスト時に使用してて問題が起きなかったんですが
時間あったら、確認してみようかな。

>なんだ、原因はケーブルか。ということになりますが、ここに至るまでが長かった。

本当にご苦労様でした。
とにかく、治ってよかったですね。

投稿者:たく  投稿日時:2015/05/05 11:58 親投稿 - 子投稿.1 No.107

今気になったので 付属のLANケーブル確認してみたら
「SFTP CAT.5E」
コネクタもシールドされてて、いいケーブルだけど…
コレってHUBとかもアース処理しとかないと駄目じゃなかったっけ?
普通のHUBやルータ使ってて、動作が不安定な人は
百均で売ってるLANケーブルと交換して切り分けてみると良いかも。

投稿者:え?  投稿日時:2015/05/06 12:41 親投稿 - 子投稿なし No.108

もしかするとOEM元のセットなのかもしれないです。
ケーブルを使うための条件はわからないのですが、ShareMAXでも、シールドされたコネクタのが入ってました。
わー、オマケのケーブルなのに頑張ったなーって思っただけで、取り回しめんどくさいんで、一度も使わず手元のcat5eのフラットケーブルを使ってますが、ソフトウェアに起因すると思われる変な挙動以外は問題は出てません。

実際問題として「付属のケーブルだと性能が発揮できない」とか「変更したら速くなった」とか、「音が良くなった()」と違って実際にベンチマークの値で出てしまってるケースも検索すると出てきたりもするので、高級感出そうとして頑張りすぎちゃって世間の民生機器と仲良くないセットになってるような気がしなくも無いです。確認はできてないので、見た目だけで加工がダメとか、そういうことかもしれませんが。

こんな理由で遅いなぁとか思われたり、エラー多いなぁって思われてる個体があったらちょっと可哀想ですね…。誤差ってレベルではなく、足を引っ張ってるケースがありそうな気はします。不安定以外でも、リンク速度が100BASEになってて遅いなんてケースもありそうなので、「安いからこんなもんかって見限ってる人」ももしかするとましになる可能性が無くも無いような。
理由があっての選択なのかどうかもわかりませんが、機器を選ぶなら、注釈くらいは必要かもしれませんね。

投稿者:Takeshich  投稿日時:2015/06/11 15:37 親投稿 - 子投稿.1 No.109

ちょっと、笑うしかないような対応をされたので、聞いてください。
もしよかったら、対応のアドバイスください。

GWの終わり頃に時間が経つとサーバがダウンするように見えるの件の障害報告と
それに関連しておそらくNICの可能性が高いので、NICのドライバのソースコードの開示を
依頼していたのだけど、サポートからなんと1ヶ月以上かけて

>恐れ入りますが、NICドライバについては、オープンソースに該当していないという
>状況から、提供は行っていない状況となります。

と回答をもらいました!

http://silverstone-usa.com/download/D ... NAND_SDK_20110609.tar.bz2
にある
SDK_1.1.0-sources.tar.gzのなかの
linux-kernel/drivers/net/gmac/
gmacのソースコードとRockDiskNextの出力メッセージを比較するとほぼ同じなのだけど
gmacのソースコードはGPLです。

また、そもそもkernelにドライバを組み込んで配布した時点で、そのソースコードはGPLと矛盾しないライセンス
じゃないといけないんじゃないしょうか。

GPLに沿っていない対応しかできないサポートなので、GPL違反がーともう強く言う気はあんまりないんだけど、
オープンソースではないということは、プロプライエタリなわけで、盗用も頭をちらつきます。
出力メッセージがほぼ同じになるって確率的におかしいですよね。。。
どう対応すればいいのかとっても迷っています。

目的は、ソースコードの開示。
とりあえずは、やる気が萎えなければ、ひどい状況を詳しくまとめて、ブログでも書きます。

投稿者:え?  投稿日時:2015/06/11 18:36 親投稿 - 子投稿なし No.110

 ある意味「自分達が売ってる物をちゃんと理解していれば」RockdiskNextのGPL由来のソースの扱いについて「明記がない」(未だにFAQにすらないよ?マニュアルの修正もないよ?元々最初にリリースするときにそれこそ自社製品のそれに倣ってコピペしとけば済んだことで瑕疵なんだから。会社の「信用」を維持したければとっととやってしまうほうが正しいと思う。)時点でお察しといえばお察しで、ばれなきゃ罪なんて存在しないことになるって会社だと「思われても良い」ってことなんだと思うのですが。
 …凄く簡単で、会社の看板の信用を「貶めない」様にするためには出来ることをするのは大事。

 SilverStoneだって、アレが最終的なバイナリと対応するソースだったとも思えませんし、使用、頒布したバイナリと一致するソースを「生き別れの兄弟姉妹一同誰も守ってない」様な気がしなくもないので、OEM元が人としてルールを守る気ねぇんだろうな…って思ったりはスルのです。
 そういう意味では、供給を受けた会社は普通は素直に提供と資料があるのにそれがないので、一定の同情はせざるを得ないのですが…ソースから生成したモジュールと、バイナリを比較して、表面的に出るもの以外に一致する点がどれくらいあるのか?という辺りは参考になるのかなぁと。多分新しい版のソースとか、修正なら一致する部分は残っていそうですし。バイナリとしてアドレスとかそういう部分を除いて同じコードのブロックがゴロっと出てきたらアウトでしょうね。

 まぁ、会社として「盗人」と思われてよければ、あんまり声を大きくして面倒くさがられるのも得るものはないんだけど、しらばっくれたりそもそも確認しない、調べる気がないってのは、「言われてないけど取引先とか、未来の取引先にそういう会社って見える」事を忘れてると、看板ごとこのご時勢消えることになりかねないってことでもあるのですが、信用って対応が遅いほど高く付くって事は考えないのでしょうかねぇ。
 だって、最初にうまいことやっとけば、そんなに請求する人も多くないものでしょうし、いちいち突かれて対応するコストも掛かりませんし、ほぼタダで、たまに酔狂なのにちょーだいっていわれる程度のコストでスクラッチから動くものを作ってテストも沢山やるってコストから逃げられるんですから、充分おいしいじゃないですか。
 逆にうまいことやらないから、おかしいよね?って突かれて人も時間も金も掛かるわけで、何でコストが掛かるけち臭いことしてんだかわからんです。

 というか、for Audioの中の人にちょっとは怒られてください。
 一応本家じゃそれなりにちゃんとしようとしてんのにお前らなにやってんだって謎回答するサポートと一緒に怒られてどういうものでどういう必要があるのか確認してください。
 むしろ、中の人は自分らのやってる仕事が無駄でばかばかしいって直販の人たちに言われてるのと同じなんですから怒ってください。
 専売モデルだけ該当部分がマニュアルから消えてるとかないよねw
 売ってる当事者だから、作ってるのウチじゃない…は通らないし、そういうところと契約書交わしちゃった責任はあるんだよなぁ。

投稿者:たく  投稿日時:2015/06/11 21:21 親投稿 - 子投稿.1 No.111

Takeshichさん

akitioやPLXがそう言ってきたの?ってIOに聞き返したくなりますね~
SDK自体がRDKの付属物なので、RDKのライセンスとGPLを混同してるのでは?

ルールやマナーに反するかもしれないけど、akitioとPLXに直接聞いてみるのはどうだろう。
IOは「オープンソースに該当していない」と言ってるけど、あなた方はどう思います?って


ここ最近他の人達からレスがなかったけど、まだサーバーダウンしてるのかな?

投稿者:Takeshich  投稿日時:2015/06/11 23:18 親投稿 - 子投稿.1 No.112

え?さん
たくさん

レスありがとうございます。

OEM元がひどくても、それがわかった時点で、正しい対応が取れない点で終わってますね。
なんかもう、明らかに戻ってくる回答が嘘で、さらにその嘘に嘘を重ねる回答になっていて
どこまで嘘ついてくれるか試そうかとも思ってしまうほどです。
NICのドライバはカーネルに組み込む形になっているので、kernelのイメージを自分で作成したのと
RDNに入っているのと比較ですかね。。。

>akitioやPLXがそう言ってきたの?ってIOに聞き返したくなりますね~
>SDK自体がRDKの付属物なので、RDKのライセンスとGPLを混同してるのでは?

もしかするとNICドライバから、キックするgmac_copro_firmwareと勘違いしているのかもしれないとも
考えたけど、普通に考えたらそうはならないと思います。
IOが頒布しているのだから、IOがソースコードを持っていなきゃいけないんですけど
持っていないような感じです。おそらく、inXtron(akitio)に確認しているんでしょうね。

>・Linux kernelはFedra 12を使用しております。
> 入手先はhttp://www.kernel.org/となり、バージョンは2.6.31となります。

と以前に回答されたので、

https://git.kernel.org/cgit/linux/kern ... .6.31.y&id=v2.6.31.14

を探しましたが、使用されているNICと思われるgmacのソースコードを見つけることはできませんでした。
ソースコードはどこにあるのでしょうか?
と質問したのだけど、回答までに1ヶ月ですからね。

もしかするとそのコミュニケーションがうまく行ってない可能性はあります。

>ルールやマナーに反するかもしれないけど、akitioとPLXに直接聞いてみるのはどうだろう。
>IOは「オープンソースに該当していない」と言ってるけど、あなた方はどう思います?って

gmacは、そのソースコードを見ると
Copyright (C) 2005 Oxford Semiconductor Ltd
となっているので、
PLX(前身がOxford Semiconductor)が著作権を持っていて、GPLとしているので、PLXは???となるでしょうね。
inXtron(akitio)が元凶ぽい。。。

RDN使用しているNASボードの製造元が著作権を持ち、GPLとしているものを
IOデータがオープンソースではないということで。。。?
おかしいですよね。

[root@iwa ~]# ethtool -i eth0
driver: GMAC
version: 1.0
firmware-version: 1.0
bus-info: AMBA

なんですよね。勘違いなのかなぁ。

まぁ、GPL的に言っても、

カーネルLinuxとリンクすることを意図した不自由なドライバを配布することはGPLに違反しますか?
http://www.gnu.org/licenses/gpl-faq.e ... #NonfreeDriverKernelLinux
http://www.gnu.org/licenses/gpl-faq.j ... #NonfreeDriverKernelLinux

はい。これは違反です。

みたいです。

投稿者:え?  投稿日時:2015/06/12 00:56 親投稿 - 子投稿なし No.113

基本的に、期待して良いことと駄目なことがあって、多分サポートは、FAQのコピペとか、操作の案内で終わるような内容に特化されてるんだと思います。
本来は、手に負えないってなったものは出来る人に回さないといけないのですが、インシデントの消化しか考えてないから解決じゃなくて言いくるめることを考えている。

…と考えると、他所で別商品に対して晒されて「酷くね?」ってなってる返事や、一部の問いあわせの返答に対する感覚とも一致します。
考えないで症状に近いものを適当に投げてきたな…ってことを言われたことは結構あります…。

普通は考えたり対処する時間が生まれるので、メールなどが一番正確でまともな回答があるのですが、インシデントの消化だけを目的にしてる場合、本来あげないといけない人がきちんと上げてない…どころかもしかするとその判断と言いがかりの判断すら付いてない可能性が有るように思います。
実際に対応してる人は、「上の人は違うって言ってるのにしつこいなぁ。」と適当な事を書いてるように思います。自分で調べて確認していれば、上の人にウチの対応おかしくないですかね?ほんとにこれ、ないんですか?って確認するんじゃないかと。…職業意識があればwでも、それも社外の人が多いでしょうしねぇ。

ですから、メールではなく、電話で、「地球の裏側と文通してるような中身で埒が明かない。責任者出してください」で行くしかないんじゃないでしょうか?リアルタイムなら保留にして業務終了までシカトとか流石にクレーム入れて良いでしょうしw少なくとも「まともな返事が返ってこない」のは問題ですし、不正直ですから、怒って良いところだと思いますし、別の部署で、「御社のソフトウェアはライセンスを守って作られていない可能性があり、本来の窓口はうそばかり並べる。申し訳ないがどこに問い合わせるべきか?」と確認してみるのも良いかもしれません。
少なくともこのあたりに「多分」あるから勝手に持ってけとか、最初からそんな返事してる時点で「条件守る気がない」んで、窓口が役に立たない、ちゃんと話しわかるヤツ出て来いで良いとも思います。わかってないか、適当なこと言って、誤魔化してるのが居るからこうなってるので。

それでもサポートとお話しするなら、ソースからバイナリ作って比較するしかないでしょうね。テキストで何かバイナリに埋まってれば比較の前に何かが見つかることもあるかもしれませんが、一致していてそれがソースから生成されるコードと同じロジックであるということが大事だとは思います…それが出てくれば、少なくともNICを制御するバイナリに、GPL由来のコードが含まれてるってことなので。あんまりアレコレ穿り返して突きつけるよりは中の人が状況と条件を自発的に確認していただいて、対応してもらうのが、みんな幸せで不愉快な思いはしないのですけどね。

何が悪いのか間違ってるのか気がつけていない中の人も心情的には大変だなぁと思うけれども、上の人が上がってきても適当な仕事で下に戻してるから下のひとが、泣きながら嘘こね回して更に墓穴掘ることになるんだが…。権限とかの問題もあるし、気持ちはわからなくもないけど、仕事の質が世間のそれを下回ってるんだから、仕方ないよね…。同情はするけど褒められたこともないし、擁護できる部分も全くない。むしろ「担当した人より上のヤツがまともに少しは仕事しろ」と。自覚もないしわからないやつしかいないなら「わかんないやつしか居ない状況について」は問い合わせないといけないですよねぇ…。

投稿者:たく  投稿日時:2015/06/12 02:14 親投稿 - 子投稿.1 No.114

Takeshichさん

とりあえず IOには「オープンソースに該当していない」という事の根拠を証明してほしいですね。
以前のOSS一覧表に無いからとかが理由だったりして…

何か別の契約で縛ってるのかもしれませんが、それが認められた判例ってあったかな~

こうなってくると、著作権者に確認するのが一番はやいのでは…
PLXがOSSですよって返してきたら、それが全てであって反論の余地はないと思う。(面倒ですけどね…)

これでも拒むのであれば、もう駄目だねこの会社は。

投稿者:Takeshich  投稿日時:2015/06/14 20:02 親投稿 - 子投稿.1 No.115

え?さん
たくさん

アドバイスありがとうございます。

とりあえず、サポートに
NAS_AP_Team_NAND_SDK_20110609ではgmacはGPLだけど
RockDiskNextで使われている
NAS_AP_Team_NAND_SDK_20110801ではgmacは
「オープンソースに該当しない」
ということか確認して、その答えを待って対応したいと思います。

改めないようであれば、アドバイスを参考にして
サポートではないところにどうにかならないものか相談したり、
うまく英語が書ければ、著作者に確認してみようと思います。

投稿者:え?  投稿日時:2015/06/15 01:04 親投稿 - 子投稿なし No.116

 一応サポートさんもお仕事なので、突きまわすのが面白くなっちゃったって感じなら他の手段が良いのかもしれません。
 というか、社会的に契約のルール守ってんの?って話なので、サポートが戯言抜かすなら、こんなことしてる会社大丈夫?って上に投げるしかないんですよね。上が技術畑の人じゃないとわかってもらうの難しそうですけど、「こういうライセンスのものを使って」いて、「御社は恩恵を受けているのに義務を果たしていない。元から拾い物の筈なので、きちんと考えて開発していれば、不利益は少々の改良が社会に還元されるだけのことである。」それでも「契約を無視する会社で良いと考えてますか」という話をするしかありませんね。
 それでいいって答えが返って来るなら「そういう会社」なのでむかつくようならもっと源流に近い権利者に怒ってもらうしかないです。
 というか、本当にGPL外のだったら、きちっと調べて直ぐにそこは違いますから、公開はしてません。って返せば良いわけで。

 実際に対応してる人からすれば、上に「ちゃんと投げても」その上が調べもしないで「GPLじゃないから断れば良いよ(キリッ」とか戯言言ってれば、酷い目みるの一番下の人だけなんですし、権限とかの問題もあるので、上がポンコツだったら、可愛そうな領域に入ってるような気がしなくも無いですw自分の署名付けて戯言言わされるとか、アルバイトでも何の罰ゲームだと。

 そもそも、サポートからどこに上がるんでしょうね…。
 普通の製品だと、開発辺りに確認が行くのでしょうし、自社製品だから、製品担当者は「わかってるはず」ですが…(それすらバカなの?って回答貰ったことありますから、判断や仕事をあんまり信じてませんが。「良いから確認してからもう一度回答いただけますか?」って返事をしなかったら言いくるめられてたんですが、サポートの仕事はそれじゃねぇっす。)その壁を突破できないと会社の中に答えがあっても返って来るのはデタラメのままなのです。
 どうも店が勝手に作ったプロダクトのようですから、開発が噛んでないと、下手すると技術的にはド素人のバイヤーのところで超翻訳で桶買いした相手と妙なやり取りが発生して、内容はよくわからんけど翻訳だけしてスルーパス…なんてこともありえますし、もしかするとOEM元じゃなくて、どっかの代理店かもしれませんし。
 うそ並べるにしても、時間が掛かるってことは、伝言ゲームとか、仕組みに何か問題が有るんだと思いますので、駄目そうなら他の方法を考えましょう。人としてこっちが間違ってきちゃいますのでw

投稿者:kens  投稿日時:2015/06/21 00:12 親投稿 - 子投稿なし No.117

たくさん

> ここ最近他の人達からレスがなかったけど、まだサーバーダウンしてるのかな?

お久しぶりです。私のところではLANケーブルを交換して以来、サーバーダウンは1度も起きていません。かれこれ2ヶ月半問題なく連続稼動しています。

当方の使い方にもよると思いますが、一度安定してしまうとそれまで度々悩まされたダウン不具合は何だったんだろうというぐらい、今では(私にとっては)購入して良かった製品となっています。
不具合に悩まされていた頃はハズレ製品を引いた気分で嫌だったのですが、こうも製品の印象が変わるとは。。。

皆さんのアドバイスのおかげで不具合が解消されたのであって、サポートには何もしてもらっていませんが。(^^;)

投稿者:たく  投稿日時:2015/06/21 01:05 親投稿 - 子投稿.1 No.118

kensさん

ご報告ありがとうございます。
無事動作してるとの事で、安心しました。

あれこれ試して、結果LANケーブルの問題だった…
ほんと基本は大事だと思わされました。

投稿者:え?  投稿日時:2015/06/21 17:59 親投稿 - 子投稿なし No.119

 意外と気がつかないでこんなもんかって使ってる人いそうな気がしますね。
 多分ケーブルも、OEM元のセット品なんだと思うけど。
 ShareMAXでも同じのだったし、LANDISKだと、大抵短いフラットケーブルつけてくるんですけどね。
 LANDISKのほうは、XRとか、Zを含め、シールドされてない普通のケーブル(やっぱりOEMっぽいHDL-Zは、太いのが入ってますが。)なんですが。
 ある意味、不具合持ってるかもしれないけど動いてみえる程度に通信できるって、よく出来た仕組みなんだなぁとも思います。

 机上ではシールドされてたところで悪影響が出るとは思えないんですが…素で加工品質とかその辺りなんでしょうかね?
 ベンチマーク的な平均以上のパフォーマンスが出てる人は別として、安いからこんなもんかって思ってる人は、意外と普通にケーブル変更するだけで思いのほか幸せになれたりするケースがあるような無いような。

 普通は「添付品だから安心」って気がするんですが、そういう意味でもどうなんだろ。

投稿者:たく  投稿日時:2015/06/21 20:17 親投稿 - 子投稿.1 No.120

私は付属品のLANケーブルやUSBケーブルは基本使わないよ。逆につけないでほしい。
出所不明なケーブルを信用する方が精神的に無理ですね。

古い記事ですが、参考までに
http://itpro.nikkeibp.co.jp/members/NNW/NETHOT/20040305/1/

海外では一般的かもしれないけど、国内の家庭向け製品はその辺微妙ですからね。
電源コードが2ピンの時点で使えないケーブルなんですけどね。

もともと、微小なノイズ相手なのでそこがゼロ電位にしっかり落ちてなければ
信号が減衰するわけだし、RDNはシールドから共通GNDに落ちるわけけど電源自体アースに落ちてないから意味もない。
ルータやハブだってアースがついてるのは業務用で家庭用はほとんど無いから、片側浮いてるからなお悪くなる。信号のロスがあってもしょうがない。

単なるメーカーの確認ミスとしかいえない。国内製品に付属させるべきケーブルじゃないですね。
一般的なUTPケーブルを付属するべきだったと思いますよ。

投稿者:え?  投稿日時:2015/06/22 04:43 親投稿 - 子投稿なし No.121

 それを使うべき場所じゃなくても、悪いほうに影響が出るなら、やっぱり部材の選択が間違っているのでしょうね。
 それでポンコツ呼ばわりされてる個体があったらかわいそうだな。

 信用するかどうかは別として、ウッカリ買い忘れって事もあったりしますし、付いてるのが悪いとまではあんまり思いませんが、取扱説明書では「使うように」指示されるものですから、水準以下や不適切なのはダメだとは思います。添付したら商品の一部ですし。

 もう販売が終わっちゃった製品なのに、今頃わかってもなぁ…w
 売ってるほうは本業の方で取り扱いがあるカテゴリの商品なのに誰も気がつかなかったんだろうか…。普通何かの機会に手に取ったときにあれ?って思いそうなんだけども。

投稿者:Takeshich  投稿日時:2015/06/25 16:37 親投稿 - 子投稿.1 No.122

なんか、サポートからRockDiskNextのNICドライバであるgmacのソースコードが送られてきました。

一ヶ月以上かけての確認で

>恐れ入りますが、NICドライバについては、オープンソースに該当していないという
>状況から、提供は行っていない状況となります。

という回答だったのだけど、GPLだよね?
ってつっこんだら、10日程度で

>恐れ入りますが、再度確認させて頂き、ソースコードについて、入手することができ
>ましたので、添付ファイルにて送付させて頂きます。

だってさ。
何を確認したら、回答こんなにも変わるんでしょうか。。。
ひどすぎて、面白くて、腹抱えて笑いました。

GPLなのをバイナリで頒布しているのだから、その元となるソースコードは、
バイナリを頒布しているIOデータがきちんと
管理していなければいけないのに、今頃、「入手することが出来ました!」と平気で
言えてしまうところが怖いです。

やっぱり、手元にはないみたいです。でも、どこかにはあるみたいですね。
なんだか、突っ込めば、SDKにあるのなら出てきそうですね。
もともとGPLなものは、物理メディアでまとめてくださいと依頼しているのに
突っ込まないと出てこないのかなぁ。そもそも把握できていないとかなんだろうなぁ。

>・Linux kernelはFedra 12を使用しております。
> 入手先はhttp://www.kernel.org/となり、バージョンは2.6.31となります。

と伝えてきたのも、入手先が疑わしいということがほぼ確定的になったので、
突っ込みますか。。。

「なんで、ここまで突っ込まないと行けないの、突っ込まなくても開示してよ!」
という気持ちがとても強いです。

投稿者:え?  投稿日時:2015/06/25 17:57 親投稿 - 子投稿.1 No.123

 お疲れ様でした。
 でもまぁ、対応や、姿勢としてはおかしいので、それはクレーム入れたほうが良いのかもしれません。まぁ、突いたら拗ねて「金輪際云々」って逆ギレした会社もありましたが、縁を切って使わないのは契約を守らないで使うよりは正しいとはいえます。影で何してるかわかりゃしませんがwいくら他所の商品流してるだけといっても、自分のところで箱と名前付けてるんですから、商材の管理って面で問題があります。クレームとしての個別対応でイヤイヤやることがおかしくて、最初から用意されてるべきものだし、用意されていればコストは最低限で済むはずのものなのがそうなってないんですし。この件の担当者、ちゃんとしてればもう問い合わせから解放されてるはずなのに、まだコストが発生してるとかおかしいって気がつけ。上の人。必要なのはユーザー言いくるめることじゃないぞ。

 一番下は権限の問題もあるので、ちょっと大変だとは思うのですけど、「何でサポート全部請け負ってる部署が、LANDISKと同じ」なのに「何も思わないのか」って面では、末端より纏めてるやつが鈍い気はします。普通は他のケースはどうだ?今まではどうしてた?って確認する筈なんですが。
 あるいみ今の形だとサポートって製品のクレーム全般が「見えるはず」で「問題も見えるはず」の部署です。でも、「ザル」が管理してるなら無駄飯食いです。おかしい、齟齬が有ると思ったら、ちゃんと上げないといけないんじゃないかと思うんですが。

 I-O DATAは「ウチが販売して義務を負う以上、必要なものはセットで出してください。うちの信用が掛かってますから」って言えば良いだけだとおもうのです。それをしないのは、正規品じゃないWindowsで商売するようなものなので、何も遠慮して嘘捏造してユーザーの方の道理を引っ込めようとしなくても良いんですが…。
 それこそ、実際にユーザーに突かれてるんですから、OEM元に対する請求権はI-O DATAに有るはずで、「ユーザーから要求でてるし、今後もあるかもしれないので、該当しそうなもので出せるものは全部一式、メディアで出してくれ。」って言って良いはずですし、「それが出来ないところはそもそも取引先としてやべぇ」って気がつくべきだとは思うんです。だって、「その会社もまた、第三者の権利はばれなきゃ良いと思ってる」んですから、その切っ先が自分に向かない保証はないってわかるべきです。

 というか、箱と、キットだけ買ってきて、中の人に手伝ってもらえば伝言ゲームも半分になったんじゃないかと思うけど、仲悪いんですかね。miniDLNAも、そのほうがもうちょっとマシなパッチ作ってくれたんじゃないかと思うし、ライセンスやそれに絡む処理も、忙しかろうと人は居るはずなのだし、リソースを使わないのはどういうことなんだ。

 回答が変わるのは…訂正されてるので笑わないで上げてください。
 体裁をどうにかするために、「検討した振り」で時間を無駄に持っていかれるよりはマシな対応です。言うことが変わることを悪だと認識されるよりは、ふらついても正しい答えを提供しようとするほうが実利はあります。認識できてないことは仕方ないですし、間違うのも仕方ないですしね…。「そうならないように努力する」のが必要ではありますが、そうか、じゃあ今度から一ヶ月くらい頑張って交渉した芝居する!ってなったらそのほうが大迷惑です。

 あきらめる。以外に、ユーザー側が可能な配慮とかできる前提条件の設定とかあっただろうか。思いつかないし、ねじ込まなくても出てくるべきものは、払うものは払うから出して欲しいとは思いますが。

投稿者:Takeshich  投稿日時:2015/06/29 17:10 親投稿 - 子投稿.1 No.124

もう、サポートすごいなぁ。

gmacのソースを開示できたんだから、
RockDiskNextで頒布されているバイナリで、SDKにあるGPLなものについての
一式を直接開示してとお願いしたら、

>ご連絡いただきました件についてですが、恐れ入りますが、以前提示させていただい
>たリストにて、GPLの提供は行っている認識でございました。
> 恐れ入りますが、不足している場合は確認させていただきますので、不足しているも
>のがある場合は、不足している内容をご提示頂きます様お願い致します。

というありがたい回答をいただきました。
GPLなものを使わせてもらっている企業としては、この対応はまずいんじゃないの。。。

なんか、たくさんが指摘していた

>以前のOSS一覧表に無いからとかが理由だったりして…

というのがあたりの気がしますw

そのRockdiskNext_Opensourcelist.pdf
https://drive.google.com/file/d/0B1Tfr ... DckY4NmM/view?usp=sharing

ですが、ほとんどが示されている入手先で対応するソースコードを見つけられません。
入手先として正しくないと思われます。似ているのがあるかすらも確認してないんじゃないかな。。。

また、GPL的にはリストのリンク先のコードが対応するソースコードであっても、
3年間は有効である保証について、ダウンロード先が保証するものではなく、
バイナリを配布した側が保証するものだから、
リンク先とバイナリを配布したものが何らかの約束を結んでいなければ、成り立たず、
すべてのリンク先とバイナリを配布した側がそうしていることは考えられないので、
満たしていないと考えられます。

別件でRockdiskNext_Opensourcelist.pdfに記載されているffmpeg-libs-2.0.1-1.fc12.armv5tel
のソースコードがどこにあるのかわからなくて、問い合わせしているのだけど
5月末に問い合わせて、1ヶ月程度たっても、自動応答メールのみで、何も回答がない状況だったり。。。
問い合わせてから、7営業日過ぎても回答ないから、受け付けられたか確認してみたけど
それにも回答無かったり。。。
(minidlnaをクロスコンパイルするときに、ライブラリはオリジナルのを持ってきて、
ヘッダファイルもオリジナルので試そうと思ったら、どれかわからなかった。)

そもそもリストがおかしいことをつっこむべきか、
SDKにあるリストにはないROM loader(GPL対象外?),stage1 loader,uboot,root file system,linux kernelを指摘するか
両方とも突っ込むべきか。。。

たぶん、本当に誰も技術的に把握しないまま販売、サポートしてたんだと思う。
やっぱ、サポート外の連絡先に相談するしかないのかなぁ。

投稿者:たく  投稿日時:2015/06/29 22:41 親投稿 - 子投稿.1 .2 No.126

Takeshichさん

Q&A 本製品のソースコードの入手方法について
http://www.iodata.jp/support/qanda/answer/s12850.htm

本来、RockDiskNextもここに記載されなくてはいけないと思います。
またIO Data自体 GPLを色々勘違いして受け止めてる感がありますね。
(そういえばライセンスやクレジットとか見た事ないね。著作権者に許可得てるのかな?義務じゃなかったっけ?)

まずは、IO Dataの対応がGPLライセンスの義務に対して正しいのか
FSFに確認してみてはどうでしょうか?
IO DataのGPLライセンスへの認識が、私たちと違うと感じられますが
私達が間違ってる可能性もゼロではありませんので。

まず何が正しいのかを互に確認してからの方が話が早いかもしれません。

もしくは、サポートに「社外コンプライアンス相談窓口」の連絡先を聞くのも手だと思います。
そちらで聞いた方が、納得いく会話が出来るかもしれません。

カーネル部分についてはAvago(PLX(Oxford))にSDKもらえないのか、再配布について何か拘束(NDAとか)しているのか確認した方が早いかもしれませんね。
Avago日本法人↓
http://www.avagotech.co.jp/cs/Satellite

投稿者:Takeshich  投稿日時:2015/06/30 00:59 親投稿 - 子投稿なし No.127

たくさん

>Q&A 本製品のソースコードの入手方法について
>http://www.iodata.jp/support/qanda/answer/s12850.htm
>
>本来、RockDiskNextもここに記載されなくてはいけないと思います。

そもそもバイナリのみの配布であるのに、対応するソースコードを提供するという書面による申し出がない時点で
いわゆるGPL違反なのです。(はじめにお読みくださいにその旨ないのでアウト)

>またIO Data自体 GPLを色々勘違いして受け止めてる感がありますね。
>(そういえばライセンスやクレジットとか見た事ないね。著作権者に許可得てるのかな
>?義務じゃなかったっけ?)

これについては、ちょっと同意はできなくて、verboseオプションで表示されるから問題ないんじゃないと思っていたり。
私としては、他の製品ではおそらくライセンスに基づくようにしているようにみえるのだけど。。。
ソースコードの開示については、問題なくできるみたいで、1週間もあれば物理メディアが届くようです。

RockDiskNextだけが、なんかとてもおかしいのです。

>まず何が正しいのかを互に確認してからの方が話が早いかもしれません。

GPL違反については、2014/9月頃にライセンス条項をさして、いろいろと指摘したのですが、
回答は、根拠を示さず、ただGPLに基づいていると認識しているでした。
とやかく言っても変わらないから、もうソースコードだけすみやかに開示されればいいと思っています。
とは言え、GPLに基づいた対応を取らないと速やかに開示されないわけで、
企業としての矜持というのを期待してしまったのですが、期待するだけムダだったようです。

対応があまりにひどいので、今後、ソースコードの開示請求をされる方が、
同じ轍を踏まないように情報共有として、やりとりを明らかにしていこうと思います。
一度あまりの対応の酷さにポッキリと心が折れてしまったので
続きの今回は寛容さをオカン級にして、のんびりいこうとおもいます。

>もしくは、サポートに「社外コンプライアンス相談窓口」の連絡先を聞くのも手だと思います。
>そちらで聞いた方が、納得いく会話が出来るかもしれません。

社外コンプライアンス相談窓口がなさそうなんですよねぇ。聞いてみるのもありかもです。
とりあえず、明らかに開示するべきものを開示しないと言ってきかない時は、連絡するしかなさそうですね。

頒布している側の自分のところで確認せずに、
存在を証明することが難しい頒布されている側からの不足情報提供を依頼するとか
末期なんでしょうね。
どこかに確認するまで自分のところでは判断できないようですから。

私が嫌なのは頒布しているのにソースコードを管理できていない状況が
如実にわかるってことなんだろうな。他人の著作物で利益を得ているのに
その著作物すら把握してないところだろうな。

投稿者:え?  投稿日時:2015/06/30 01:02 親投稿 - 子投稿なし No.125

なんとなく、「わかるやつ出て来い」か「サポートに物を考える気が無い様なのだが、御社のサポートはユーザーに嘘を流して黙らせることだと考えているのか?」と部署そのものの問題を問えば良いような気がしている。
目的が「わかって無い人小突き回してオロオロする姿を嘲笑う」のなら、今の担当の人をつつき回せば良いのだろうけど、得るものも無いし、無駄にそれなりの仕事をしている人が嫌な思いをするだけだと思う。結局その上が機能して無いので、まともにサポートとして、きちんと話を聞いて、検討して返事をする気も無いごっこ遊びにしかなってないし、その「ザル」だか「HUB」は一応ソースを一部だけ引っ張ってこられてるので、他所と繋がってるはずですから、伝言ゲームから、効果が期待できない今の直接の担当者を外してもらうだけで「無駄に嫌な思いをして、無駄に話が通じない」可能性が少しだけ減ります。

それを「知っててそんなもの」と思ってる人たちが運営してるなら、「どうにもなりようが無い」ので、「権利者に通報」しかないでしょうが、正直「構造的にサポートセンターが腐ってる」としか思えないんですよね。少なくとも問い合わせ先は、商品ごとに現状分かれてるんですから「似たような商品の全部のクレームを含む情報があるはず」なのに、商品が違ったら情報が遮断されてるとかバカが運用してるか物を考えて仕事して無いかのどっちかですし、自分が矢面に立たないから、適当なこと下にほざいてのんきにやってんだと思います。
その戯言を答えとして伝えた人間がなお同じようなこと言うようなら部署が終わってます。

そして、そういう現状は、一応上の人は知る必要が有ります。ソレを生かせないなら「そういう会社」で、気がつけてないところが、「だから社員切る羽目になっている」のだろうし、ちゃんとする気が無い人達には、正当性があっても多分話は通じないです。

OSS一覧は本家のソレとも違うので、もしかすると代理店のようなものがもう一つ噛んでる可能性もあって、一応形だけ、そういう表を作ってもらったか、流してもらっているのだと思います。でも…確認しない商品担当者はもしかすると文字が読めないのかもしれません。日本語部分もおかしいですし、なんとなくRockdiskNextのマニュアルを片手間に書いた人に似た印象を受けるんですよね…。仕事のずさんさとか。

一応Versionと名前があるんですが、使ってるパッケージからすれば、fc12のパッケージのソース辺りに誘導するのが妥当は妥当だと思います。が、整合性を取ろう思うことすらないってことですね。

まぁ、最初からでたらめ言われてるわけですから、最初の時点で「責任者か、まともにわかるやつ出て来い」(下の対応じゃなくて、そもそも流してる情報がどうかしているので)でも構わなかったかもしれません。条件を満たしていると考えてます。が「そうはどう見ても思えないので相談させていただきたい」訳ですから、権限や、自発的な発言が難しい人たちにソレをさせるのはそもそもちょっと酷です。というか、「責任なんてものがあっても金銭の要求じゃない」ので「ちゃんと日本語が理解できて、ライセンスについて、権限、判断できる人」じゃないと話にはならないんですけど。

下の人は、ソースが出てくるってことは相談はしてるはずなんですよね。普通まともな上の人なら話し聞くだけじゃなくて、問い合わせの文面も一緒に確認するはずなのですが、「ソレを見てこの有様はありえない」とおもうんですよ。

正攻法なら、担当の人を通してきちんと話したいところですが、多分担当の人が大変なだけなので。既に交代しててコノザマならサポートセンターだか、外注先だかは丸ごとつぶれたほうが良いですw人を騙して黙らせるための部署ってサポートじゃないです。

スルーされてる部分は、脊髄で反応しているので「ソースコードそのものに対する問い合わせは対応しなくても良い」という条件で排除されてるのだと思いますし、そもそも何言われてるかわかって無いと思います。
…技術力があって、まともな判断力があれば「言われなくても出てくるもの」なんですから、それ自体が恥ずかしいことなんですが、仕事をしない理由になれば何でも良いんじゃないでしょうかw

どっちにしろやり取りとしておかしなことになってるので「きちんと把握できる人、権限が有る人(場合によっては提供を受けないといけませんから、その判断と実行をしてもらわないといけないのですし)」に出てきてもらったほうが、無駄に面倒な客ってことには(経過時間からして変わらないかもしれませんが)少しはならずに済むかもしれません。

投稿者:え?  投稿日時:2015/06/30 01:13 親投稿 - 子投稿なし No.128

>本来、RockDiskNextもここに記載されなくてはいけないと思います。
これはFAQですが、記載が無い新しいRockdisk forAudioの元になるHLSシリーズや、HVL系の製品の記載がありません。
「しかし」RockdiskNext「以外」については、きちんと取扱説明書に記載があります。それは、ダウンロードできるマニュアルでも確認できますので、「言われてて、認識されても直さないioplaza」とはまた違うのです。
本当は、該当製品に追加されるべきですが、どっちにしろサポートに問い合わせを行ったうえで、必要事項を連絡し、提供を受ける形になるので、掲載が無くても直接質問しても変わりません。
少なくとも「製品にGPL下のバイナリが含まれ、請求に応じる」という記述がありますから、FAQの方は、無くても問題は無いものと思います。

ライセンスやクレジットも同様です。ミドルウェアなどは直接マニュアルで取り扱っていない単語についてはどうだったかは定かではありませんが、一応そういう表記は「本家の商品では記載があります。」

そういう意味では「自分のところで企画して、管理している商品」は「きちんとしようとして」いるようです。
HDL-XV/XRでは、telnetdを有効にする手段を用意し、保証と引き換えに、内部にアクセスできるようにする方法もドキュメントで提供しています。システムが暗号化されているものについては、なくなっていましたが。

まぁ、ioplazaの専売品が限りなく白箱なバルク品を流してるだけって言うのもあって、全体的にいい加減なだけなんですよ。
でも、他の部署の人が「気がつかない」ってのも他の人の仕事に全くお互いに微塵も興味持ってないんだなwとは思いますが。
規模の割には希薄な関係ですよねぇ…。

投稿者:え?  投稿日時:2015/07/06 17:34 親投稿 - 子投稿なし No.129

http://www.ioplaza.jp/shop/contents/review1507rockdiska.aspx

…あれ?またケーブルが…。
確認すると、HLS-C自体が、
http://gigazine.net/news/20141204-iodata-hls-c/
ここの画像
http://i.gzn.jp/img/2014/12/04/iodata-hls-c/f08.jpg
これも、ケーブル太めで、コネクタ部が覆われている。
ケーブルに印刷が見えないので、「嫌な予感」だけで、本当は大丈夫かもしれないけれど。

…買ったことがあるI-O製品のオマケケーブルって、白のフラットでCat5eばっかりだった気がするんだけど、ポケドラはやっぱり別ラインなんだろうか。

まぁ、そうみえるだけで普通のケーブルだったらいいんですけどねぇ。
レビューの動画のほうは、よそ様製の汎用フラットケーブルって自分らも使わんものつけとるのかいwそりゃ使ってなければ、気がつかないっすよね。

別の出自の箱で後継って、Nextは、「音質」でゴリ押ししてる以上、機能で訴求するのはアレだとおもうんだけども。
http://www.ioplaza.jp/shop/contents/review1412pocketdriC.aspx
「簡易的」としちゃってるし、Nextを無駄に本格的ってしてしまっている。
余計な事いわなければ、変な齟齬は無いのに。設定項目が開放されてるなら、それも広告に使えるところだけどそうじゃないならメディアサーバとしても同程度なんだよなぁ。

というか、HLS-Cとの比較表くらい作ればいいのに。
Mediaサーバとしての優位性とか、機能の有無について、明確な比較表が無くて似たような型番って下手すれば自社社員も違いわからんのではないか?
ブランド名増やすより、HLS-Cをアップデートでレプリケーション対応して、専売モデルは限りなく無音のSSDモデルもあるんですよ!とかシンプルにしたほうが売りやすいし間違えにくいと思うんだけど、縋りたいほどNextって売れたのかな?でも、前面に出してた音質は物理的にはHLS-Cと同じで、且つ、今回はお墨付きが無いので、後継として期待されるところと実際の商品違いすぎる気もするんだけど、買った人で『本当に違いがわかる人』に怒られたりしないだろうかw本当はそんなもんないなら、何も言われないでしょうけどもw

アンケートの設問で、一応「作ってるって言ってたの」はまだやってるようなことが書いてありますね。ほしいほしいっていえば、少しは気合入るかもしれませんね。
ケーブルが理由で不幸になる人たちやものたちがありませんように…。

投稿者:閲覧者  投稿日時:2015/07/07 10:29 親投稿 - 子投稿なし No.130

え?さんへ。
いい加減にしたら?もはやNextの話ですらないし粘着にも程があります。1ユーザーとして見ていて気分が悪いです。自重してくれませんか?他でやってください。

投稿者:閲覧者  投稿日時:2015/07/07 10:30 親投稿 - 子投稿なし No.131

え?さんへ。
いい加減にしたら?もはやNextの話ですらないし粘着にも程があります。1ユーザーとして見ていて気分が悪いです。自重してくれませんか?他でやってください。

投稿者:ゲスト  投稿日時:2015/07/07 14:37 親投稿 - 子投稿なし No.132

当方も同じ症状で悩んでいました。
修理に3回出しましたが直らず困っていました。
先日当スレを発見し付属のLANケーブルを止め
あまっていたLANケーブルに交換したところ、
一ヶ月程たちますが今の所不具合は起きていません。
このまま不具合が起きない事を祈っています。

2013年3月に購入してかれこれ2年…長い道のりでした。

投稿者:Takeshich  投稿日時:2015/07/19 18:07 親投稿 - 子投稿なし No.133

ひさしぶりに本題なのですが、今までのまとめと気になる点についてです。

時間が経つとサーバがダウンするように見えるという症状でも
似ている症状だけど、複数の症状があることがわかりました。
このスレッドで、明らかになったのは2つです。

1.付属のLANケーブルが不良で物理的な原因によるもの
2.NICのドライバがTCPの送信をしなくなることが原因によるもの

切り分け方ですが、

・IPアドレスを固定にする。
・症状が出た際にネットワークケーブルを抜き、20秒待つ。
・ネットワークケーブルを挿す。

上記対応で通信が回復し、必ず復旧し使えるようになるのであれば、2の症状です。
復旧しないことがある場合は、おそらく1の症状なので、付属のLANケーブルを
別のケーブルに変更し、経過を見ます。ある程度経過しても、症状が発生しないのであれば、1の症状です。

問題なのは、2の症状の場合で、対処方法がありません。
というのが今までのやりとりで判明したことです。

ここからは気になる点です。
2の症状の再現性なのですが、最近までは1度しか遭遇したことはなかったのですが、
HDDを入れ替えて、swapを作らずに使用していたら、
かなりの頻度で再現するようになりました。

私の場合だけなのか判断がつかないので、swapoffするなどして、確認頂きたいです。
どなたかお手すきの時に確認お願いします。

投稿者:たく  投稿日時:2015/07/19 19:31 親投稿 - 子投稿.1 No.134

Takeshichさん

swapoffですね。時間あるときに試してみます。

症状は、アクセス中になりますか?
少し使用してから、時間を空けて確認した方が出やすいですか?

投稿者:Takeshich  投稿日時:2015/07/20 02:59 親投稿 - 子投稿なし No.135

たくさん

おそらく、スワップを使わなくするとそれまで動いていたnmbdやminidlnaが落ちます。

>症状は、アクセス中になりますか?
>少し使用してから、時間を空けて確認した方が出やすいですか?

どうもメモリが使い切られると再現するようです。

私の場合、minidlnaのfile.dbを削除して
/etc/init.d/minidlna start
するとスキャンの途中で再現します。

と書いたところで、色々いじっていたminidlnaを使用していたことに気づきました。

で、元に戻したら出ないですね。
すみません。私の環境だけみたいですね。。。
申し訳ありません。

なんか腑に落ちないので、ちょっと試してみました。

http://q.hatena.ne.jp/1265176514#a988754
を参考に256MB程度のメモリを消費するスクリプトを実行させてみて、再現するか確認してみました。

#! /bin/sh
# Enter を押すとメモリが消費されます
# 未テストです

echo PID=$$
echo -n "Enter=more EOF(^D)=exit >"
c=0
while read byte; do
eval a$c'=$(head --bytes 256000000 /dev/zero |cat -v)'
c=$(($c+1))
echo -n ">"
done
echo

oomkillerによってプロセスが殺されるまで(1分程度)は、TCPの送信ができなくなったように見えました。
ただ、プロセスが殺されるとメモリが開放されて通信が回復しました。
どうもminidlnaはoomkillerによって殺されないようです(理由不明)。
シリアル通信を試そうとしましたが、なぜかシリアルで接続できませんでした。
メモリ不足が影響しているのかもしれません。詳しくは切り分けられてはいません。

TCPの送信は受信と違って割り込みが発生しないようなので、同じようには見えるけど
メモリ不足でシステムが不安定になった現象なのかもしれませんね。

以前、1度症状が発生した際のログには、out of memoryなどのログは吐かれていなかったし、
他のプロセスは正常に稼働しているログだったので、ちょっと違うのかもしれません。

お騒がせしました。

投稿者:たく  投稿日時:2015/07/20 08:31 親投稿 - 子投稿.1 No.136

Takeshichさん

>と書いたところで、色々いじっていたminidlnaを使用していたことに気づきました。
>
>で、元に戻したら出ないですね。
>すみません。私の環境だけみたいですね。。。
>申し訳ありません。
 了解です~
 どんなタイミングで発生するか聞いてからの方が確認しやすいかと思っただけですので
 実験する前で良かったです。

>以前、1度症状が発生した際のログには、out of memoryなどのログは吐かれていなかったし、
>他のプロセスは正常に稼働しているログだったので、ちょっと違うのかもしれません。
 たしかに、そうでしたね…、今回の実験ではOOMだったのですね。
 また難題そうですね。


ついでで申し訳ないのですが、/tmpの件なのですが 
以前、ブログを拝見した時に少しあれ?っと思ってたのですが、他の事してる間にまた忘れてて…
今回の件と関係あるのかは微妙なのですが…

/var/tmp と /var/log はNANDの書き込み削減の為に、tmpfsでマウントしてるのですが
/tmpがいっぱいになっているのを見て、何で /var/tmp でなく /tmpを一時ディレクトリに使ってるのだろうと疑問に思いました。
/tmpだとNANDに直接 読み書きするし、空き容量が数十MBしかないのに何故ここをTMPDIRにしてるのかなと…
購入時に環境変数の確認を忘れてしまったので今となってはわからないのですが
現在のファームではTMPDIRは設定されてないみたいなので、デフォルトの/tmpが使われてるみたいですね…。
何の為に/var/tmpマウントしてるのだろう?メモリ半分も使われてるんだけど… 何か意図があるのかな?

tmpfsはswapがoffだと不安定になる様な事をどこかで見た事があったのですが
確証がないので憶測になってしまうのですが…

TMPDIR=/var/tmp とか環境変数設定してswapを大きめに割り当てたら少しは変わるかな?
minidlnaのfile.dbのスキャンが何か原因があるかとは思ってるのですが、
実はDSDファイルに変換するソフト持ってないので、検証できそうに無いのです…

投稿者:Takeshich  投稿日時:2015/07/20 12:08 親投稿 - 子投稿.1 No.137

たくさん

>/var/tmp と /var/log はNANDの書き込み削減の為に、tmpfsでマウントしてるのですが
>/tmpがいっぱいになっているのを見て、何で /var/tmp でなく /tmpを一時ディレクトリに使ってるのだろうと疑問に思いました。

実装した方が、そういう実装をしているので。。。
https://github.com/takeshich/minidlna- ... gutils/tagutils-dsf.c#L31

深くは考えられていないような気配がします。

>何の為に/var/tmpマウントしてるのだろう?メモリ半分も使われてるんだけど… 何か意図があるのかな?

定かではないのですが、ファームウェアをダウンロードする領域が/var/tmpだったような気がします。
正確ではないし、確認もできないのですが。

>minidlnaのfile.dbのスキャンが何か原因があるかとは思ってるのですが、
>実はDSDファイルに変換するソフト持ってないので、検証できそうに無いのです…

使用していたminidlnaは、IODataが作成したものではなく、独自実装のものでして、
DSDのタグを読み込む時にメモリ中で処理しているのですが、
メモリが少ない場合の処理を考慮してないので、out of memoryなってしまっているようです。
実装が良くないですね。。。はずかしい。

投稿者:Takeshich  投稿日時:2015/09/11 21:57 親投稿 - 子投稿.1 No.138

ちょっと寂しい話というか残念なお話です。

http://bbs.ioplaza.jp/forum/index.php?topic_id=2398#post_id10431
から繋がる話なのです。
6月末に話題にしたソースコードの開示の件ですが、実はまだ終息しておりません。

Linuxカーネルのソースコードやテキトーなリストについて
6月末に指摘した後、7月半ばまで全く連絡がなかったため、
サポートに電話で問い合わせました。

その際に社外コンプライアンス相談窓口はないかと確認しました。
おそらく、それが効いたのか、窓口はないとの回答でしたが、
どうやらそれを含めて対応がちょっとまずいのではないかという
ことについてサポートに気づいてもらえたようです。
今まで散々指摘していますが、本当に理解しているかは怪しいのですが、対応に問題はあって
GPLに基いてきちんと対応しなくてはならないことは一応ある程度理解していただけたようです。

サポートは
7月の半ば以降からinXtronに対してソースコードの開示についても交渉しているようですが、
inXtronが開示しないようで現在に至っています。

20150429および20150807の更新が行われたのは、
サポートがちょっとまずいと気づいて、対応を始めたと思われる後なのですが、
残念ながら、いろいろと問題のあった更新されたminidlnaのソースコードを開示請求してみたら
すぐには開示できないという回答をもらい、今までの対応に問題があり、GPLにもとづいて
対応しなければならないことは把握しながらも、対応していないというひどい状況です。

7月の後半以降、週に一度サポートから連絡をもらっていましたが、
inXtronとの交渉は全くうまく行っていないようで、良い話は全くもらえませんでした。

現在、7月の後半から一ヶ月以上経ちますが、全く話が進まないようで
一週間に一度の連絡も全く進捗状況を伝えられないので、サポートが回答を拒む形となり
開示できるようになったら、連絡するという回答がサポートから来ました。

対応する気は一応はあるのだろうけど、
いろいろ指摘したけど、迅速に対応する気はなくて、
まぁ面倒くさいこと言われているけど、RockDiskNextではGPLについては
きちんと対応できてないから対応しますよって感じでサポートから対応されてます。

ただ、IODATAでRockDiskNextのGPLに対する対応がまずいのは理解いただけたようなので
そこはまぁ評価できるところです。
今後、どのようにそのまずい対応を是正するべく、対応するかについては全く言及がなく
意思についても明示されないので、生暖かく見守るしかないようです。

現状は、IODATAでもRockDiskNextのGPLに対する対応についてはGPL違反状態が継続しているけど
inXtronには開示を請求しているので、改善の意思は感じられる。
ただ、inXtronが開示しないので正しい対応が取れないという状況のようです。

IODATAには各著作者に対してどう対応するべきかを連絡して、確認してくださいとお願いしてあります。
IODATAがきちんと対応しようと考えているのであれば、うまく対応されることでしょうから
それを期待しつつ、まぁ今までの対応ならきちんとできないこともあるなぁということも
考慮しています。

内容の詳細について後日まとめようと思います。
サポートは本当にネチネチ言わないと理解できず、是正対応をしていただけないようで
IODATAが法令および社会規範を遵守することを基本方針としているのは嘘に近いと
感じられます。

今後進展があったらまた書き込みます。

投稿者:え?  投稿日時:2015/09/12 03:13 親投稿 - 子投稿なし No.139

 そもそも「そんな胡散臭いサポートセンター」に「バカ正直に社外コンプライアンス窓口」を聞いて教えてくれますかね?まぁ、あれば最初から問い合わせ先がありそうですが、内向きには「あるはず」なんですけど、機能してるかどうか怪しいし。
 どこぞのデザイナーさんじゃありませんが、仕事の質と結果で、「信用が無い人」の言葉を信じる理由も無いので、「大代表とか別部署」で聞く必要が有ると思う程度には「あしらい方すら適当」だとは思います。「わざと適当なところにしらばっくれて問い合わせる」と「あれば適切なところにその話しは行くはず」ですし。行儀は悪いですし、正攻法ではありませんが、窓口が信用できなければ仕方ないです。

 ただ、構造的に回らないようにしてるのはたぶんioplazaなんですよね。内製の製品が多かったので、可能なことはサポートで。ダメなら担当者へ問い合わせ。データベースに追加しつつ、戻ってきたのを回答ってことになってるとおもいます。だから、「担当者にその気があるLANDISK(まぁ、一部製品は法人向けですし、信用大事。)は、他所のだろうなって製品でもソースが出てきます。が、それは担当者が用意した上で、サポートにこういう対応しておいてね。っていう情報を出してるからなんだとおもいます。手順がいつでも同じですし、同じ内容でも、情報が共有された後と前で、言うことが違うので、多分そういうことなんだと思います。
 そういう意味では、もう、サポートとこの担当者じゃむりなんじゃないかなぁとも思うんですよ。というか、多分一番割食ってるのはサポートだと思います。だって、いつもどおり担当者に投げてそれを返してもユーザー怒るんだものwどっちの言ってることも多分サポートの人わかって無いですよね。かわいそうに、板ばさみになって、投げても無駄だからって言い訳考えてまたそれでいじられてw気持ちはわかるが、仕事でソレはダメなのだよな…。ただ、普段から切り分けおかしいとは思います。

 で、問題は構造と俯瞰から見てる人が居ない状況にあって、価格comとかでも、ルータ、ネットワークまわりは、ユーザーがサポートの地雷踏みまくって、泣いているひとが結構いるので、「実はユーザーが諦めて見限ってるだけで、ちゃんとまわってない」ことは上の方にわかってもらわないと駄目な気がします。

 まぁ、ioplazaに何か言って効果がある人は「せんせー」しか居ないでしょうねぇ。あの人も「エンジニアとして欠片ほどでもプライドが有れば」(まぁ、現状でも怪しいんですが)流石にコンプライアンス的にアウトなものを平気でお奨めしたりはしないでしょう「人として」。ファームをアップデートするのは頑張ってるといえなくも無いのですが、それはやることやった上で、頑張るから美徳なのですし、定年になるまで働いた人が流石にこれでも太鼓もちなんざしないと思いますが、するようなら「オーディオ周りの人なんてそんなもん」ってことですね。よそでも、GPLだからってソース出さなくてもいいなんて戯言を何年にもわたって掲載し続けたライターさんもいらっしゃいますし。

 あとは、会社の上の方に「自社製品を買って、使って、サポートを利用してみて大丈夫か確認してください」ってお願いするくらいですかね。少しでもやる気がある経営の人たちなら、あわてると思います。一応別の部署から回ってくるような有様なら、クレームは届くと思います。その上でどうするかはわかりませんが。此処の社員の方は自社製品ちゃんと欲しいのですかねw
 そっち経由で何も動かないなら「その気が無い」のだと思います。

 わかっててこうなら、仕方ないですね。やる気無いんですから。
 でも、知らないなら、わかってもらうしかないのですが。

 基本的にサポートもそうなのですが、「目の前しか見て無い人」ばっかりの印象です。
 此処も楽天もそうなのですが、モノが探しにくい。
 http://www.ioplaza.jp/shop/contents/cl2.aspx?affiliate=OPhd106
 専売品が無い。
 http://www.ioplaza.jp/shop/contents/i ... aspx?affiliate=TC150907Q1
 比較表が奥の方にあって、Rockdisk for Audioを探しに来た人には見つけられない。比較表も(突っ込まれたのかなおってるけど)間違ってた。ブランド名、型番がHDL-AとかLANDISKと別の系統のものになってるので、実績があるのに情報を検索しにくい型番で、LANDISKの直販モデルでこんなに安い!で済むのに、謎の新製品扱い。
 多分HDL-Aとか、HDL2-Aとか、LANDISKで検索したら、買う人検討しやすいのに。比較的長く売られてる商品なんだから。
 存在しない交換用HDDのモデル…どうせ中身空っぽで保証のついてるドライブなのに、専用品って効率悪いにも程が無いか…?(これ、LANDISKのページを引き写し損ねてるんじゃなかろうかどっちにしろろTYPOもある。)。
 RTC用の電池交換できねーじゃんっていう写真。
 こんなのばっかり。楽天のほうもカテゴリ設定間違ってるらしくて検索しないとカテゴリあってても引っかからないとかザラwもう売って無いのに残ってるとか。
 …こういう仕事ぶりは怒られなくて良いのかな…。FBとかで媚売ってる場合じゃないと思うんだが。一つ一つは瑣末なことなんだけど、「こういうのがドッサリ」ってのは、仕事の質とか姿勢に丁寧さが無いんだと思う。掲載はしてるけど、自分が買うときにトップから追えるか確認して無いんじゃないかと。
 商品説明も、派手目だけど商品を知ろうとしてない。愛着も無い。そんな広告が多いのも残念。傍目にも開発担当者にちょっと同情するw
 きっと、タスクが重くて毎日大変とかあるのでしょうが…それでももうちょっと頑張って見せてくださいな。
 さすが直販って仕事、見せてもらえないものですかね…。

 多分サポート経由だと、末端の人が涙目で仕事するだけで得られるものは無いと思います。たぶんどうにかしたくても、前線で対応する人は直接交渉できないと思うので。仕事だからといえばそれまでですが、「すべき仕事をして無い」ヤツは矢面に立たないんで、なんとも思わないでしょうし、その人がのらりくらりしてるからこのありさまなわけですから、理詰めで話をしても不幸な人が増えるだけの気がします。

投稿者:たく  投稿日時:2015/09/12 07:45 親投稿 - 子投稿.1 No.140

Takeshichさん

色々とご苦労さまです。
本心としては参戦したいのですが、多人数で責めるとサポートがパニックになって、余計変な行動に出そうなんでこの件は問合せを自粛してます。

>IODATAが法令および社会規範を遵守することを基本方針としているのは嘘に近いと感じられます。

 末端の人が理解してないのはよくある事で、こういうケースに対してどう対応して良いかノウハウがないのでしょう。
 社内向けのコンプライアンス相談窓口はあるんでしょうから、その部署とサポートとinXtronの三者で法令が守られているのかをまず確認しあってもらうように促すのが良いかと思います。

投稿者:ん?  投稿日時:2015/09/12 18:09 親投稿 - 子投稿なし No.142

 そういえば、HLS-Cを買った人が居たので見せてもらったのですが、添付ケーブルは、cat5eのSTPでした。ロットによって違うかもしれませんがI-Oやその貸与製品の写真は同じ形状でコネクタがシールドされてます。
 ……商品のパッケージは縦長で、見慣れたのとは様子が違って面白いパッケージだなとは思いましたが。
 基本的には、高くて効果も発揮できない(というか、cat6はともかく、cat5eだと独自実装だったような…)だけで使えなくないってことになってますが、どっかのオーディオマニア向けの詐欺まがいの商品じゃあるまいし、見た目がなんとなく派手で違うからって理由でつけてるなら、「素直に対応しているもの」を添付していただくと良いと思います。
 設計のほうにマージンがあったりすればマシなのかも知れませんが、RockdiskNextでは、実際にケーブルが犯人で色々パフォーマンスを発揮できずに妥協して使われてたなんてケースもあるので「こっそりでいいので確認、必要なら変更」したほうがいいのではないかと思います。
 世間の人だと素直にcat5Eのフラットケーブルの方が引き回しがしやすく使いやすいですし問題も少ないような気がします。効果があるものなら、品質がいい、グレードが高いほうがいいのですが、見た目だけなら安くしてもらうかつけないほうがましです。困るのユーザーのほうですし。
 RockdiskNextの添付ケーブルでおかしい事例が出ていたのがケーブルの質なのか、実装なのか、引き回しのしづらさによる破損なのかわかりませんし、症状が出るケースも出ないケースもあるので、「無難なもの」にしたほうが良いとは考えます。
 自分のじゃないので、中開けて素性を確認することは出来なかったのですが、forAudio含め、HLS-Cもなんかおかしかったらケーブルを変えてみるっていうのはやってみたほうがよさそうかもしれないです。

 複数刺せるタップ(ACアダプタ形状がちょっと特殊なので、コンセントの向きでものすごく使いづらくも、使いやすくもあったりする)なんかをお勧めしたりするのが、「物理的な状況や仕様も知っている」直販ならではの提案(一応レプリケーションなんて提案してるんだし)じゃないかと思ったりするんですがね…。そういう意味では尻尾が出てるRockdiskNextのほうは使いやすさに配慮があったACアダプタだと思います。

 http://www.iodata.jp/product/lan/hub/etx-esh8/spec.htm
 樹脂製で、ACアダプタでアースできそうもないけど、STPが対応ケーブルに含まれてるのもどうなんだろう。基本的にI-O DATAとしては、「UTP相当として使用は可能」とは考えていそうだし、基本的にはそうなんだけども…正直で正しい表記なのか?というと、どうなんだろ。

 ソースについては、ちゃんと同じようなのを作ってる部署に手順を確認すれば「発売前に準備されていた」はずで、ごねなくても済んだはずなのですが、発売にやるべきことが販売が終わってなお出来てないというのは残念ですね。
 仕様でダメなのは仕方ないんですが、せっかく選んでもらってユーザーの手に渡ったのに、誤解されるとかパフォーマンスが発揮できないとか、商品が泣きます。

投稿者:たく  投稿日時:2015/09/12 19:27 親投稿 - 子投稿.1 No.143

ん? さん

ケーブルのシースにはSTPみたいな記述ありましたか?
UTPケーブルでもコネクタだけ金属のものもありますので。

投稿者:え?  投稿日時:2015/09/12 21:21 親投稿 - 子投稿.1 No.144

ケーブル自体の被服にはcat5e FTP PATCH CABLEの印刷がありました。
RockdiskNextとか、ShareMAXあたりの添付ケーブルと似たような感じですが、それらは手持ちのケーブルで配線してあるので箱から引っ張り出さないと刻印は確認できないです。
コネクタは樹脂製のRJ45に鎧を着せたようなものでしたが、実際の結線はわからないです。自分のものじゃないんで、見た目しか確認してません。
使って無いとはいってたので借りてくれは良かったですかね。

もし、間違いで「安心して使えるものだと思われる」ということなら、それはそれで、大事な情報なので、教えていただければ。実物が無いと確認できないものは今すぐには確認できませんが。

投稿者:え?  投稿日時:2015/09/12 21:27 親投稿 - 子投稿なし No.145

 投稿者名がかわってました。
 オートコンプリートを使っていて、他の候補も出ないので、なにを間違えたのかわかりませんが、ん?と同一の人物と思っていただければ。
 影響は無いと思いますが、特に別人物を騙ったわけではないので、一応修正です。

投稿者:たく  投稿日時:2015/09/13 00:16 親投稿 - 子投稿.1 .2 No.146

え?さん

>ケーブル自体の被服にはcat5e FTP PATCH CABLEの印刷がありました。
 シールドが編組チューブ(アルミ線を編込んだ物だと思う)を使用したものかと思います。
 STPとFTPの仕様とか探せば詳しく判るかもしれませんが、メーカーが独自に作ってる可能性もあるので、切って中身見ないとわからないかもしれません。

ケーブルがSTPやFTPであっても、コネクタ側のシールドと結線されていなければUTPケーブルと同じように使えるものと思います。
テスターで導通確認するのが正確なんですが、持ってる人の方が少ないですよね。
RockDiskNextに添付されてたケーブルのように半田づけされてたら、調子が悪い時はケーブルを1番に疑うポイントになるかと思います。
コネクタのシールドにセロテープでも貼って簡易絶縁すれば切り分けになるのでは…?

コネクタは従来のRJ45(正式には8P8C)より、ARJ45等の方がケーブルとの接続箇所でのノイズに強いと思われるので、コネクタだけARJ45等を採用してるのではないかと思います。

IO Dataで唯一現行品のLANケーブル「LC-C6シリーズ」のコネクタもシールドされているのでSPTか判断出来ない形状ですが、
http://www.iodata.jp/support/qanda/answer/s18140.htm
サポート曰く、シールドなしUTPだそうです。

あとフラットケーブルですが、使いやすいのは良いのですが
ツイストペアではない(TPのあるのかな?)ので、ノイズにはどうしても弱くなってしまいますね。
短ければまだ良いのかもしれませんが…
あと長すぎるケーブル買って、余った分をとぐろ状に巻いてノイズを誘い込んでないかな~と…

この辺のノイズ対策も色々あって、回路設計段階で決めるものなので
for Audioでその辺も考えて作られてたら、素直にほめてあげたい。

ファームウェアじゃ変更出来ないから、RDNはもう遅いんだけどね…

投稿者:Takeshich  投稿日時:2015/09/13 01:59 親投稿 - 子投稿なし No.141

え?さん たくさん

返信ありがとうございます。

サポートから何度も何度もデタラメでテキトーで嘘な回答をされていると
たとえ正しい回答だとしてもそれを素直には信じられず、確固たる証拠を示さないと
信じられない状態です。

そういう状況なので本当かどうかは疑わしいのですが、いわゆるGPL違反状態については

>サポートセンターのみではなく、弊社全体の問題として確認させて頂いております。

とサポートからは回答を得てはいます。

inXtronがソースコードを出してこないので、IODATAとしても対応できないような雰囲気です。
もしかすると現状、両者の関係があまり良いものではないのかもしれません。

手動アップデータの公開は本件の解決を待って行う予定です。
http://bbs.ioplaza.jp/forum/index.php?topic_id=2718#post_id10511

解決後一ヶ月以上経過しているのに、未だに対応されていないことや
minidlnaのソースコードについては、以前は指摘後10日程度で出てきたのですが、
今回は、いつ出せるかわからないけど、得られたら出すと回答してきていることが
そう考える理由です。

DLNAサーバーのフォルダ表示について
http://bbs.ioplaza.jp/forum/index.php?topic_id=2726

においても担当者とinXtron間の伝言ゲームが行われたようにも思えません。
あくまで推測ですが。。。

>末端の人が理解してないのはよくある事で、こういうケースに対してどう対応して良いかノウハウがないのでしょう。

末端の人が理解してないのは仕方のないことなのですが、
今回は担当者(ioplaza)が理解していないか理解していても遵守する気がなく
テキトーな対応をしつづけていたというところが問題なのです。

たぶん、最初は担当者(ioplaza)が理解していないでinXtronがテキトーな返答をしてもよく理解せずに
こちらにそのまま回答してきたのだと思います。
そのうち当方からの指摘で対応の不味さにちょっと気がついたけど訂正することなくゴリ押しし、
その酷さに当方が一度はもういいやとなったので、事なきを得たのでしょう。
でも、当方がNICのバグの件でもう一度突っ込むと社内の他方からの指摘もあって
きちんと対応しないとまずいということになったけど、ファームウェアの更新時には
理解が追いついていなくて、対応しなければならないことができなかった。
現状は本当に理解できているか不明といったところだと思います。

そもそも
>ちゃんと同じようなのを作ってる部署に手順を確認すれば「発売前に準備されていた」はず
ですよね。
そして、担当者(ioplaza)がきちんと理解していれば、RockDiskNextは販売されることがなかったか
きちんと発売前に準備され、販売されて、今回のようなことは起きなかったはずです。

現状、IODATAから問題解決のための対応策も説明なしに、ただ待ってほしいと言われています。
それには納得出来ないので、対応策などの説明を求めています。
法務部門や顧問弁護士にも積極的に関わっていただき迅速に進めてくださいとお願いしているのですが、
サポートから先に伝わるのかなぁ。

投稿者:え?  投稿日時:2015/09/13 02:25 親投稿 - 子投稿なし No.147

 色々ありがとうございます。

 テスターは自分は持ってるんですが、相手方には多分無いので、今すぐはむりですね。ただ、オマケの品がいくつも無駄にバリエーションが有るとも思えないので、RockdiskNextのそれがそうなら仕様はおなじ「可能性があり」ます。
 何処が結線されてたらどうなんでしょ。シールド間が接続されているかなら、シールド部分は大きいので簡単にわかりそうですが。ざっと見たときには、食い込んでた気もするので、繋がってそうでしたが、確認はして無いので断言できないです。それ以外に確認するところありますかね。可能なら次の機会に確認します。

 まぁ、問題は、「少なくともRockdiskNextの場合は、少なからず速度が遅いで済めば良いほうで、不安定なんてケースすらある」という状況が問題で、再現性がたかければいいんですが、うちでは…いや、そもそも試してなかった…。どうなんだろ。症状が出ないと、切り分けようも無く、「そもそも切り分けられる必要が出るような疑わしいものじゃなくて普通の付けたほうがいいんじゃないのか?」という話なので、もし原因がケーブルの仕様ではなく、それ以外の加工精度などの品質によるものならそれはそれで「やっぱりもっとまともなのにしてよ」であって、「動作確認に使う程度のものを入れるなら入れてくださいな」なのです。見た目が同じなら「大丈夫なの?」って思うわけですよ。目立つのがあのシールドとケーブルの種類なので、最初に疑っているだけで。でもあの太さとシールドの派手さで、100円ショップのケーブルの方が道具としてマシだったら本当に意味無いとは思います。仮にケーブルのリコールとか変更のアナウンスがあれば「そういうものではなくなった」と判断できますが、見た目はダメなのと同じではユーザー側からは判別できませんし。「犯人はケーブルでした」だけはつけるのやめるか、普通に使えるのにしといてと。

 「調子が悪い、悪かった」ではなく、「そういう話が出てる部材ではないかと疑われるものが使われている」ので、手にする人はもしおかしければ、確認したほうがいいのではないか?という話ですね。

 http://www.sanwa.co.jp/lan/lan_qa.html#kb_q5
 こんな話もあるので、素直にUTPで普通のRJ45の方が「安全」な気がしますし、それで駄目な人が他のグレードを買えば良いような気がします。「一番地雷になりにくい選択」ならソレが一番良いと考え居ているのですが。

 フラットケーブル云々については、オマケケーブルの代案の話なので、家庭で使うものは普通の人が取り回しやすく使いやすく、かつ、どうせ短いのしかつけないんだから、ノイズを気にするほどのケースは少なかろうという「どうせオマケでつけるなら、HDL-Aとかと同じようにあの部材でいいんじゃないか」というくらいの話です。なので、長すぎるとか、とぐろっていうケースはあんまり考慮してません…がとぐろとかは、一般家庭だとやりがちかもしれないので、説明書に注意書きはあったほうがいいかもしれませんね。

 ただ、LANの場合回路設計といっても、「もう片方の尻尾」は不定なので、害に転じる可能性のある部材はやめとくべきだと思います。
 対応なしなら、何も起きないが…というものは別として。
 接続する先まで選んでいる製品は別ですが、こういう製品の場合は、「よく考えること自体が難しいので素直に作って素直に選ぶほうがマシ」とおもうのですが。

 でも、パッケージに入れて保存するわけじゃなし、見た目とケーブルの種類が、普通のUTPっぽくないケーブルって罠でしかないような気がしなくも無いです。区別の必要がなければ良いんですけど、あるんですかね?効果。

投稿者:たく  投稿日時:2015/09/13 02:38 親投稿 - 子投稿.1 No.149

Takeshichさん

多分Takeshichさんが確認に必要なのは
uImage(linux kernel),U-Boot(stage1.wrapped,u-boot.bin),rootfsなどの作成に使われたソースコードですよね?

となると、SDK(NAS_AP_Team_NAND_SDK_20110801)のほとんどと
inXtronで改変されたソースが必要になりますね…

いまさらさらですが、応援が必要でしょうか?
派手な事は出来ませんが…

投稿者:たく  投稿日時:2015/09/13 06:38 親投稿 - 子投稿なし No.168

え?さん

>何処が結線されてたらどうなんでしょ。
 コネクタのシールド両端で結線されてます。
 ちょっと見ずらいですが下の写真 矢印のところで半田づけされてます。
 製造工程が進化して完全にコネクタ内に収まってたり、ブーツ履いてたら見た目では判断できませんね。
 両端のコネクタシールド間をテスターで導通確認し、導通してたらメモつけてジャンク箱か元箱へ封印してくださいw

投稿者:たく  投稿日時:2015/09/13 06:50 親投稿 - 子投稿.1 No.169

え?さん

>まぁ、問題は、「少なくともRockdiskNextの場合は、少なからず速度が遅いで済めば良いほうで、 …

 このLANケーブルの件は、RockDiskNextに限った話ではなくネットワーク機器全般の問題なので、ある程度見分ける知識も必要なんだなぁと思う。
 今回は言われるまで気づかなかっただけに、偉そうに言えないけど…
 最近は独自規格ばかりで毎回サポートに確認するのも面倒だし、不具合あってもメーカーは詳細にフォローしそうもないので
 以前「私は付属品のLANケーブルやUSBケーブルは基本使わないよ。逆につけないでほしい。」と書いたわけです。
 メーカーとか規格が違う物が混在するとトラぶった時に切り分けにも時間かかるんで、大体同じメーカーで同じシリーズので揃えてます。
 
>「調子が悪い、悪かった」ではなく、「そういう話が出てる部材ではないかと疑われるものが使われている」ので、手にする人はもしおかしければ、確認したほうがいいのではないか?という話ですね。
 その通りですね。
 RDN以外でも使われている可能性もあるので、まず確認を!

>ただ、LANの場合回路設計といっても、「もう片方の尻尾」は不定なので、害に転じる可能性のある部材はやめとくべきだと思います。
 「もう片方の尻尾」が対応してない場合は、相手側が開放状態という事なので
 その辺検知するようにして不平衡状態時にはGNDから切り離すぐらいの芸当が出来ないのかな?今の技術ならそれぐらい出来そうだけど、今の自分にはそこまでの知識がないので軽く言ってしまってるが、
 こんな風に悩まなくてすむ無難な部材を選らんでつけて欲しいですね。
 せめて取扱説明書に書いておいて欲しい。

>あるんですかね?効果。
 コネクタが結線されてないSPT、FTPケーブルの場合ですが
 外来ノイズは多種多様で、どんな外来ノイズがシールドで抑えられるか、また通信に影響あるのか自分で検証しないと納得出来ないけど、そんな機材は個人じゃ揃えられないな。。。
 sanwaも高出力スピーカーの傍で使用される事まで考えてるかな?
 周波数が高くなればケーブル内部からもノイズとして漏れると思うのですが
 そもそも電流は電位の高いところから低いとこに流れるのが基本で、シールドがあってもそこの電位が不明な状態だったら、吸収もすれば反射もするという曖昧な状態って事で、一見意味なさそうだけど理屈的には確かに外には漏れにくいな…
 ただコモンモードノイズは増加するだろうけど許容範囲内なんだろうか。。。

 結論としては、ノイズに対してUTP以上のS/N比向上効果は期待できないと思います。
 ただし、ケーブル内部から外部へのノイズはUTPより抑えられ、隣接するケーブルへの影響は減少するのではないかと思われます。
 まだまだ不勉強な所がありますので、参考程度でお願いします。

 コネクタがシールド処理されているSTP、FTPケーブルでは、対応してる機器間では内部、外部からのノイズはどの程度かは判りませんが、シールドで吸収してくれると思いますのである程度の効果はあると思います。
 ただ1000BASEより上の規格でないと、その恩恵は体感できないかもしれません。

投稿者:Takeshich  投稿日時:2015/09/13 13:47 親投稿 - 子投稿.1 No.150

たくさん

>多分Takeshichさんが確認に必要なのは
>uImage(linux kernel),U-Boot(stage1.wrapped,u-boot.bin),rootfsなどの作成に使われたソースコードですよね?

そうですね。開示までに時間がかかって本来やろうと思ってたことのやる気は失せてしまいましたが、
開示され公開することでもしかすると別の誰かがいろいろと対応してくれる可能性もあるので、
この件は最後まで進めようと思っています。

>いまさらさらですが、応援が必要でしょうか?

よろしくお願いします。
ただ、ご存知とは思いますが、サポート、担当者がひどいので
イライラする事が多々あると思います。
それでも構わないのであれば、ご協力いただけると大変助かります。

サポートからどういう回答をもらえるかは興味があります。

投稿者:え?  投稿日時:2015/09/13 14:24 親投稿 - 子投稿なし No.170

 コネクタ部分はブッシュの様になったところからシールドに掛かってたと思うので、写真の様には覗き込めなかったと思います。
可能になってたら見たと思うのですが、記憶に無いので。やっぱり真相はシールド間の接続を確認してみないとわかりません。これもまた、原因がコイツなのか、ケーブルや加工品質の問題なのかで話が変わるので、STPを理由に切り分けていいのかも微妙ではあるのですが、「添付ケーブルはあちこちで災厄を招いていて、ふつーの安物の方がマシな結果をたたき出す」のは真でも、それがシールドの悪影響によるものであると証明することができないうえ、「安物はUTP」なので、カタログが立派なシールド様より結果が出ないのは駄目なわけで。

 ただ、結局ユーザーが自分で買っても買ってくるのも規格のなかで定義されたものを満たすものというだけですし、多分サポートの切り分けも「付いてる奴でやってみてください」がセオリーだと思うのですよ。
 ですから、期待はしないが、「こういう安いのを買う人で、広告の文句に惹かれるような人」は多分素直に添付品使うんだから、無難なの付けろよとwそうしないとサポートにとっても地雷になるんですが、ここのサポートのセオリーの一つである「見てやるから送って来い」発動ってのは乱暴だと思うのですよね。
 つけなければ付けないで、足りないとか不便だって文句言われるからつけているのでしょうが。

 まぁ、一応ケーブルとかサプライがメインなサンワを引きましたけど(だってI-Oのページに説明無いし!)、基本的に「説明を必要とする人」向けの説明ですから、主にこんな風ですよって解説なので、あんまり意地悪な条件付けしたらかわいそうだとは思います。「ちゃんと考えたの?」っていう仕様表とか、ページ構成とちがってw
 個人だと計測のしようも無いですし、どこぞのセンセみたいに音が違う!とか、そんなもんわかるような解像度を得られる機材も耳も無いですし、「俺様理論はどうでもいいから、商品は素直なの作って!」です。シールドされてるコネクタにシールドされてるケーブルでかつ、アースに落ちませんし繋がってませんってそれって、パッケージから出したら、ただのトラップじゃないですか(当該の製品はケーブルのシースにはUTPってちゃんとなってるかもしれませんが、底意地の悪いw

>ただ1000BASEより上の規格でないと、その恩恵は体感できないかもしれません。

 こいつを「悪い方向に違いを体感させられている」って人が居ることが論外なのです。そういう原因になるなら「素直にふつーのつけろ」と。「違いがわからない」ってのは「機器のパフォーマンスはでていて、買った人の役に立てている」ということですから、幸せで素敵なことです。その状態を作れればどんなに安物でも良いんです。そもそも、まともなケーブルだったら、長さがなければ、結構な粗悪品でも「ふつーに」働いてくれるものだと思います。「何かおかしい」と思わせるものが「ダメ」なだけです。今回のは「もっとイイヤツ」じゃなくて「ふつーのにして。ふつーのに」って話ですし。

 あれを「選んだ」のなら、広告に書けるくらいのこだわりがあるんじゃないかと思うのですが、言及は無いですねぇ。

投稿者:え?  投稿日時:2015/09/13 14:39 親投稿 - 子投稿.1 No.151

 新規の問い合わせのアクションを起こす方は別として、いい加減「責任者出せ、わかるやつ出せ、対応できるやつ出せ」で良いんじゃないかと思います。クレーマーじゃなくても一年越しで未だに目先の時間稼ぎと相手が諦めることを期待した持久戦とか、サポートの仕事になってません。

 多分担当者も「そういってあげたほうが助かる」と思います。
 権限はないし、対応できないから上に上げると嫌な顔されて戻ってきた回答をユーザーに戻すとまた怒られてってそんなの誰も幸せにならないです。
 上が嫌な顔してなけりゃ、下の人が適当な言い訳して誤魔化して辻褄合わせようなんてしないとおもうのですよ。また痛い目みるの自分なんですから。

 仕事としては仕方なくても、なんか違う人に負担がのしかかってるように見えるのですよねぇ。
 結構適当な事を垂れ流すサポートではありますが、基本的には、ユーザーに対して会社としての対応をしているわけですから、担当者の権限や知識よりは、いっていいこと、公式の見解が優先される形になると思いますし、サポートの担当者が頭越しにOEM先と交渉するわけ行かないわけですし、多分今話してる相手には「どうにもできない」と思います。普通の製品サポートならこういう拗れ方しないんですけども…。
 まぁ、人が上の人に代わってもこれなら、こっち側は配慮のしようがありませんが。

投稿者:Takeshich  投稿日時:2015/09/13 18:43 親投稿 - 子投稿.1 No.152

え?さん

回答における日本語の使い方や文章の展開において、GPLについては怪しいですが
ある程度のものが時々来るので、おそらく上の人には伝わっていると思います。

inXtronとはソースコードの開示について交渉をしているけど難航しているということを
1ヶ月前に回答されたので、一部の人は問題について、最近やっと理解できて、
きちんと対応しなければならないこともやっと理解できたのだと思います。そう信じたい。

企業間での交渉をはじめて1ヶ月経っても、ソースコードが出てこないのだから
交渉を継続しつつ、当たり前ですが、何らかの別の対応をしなければなりません。
各著作権者に連絡を取って、inXtronからソースコードを出させるようにするしかないと思うのですが、
IODATAにしてみれば、連絡を取ることによってRockDiskNextについてGPLを遵守せず販売していたのが
著作者に知られる可能性があり、損害賠償請求などリスクがあるのではないでしょうか?
そういう意味合いもあって対応について決めあぐねているような気配がします。

もしそうなったら、身から出た錆なので甘んじて受けるしかないと思うのです。
個人的には。

更新されたminidlnaのソースコードを開示請求した際(8月末)には、サポートと担当者のいつもの
ひどい対応だったので、今、ソースコードを開示請求したら、どのような対応なのか興味があります。
そういった意味では、担当者は対応についてなんかやばいことはわかったけど、
対応しなければならないことについては、理解できていないと思え、もうかかわらないで欲しいです。
最初から上の人の対応になるわけでもないですから、伝わるまで苛々する処理を経なければなりません。
改善されていればいいのですが、期待できないですよね。

投稿者:え?  投稿日時:2015/09/13 20:20 親投稿 - 子投稿.1 No.153

結局伝言ゲームになってしまうなら、そのノイズの発生源を一つバイパスすることにも意味は有ると思うのです。すくなくとも「その人がバッファになることで、その上の人に本当に酷いことが伝わっていないか、その先がどうかしてるとしか思えない」ので。
そして責任を取れる人が矢面に立って、「いい加減にしろ」という声は聞く必要があります。いい加減な対応によって部下や、下の人間に負担を押し付けるなら肩書きなんてゴミなんですよ。本当にまずいとおもってれば出てくると思うのですが。ユーザーが怒っているならそれは上がってきた問題に対して怠惰な対応をした結果なのですから「そいつのせい」です。無毒化された報告だけだからいつまでものうのうとしてられるのだと思うのですが。少々のことで上を呼べなんてのはどうかとも思いますが、一年嘘まで並べられてまで遠慮する意味も無いと思います。それでいいのは「相手が誠実さ、真摯さを見せているときだけ」じゃないでしょうか。少なくとも、ユーザーや、その仕事のフローの想定外の状況については、「対応するべきなのは上の人」ですし、それでも、直接対応が出来ない人が矢面に立つのは、同情をしてしまいます。

この会社全体が「目の前が乗り切れれば」なのがアレなんだとおもうけど、(根拠が無いわけではなく、購入前、購入後の別製品を含むサポートなどをみてて。)それにしたって適当な仕事の尻拭いを下がやるっておかしいんですよ。普通は上の人が下の失敗(それが委嘱先なのか、部下なのかは知らないけど)をきちんとフォローしてやるから肩書きがあるわけですし、権限が無いと対応でき無い事だってたくさんあります。ですから、対応に必要な権限は持っている人が出てこないとまた何年もかかります。

というか、「実は微塵も理解していない」のは
>更新されたminidlnaのソースコードを開示請求した際(8月末)には、
>サポートと担当者のいつものひどい対応だった
ここに現れてます。
話を聞いてて、問題だと思ってれば「リリースの前にソースを出させないと」「リリース直後に請求があるかもしれない」のに対応できるわけが無いのは「バカでもわかるはず」のことなんです。一部が認識した?認識して繰り返しますかね?一年突きまわされてることですよ?w
それを「しないでリリースしてヘラヘラできる」のは自分達の問題として認識していないし、理解もしていない証左ですし、話を聞いていたら、「事前にないと困る」のは考えるどころか反射のレベルで理解できるはずです。そうならないのは「大半が右から左」だから以外に理由は無いですし、ソレが不可能なら「リリースを先に止めるべき」なのに気がつくことができない担当者は人を変更するか、わかる人をつけてやらなければ会社の信用に関わります。

「他はともかく、先生に媚びうるために行った修正」なんですから、該当するファイルが修正されないわけが無いので、(先に連絡しない担当者もどうかと思うけど)予め準備してから頒布、販売をするっていう手順を「行えない」のは「何も変わってない」ってことです。
逆に、それが改善されていてはじめて、理解してくれていると認識することができるのだと思います。
逆に「miniDLNAの今回修正したところを出してください」といわれて「すぐに出てくるようなら」他のことやこれからを信じて良いと思えるわけですが、そうならないのは「本気で話なんてきいてないし少なくとも真剣に問題が有ると認識できていない」ということです。

話を聞いて、問題だと認識するってことは「同じ事を繰り返さないこと」でのみ証明されます。口先だけの文言なんて小学生だって取り繕います。miniDLNAについては一度請求されているわけですから「違うファイルだから違う話だい!」という戯言も不可能です。それがGPLであり、ソースを公開したわけですから、その派生物である変更点が「除外されるわけも無い」し「変更点を出さないといけない」のはそのサポートの履歴によって、話を聞いていて、りかいしているなら「回答として不適切で、対応も不適切」なのはメールを返信する前に顔が青くならないとおかしいところです。
が、そうならない。それでも不味いと思ってる人が本当に存在するのでしょうか。少なくとも本気で問題があると思ってる人の存在には疑問符をつけざるを得ないです。

わからない、できないは仕方ないですが、せめて「正直では」あってほしいですし、そうじゃないと信用できなくなってしまいます。そういう露骨な嘘すら並べる対応をされているのは「信じてくれるとは思わないけど騙せて誤魔化せればいいか」と思ってるのではないかという疑念も生まれます。「あきれて黙ってくれればそれでいい」も含まれてるように思うことも無くは無いのですけれど。

投稿者:Takeshich  投稿日時:2015/09/13 23:49 親投稿 - 子投稿.1 No.154

え?さん

更新されたminidlnaのソースコードの開示請求への対応について、
サポートには、もし理解しているとするのであれば
ライセンス違反と知りながら違反をするという行為が悪質だし、
理解していないとすれば、それも問題があることについては、
強く何度も指摘しています。

それを受けても、サポートは理解していると答えてきていますので、
問題ある行為をした自覚はあり、しなければならないことを理解していると思いたいです。
全く信じられませんが。

>わからない、できないは仕方ないですが、せめて「正直では」あってほしいですし、そうじゃないと信用できなくなってしまいます。

残念ながらサポートは、そうじゃないので、信用できません。
毎週金曜日に状況を伝えてきていたのですが、その中でサポートが進捗を報告するという表現を一度だけ使ったのですが、
次から進捗どうですか?と聞いても回答せず、最近、進捗については具体的に紹介できないという回答を得ました。
間違って言ってしまったら、すぐに直せばいいものを、訂正すらしません。
真摯さが全くありません。
全く信用できません。

>きちんと対応しなければならないこともやっと理解できたのだと思います。そう信じたい。

と書きましたが、
きちんと対応しなければならないこともやっと理解できたのだと思います。そう信じたい。けど信じられない。
というニュアンスでした。
もしかするとうまく伝わらなかったかもしれないので。

サポートから何度も何度もデタラメでテキトーで嘘な回答をされていると
たとえ正しい回答だとしてもそれを素直には信じられず、確固たる証拠を示さないと
信じられない状態です。

そういう現状において、対応していることすら怪しくなってきてしまい、本当に対応しているのか?
対応しているというのであれば、今後どういう対応をするのか
対応策について回答を求めています。

投稿者:え?  投稿日時:2015/09/14 01:13 親投稿 - 子投稿.1 No.155

 私が「責任者出せ」で良いんじゃないかというのは、通常のフローを外れていて、多くの回答にもう一段通さないといけない案件だからです。
 下のほうからもうわからないからお願いしますといいづらいこともありますので、場合によっては「責任者出せ」を言ってもらえるほうが下の人は助かることもあります。実際の運用はわかりませんが、普通は長引いてると上の人が出てきて対応したりする形に(内側に居て知ってる別会社では)してたりして、いつまでも伝言ゲームを時間稼ぎながらするところは無かったです。
 そんなこともあって、サポートが検証、開発に連絡みたいな問い合わせならばいざ知らず、結局外と折衝しないといけないケースなら、どうせ役に立たないプロセスは排除して、怒ってること、いい加減に真面目に仕事して欲しいこと、それが知財に関わることで、他者の権利に関わることで、信用に関わることであるということはきちんと認識してもらわないと、また片手間の作業になってしまうと思います。
 大体「あわて始めた」のって、電話で企業コンプライアンスに対する問い合わせって何処ですかね?って話をしたときじゃなかったですかねw大事なのは目先のことが大きくならないことなので、つれたのだと思いますが、説明はされているのですし、「よくわかんないけどソース出せっていわれてるんですけどー」みたいなダメ伝達でもしていなければ、何か思わないとおかしいところで、それが一年近く続いてることも考えれば、鈍感なんじゃないかと。普通は上がってきたら履歴も経緯確認するために見ますよねwそうするとずらっと一年分ログがあったらびっくりするのが普通だと思うのですが。

 その状態でも、バッファになる人を入れてしまうことで、時間を稼げば諦めるだろう的な甘い考えを生んでる気がしなくも無いですし、それによって、色んなものが伝わりにくくなっている(そうじゃないとありえないような受け答えもありますよね。)と思うので、せめて直接(今回は)役に立たない人は外していただくのが良いと思うのです。そのほうが、多少でも伝わりやすくなるだけ、お互いマシだと思うので。

 サポートの外にも言わないとダメなのかなぁと思うのは、「この目の前のやつだけ黙らせれば仕事できるやつ」的な対応が、「全部そう」で他所のサイトでも「被害者」が多々居るので、わかっててこの質なのか?って思ってしまうのです。
 ちょっと厄介な話だったから、ちょっと難しい状況だったからというなら仕方ないですし、すぐできないこと、難しいこともあります。
 でも、黙らせるための嘘なんてどっかの知恵袋じゃないんですからソレはダメです。百歩譲って「言い方」で誤魔化すのはありでも嘘はダメです。どうせ忘れて別の担当者や同じ人が違うこといっちゃうんですから。

 ですので、対応としてはとりあえず精神的にヘラヘラできる要因である盾になってるだけのひとに外れてもらう。肩書きや評価がかかってくれば、「目の前のことが大事な人たち」は頑張り始めると思います。実際お互いストレスになるだけで盾のひとと話すプロセスに意味が無いですよね。担当者に直接クレームを言うとははーということを聞くらしい先生にも「太鼓持ちなんてやってるとあなたの名声も傷が付くと思いますが。知財に鈍感でなにがすばらしいと?誰が頑張ってると?」とお話をする。別の部署に「企業コンプライアンスの外部向けの相談窓口はありませんか?サポートでは役に立たないです」と相談してみる。どれも行儀は良くありませんが、正攻法でダメなら「やる気があるのか、できるのか」を確認するにはそんな方法しか無いように思います。
従来どおりの方法で、必要が無いストレスを感じる人が居続けるのはあんまり得策とは思えないとはおもうのです。
無理強いはできませんが、相手が信じられないのに正攻法でお互い疲弊するのは良いこと無いと思うので、無理だったら、正攻法以外の手段でも仕方ないと思うのです。どうせ適当な返事なんだろうなって思って書くほうも、それを受け取るほうもいい気分じゃないでしょうし。

 正直で、頑張ってる様子だと、「ダメなんだけど、伝わって無いけど、まあいいか。」って思えたりもするんですけどね…。逆に良くこれで回ってたなって思ったりもしますが、開発の方は比較的真面目な人が多いのかもしれませんね。ioplazaだとバイヤーさんみたいなものですから、後ろでサポートを支えるのは厳しいですよね…製品ページがあの有様で、マニュアルがああなんですから…。……よくこれで長期保証で法人様もどうぞとかチャレンジャーな事言えたよな……。いろんな意味で。

投稿者:え?  投稿日時:2015/09/16 19:11 親投稿 - 子投稿なし No.148

 借りられたので確認しました。HLS-Cの添付ケーブルのシールド間はきちんと繋がってますね。
 ですから、見た目だけシールドじゃなくて、ちゃんとシールドされてるみたいです。ただ、ブーツを履いてるので、規格はともかく、モノとしては違うかもしれないのでRockdiskNextの添付品があちこちで駄々捏ねてるのとは違う傾向を示す可能性もあります。ただ、普通に作られたケーブルとの特徴的な違いとなると、それがケーブル自体の品質そのものじゃないなら、やっぱり似たような問題をばら撒く可能性を孕んでます。

 発生状況が限定的なので、RockdiskNextとか添付品としている機器側は「使っても大丈夫」でも、HUBとかルータとか、向こう側が、アースとGNDの扱いが微妙とか、不適切とか、ケーブル自体の加工が甘いとか、単体で完結しないだけに、RockdiskNextでありがちな添付ケーブルでの問題は、どこに原因があるのかは判断が難しいです。ただ、HUBとかルータとか向こう側の仕様表で「UTP」って書いてあるようなら、「対応してるなんて言った覚えはありませんが」で仮にアースの処理が単にGND直結になっててもそっちが悪いとは言え無い様な気もしますし。

 ただ、ちょっと気をつけたほうがよさそう。という感じでは有ります。で、中の人は気がついたら、「ふつーのつけて下さい。ふつーの」。その派手なのつけてもらっても性能を発揮できる環境作れないので。cat6のUTPにしてくれたほうが多分不幸になる人は少ないんじゃないかと思います。

 セロテープだと、熱だの経年劣化だので抜いたときにゲンナリすることにもなりかねないので、絶縁して使うくらいなら、普通のを買ってきたほうがよろしいかとも思います。

 一応騒いだ手前確認とその結果のご報告でした。
 まぁ、確認できることは違うケーブルだとマシになるってだけなので、オマケケーブルの「なにが」「誰と」仲が悪いのかはよくわかりませんけどね。

投稿者:Takeshich  投稿日時:2015/09/18 22:01 親投稿 - 子投稿.1 No.156

回答が不誠実で真摯さを感じられないと突っ込んでいたら

> ソースコードにつきましては、弊社と致しましても製造元に強く要求しておりますが
>、
>現段階でまだソースコードの提示がない状況でございます。
> その為、弊社と致しましてもGPLを順守したいと考えており、引き続き働きかけを継
>続している状況となります。

と回答頂きました。ある程度信じてもいいと思いますので、現状でしょう。
IODATAとしての意思もそうなのだと思います。

しかし、交渉をしていると言ってきてから、2ヶ月ほど経つので、
GPLを順守したいと考えるなら、引き続き働きかけを継続するだけでは不十分で
IODATAには各著作者に対してどう対応するべきかを連絡して、確認してくださいとお願いしてあります。
8月末からお願いしてあることなんだけど、理解しているのかは不明です。

少しはまともな回答が得られました。

貴社の法務部門、顧問弁護士やGPLを理解している技術者の方などに確認頂き回答くださいと何度も言ったあとの回答なんで、責任者の回答なのだろうけど。。。

投稿者:たく  投稿日時:2015/09/19 00:17 親投稿 - 子投稿.1 No.171

Takeshichさん

とりあえず私も請求してみました。
「まだ準備出来ないので、待ってください。」との事でしたw
まだプライオリティが低いようですね…。
変に横槍しないように気を配ったつもりだったけど、無用だったかな。
まだまだ時間かかるんだなぁ…

akitioはinXtron名義のGPL文書を出してるけど。IOはこの期に及んでも、まだ何も出してない。
製品に添付できなかったとしても、その意思表示をなぜ公に示さないのだろう。
inXtronは自分で出した文章の意味や内容が判ってるとしたら、IOから請求が来たら準備は容易なはずと思うのだが
何に時間がかかってるのだろうか?理解に苦しむよ。

え? さん
確認ご苦労さまでした。
今回通信不良していた環境だと、接続相手のルータのコネクタがシールドされてない物で
完全にケーブル片側が浮いていたので、症状が顕著に出たのだと思います。
ETX-ESH8はコネクタ部がシールドされてるっぽいので、酷い状態にはなりにくいかと思います。
また、HLS-C自体がこの手のノイズが他回路に回り込まないように工夫されているかもしれませんね。

投稿者:え?  投稿日時:2015/09/19 00:20 親投稿 - 子投稿.1 No.157

まとも…なんでしょうかね?

ちょっと盛ってあるけども、「開発元(製造元であってるんだろうか?)にソースくださいと交渉中です。」
事実はこれだけなんじゃないでしょうか?
実際には危機感が無かったわけですから、返事によって対応も変わるかもしれませんし相手が突っぱねたらごめんなさいされちゃう可能性の方が高いと思います。開発元相手には、一寸は頑張ってくれるかもしれませんけれども。というか、これくらいの返事、ほぼ何もしてなくても返ってきそうな気がするんですが、今までのはどれだけ酷かったんでしょうw

…まぁ、「リリース前に処理して無いやつ」が悪いしそのいい加減な仕事に気がつかない周りとか上もザルなのも悪い。サポートもいいとばっちりだとおもいます。というか、そんな人だから、ユーザーに不利益のある障害は放置して、パッチは捨てちゃうんだと思うのですがwいったい何処の誰がオーディオ好きなんだかw頑張りすぎて、エンバグしちゃったくらいなら許せる失敗なのですが、信用を毀損するような仕事した本人よりサポートが悲鳴上げてるのも変な話ですねw

多分、
>IODATAには各著作者に対してどう対応するべきかを連絡して、確認し
>てくださいとお願いしてあります。
これは何を言われてるんだかわかって無いし、多分そこまでする気は無いんじゃないかと。だから返事は無いんじゃないかと思います。
開発元とは話す気があっても、含まれるソフトウェアの権利者まで引っ張り出す気があるとは思えないです。それくらいの責任感があれば、リリース前にちゃんとします。

なんというか、表面的に機嫌取りに来たなっていう実の無い装飾は期待してはいけないと思います。そりゃ、不満や、思ってることは伝えているわけですから、返事はそーなりますよね。理解して無くても。問い合わせに対する回答じゃなくて「感情に対する回答」になってるんだと思いますよ。

他所でもそうなんだけど、ああ、わかんなかったんだなっていうモゴモゴしてる返事が来ると、可哀想だなとおもいつつ、わからないと困るけど…とか色々迷います。できれば切り分け位できる人を窓口においてください…。多分他のお客さんもこまるよなーとか、でも、部外者が怒るのもちがうのかなぁとか、誰かに負担を掛けてまでどうにかすることかなぁーとか迷います。

とりあえず、お疲れ様でした。製造元さんの機嫌次第ですね。でも、アップデータがああってことはちゃんと整理できて無いんだろうなぁ。

投稿者:Takeshich  投稿日時:2015/09/19 01:23 親投稿 - 子投稿.1 No.158

たくさん

>まだまだ時間かかるんだなぁ…

7月末にソースコードに関する交渉が難航している状況という連絡をもらいました。
その後8/7にメーカーより情報は提供されておらず、引き続き交渉中という連絡をもらいました。
その後、交渉の状況については連絡いただけていませんでした。

まぁ、交渉していると言い出してからも2ヶ月ほど経っているのに
現段階でまだソースコードの提示がない状況なのだから、
inXtronは出す意思がないのですよ。

>inXtronは自分で出した文章の意味や内容が判ってるとしたら、IOから請求が来たら準備
>は容易なはずと思うのだが
>何に時間がかかってるのだろうか?理解に苦しむよ。

http://archlinuxarm.org/forum/viewtopic.php?f=27&t=2469
にもあるようにinXtronは出さないみたいです。

http://wiki.myakitio.com/software_gpl
を見ても、私には出す気が感じられません。。。

おそらく、あと数ヶ月とか年単位で待たされるような気がしています。

>akitioはinXtron名義のGPL文書を出してるけど。IOはこの期に及んでも、まだ何も出し
>てない。
>製品に添付できなかったとしても、その意思表示をなぜ公に示さないのだろう。

会社としてのアピールはGPLを順守したいと考えているんだけど、
対応する人がしなければならないことを理解できていないんだと思います。

え?さん

>理解して無くても。問い合わせに対する回答じゃなくて「感情に対する回答」になって
>るんだと思いますよ。

そう思います。
でも、嘘をつかないでねと何度も何度も言っているので、考慮はしているものと思ってます。
まぁ、言ったことが嘘かどうか確認できる場合はきちんと確認しますけど。

理解してなくても、きちんと対応するには理解しなきゃいけない内容なので
きちんと対応されなかったら、突っ込めばいいという感じでいます。
時間をかければかけるほど自組織の信用を毀損するということにすら
想像が及ばないようなので。。。

投稿者:え?  投稿日時:2015/09/19 01:52 親投稿 - 子投稿.1 No.159

 というか、(当たり前すぎて忘れてたけど)「親会社の製品ではFAQから漏れててもきちんとマニュアルに記載がある」使ってますよ宣言が「この期に及んでこの製品のドキュメントに一切無い」とか「どの口が遵守」だっつー話です。

 自分のところの製品のマニュアルか、新規でドキュメントを掲示すれば良いだけのことすらしないで、他所の会社突いて「ソース出してよー」はブーメランになりかねません。
 「お前らだって、しょっぱなから守ってねぇジャン」って言い返されたら返す言葉無いですよね。一応あっちの会社は、「GPLの製品はこれが入ってるんで勝手に公式サイトから持ってけ」くらいの表示はしてるんで、不十分ではあっても「突いてる会社よりは明示してるだけマシ」という残念な状況の人が本当に契約を守る気があるのか?という問題があります。「遵守しなければいけない」なら、一番簡単で自分の管理下にあるところから直さないとダメなのに、他所との折衝を理由に適当な返事するのは悪い人じゃないかもしれないけど、善人だったり誠実な人では無いです。

 責任もとれないし理解もできないものを「オリジナル」だの「自社の名前を冠したり」しちゃダメッすよ。特集で写真があるから時期が来たらドヤ顔しそうだけど、バイヤーとしての目利きがきちんとできてれば「もう一寸素直で、いいやつがお値打ち価格」になるんじゃないかなぁ。値札と仕様表だけ見ちゃうから、「違うところでコストがかかる」のであって。で、ちゃんとなにを売ってるのかわかんないなら、わかる人に手伝ってもらわないとダメだと思う。

 …まぁ、言い分が「なだめるときのセオリー」過ぎて、逆の立場なら、言うかもね的な文言が並んでるので、まともとも、信用できるとも思わなかったんですが。「枕詞」ですし。
 OEMとか、法人相手でどうにかなってるのかもしれませんねw

投稿者:え?  投稿日時:2015/09/19 02:24 親投稿 - 子投稿なし No.172

ドキュメントに明示が無いのはしっかり忘れてました。
本家はFAQになくても、マニュアルにはきちんと明記があります。
ですから、「本家の担当者は相応に仕事してます」。
マニュアルすらシカトしてるのはRockdiskNextだけです。NAS製品でGPL由来のは。

あの添付ケーブルは、遅いってケースは他所でもけっこうあるので、たくさんだけでは無いんですよね。
不安定になるところまで酷いことは少ないようですが、いないことも無いのでもしかするとその人も原因は…。

ETX-ESH8は「使えるとうたっている」(実効性があるか、機能的に使えるかはどうなんだろうと思うけれども)ので、最低限の処理をしていないと困りますw例としてどうなんだろうと挙げたのは「仕様で明示していて、飾りやお守り程度」でも対応と言えるのかな…とちょっと思ったからです。問題が出ないなら、構わないとは思いますが、注釈はいるケースかなと。

別で起こしたツリー絡みでちょっと確認したときに見つけたのですが、
http://www.iodata.jp/product/av/tuner/hvtr-bctx3/index.htm
多分NASにDTCP-IP必須のはずなのにDLNAとしか書いてないw
自社製品の現行品だって一部は満たさないけど、確認済みに無いからしらないって言うつもり?WDの製品も扱うんだよね?あそこのは多分対応して無いよ?DTCP-IP無しで録画できるなら新しいなーとは思うけど…。
HLS-Cとか、Rockdisk for Audioとか、RockdiskNextも無理だと思うのだが、確認済みは「DTCP-IP対応モデルだけ」なんだよなぁ。見事に。
録画は苦手ってかいたのは実はこれが引っかかったから…だったりします。

…民生品に近い製品でこういう広告普通する?
いや、勘違いで、なんならUPnP-AV対応してりゃ大抵いけますぜっていうなら申し訳ないところだし、凄く画期的だけど。
こういうのを見ると、あの仕様表の意味はどういう観点で書かれてるんだろうなぁと思うわけです。無関係でも、サポートとか、店員さんとか地雷踏まれたら大変だなぁって心配してしまうのです。

一回は売れても、騙されたって思ったユーザーは結構根に持って吹いて回るよ?周りにも引きが悪くて壊れたって理由でも、USB-HDDが壊れた経験則でI-Oの製品は壊れるから買うなって何かにつけて言う奴居るし。チューナーボードがらみも結構恨み買ってそうで、合わなかった人は結構メーカーごと全否定の傾向…。

ちゃんと「わかってもらって買ってもらう」って大事なことだと思うけどなぁ。頑張ってもすれ違っちゃうのは仕方ないけど。

まぁ、ケーブルについては「繋ぐ先の仕様表を見る。」そこにUTPしかなければ、普通のケーブルを使う。そんなことを試すと、不幸になる人がちょっとは減るかもしれないと思います。
直接は関係ないんですが「もうちょっと誤解されない仕事を頑張ってみて欲しいなぁ」というお話だったりします。

投稿者:Takeshich  投稿日時:2015/09/19 16:20 親投稿 - 子投稿.1 No.160

え?さん

GPLv2で言うところのsection3のb)の記述については、
http://www.opensource.jp/gpl/gpl.ja.html

GPLについて順守するつもりなら、当然やらなければならないことなのですが、
実行形式で頒布したものに、ソースコードを提供する旨を記した書面を添えるということだと
思うので、これをどう実現するのかは興味があります。

私の考えでは、書面って媒体は紙だと考えるのですが、
そう考えた場合、RockDiskNextを購入した人全員に郵送しなければならないことになります。

PDFで作成した文書で構わないと考えるのであれば、
・添え忘れたことを明記して、HPのどこかにその文書を置く
・購入者にメールに添付して送信
などの手段を取る必要があります。

中古で入手とか更に第三者に渡っていることも考慮すれば
送付とPDFにしてHPのどこかに置くというのが、妥当なところなのでしょうかね。。。
最低限、添え忘れたことを明記して、HPのどこかに置くことはやらないと。。。

この件については、今後、問い合わせていくつもりでいました。

>…まぁ、言い分が「なだめるときのセオリー」過ぎて、逆の立場なら、言うかもね的な
>文言が並んでるので、まともとも、信用できるとも思わなかったんですが。

少しはまともと書いたのは、今までの回答に比べれば少しはまともなのであってです。
一部でも事実と思える回答を得られたということで、お察しください。
そういうレベルの回答なんですよ。。。

投稿者:え?  投稿日時:2015/09/19 19:04 親投稿 - 子投稿.1 No.161

LAN Tankとかだとどうなってたかな…。
インストーラの起動画面の表示と、インストールメディアに直接ソース。あとは箱にあったかもしれない。

でもまぁ、RockdiskNextの場合は基本的に紙一枚入ってなかった筈なので、商品ラベルに記述するくらいしか方法も無かったでしょうね。

ドキュメントはWeb上にあるわけですし、公式の製品ページが基本的に「添付書類の役割」を果たしているとは思います。
本来は「やり損なってること」なので「能動的にユーザーにしめさないと」いけないのですが、興味の無い人にはSPAMも同然ってことを思えば、何か言う前に、公式ページに掲示する必要があるとはおもいます。
ここまでいい加減なら、公式ページや、お知らせで、掲示した旨の報告と、文章のリリース(といってもテンプレートはあるはずなのでその気があればすぐ出来るはず)が妥協点かなとは。というか、「ポーズだけでもアクションをしないと」流石に説得力が無いです。

紙媒体じゃなくてもいいと解釈すれば、「次回のファーム」なんて手もありそうです。フルセットでなくても、接続が前提なので、実体はなくてもリンクで。
毎度出るとそれはそれでうっとうしいのですが、「周知、公示」という面では、初回のみで、以降は公式サイト参照で、公式サイト側ではニュースリリース等で、言及くらいが落としどころのような気がします。丁度「オフラインインストール用のバイナリすら遅れてる」んですから「次は有るつもりなんですよね?」

まぁ、「誰が悪いのか」といえば「ろくに製品を確認もしないで買ってきて売ってる人」なんですがね。
売る前に準備すれば、コストは最低限で済んだはずですから。

しかし、お約束の定型文のようななだめる文章と「はい、ソースの請求はしました。相手の出方次第ですが、もう少しお時間ください!」が「まともな返事」と感じるのは、どれだけ酷いやり取りがあったのか想像もしたくないです。
普通は「うっさいないまやってんだよ」って意訳の時の返事です。それが「珍しくまともだ!」と見えるのは、もう担当の人が手におえてないですね…。

相手にあきれて諦めてもらうのは、インシデントは消滅しますが、先に書いたみたいに「届かない形で悪評は広がり」ますから、見た目以上のコストに実はなってるのですが、目の前のことで自分に責が無い形になればいいやなのかもしれません。結果的にそうなるのはしかたないですが、解決したことにする手法にしちゃうのはアウトだと思います。難しいことですけどね。

投稿者:Takeshich  投稿日時:2015/09/21 16:33 親投稿 - 子投稿.1 No.162

え?さん

>でもまぁ、RockdiskNextの場合は基本的に紙一枚入ってなかった筈なので、商品ラベル
>に記述するくらいしか方法も無かったでしょうね。

はじめにお読みくださいという書面はありました。紙だと入っていたのはその書面だけでした。
本来はそこに記述する必要があると思うのですが。。。
ソースコードを提供する旨についてだけでなく、保証規定などもないです。
普通はありそうなものですが。

>ドキュメントはWeb上にあるわけですし

その書面はWeb上では見つけられません。。。

>紙媒体じゃなくてもいいと解釈すれば、「次回のファーム」なんて手もありそうです。

そういう運用は普通に想定できますが、ioplazaにはできないんじゃないでしょうか。。。

管理画面のヘルプボタン(右上の?)を押すと
なぜか
http://www.ioplaza.jp/shop/contents/rdnext.aspx#manual
に飛び、URIとしてはそれっぽいのですが、マニュアルじゃなくて
メディアサーバーの配信可能フォーマット
ですよ。
アンカーとして何個もmanualが使われているようで、
本来なら
マニュアル (CL2-005LDシリーズ、CL2-005LD/Aシリーズ共通)
に飛ばそうとしているようなんだけど。。。

こんなのも気づかないで、商品としているんだから
運用自体が無理ですよ。。。

過去もにファームウェア更新に関することを散々な感じで公知してたりしますから。
http://archive.is/YqEjM#selection-2561.0-2561.6

投稿者:え?  投稿日時:2015/09/21 20:17 親投稿 - 子投稿.1 No.163

 箱見たら、確かに一枚だけ入ってた…多分出したときは興味が無くてそのまま置きっぱなしにしたか、気がつかなかったのか、忘れてたのかは定かではないですが。
 重複するものは不要ってことなのか、確かにPDFで同じものは無さそうですね。

 URIについては、「更新した担当者が、まともに編集できない」だけだと思います。
 本来は「マニュアルの頭が来る様な固定URI」のはずなのですが、「意味をわかってない」人が編集してるってことが「いろんな意味で酷い」ですね。
 …多分商品から、呼んでる事すら忘れてる。もしかすると初版はレイアウトの問題から「機能していた」のかもしれませんが、このミスをする人がソースを直に書いてるとも思えないんですが、どういうことなんだろう。
 流石に打ち合わせの一つくらいはしてますよね?…「ioplazaが」やっぱり元凶か。…これができないのに、何で商品を自分らで企画して作れるとか思っちゃったのだろう?絶対周辺の部署に迷惑かけてると思うんだが。
 機能していれば「周知させたいところ、更新を知らせたいところ」に飛ぶわけですから、マニュアルとかの記述によっては、それなりの意味があるはずなのですが。
 スペルミスも見つけた。farm?firmなんだけど、この間違いをするのは「その単語が先に来るか、firmのほうを使わない人」ってことなんですよね。組み込みの機器が多いメーカーとは思えないけど、営業とかバイヤーが使うわけも無いか。でも、「書くときに資料は調べないし意味も確認しない」という疑いの要素にはなるけど。
 バグ農場じゃこの有様も仕方ない…w
 仕様表も2.5インチ対応なんだけど、忘れちゃってますね。比較的長く売った商品が、販売終わってまだ間違ってるってのも凄いけど。
 ただ、ファームで告知が「本来は」一番無難だと思うのですが、アップデートの仕掛けが適当だと、難しいかもしれませんね。…ソースを開いて「自分の普通」すら高いハードルなんだと理解した。素人でもできそうな普通すら期待してはどうやらいけないらしい。Web屋ではなくても、周辺機器取り扱っててこれって酷いし、普通はWebの担当者がちゃんとするものじゃないかと思うのだけど、できもしない製品担当者がやらないといけないことにでもなってるんでしょうか。やっぱり上の方に報告しないと、「ちょっとしたミス」じゃなくて構造や、質的に問題があるとしか思えないですね…。ちゃんとしとくと「楽なのはじぶんたち」なんですが。

 保証はどこかに…
 http://bbs.ioplaza.jp/forum/index.php?forum_id=52
 とおもったけど、ちょっと規定といえないような残念な文面しか見当たらず。
 適当な商品のpdfでも引っ張ってこれに準拠ってことすらしないのもいい度胸w
 これって、自分達の仲間も、ユーザーもお互いに運用次第で守れないってことなんだけど、自分達以外の苦労はどうでもいいらしいw

 GPLの目的からすれば、ニュースヘッドラインなどでの掲示、公式ページでの掲示、FAQへの掲載と、マニュアルの更新。
 ソースコードの早急な提供の開始。
 この辺りが「妥協のライン」だと思います。要は「必要があったり、欲しいと思う人」が「手に入れることができない。それが明示されていない」ことが問題なので。
 興味の無い人には無理に送りつけられても逆に迷惑な気がしなくも有りませんし。
 文面どおり「遵守しているか」といえばアウトですが、最低ラインは維持していただきたいと。
 「守れる会社なのか?」は「リリースする時点でできてないし、販売が終わるまで気がつきもしない」人たちが「どの口で言うか」という状況ですから、そういうことをヘラヘラいえる時点で、信用ならんわけですが。
 「その気があったら、世に出す前に確認するはず」なので、この製品の担当者は、「きちんとできてる商品担当者に怒られて」ください。無視なのは「資格が無い」のであって「仕方が無い」訳ではないですし。

 どっちかというと、以前は愚直というか、教科書どおりというか、そういうパターンの引き方とか、商品が多かった印象なのですが、仕事がいい加減であとでどうにかすれば良いやっていう「悪いところだけ競合のアレコレ」と同じような仕事ぶりなのは「まともな人」はみんな居なくなっちゃったんでしょうかね。

投稿者:Takeshich  投稿日時:2015/09/27 19:01 親投稿 - 子投稿.1 No.164

http://bbs.ioplaza.jp/forum/index.php?topic_id=2398#post_id10631

>しかし、交渉をしていると言ってきてから、2ヶ月ほど経つので、
>GPLを順守したいと考えるなら、引き続き働きかけを継続するだけでは不十分で
>IODATAには各著作者に対してどう対応するべきかを連絡して、確認してくださいとお願
>いしてあります。
>8月末からお願いしてあることなんだけど、理解しているのかは不明です。

と書いた内容について、8月末からずっと言い続けてた内容でしたが、
9/25に

> ご連絡頂きました他の手段を利用して、働きかけを行って欲しいという内容につきま
>しては、関係部書にご要望として報告させて頂きたいと存じます。


明らかに日本語の組み立て方からして、責任者じゃなくおそらく担当者とわかる回答が来ました。
そして、やはり組織としてGPLについては理解できていないようでした。
さらに1ヶ月前から言い続けていることに対して、今更こういう回答をするとは。。。
検討しているものとばかり思ってたけど。。。
理解できないなら、その時点でどういう意味か聞いて欲しいんだ。

以前から、担当者のひどい回答だと嫌だから
貴社の法務部門、顧問弁護士やGPLを理解している技術者の方などに確認頂き回答くださいと
何度も言っていました。
でも、なぜ責任者から担当者へ回答対応を委譲して、ひどい回答をしてしまって火をつけることするんだろうか。
わかってたら、こういう対応をしないと思うので、
この件については、IO DATAとしては組織としてどうでもいいと思っているのでしょう。
責任者出せだけじゃどうにもならないですね。
責任者出続けろとかじゃないと。

責任者と担当者のはざまで理解できないことだから、確認も検討もされず
捨てられそうになってたんだと思います。
おそらく、今後も強く言い続けないと捨てようとするんだろうなぁ。

責任感とか誠実さとか真摯さを全く感じられない対応です。

また、ソースコードの開示の他に対応しなければならないことについて、
まだ対応されていないことを指摘しておきました。
何をしなければならないか明確には記述しなかったので、
考えて対応していただけることでしょう。

以上、愚痴でした。

投稿者:たく  投稿日時:2015/09/27 20:39 親投稿 - 子投稿なし No.173

Takeshichさん

本当にご苦労様です。

正当な要望をメーカーが対応してくれないのであれば
国民生活センター(消費生活センター)等に相談された方が良いかもしれません。
特にTakeshichさんの場合、購入前に問合せ確認してるのですから…

まずは相談しOSSやGPLがらみで同様なトラブル事例が無いか、国内で活動してる団体などないか聞いてみてはどうでしょうか?

ユーザーの意見を無視するのであれば、無視出来ない様にしてあげるのも良いのではないかと思います。
メーカーに対処する時間は十分にあげたと思うので、遠慮する事は無いと思います。

投稿者:え?  投稿日時:2015/09/27 21:34 親投稿 - 子投稿.1 No.165

お疲れ様でした。

まぁ、予想通りというか。

少なくとも回答者っていう伝言ゲームの参加者にいなくなってもらうだけでも、「お前の部署何考えてるの?」って「怒ってること」を緩衝領域なしに叩き込めるような気はします。

というか、下の人かわいそうになるな。普通は上の人が燃えるの懸念して出てきてそれなりの対応して火消しする話で、下の人がストレス溜めながらうそ回答するところじゃないと思うんだけど。

そもそも「うそをつく部署」なので、「大代表」とか別の場所から、「サポート使えないし、企業コンプライアンスに関することなのだが問い合わせ先どこ?」でもう良いんじゃないでしょうか。仮にあっても、このレベルでうそとごまかし始めるサポートは答えないと思うし、まわされそうになったら「一年近くもうそを並べる部署で役に立たないので話ができる人のところでお願いします」でもういいでしょう。

担当者の必死の言い訳も含め、基本もみ消そうとする体質があるので、企業として云々って人までいかないとおもうのですよ。権限が無くて、上も助けてくれない上に同じ事いってるなら、まぁ、あんな感じにならぁねとは思います。

むしろLANDISKのチームは(当たり前のことしかしてないんだけど)まじめだなって思います。一応製品が問題ないようにしてから、流してるんだし。
…ただまぁ、最近のファームの傾向おかしいけどね…いらないことばっかりして。というか、「製品担当者が出自が出自なので、比較的まとも」だからぎりぎり回ってた仕組みなんじゃないかと。
優秀だったらこの構造のサポートは俯瞰から何かあったときに見つけてくれるので悪くないのですが、ここまで笊だと、大事になってから経営側にエスカレーションみたいな状況になりかねないですね。むしろ個人向けの商品については会社を傾かせかねないんじゃないかと。

>何をしなければならないか明確には記述しなかったので、
これは
>考えて対応していただけることでしょう。
こうならないことを予見した上でそうするのってどうなんでしょう。
「理解できないからこの有様で、できることからはじめようともしない」のであって、悪いと思ってない以上反省もしないような気がするのです。

だって、「できてもやらない」ことなんてもうわかってるのですから、二行目ありえないじゃないですか。
「言われたことも」やら無い人は「言わなかったことには気がつくことすらない」ですし。

あと、大体の会社だと普通はまともなルートで話を通すので、「イレギュラーなルートから来るクレーム」はそれなりに処理されるはず…ということもあって、ほかから回ってみるのは無駄じゃないと思います。
相手が誠実であるという条件の場合は、行儀が悪いあまりいい方法ではないですが、論外なときには逆手にとって「頭越し」に叩き込むのは「よっぽどのことなんですよ」と明示するのにそれなりの効果はあります。が、相手にその気がなければその限りではないですが。

まだ残ってるのかはわかりませんが「まともに仕事してる人たち」がとばっちりですよね…。

投稿者:Takeshich  投稿日時:2015/10/05 23:35 親投稿 - 子投稿.1 No.166

GPL違反が継続状態の件について、面倒だったけど、まとめました。

http://takeshich.hatenablog.com/entry/2015/10/04/004036

それと消費生活センターに相談してみました。
進行中のことなので書ける時期になったらまた書き込みます。

投稿者:え?  投稿日時:2015/10/06 23:45 親投稿 - 子投稿なし No.167

色々お疲れ様でした。
でも、SDK辺りは、この会社だったら、直接チップベンダから貰ったほうが早そうな気はしますね。
バイナリとの対応が問題なのでダメなんだけども、そんなに手を入れてるとも思えないし。HDL-CE辺りで石は違っても、同じようなのを記憶違いじゃなければ使ってたんじゃないかと。毛色が違うので、OEMかもしれませんが。

なんというか「諦めてもらって解決する」ってのを半分インシデントの消化手段に使ってそうな気がしなくも無いです。対応としては、必要悪とか、裏技に近いので、解決の努力をしないでそれやっちゃダメだと思うんだけどな。
正直「適当対応」は製品カテゴリによっては結構やらかしてるので、意図的にサポートの品質を落としてるのでなければ、見直すと「助かるユーザーは増えそう」ですけれど。
正直で、頑張ってる様子だったら、杓子定規に責め立てるのもどうかとも思うのですが、なんとか終わればそれでいいってのが透けて見えるのは、どうしたものかと思います。

あの「高いやつ」も「コレの関係者」が噛んでるっぽいのですが、また「必要な表記や対応」をしないのではないでしょうなwこういう対応の「原因を作った人」が「信頼」を由来とする名前の製品の営業活動してるのは何の冗談かと思います。いや、「後始末してけじめをつけた後」なら「ちゃんとする人たち」だから「信じて良い」と思うんですが、問題は「素振りも無い」ことなんですよね。

投稿者:たく  投稿日時:2015/10/08 19:59 親投稿 - 子投稿.1 No.174

Takeshichさん

今日、サポートからソースコード準備出来ましたとメールが来てました。
CD-ROMで送ってくれるみたいですので、申し込んでみます。
内容は来てみないとわかりませんが、ちょっと不安ですね…

投稿者:Takeshich  投稿日時:2015/10/08 20:28 親投稿 - 子投稿なし No.175

たくさん

>今日、サポートからソースコード準備出来ましたとメールが来てました。

今のところ、特に私のところには連絡はありません。。。

たくさんのアドバイスを元に
消費生活センターに相談して、その後書面で通知とかしたので、色んな意味で、その影響かもしれませんね。

>CD-ROMで送ってくれるみたいですので、申し込んでみます。

対応よろしくお願いします。

>内容は来てみないとわかりませんが、ちょっと不安ですね…

不安ですね。。。
内容一覧のリストとか先にもらえると不足しているのとか突っ込めるからいいのですが。。。

9/25までは、inXtronに働きかけを行っているという話はでていたので、その後、inXtronから開示されて、iodataで不足ないか確認できて、準備ができたということだろうけど、これまでの流れを考えると期待できないですよね。。。

投稿者:え?  投稿日時:2015/10/09 04:34 親投稿 - 子投稿.1 No.176

他のソースと同じようなら、GPLに基づくものですよっていうテキストファイルと、各種ソースリストがドチャっとアーカイブされたtarballが入ってるだけです。
例外的なケースでは、ソース単体がCD-Rに焼いてあるだけというケースも有りました。製品としてコレに近いものは、素で各種ソフトウェアのアーカイブが投げ込まれてるだけでしたが…。CD-Rだと多分一式じゃなくて、最低限のソースなんじゃないですかね。
ですから、多分一覧みたいなものは無いんじゃないかと。ビルドに必要なもののうち、シンボリックリンクとか、設定がらみとかそういうのは他のも入って無いです。
ですから、実際のバイナリは別の商品でも同じソースが来ます(/ました)ので、そういうのは全社的な仕様なんだと思います。

手順は、500円分の切手+シリアルの連絡…ですかねぇ?

なんとなく、散々問い合わせた人は後回しで、後から問い合わせた人にはできましたって順番はあれ?って思いはしますが、誤魔化すだけのつもりも無ければ一応動いてくれていたってだけでもマシですし、こういっていいのかどうかはわかりませんが、今までのような空振りよりはよかったですね。

でも、おかしいと思ったら外後からの威厳を使えってそれはそれで、相手を信用していない様であんまり使いたくない手ではありますね。
素直に話を聞いてくれて(ユーザーが本当に間違ってることだって状況によってはあるので)、その上で、正直、且つ、可能な最適解で返事が返ってさえくれば構わないのですが、そういや、リコールになった件も外から圧力掛けた人が居なければ、「タダの修理」で有償になってましたね…。

あとは、中身と、一番問い合わせた方への連絡と返事次第なんですが、良い返事が早く届くと良いと願っております。というか、ドキュメントの修正の方はまだなのですよねぇ…。

投稿者:Takeshich  投稿日時:2015/10/09 12:56 親投稿 - 子投稿.1 No.177

え?さん たくさん

私のところにも連絡がありました。
消費生活センター経由でソースコードが開示できる旨連絡が来ました。
書面で通知していた内容への返答も書面で来るようです。

書面がiodataに着弾したのが10/7なので、外圧の影響というよりは
もしかするとすでにある程度準備ができていたのかもしれませんね。

ただ、中身を確認するまでは安心できません。

投稿者:え?  投稿日時:2015/10/10 03:13 親投稿 - 子投稿なし No.178

 うーん。普通は連絡が早く付きそうな方でも連絡入れるものですけどね……。
 こういう手抜きが「慇懃無礼」って思われてしまうわけで、「消費者センター様を経由してご回答させていただいています。」と一報入れることが何故できないんだろう。普通は、形だけでもやると思うのだけどな。すべきことを指定無いので、現状があるわけですから。

 でも、後回しにされてるわけではなくて、回答の経路が一つで、かつ遅いほうだっただけでよかったですね。

 ま、10/7の警告で対応がこのタイミングなら、「持ってなかった」がうそになりますし、「法務とか、企業コンプライアンス」を持ち出した時点辺りからバタバタあわてたと考えると「こんなもんかな」というタイミングだと思います。でも回答があの有様なので、行き違いは仕方ないですね。

>このRockDiskNextは挑戦者でもCL2-xxxの型番がついている通り、
>アイ・オー製品ですので、バイヤーの私が勝手に買ってきたもので
>はありません(笑)
 安く買ってきたものだし他社製だからしょうがないよねと、遠慮の必要はなく、且つ、サポートさんは「もう一つ嘘をついた」ことになりそうですね。「アイ・オー製品」といってしまってますし。文脈的には箱のほうだけなんだけど「買ってきただけじゃないやい」と言い張るってことは相応の責があることもわかってるはずなのであって。
 あと、「メインの基板はガラクタでも、箱だけ頑張れば大丈夫」に近いことも言ってますが大丈夫なんでしょうかねぇ。本家の技術の人が多少なりとも手を出しててこれってのも、不味い発言だと思いますし、挙動を決めるファームウェアを機能があれば良いと作りこまないのも論外で「不手際で明確な迷惑を掛けたことがある」ことを思えば、言葉くらいは選んでくれても良いと思うのですがね。
 こういういい加減で余計な事を言う人を「ユーザーや、取引先の前にひとりで立たせては」いけないと思います。というか、挑戦して「痛い目見る」のはユーザーですしね。Nextが付かないほうで困ってる人はそのままですし。

 そういえば、今年に入ってから「管理人」がリリース出すときに名乗らなくなっていますが…。オフラインアップデートの公開がまだってのは忘れて無いでしょうなぁ?まさかw

投稿者:たく  投稿日時:2015/10/10 08:51 親投稿 - 子投稿.1 No.179

Takeshichさん

今までメール等で問い合わせた内容と消費生活センター経由で問い合わせた内容で重複するものは、消費生活センター経由での返答のみになるかと思います。
なので連絡が少々遅れるたのかもしれませんね。

タイミングが悪かったかもしれませんが、別件もあるかと思いますし
消費生活センターが間にいるので、今までの様にいい加減な回答はしてこないと思います。

>もしかするとすでにある程度準備ができていたのかもしれませんね。

そうですね。進捗を教えてくれてたら もう少し待つ手もあったのですが
しかし、製造元(inXtron)と折り合いついたのかしらないけど
ついたならついたと言って欲しいものだ。

ま、肝心の中身がどの程度かCDを待つことにしましょう。

投稿者:Takeshich  投稿日時:2015/10/10 15:22 親投稿 - 子投稿.1 .2 No.180

え?さん

ダブスタでホント気持ち悪いですね。

>RockDiskNextは挑戦者でもCL2-xxxの型番がついている通り、アイ・オー製品ですので、
>バイヤーの私が勝手に買ってきたものではありません(笑)。中身は海外メーカーのOEM
>で、ソフトウェアや回路基板は流用ですが、ACアダプターや筐体は当社用にカスタマイ
>ズされており、実はこのfidataのハードウェア設計者が監修しています。
http://archive.is/9gOLY#selection-509.3-509.169

としているにもかかわらず、サポートから当方への回答においては、

>RockDiskNextについては、挑戦者製品ということで、弊社で作成している製品
>ではないため、この度のように対応に時間がかかっており、大変お待たせしている状況
>がございます。本当に申し訳ございません。

としていたり。。。

これだと技術者の方がきちんとやっていないんだよということになりますが、
RockDiskNext以外の製品だとある程度は対応されているようなので
そういうことでもないようですよね。

この方や、サポートにおいて言葉の選び方について言えば、もっと慎重に、熟慮したほうがいいと思います。
サポートなんだから、言えないことは言えないこととしつつもほのめかすとか
嘘にならない範囲でもっとうまい言いようがあると思うのですが、
全くできていないようで。。。

たくさん

>進捗を教えてくれてたら もう少し待つ手もあったのですが
>しかし、製造元(inXtron)と折り合いついたのかしらないけど
>ついたならついたと言って欲しいものだ。

製造元よりソースコードの入手が完了した際に連絡くださいとお願いしていたんですけど。。。
言ってもらえれば、お手紙出す必要もなく。。。

届いてからすぐというおかしなタイミングで開示準備は完了したようですし。
中身が心配ですが、

>お客様にご連絡できる内容として確認させて頂いた上でご連絡させていただきたいと
>考えております。

以前にもらっているので、確認したことでしょう。半信半疑ですが。

何かどこかで嘘があるようですが、それが嫌な方向へ進む原因にならなければ
いいと今は考えています。

投稿者:Takeshich  投稿日時:2015/10/10 16:46 親投稿 - 子投稿.1 No.181

佐川急便でソースコード届いた。
ざっとみたところ、中身はそれっぽいけど、u-bootないみたい。
それとsrpmでないのがあるし、20140430版時点で開示請求をしたので、更新分については分けて欲しいと伝えたのだけど、そうもなってない。

これから詳しく見ていくけど、残念ながら、iodataで技術者が確認したとは思えないレベル。

また、長いやり取りが発生しそう。

投稿者:Takeshich  投稿日時:2015/10/10 17:58 親投稿 - 子投稿なし No.182

開示されたソースコードまとめて置いておきました。

https://drive.google.com/file/d/0B1Tfr ... MSmtsV2s/view?usp=sharing

500MB以上あるので、ご注意を。

minidlnaはdsd対応がないことになってたりする。。。

投稿者:たく  投稿日時:2015/10/10 19:10 親投稿 - 子投稿.1 No.189

Takeshichさん

サポートからのメールで
>※配布するソースコードはGPL/LGPLに基づき、本製品を構成しているプログラム・ドラ
> イバのうち、本製品向けに独自に作成された部分を除くオープンソースソフトウェア
> のみ配布いたします。

となってたので、怪しいなとは思ってたのですが
「本製品向けに独自に作成された部分を除く」というのが「改変した部分は除く」という意味だったとしたら
GPL/LGPLを本当に理解していないという事であって、ライセンスを自分の都合の良いように解釈している。

もしIO Dataがこれでソースコード開示の義務を果たしたと思ってるんだったら、人を馬鹿にしすぎだね。

オリジナルのソースまとめただけの物
製造元(inXtron)と何も協議してないだろコレ…

コレはサンプルで、来週は違うの来てくれないかな…

投稿者:え?  投稿日時:2015/10/10 20:47 親投稿 - 子投稿.1 No.183

あー…残念ですねぇ。
というか、HDL-CEはPLX7715だった筈なので、多分SDKなら自前で版確認してベンダの方に請求できるんじゃないかな…。

筐体とACアダプタは最初から一定の広告を打ってるわけですから、頑張ったところではあるのでしょう。でも、あの書き方は「信頼を自分で叩き壊すスタイル」でしかないです。先生との対談記事も尻尾振ってるファンと先生様状態ですしね…。あーほめられてうれしいかぁ?ワンコwって記事を自分で出してくるのは凄い度胸だと思います。

他の機種だと、一応U-bootとか、shiplとかのソースは入ってますね。
ビルドに必要な設定がらみは入ってないので、オプションが違うだろう機種もベースが同じだと「ソースは同じです」という回答。
積極的に遊んでやってくださいという好意的な感じではないが、義務は果たすスタイル。
HDL-CEは、機種自体がちょっと変な構造になってて、且つ、ソースは今回のに近い感じでアーカイブだけ入ってました。こっちはブートローダのソースあったかな…。
やっぱり担当者の胸三寸なのかもしれませんね。
ただ、明らかに無いのは「ソースとは分離されたドライバ」とか、周辺ツールのバイナリソースだけなので、「所謂GPL汚染の外」は提供しませんよという意味での断り書きになっているはずで、やっぱりRockdiskNext周りの対応はおかしいです。少なくとも「他の製品」では出してるので、「変更部分は除く」ではなく「GPLと接触していない独自のバイナリのソースは無い」が会社(というか、LANDISKなチームの)解釈であると思われます。でも、RockdiskNext「しか」知らなければ「いい加減な会社だ」と思われても仕方ないですね。
ある意味「探せば見つけられるようなものだけ」固めて出てきた感じですねwもしかして一覧を元に自分らで探したんだろうかw
アップデートでバイナリの出自が変わってるものもあるんだがw

NICのソースとか、初期のDSDパッチもなかったことにされちゃってるんでしょうか。
一応バグ対策前のソースは提供されてましたよね?普通だったらそれより後のもの。ちょっと譲っても公開されたアレじゃないとおかしいんですが。
あと、自動アップデートで「バイナリを配って使ってる」ので、「今の」ソースは出さないとだめですね。

というか、それって「ソースが管理できてない、バイナリの出自も怪しい」ファームってことになるわけですが…。

投稿者:Takeshich  投稿日時:2015/10/10 20:48 親投稿 - 子投稿なし No.190

たくさん

>「本製品向けに独自に作成された部分を除く」というのが「改変した部分は除く」とい
>う意味だったとしたら
>GPL/LGPLを本当に理解していないという事であって、ライセンスを自分の都合の良いよ
>うに解釈している。

いやいや、まさか。。。
この期に及んで変な冗談はやめてくださいよ。
プロプライエタリなのは開示しないよっていう意味にも取れるけど
minidlnaはdsd対応がないことになってたりするので、本気でそう理解しているのかな?
動的リンクならその主張はもっともだけど、過去に一部開示されたものでは
そうなってないし。
https://github.com/takeshich/minidlna-IODATA-1.1.0

>もしIO Dataがこれでソースコード開示の義務を果たしたと思ってるんだったら、人を馬
>鹿にしすぎだね。

物理的にソースコードの開示をしたのだから、本当にこれで問題ないと思っているんだと私は思いますよ。
散々やらかしておいて、このレベルのものなんだから、本当に理解できていなくて、
私としてはものすごく馬鹿にされている気分だけど、担当者はそうは思ってないんじゃないですかね。
じゃなきゃ、こんなの出しちゃいけないって判断できるはずですから。
おそらく、IO Dataの技術者においても、わかっている人ほんの少しなんじゃないですかね。
恥ずかしいから、頑張って止めるはずなんだけど。
何度も指摘されていることに対応できないってすごいですよ。

>オリジナルのソースまとめただけの物
>製造元(inXtron)と何も協議してないだろコレ…

製造元が手を加えたものと思われるのが全部ではないけど、src.rpmになっていないですからね。
他のパッケージはsrc.rpmで出てきていて、それが対応する完全なソースコードなんだから
tar.gzだと対応する完全なソースコードではないので、IO Dataとしては
突っ込むところだと思うのだけど、できてないし。

ほんといい加減にしてほしいですわ。

投稿者:Takeshich  投稿日時:2015/10/10 23:37 親投稿 - 子投稿.1 No.184

え?さん

>NICのソースとか、初期のDSDパッチもなかったことにされちゃってるんでしょうか。

NICのソースはkernelのソースの中にありますね。
SATAのもありますよ。改変されたのもあるから、kernelのソースコードをそのまま出している時点で
改変した部分は除くということでもなさそうですね。

ただ、minidlnaは、変更が入ったものではなくオリジナルのものだけしかないですね。
20140430以降のアップデートに使われたパッケージのソースはほとんどtar.gzでオリジナルのもののようです。
fedoraオリジナルのパッケージは、rpmで頒布されたのだからもちろんsrc.rpmであって
中にはspecファイルとかパッチとかがあります。
対応する完全なソースコードはもちろんsrc.rpmですから
rpmで配布しているのにオリジナルを開示している時点でおかしいです。

特にminidlnaについては、RockDiskNext向けに変更が入っているし、
去年、私が請求した時に一部のソースコードは開示されて、IO Dataが保持しているわけですし、
src.rpmで開示されない(specファイルがない)ことを当方が指摘しているので、
あれ、これおかしいよね?とIO Dataは気づけるはずなのですが。。。

そのため、今回開示されたものの中身をIO Dataが確認してないんじゃないかと思います。
最低限、製造元にDSD対応を依頼したminidlnaぐらい確認しろよと思うのです。

サポートから
>お客様にご連絡できる内容として確認させて頂いた上でご連絡させていただきたいと
>考えております。

という回答をもらっているのですが、こういう惨状を見るにつけ嘘つくなよと思う次第です。

投稿者:え?  投稿日時:2015/10/11 00:48 親投稿 - 子投稿.1 No.185

miniDLNA以外は、I-Oがそんなもんと思ってるような気がします。
他のソースも普通にオリジナルと、その差分とかで出てきますが、コンフィギュレーションの類のファイルは全部削ってあったように思います。
実際のコードに変更がなければ、対応するソースと思ってるのだと思います。

fc12に含まれるのは「素直に対応するものを出した」ので、パッケージのは普通にfc12のソースが来ているのだと。
ただ、自前でビルドしたものは、オリジナルにソースとしては手を入れていないから、版があってればOKと思ってそうです。
実際「specファイルは公開しない」という回答もあったはずですし。

ただ、miniDLNAでやらかしてるので「ほんとはどっからもってきたの?」って思われちゃってるだけで、一応(版だけ聞いて拾い集めたのか、送ってもらったのかはわかりませんが)これでできてるつもりなんじゃないかと。寧ろ「本家側」はfor I-O DATAのソースじゃない「筈」なので、開発元から製品固有の部分の反映を忘れたソースが来て、名前あってるからいいやで横流ししたって可能性はありそうです。(どっちにしろちゃんと管理できて無い可能性が…)
ただそれでも、OSより前の部分とか、そういうところは忘れちゃってるような気がします。

本当に手を入れてなければ良いんですが、誰が言うことが本当なのやら。

ですので、「思われてるよりは当人達はちゃんとしたつもり」なのではないかと思います。というか、これに近似した回答が質問したらあるんじゃないかと…。

投稿者:Takeshich  投稿日時:2015/10/12 01:20 親投稿 - 子投稿.1 No.186

え?さん

>実際のコードに変更がなければ、対応するソースと思ってるのだと思います。

私は開示を担当した人はそんなにきちんと考えてないと思いますよ。
ファイル一覧見てても、一貫性ないですし。
avahi-0.6.31-14.el7.src.rpmというファイルもあったりして、一貫してなかったりしますし。

単に製造元から開示されたファイル一覧を見て、対応するソースらしいものはあるから
開示できるとしただけのような気がします。
開示を担当した人は中身の整合性の確認が必要なことを認識していないと。
製造元から出てきたものだから、間違いなく正しいとでも思ってたりするのかもしれません。
まぁ、普通はそう考えてもいいのかもしれませんが、今回は今までの経緯を考えると
そう考えるとまずいのは明らかです。

>実際「specファイルは公開しない」という回答もあったはずですし。

まぁ、そういう回答(以下)も過去にありました。

> また、「SPEC」ファイルにつきまして、SPECファイルは、指定されたシステムや開発
>環境に依存する、ソフトウェア開発者が個々に利用するユーティリティであり、GPLで
>の公開義務の範囲以外にあると認識しております。
> そのため、大変申し訳ございませんが、ご要望いただいたSPECファイルをご提供する
>ことはできない状況でございました。

この回答で、株式会社アイ・オー・データ機器としての回答で問題ないとのことでした。
ただ、今回specファイルを含むものを多数開示しているので、
どう説明するのでしょうかね。。。

>ただそれでも、OSより前の部分とか、そういうところは忘れちゃってるような気がします。

以前から何度もboot関連のソースコードについてやり取りの中で
全く提示されていない点について指摘しているのですが、
販売している製品なのにその部分の仕組みを理解している人がいないようで
忘れちゃっているというよりは、存在に気づけないだけだと思います。製造元も言われなきゃ出さない感じだし。

今まで複数回指摘しているので、わかっていれば確実に開示するはずですから、
本当にわかってないため、存在自体を認識できないのだと思います。

前から感じていることではありますが、
GPLについての捉え方以前の問題の気がしてなりません。

投稿者:え?  投稿日時:2015/10/12 08:25 親投稿 - 子投稿.1 No.187

 「確認する」には「正しい状況の理解」が必要で、ご飯おごるんで教えてって頼めば、「わかる人居るんじゃないか」と思うんですけどね。
 当初の一覧表にはブートコードどうなってましたっけ?一覧表との比較すらして無いならやっぱり酷いとは思うけれど。
 ただ、あの受け答えで、表との対応確認以上のことができる人が居るとも思えないから「気がつけ」って言うことは色々無理だとは思います。ですから「確認してから」が悪手でむりな約束だったのだと。

 というか、そりゃredhatならrpm使えるけど混ぜていいのかな…el7の。ただ、「本当にfc12がサポート切れで持ってきた」のかもしれないけど。むしろこのポンコツサポートが、そのソフトウェアが別途リリースされてるのに、別ディストリビューションのを探してきて引っ張ってくるとも考えにくいのでアーカイブの提供元(開発元)の仕業かなと。
 miniDLNA(これも、途中で本家もサーバ入れ替えてた気がするのですが)が戻っちゃうのも、開発元がカスタマイズを忘れてて元のソースを持ってきたとかならありえなくは無いです。

 specファイルについては「基本的には公開範囲には無いから無いものは提供しない」が「対応するパッケージに対応するソースのパッケージがあればそれが対応するものである以上その限りではない」ということのようにも思えるので、含まれていることを元に「他のも付けろ」は必ずしも整合しないような気はします。問い合わせは多分fc12以外のパッケージのソースについてだった筈で、パッケージを直接使ってるのにわざわざ抜いてアーカイブするのも変ですし。場合によってはバイナリはどっかから持ってきたやつで「使ったソースが無い」のかもしれませんが。

 ブートコードは問い合わせに含まれてるなら「よくわからないから薮蛇にならないように見なかったことに……」としてそのままというか、基本的な回答方針は「可能な限り余計なことは反応しないし回答しない。」なので、本当に何か大きな問題でもコレじゃエスカレーションできないんですがね。話題として出してて無視なら「確認してからものを言わないとダメ」ですね。
 まぁ、大半の問い合わせが対応だけとはいえるのですが、製品に反映させる気が無い、情報を活用する気が無いのはある意味サポートが本当に無駄金になってる気がします。

 まぁ、そういう「GPL以前」の部分については「ちゃんとした人、上役出せ」で普通は「権限と対話スキルと、それなりの知識を持ったデキるひと」が出てくるはずなんですが。ioplazaもあちこち表記ミスとかtypoが新しいページができるたびにあったりするんですが、一つ一つは瑣末なんですよ。でも「そういう状況を作ってしまうロジック」に問題があるので、もぐらたたきに意味は無いんですよね。多分悪い人ではないんだろうけど、サポートといい、ioplazaといい、目の前の狭い範囲だけ見て全力で取り繕ってるような仕事の印象が強いです。三歩後ろに下がると構造的におかしいような仕事が多々あって、数通前のメールと齟齬があるとかは普通気をつけるはずなんですけども。
 他人事だから心配しても仕方ないんだけど、この程度の会社ってものをいわずに見限るほうが良い顧客なんでしょうかね。感情論としてはそうだろうけど、商売としてはどうなんだろう。

投稿者:え?  投稿日時:2015/10/12 12:08 親投稿 - 子投稿なし No.188

あ、でもインストールされたパッケージというか、アップデータの中に、el7が含まれたの見た覚えないですね。
I-Oのあの返事の水準なら多分「気がつくこと」はないでしょう。まあいいやでファイル名の頭のほうだけ一致してればOKってザルチェックだと。

考えるほどに、素性そのものが怪しくなっていきますね。

投稿者:たく  投稿日時:2015/10/15 20:52 親投稿 - 子投稿.1 No.191

今日ソースコードのCD-Rが届いたけど
残念ながら、Takeshichさんのとまったく同じでした。
予想を裏切らないですねホントに。

投稿者:Takeshich  投稿日時:2015/10/15 22:11 親投稿 - 子投稿.1 No.192

たく さん

>今日ソースコードのCD-Rが届いたけど
>残念ながら、Takeshichさんのとまったく同じでした。
>予想を裏切らないですねホントに。

やっぱりと言っていいのか悪いのか。
同じことをされたものとして、心中、お察しいたします。

消費生活センター経由で不足しているものについては指摘しています。
ただ、消費生活センターの担当者の方は技術に詳しい方ではないので、
どこまで伝わっていてさらにiodataにもどのように伝わったのかは
ちょっと心配なところです。

たく さんにおいても、お手数おかけしますが、サポートへ
足りないものについての指摘をしていただきますよう、よろしくお願い致します。

気がつくこともできずわかっていない担当者とは言え、
開示を行った複数の対象から同じような指摘があれば
何か問題があるという程度は気がつくのではないかと思います。

投稿者:え?  投稿日時:2015/10/16 17:36 親投稿 - 子投稿.1 No.193

 中途半端に対応や中身が違わないだけマシというか。
 仮に再交渉していても、タイムラグ的にそんなに簡単に出るものなら一年も掛かってコノザマなわけが無いはずで。

 ある意味「公平」な対応なんですが、低水準で公平でも意味が無いと思いつつ、このタイムラグで改善を期待するのは酷だとも思います。

 というか、iodataの仕事が最近いい加減にも程があるのはどういう事情なんだろうなぁ。
 新しい製品が出たんですが(誰かが教えてあげたのか、自分で気がつくことができたのかはわかりませんが)NASの新製品なのにUSB-HDDの新製品の仕様表が商品の購入ページに書かれているという素敵仕事でした。個々の問題は瑣末だし、直せばいいことも多いんだけども問題は「繰り返し、確認が甘いことによって事故を起こすロジックが放置」っていうこと。
 あの新製品も、ioplazaなら高性能高機能商品が同容量で更にお安く!とか、新製品でもあの性能と割りきりまくった仕様でお値段据え置きは何処に訴求力が有ると思ったのか…。
 本家は大丈夫かといえば、やっぱり新製品の写真が違うとか、表記がおかしいとかちょくちょくやらかしてる。
 ってことが「頻発していることを把握している人が居るのか?」は他人事ながらちょっと気にはなる。
 「それでいい」と思ってそうなら仕方が無いのだけど、把握すらしてい無いのは残念どころの話ではないし、隠蔽されることで誰も把握していないなら末期的ですし。

 多分「パーツ単位」では気がつかないようなミスが堆積してヘンテコパッチワークになってるんだと思うんだけど、そろそろ中の人は自分で気がついて!今度は人員の削減じゃすまないと思うのだが……。

 生活消費センターを通すときは「よくわからなければそのまま突きつけていただければ」という不足のリストと、その不足している根拠を書いて出すと「第三者の箔が付いて多くがそのままで少しは届くべきところに」届くのではないかと思います。わかってもらった上で、翻訳してもらうのは多分難しいと思いますしコストが掛かることだと思うので。
 利害という面では、金銭的、物質的な「被害」が生まれるものでは無いので、消費者センターの人も難しい仕事の気がします。

 複数の対象から投げても、こうも連携が取れていないとがっかり二乗で更に「他からの問い合わせはございません」とシラを切るのは、ルータがらみの問い合わせでされたという履歴があちこちにあったりしますので「期待は禁物」です。残念ですが。

投稿者:Takeshich  投稿日時:2015/11/18 21:10 親投稿 - 子投稿.1 No.194

お久しぶりです。

指摘して1ヶ月程度経って、指摘していた一部のソースコードが送られてきました。
20140430バージョン時点のソースコードだそうです。
おそらく開示したものと異なるものなのでしょう。。。

https://drive.google.com/file/d/0B1Tfr ... tUDZhVnM/view?usp=sharing

また、specファイルについては

>尚、Specファイルに関しては大変恐れ入りますが以前ご回答させていただきましたとお
>り、GPLでの公開義務の範囲以外にある考えております。提供形態の都合上specファイ
>ルとしてお送りしております部分はございますが、大変申し訳ございませんがご提供で
>きるのは既にお送りしております内容までであり、追加のご要望にはお応えいたしかね
>ます。

ほどんどのspecファイルについては、開示しているけど、
IOデータとしては、
* specファイルについては、GPLでの公開義務の範囲以外にある。
* 提供形態の都合上specファイルとして送っている
(specファイルを含んだ形になっているという意味だと思う
もしかして、srpmとか理解してないのかもという書きぶりだけど)

ということで、
改変したところのspecファイルだけは出せないってことなんだろう。。。

1ヶ月もかけてたったこれだけの対応かと思います。
当たり前に相変わらずひどい対応。なんでこんな程度ことに1ヶ月もかかるの?
この対応なら遅くても1週間かからないと思うのですが。

また、
その他指摘しているものについては全く言及されず、あるのかないのかすらわからない。。。
出てくるのすら。。。

投稿者:え?  投稿日時:2015/11/20 17:10 親投稿 - 子投稿.1 No.195

 ふと思ったのですが、「会話が成立する」と思ってるのが間違ってるんじゃないでしょうか。
 目の前の文面に対してだけ「応答」しているだけなので「話が全く積みあがってない。」
 普通のインシデントなら、三通くらいで始末が付くはずなので、多分過去のことは忘れているような気がします。

 ですので、「理解してもらう」という意味では自分で到達して欲しいところですし、答えを書くと同じロジックで他のユーザーにも酷い回答を繰り返しそうではあるのですが…。
 1.過去のメールを引き、該当部分を引用し、要求、食い違いを再度確認する。既に言及している旨、それに対して返信、対応が無い、若しくは不十分である旨を明示する。
 2.GPLを遵守できていないと思われる部分は「GPL側の記述」を引き、それを根拠に「提供されないといけない」と明示し、「もし、それが不要と考えるのであれば、条文の不要である根拠とする該当部分とその解釈を明示」するように要求する。
 3.同様に不足分についてもGPLに抵触する根拠とそれが提供しなくていいと考える根拠の明示を要求する。
 4.以上のうち、どの部分が「ガン無視」されているのかを明示し「本当に話を聞いているのか」確認し、「何処の誰が何をわかってて対処するなどといってるのか?」と問う。
 結局、問い合わせに対する対応を行うところで思考が止まってるので、自分達は正しいが、クレームがあれば個別対応っていうロジックになってるような気がします。
 提供されないことに対して妥当な理由が存在する可能性もあるものの問題は「弊社は問題が無いと思っている」と具体的にどういう解釈と根拠によって契約が履行されていないのかが明示されていないことで、それが妥当ではないという反論が出来ないし、すれ違うのではないかと。
 こうしろと明示があるにもかかわらず「その必要は無い」とするなら、そのやるべきだということを否定する理由が存在するはずです。理由が無いのならI-O DATAは正当性の無い事を自己都合で言い張ってるに過ぎないということになります。
 SPECファイルは兎も角として、おかしいと思う部分が有るのなら、明示しないと「能動的に考え気がつく」ことを期待するのは無理だと思われます。
 少なくとも、現状の問題についての解決を目的とするなら、自覚をさせるところに持っていくのは不可能に近く、何処をどう読めばそれが正当化されるのか?という点について、説明を求め、それが出来ないなら履行を請求するのがよさそうな気がします。
 わかってるならそのうち返事があるだろうという期待が間違いで、無いものは無視されたものとして毎度(コピペでいいので)争点、放置されている部分は明示するようにすると逃げにくいのではないかと思います。
 対応を見る限り、問題ないと思うんだけどなにやらこのユーザーは不満らしい。表面的に見ると欲しいファイルはこの辺りらしいけどってところをちまちま出してきてるだけで、自分らに問題があると考えていない節があります。

 どうせ自発的に何かを理解することも調べることもしないのですし、明文化されたライセンスが双方の根拠になるはずなので、それを根拠に「おかしくないというのならその該当部分と根拠と解釈を明示させる」方が水掛け論にはならないとは思います。
 その釈明、根拠が「そう読める」ようならその辺りが落としどころでそれが曲解に近いのであれば、その齟齬をどう読めばそうなるのか?と追求するほうが、同じことを言われずに済むのではないかと思います。
 その際、ガキの使いの様な状況になるようなら「まともにわかる人と話をさせてくれ」でいいのではないでしょうか。
 毎度、返事が出来そうなところ対応できそうなところだけ拾って適当に返事が返ってくるようなので、その場で問われないことはスルーしていいと解釈しているようにも見えますから「終わっていないこと、解決していないこと」は明示しないとダメなんじゃないかと。
 面倒でも毎度箇条書きのように、条件を明示して、終わったものだけ消すようにするとかしないと、黙ったものは気が済んだことにされてる気がします。

 面倒かもしれませんが、これだけやる気が無い相手なら、争点、要求は明瞭にして、「とっととやれ。使うための条件としてはっきり書かれてるんだから準備はあるよね?」と言ってしまったほうが時間は掛からないのではないかと。

 そういえば、HDL-CEのオマケケーブルもcat5eのSTP(ケーブルに明記、並びにコネクタもシールド)されていて、そういえば、色んなところが、「これと似た感じ」だったりするのですよね。
 フラットの短いケーブルだった気がしたのは別の機種だっただろうか…HDL-CE1.0は持ってたはずなんだけど。
 ソースに「有りそうなものが無いなぁ」と思いつつそのままにしてあったのですが、これも足りてないのかもしれませんね。ただ、製品の該当部分へのアクセスが面倒で確認が…。

 あと「最後のアップデート」のオフラインでのアップデートファイルの提供がいつまで経ってもありませんねぇ…。

投稿者:Takeshich  投稿日時:2015/11/20 23:26 親投稿 - 子投稿.1 No.196

昨日サポートから確認のメールがあって、
サポートとしては2週間ほど前にも今回のとは別のファイルをメールで送付したようでした。
ただ、当方のところにはメールは届いておらず。。。
どうやら、本当に齟齬があったようです。

おそらく、当方の使用しているメールサーバが受信を拒否する容量のメールを送ってきて
断られたことにサポートしては気づいていないようです。

当方の使用しているメールサーバでは20MB以上のメールは受信できない旨は伝えてあるし。。。
もし、伝わってなかったとしても、メールを扱う職業に就いていて
最低限のリテラシーとしてある容量以上のメールが届かない可能性も考えられるはずですし、
さらにサーバから拒否されたらリターンメールが確認できるはずなのですが。。。

あくまでも想像で、
まだサポートからの返信がないので事実ではないかもしれず、なんともいえませんが
残念な可能性は高そうです。。。

投稿者:え?  投稿日時:2015/11/21 00:58 親投稿 - 子投稿.1 No.197

 一体どれくらいの容量だったのでしょうねぇw
 まぁ、馬鹿でも20MBくらいしか受け取れませんよって伝えていれば、分割して送ってくるくらいのことはド素人でもやるはずですし、事前に確認とかするものではないですかねぇ。
 営業さんとかなら仕方ないところはあるかなとは思いますが、ユーザーサポートって対外的には開発ほどではないにしろ技術職に近いところのはずで、メール一つまともに送れないで誰のサポートが出来るんだって話だとは思います。いや、びっくりするような返事あちこちでしてるけどね…ここのサポート…。
 送受信はフォームを介して行うようになっていますし、基本的には作業に使ってるもので直接のメールのエラーなどは確認できない可能性もあるのですが…連絡が到達していないことでクレームなんていう馬鹿らしいことを引き起こすなら、チェックはすべきだと思うのですけどどうなってるんでしょうね。少なくとも一回社員だか派遣だかは、講習会開いて基本から勉強しなおしたほうがいいんじゃないかと思います。

 まぁ、20MBをどの程度上回っていたのかわからないのですが、ioplazaのサーバにファイルとして置く(そもそも此処がまともな製品を構成しなかったからこうなってる)とか、幾らでも手の回しようはあるはずなのですが。

 どっちにしろ、ドキュメントの変更や、周知などの件は手もつけていないので、まだやらないのかなーと思ってるくらいなら、全部箇条書きにして送ると少しはマシなんじゃないかと思います。
 多分何もいわ無い事は何も自覚が無いし、何もする気は無いのだと思いますし。
 届くはずだったもので全部揃ってても、ドキュメントの更新などが残ってると思うので、どっちにしろ未履行なことは確認しておいたほうがよさそうです。

投稿者:Takeshich  投稿日時:2015/11/24 22:56 親投稿 - 子投稿なし No.198

minidlnaのソースコードは届きました。

https://drive.google.com/file/d/0B1Tfr ... zc2diMVE/view?usp=sharing

tagutils-dff.cのタイムスタンプが頒布されたバイナリの日付より未来なのが気になる。。。

u-bootのソースコードも送ったようですが、まだ届いてないです。
おそらく15MB以上20MB以下の添付ファイルで、制限に引っかかってしまっているようです。

> 届くはずだったもので全部揃ってても、ドキュメントの更新などが残ってると思うので、どっちにしろ未履行なことは確認しておいたほうがよさそうです。

問い合わせたのでそのうち回答が来るはずです。

投稿者:え?  投稿日時:2015/11/26 19:56 親投稿 - 子投稿.1 .2 No.199

 u-bootで問い合わせた分が揃うなら、ソースの件は終わりなのですけども……。
 ……こういう添付メールごとロストなんてことが無いように「メディアに入ってれば終了」だったのですけどね……そもそも、「メールで」とは指定していないのに、何でメールで送りつけてくるんだろう……メールボックスに入らないからっていうのも「円盤でくれ」の立派な理由のような気もしますし、事実、最初のアレよりは随分とおきな規模になっているわけですが…。
 別件のついでに請求したらちゃんとしたセットが届くのでしょうか。

 ドキュメントの調整は一番楽な作業の気がするのですけど、やりました終わりましたの報告じゃなくて、返事を待つというのが一年越しの話にしては随分とアレなきはしますね…。

 せめて、言い訳、言い分の類が少しでも納得できる解釈に基づいたものだといいのですが。

投稿者:Takeshich  投稿日時:2015/12/11 21:06 親投稿 - 子投稿.1 No.200

>別件のついでに請求したらちゃんとしたセットが届くのでしょうか。

現状では届かいないと思います。

minidlnaのソースコードについてtagutils-dff.cのタイムスタンプが頒布されたバイナリの日付より未来なのが気になり
minidlna-20150520-1.fc12.armv5tel.rpmの中にあるminidlnaのタイムスタンプは
2015-05-26 23:23
なのに
minidlna-20150520.tar.gzの中にあるtagutils-dff.cのタイムスタンプは
2015-06-15 10:49
ということについて、問題ないか確認しておりますが、10日以上経っており
回答がないので、どうやら問題があるらしい。。。です。
そもそもバージョン管理をしていれば、適切なものを開示できるはずですが、
すぐに回答できないということは、そうできていない状態なようですね。

ソースについてバージョン管理していない状態で、問題があったら
頒布したバイナリに対応するソースコードは存在しない可能性が高いわけですから
どう対応するのでしょうか。。。

u-bootについては結局送れなかったようで、
メディアファイルに保存して発送するという回答をもらったのですが、
上述した問題が片付いたら、今までのファイルを纏めた形で送ってくださいとしております。

>ドキュメントの調整は一番楽な作業の気がするのですけど、やりました終わりましたの報告じゃなくて、返事を待つというのが一年越しの話にしては随分とアレなきはしますね…。

この件については、
今しばらく弊社内にて確認したいことがございまして追ってご連絡をさせていただきます。
と回答をもらって2週間経ちましたが、未だ回答を得ておりません。
今しばらくがどの程度かよくわからないのでまぁそのうちなのでしょう。
私個人の感覚ですと遅くても1週間もあれば対応できると思っているのですが。。。

さらにファームウエア更新後
RockDiskNext-20150429.zip
RockDiskNext-20150807.zip

アップデータとしてHPよりダウンロードされない件についても問い合わせしておりますが、
現在確認中ですので、改めてご連絡させていただきます。
と回答を得てから10日ほど経過しておりますが、未だ回答はありません。。。

まぁ、相変わらずの最低な対応です。

投稿者:Takeshich  投稿日時:2015/12/11 21:06 親投稿 - 子投稿なし No.208

>別件のついでに請求したらちゃんとしたセットが届くのでしょうか。

現状では届かいないと思います。

minidlnaのソースコードについてtagutils-dff.cのタイムスタンプが頒布されたバイナリの日付より未来なのが気になり
minidlna-20150520-1.fc12.armv5tel.rpmの中にあるminidlnaのタイムスタンプは
2015-05-26 23:23
なのに
minidlna-20150520.tar.gzの中にあるtagutils-dff.cのタイムスタンプは
2015-06-15 10:49
ということについて、問題ないか確認しておりますが、10日以上経っており
回答がないので、どうやら問題があるらしい。。。です。
そもそもバージョン管理をしていれば、適切なものを開示できるはずですが、
すぐに回答できないということは、そうできていない状態なようですね。

ソースについてバージョン管理していない状態で、問題があったら
頒布したバイナリに対応するソースコードは存在しない可能性が高いわけですから
どう対応するのでしょうか。。。

u-bootについては結局送れなかったようで、
メディアファイルに保存して発送するという回答をもらったのですが、
上述した問題が片付いたら、今までのファイルを纏めた形で送ってくださいとしております。

>ドキュメントの調整は一番楽な作業の気がするのですけど、やりました終わりましたの報告じゃなくて、返事を待つというのが一年越しの話にしては随分とアレなきはしますね…。

この件については、
今しばらく弊社内にて確認したいことがございまして追ってご連絡をさせていただきます。
と回答をもらって2週間経ちましたが、未だ回答を得ておりません。
今しばらくがどの程度かよくわからないのでまぁそのうちなのでしょう。
私個人の感覚ですと遅くても1週間もあれば対応できると思っているのですが。。。

さらにファームウエア更新後
RockDiskNext-20150429.zip
RockDiskNext-20150807.zip

アップデータとしてHPよりダウンロードされない件についても問い合わせしておりますが、
現在確認中ですので、改めてご連絡させていただきます。
と回答を得てから10日ほど経過しておりますが、未だ回答はありません。。。

まぁ、相変わらずの最低な対応です。

投稿者:え?  投稿日時:2015/12/15 00:32 親投稿 - 子投稿.1 No.201

 なにやらSPAMの削除すらやらなくなっちゃってますけどね。
 挑戦者ブランドそのものが最後のプロダクトだったRockRizmが完売して商品がありませんし。
 ……なのになんでRockDiskの名前を残したんだか。
 命名規則的にも挑戦者じゃないですし本家が引き取ったのに。

 ソースは本家が結構適当な事をしていますから、開発元の問題でしょうねぇ。
 でもまぁ、ソースを提供しないといけない意味をだれも考えてないのだとは思います。バイヤーと、それにちょっと入れ知恵したハードウェアの人と、適当仕事の海外の人たちしか居ないのでは仕方ないんですけども…。
 問題があったら、現状のコードに場当たり的なパッチを当てるか、オリジナルに戻すとかするのではないですかね。動いたら何でもいいと思ってそうではあります。

 u-bootはファイル分割するなり、当事者であるioplazaのサーバを借りるなり、転送手段はありそうなのですが、出来ないのがなんとも…。
 サイズが大きいだけで対処できなくなるのも業種を考えたら残念すぎますよね…。問い合わせた先は「技術サポート」のはずなんですけどね。営業じゃなくて。

 ドキュメントについても、配布すべきソースがこの有様だからという可能性もありますが、説明をしないところがちょっと酷いかなと。

 ファームも、中途半端なアップデートや途中で抜けがあったりしたこともあるようなので、出来ればファイルのチェッカとか、上書きで累積的アップデートの提供があっても最後の積もりならよさそうな気はしますね。
 親ブランドだと、初期ファーム+アップデータのアーカイブで装置初期化するので、アップデータは常に累積的アップデートになってるんですが、この製品の場合は、アップデートの成功のチェックや、整合性の確認をしてるように見えないのはこのままなんでしょうかねぇ。
 まあいいかとか、動いてるようだで、変な状況になってるのがゴロゴロとありそうな気がしなくも無いです。

 アップデータについても、確認だけで時間が掛かるのは残念ですね。

 まぁ、会話によって返事から確認するのではなく、全部文字に起こして直接的な表現で要求、問い合わせをするのがよろしいのだと思います。そうしないと、多分まだ何年も掛かってしまいます。
 そこに文字があることについては相応に(少なくとももう一寸待ってください程度の)返事は来るはずですし。
 でも、後一寸じゃないですかね。ファイルについては、後一寸ですし、必要な対応も既にすべき対応について投げたわけですし。
 お疲れ様でした。

投稿者:Takeshich  投稿日時:2015/12/25 22:17 親投稿 - 子投稿.1 No.202

んー。

>minidlnaのソースコードについてtagutils-dff.cのタイムスタンプが頒布されたバイナ
>リの日付より未来なのが気になり
>minidlna-20150520-1.fc12.armv5tel.rpmの中にあるminidlnaのタイムスタンプは
>2015-05-26 23:23
>なのに
>minidlna-20150520.tar.gzの中にあるtagutils-dff.cのタイムスタンプは
>2015-06-15 10:49
>ということについて、問題ないか確認しておりますが、10日以上経っており
>回答がないので、どうやら問題があるらしい。。。です。
>そもそもバージョン管理をしていれば、適切なものを開示できるはずですが、
>すぐに回答できないということは、そうできていない状態なようですね。

この件について、先ほど質問から1ヶ月以上経ってやっと回答が来ました。

minidlna-20150520-1.fc12.armv5tel.rpmの中にある
minidlnaのタイムスタンプ(2015-05-26 23:23)と
minidlna-20150520.tar.gzの中にあるtagutils-dff.cのタイムスタンプ
(2015-06-15 10:49)の違いにつきましてはファイル管理上の問題でございましたので、
ご提供にあたり問題はございません。

とのことでした。説明の意味がわからないのですが、
おそらく、GPLに沿っていてバイナリに対応するソースコードということなのでしょう。
私は確認にこれほど時間がかかるはずがなく、回答に1ヶ月もの時間を要するのですから、
問題があって、ゴニョゴニョあった結果、対応するファイルが存在しないので、
こう回答せざるを得なかったと思っており、回答の正しさを信じていないのですが、
このようにIODataさんが主張するのですからそうなのでしょう。
この説明で理解してもらえると思って書いているのでしょうかね。。。

で、さらに、このような回答をしてきたのにもかかわらず、
この問題がクリアになったら、今までのファイルを纏めた形で送ってくださいと
お願いしてあるのに、
今までのソースコードをまとめて、メディアに保存して発送したというのが連絡が
一緒に来ないのは、なぜなのでしょうか?

これで、ソースコードの開示については完了できるはずなのに。。。

もしかすると他にお願いしている件についても完了した後に、
メディアを発送するつもりなのだろうか。。。意味不明。。。

ぼんやりと対応してるんだろうなぁ。

投稿者:え?  投稿日時:2015/12/28 18:29 親投稿 - 子投稿.1 No.203

 素直に考えれば、「うっかり触っちゃってタイムスタンプは変更されたけど中身は同じよ」なのかもしれませんが…。
 多分伝言ゲームなので、「そういわれただけ」なんでしょうね。
 で、「投げた質問が返って来たのがこの前」だったのかもしれません。この辺りは、別の会社が入ってて、下手すると開発元との間にも何か入ってる可能性もあるので、I-Oだけが全部悪いのか?というと微妙ではありますが、「顧客にとってはそんなことかんけーない」のもまた一つの事実です。
 というか、乗り込んでって確認するわけでもなく、結局は問い合わせを投げて戻ってきたものを翻訳なりして更にこっちに投げ返しているだけなのでしょうし、ドキュメントの改定があの有様なら、更に社内でぐるっと回って遅延してるような気もします。

 あと、「基本的に積み上げる気が無い」のが此処一年の対応なので、「気がついたときに言葉にして投げ込まないと」忘れて消えちゃう可能性が高いです。書いてあって行動を起こさないなら、何かあるか、読み飛ばしたか忘れたのだと思いますが。

 一番楽そうなアップデータの公開と、ドキュメントの改定が他所が噛んでる話よりも「確認するといって進捗すらない」のもよくわからんです。

 結局年内に終わることは無さそうですね。残念ですが。
 でも、なんだろ。多分悪い人じゃないんだろうなぁとはおもうんだけど、適当な人たちだなぁとはioplazaの広告を見てても思います。
 自社製品なら、開発に聞けば、もっとちゃんと製品を棲み分け、製品に応じて訴求できそうなんですが、何故か製品のカタログだけなぞってアピールするから、相関関係がおかしいのですが。
 専売品のウリになってるところの機能の大半は実はベース製品も持ってるのに、固有のものの様にアピールするのは誤読を狙ってるとしか思えませんし…。
 ちゃんと広告しても売れるように売価に差をつけたのでしょうに、何でこんなことするんでしょうねぇ…。出自が違うブランドを混ぜちゃったりしてますし。

投稿者:Takeshich  投稿日時:2015/12/28 23:06 親投稿 - 子投稿.1 No.204

>素直に考えれば、「うっかり触っちゃってタイムスタンプは変更されたけど中身は同じよ」なのかもしれませんが…。
>多分伝言ゲームなので、「そういわれただけ」なんでしょうね。

そう素直に考えられない点が一つあって、
挑戦者のtwitterアカウントが一度ファームウェアは近日公開予定と言っておきながら
数日後に詳細決まり次第挑戦者BBSにてお知らせいたします。とコメントしたのが
ちょうどtagutils-dff.cのタイムスタンプ付近で、リスケするための確認とかでいじったんじゃないかな?
と思えるからです。でもまぁソース見るとそうでもなさそうなんだけど、コメントアウトの部分とか
20140415版と比較すると増えています。
素直に、「はい、そうですか。」と思えないところです。
また、以前ID3tagが取れないのが仕様かどうか確認した際は、1週間程度で回答があったので
1ヶ月かかったことに違和感を覚えます。

IOはinXtronにこれだけひどいことをされていても、伝言ゲームやるしかないんですかね。
技術者はほとんど絡んでいないみたいだから、仕方ないか。
最低限やるべきことをわかっている方がいないみたいですしね。

>一番楽そうなアップデータの公開と、ドキュメントの改定が他所が噛んでる話よりも「確認するといって進捗すらない」のもよくわからんです。

開発元がひどいことは置いておいて、開発元に関係なく対応できるところなのに1ヶ月以上経っていますね。
できない何かがあるのでしょうね。忘れたり、社内で消えちゃったりしてないことを祈ります。

10月に物理メディアが送られてきた時には、やっともう少しと思ったもので、年内には終わるかなぁと期待していましたが、
年内で終わらないのは残念ですね。あとちょっとがすごく長い。

投稿者:え?  投稿日時:2015/12/30 20:52 親投稿 - 子投稿.1 No.205

 これも「素敵な対応のおかげ」で気がついちゃってるというか、相手が信用できれば、問い合わせとして投げる前にどうせ手を入れちゃうし、多分大丈夫なんだろうと、問い合わせにはなってない気がします。
 もちろん「対応するコード」じゃないと「現状の動作」を担保しないのでだめなんですけど、コード見て直ってりゃビルドして差し替え、直ってなければ直して差し替えとか対応は出来るので、そんなに突っ込まれることは少ない気がしなくも無いんですよね。

 あと、同じようなものをうってるあそことか、あそこだったら、門前払いしそうなことを思えば、「意外と生真面目」なんて評価も出来そうなんですが、内容が残念すぎて相殺されてるのは、労力に見合ってなくて損してますね。ちゃんと対応できると、老舗の周辺機器メーカーで技術力もOKってアピールにもなりえるのですが。

 ただ、社内で完結することが「確認事項がある」って理由で放置している進捗を報告しないのは流石に酷いかなと。これは、せめて、遅延理由や何を確認しているのかを明示しないと言い訳にもなってないので。

 面倒だなぁって空気はサポートからの対応から漂ってるんですが、わかりそうな人に相談して、一気に片付けてしまえ!という発想は無いんでしょうかね…。バイトでも、正社員でも間違いなくのらりくらりが「何の生産性も無いムダコスト」になってて、信用を毀損する分マイナスになり続けてるのですが。もしこれに成功体験があるんだとすれば、毎度「それでいいと認識してます」とか「要件を満たしています」で黙らせてるってことになるんですが、それは流石にサポートじゃなくて、タダの嘘ですよね…。

投稿者:Takeshich  投稿日時:2016/01/17 17:39 親投稿 - 子投稿.1 No.206

minidlnaのソースコードは、問題がないと回答を得たので、
U-Bootのソースコードとか今までに開示されたものを含んだ物理メディアの送付がされるのだろうと思っていたけれども、どうやらされないようなので、年末に催促していました。

しかし、年が明けて1週間経っても返答がないので、さらに催促して
やっと先週末に物理メディアを送付したようです。届いたら内容を確認し、どこかにUPしようと思います。

催促と同時に1ヶ月半ほど前に
*HPに未掲載のアップデータについて
*GPL遵守に関してソースコード開示以外にしなければならないこと(ドキュメント関連)
について指摘していて、回答をくれると言っていた件についても
いつ頃回答がもらえるのか確認してみました。

すると
「 こちらにつきましては弊社見解を改めてご案内させていただきますが、大変申し訳ご
ざいませんが、現時点におきましてもご案内出来かねる次第であり、なるべく早くご連
絡をさせていただきますので、何卒よろしくお願い申し上げます。」

という1ヶ月半も放置していたことにもかかわらず、この回答なの?
と思える返答を頂いて、相変わらずなのだなぁと心から思った次第です。
改めてって一度も回答もらってないんだけどなぁ。。。

アップデータは手元にないのかなぁ?2015年の前半はフライング気味に公開してたのに。
ドキュメントの件はなんとなくだけど、担当者が上にあげてないとか忘れてたような気がするなぁ。

投稿者:え?  投稿日時:2016/01/17 23:09 親投稿 - 子投稿なし No.207

ビルドして整合性確認するしかminiDLNAは無いでしょうねぇ。
督促しなくても、進捗と予定を明示すればそれでもつなぎになるのに、ほっとけばほっとくほど怒らせるし信用を毀損してしまうのですけど、これが「対外的に一番ユーザーに近い場所」というのが本当はよろしくねいと思います。無関係な会社ですから大きなお世話でしかありませんけど、これ、相手によっては、要らない問題を作るだけだと思うのですけども…。

とりあえず、今でも見る人は居ないわけでもないですから、「掲示板のSPAMの掃除」も追加したほうがいいのかもしれません。ただの広告ならいいんですが、ちょっと怪しげな内容のリンクも含まれているような…。一応これでも生きてた頃はちゃんと掃除されていたんですがね。去年も一定の時期まではああ、一応消えてるって思った記憶がありますが、そういうのなくなりました。

もしかすると「挑戦者」は潰してしまったのかもしれませんね。なので、面倒を見る担当者が居ない感じがしなくもありません。
これも、せめて、調整中の内容、確認してる内容を開示すれば良いような気もするのですが。
結局サポートから投げても、その先で止まってれば答えようがないのも事実ですが、ユーザーからは関係がないのも事実ですし。

アップデータも基本的に要望は投げるけど、向こう側が主導でこっちは受身でアナウンスと対応だけしてるような雰囲気なので、サポートの外側も動きが止まってるのかもしれませんが、もう担当が居ないから止まってる…ということもありえて怖いw

自分でこじらせてるのに、多分面倒くさい問い合わせだなぁって思ってるんだなぁとは感じたりはします。
あと、もう売ってないんだからいいでしょって雰囲気も感じますし、多分解決しても糧にはしてくれないんだろうなって気も。

「原因とか、原因の責任者」はまだ在籍はしていそう(バナーに登場してるし。)なんですけどねぇ。でも手を離れればでき無い事もあるから、これもまぁ、本人がやれってのも外側の人間の意見でしかないんですが、めんどくさいなぁって思われるのと同じようにこれもまた、感情論とか心情的な部分での納得の出来なさなんですよねw

投稿者:Takeshich  投稿日時:2016/01/21 22:34 親投稿 - 子投稿.1 No.209

ソースコードが届いていたので、置いておきました。
https://drive.google.com/file/d/0B1Tfr ... FUnpMU3M/view?usp=sharing

これでソースコード開示は一応終了です。

u-bootのソースコードですが、自分宛てにメールに添付して送ってみましたが、14MB程度にしかならず
キチンと届き、20MBを超えるものではありませんでした。プロバイダで受送信時にウィルススキャンを
しているようですが、それにも引っかからなかったため、当方が使用しているメールサーバが受け取りを
拒否したものではないようです。
おそらく、iodata側のSMTPサーバ(ウィルスチェックサーバ?)で弾かれて送れてなかったような気がします。
u-bootのソースコードより容量の大きい物でメールに添付されたものもありました。

追加で来たものの中には、圧縮ファイルなのに無意味に更にzipで圧縮されているものもあり、
そこから見えてくるものもあるなぁと感じました。

投稿者:え?  投稿日時:2016/01/22 22:45 親投稿 - 子投稿.1 No.210

 お疲れ様でした。
 ただ、開発元が他所にもこんな感じのようなので、生き別れのアレコレのユーザーにも場合によっては何かの参考や手助けになるかもしれないです。
 SDKを公開してるメーカーもあるのがもうよくわかりませんが。
 最新版のSDKが公開されれば、それはそれで、必要分のみよりも何か判る可能性もありますが。

 メールについてはリテラシの問題ですね。送って良いですか?届きましたか?この確認をしてないから問題になってしまうわけで。
 お互いに不都合があるなら、それは仕方が無い事ですり合わせればいいのですが、勝手にやって、こっちは間違ってないよってやるからあれなのであって。でも、通常サポートの場合送ったとしてもログとかの類でアップデータの類は多分ダウンロードコーナーにおいてあるもので話が済むでしょうし。避けられたことで、色々がなければしょーがないっすねーで済んだことも、うそとかごまかしがあるから心象が悪くなってる気もしますし。

 圧縮云々は、圧縮率じゃなくて書庫として使ってるとか状況にも寄りますが、置いてあるときには既にアーカイブされていてフォルダ丸ごと圧縮したとか、ないわけでもないかなぁとは思いますが、これはI-O側がいじっては居ないと思うのであちらの管理とかの問題だとは思います。

 でも、社内で直接話を出来そうな範囲で解決できそうな中身が一番最後というのもなんとも言えませんな。
 普通そこから片付いて、外が絡むものは遅くなりますごめんなさいって進捗を投げ返されるような形なんだと思いますが。

 トップページが更新されて更に挑戦者は奥に追いやられ、まだ在庫がある商品が見えにくい場所に隠れてしまったりと、何がしたいのかよくわからん変更が…。

 なんというか、内容の割には時間掛かりましたね。お疲れ様でした。あとは…中の人にやる気があるなら、限りなく事務手続きに近いアレコレなんですけどね。
 もうソースは一式あるのですから、他と同じフローで頒布しても楽なはずですし、興味があって請求される方は「ちゃんと入手」出来るはずですが。

 長期にわたってひとまずお疲れ様でした。

投稿者:Takeshich  投稿日時:2016/01/26 12:54 親投稿 - 子投稿.1 .2 No.211

なんか
ファームウェアのアップデータを公開した旨、ドキュメント関連の対応をしたという
連絡が来ていました。
http://www.ioplaza.jp/shop/contents/rdnext.aspx#farm
http://www.iodata.jp/support/qanda/answer/s19384.htm

結局、対応された人は、GPLについては理解できなかったということで、もういいかな。

来たメールには、
以後同様のことの無きよう確認作業等を徹底させていただきます
と締めくくられてたんだけど、確認作業が甘いようで、

ファームウェアのアップデータを公開した旨のお知らせは更新されていないようだし。
http://archive.is/qA5Zh#selection-787.0-787.31

GPLについてこれでいいのですかねぇ。少なくともGPL理解しているならこういう書き方にはならないだろうに。きちんと確認したのかなぁ。
http://archive.is/bonGR

最後まで嘘な感じで、まぁお疲れ様でした。

投稿者:Takeshich  投稿日時:2016/01/26 14:08 親投稿 - 子投稿なし No.212

20150429の手動アップデータ、自動更新のアップデータと内容が微妙に違うんだが。。。
もうどうしようもない。

ntpdateが細かいリビジョン違う。

以下の
http://bbs.ioplaza.jp/forum/index.php?topic_id=2672#post_id10538
で書いた修正対応がされているのとされていない差のようだ。
手動アップデータは古いので、ntpdateが起動しない版のよう。

手動アップデータ:
ntpdate-4.2.8p2-1.armv5tel.rpm

自動更新のアップデータ:
ntpdate-4.2.8p2-2.armv5tel.rpm

開発元もiodataも腐っててもうどうしようもないのね。
「確認作業等を徹底させていただきます」は口先だけね。

投稿者:たく  投稿日時:2016/01/27 00:03 親投稿 - 子投稿.1 No.216

Takeshichさん

ソースコード開示の件、本当にお疲れさまでした。
後半あまり手伝えなくて申し訳ないです。
stage1のソースもあれば良かったのですが、
そこを変更する事はあまり無いと思いますが、他と変わってないといいですね。

GPLに関しては、判らないふりして適当に流された感じですね。。。
inXtron(akitio)には徹底してねと指示だけして、自分達は何もしてないんだろうと感じられます。

自動更新のアップデータは、現在のFWがVer20141023~Ver20150303のRDNには同じものがDLされてます(RockDiskNext_tr_20141023-20150429.zip)
なので、変に加工せずいつものようにリネームだけしてアップして
手順をそれに合わせて変更すれば問題なかったはずなのに。。。
何やってるんだろうね。

同一Verで挙動の違う物があるなんて、サポートもやりずらくなるだろうに。。。

投稿者:Takeshich  投稿日時:2016/01/27 15:58 親投稿 - 子投稿なし No.217

たくさん

>自動更新のアップデータは、現在のFWがVer20141023~Ver20150303のRDNには同じものが
>DLされてます(RockDiskNext_tr_20141023-20150429.zip)
>なので、変に加工せずいつものようにリネームだけしてアップして
>手順をそれに合わせて変更すれば問題なかったはずなのに。。。

あー。微妙なバージョン間での累積のアップデータがあるんですね。
累積されてないアップデータもあるようですね。
アップデータ6つあるのを4つにすればいいのにって話ですか?
RockDiskNext-20140430
RockDiskNext-20141023(RockDiskNext_tr_20140430-20141023)
RockDiskNext-20150429(RockDiskNext_tr_20141023-20150429)
RockDiskNext-20150807(RockDiskNext_tr_20150429-20150807)
ってことかな。

>同一Verで挙動の違う物があるなんて、サポートもやりずらくなるだろうに。。。

そもそもサポート自体が気づいていないのだから、
minidlnaのフォルダ表記と同じ感じな残念な対応な気がする。
一応、サポートには内容が違うことは伝えた。

>何やってるんだろうね。

なんでこんなにサポートは自らこじらせてくるのか。
サポートとユーザどちらにも益にならないことなのに。。。
ほんとに何やってるんだろうね、どうしようもない。。。
iodataでわかっている人いない可能性高いし、inXtronとの関係よくないのかなぁ。
inXtronにテキトーに対応されて、それが正しいか確認できない状態で開示するのは相変わらずのようで。
同じこと何度も繰り返しても責任も感じていないようだし。

サポートへの問い合わせもう終わるかなと思ったら、まだだった。。。

投稿者:え?  投稿日時:2016/01/27 21:40 親投稿 - 子投稿.1 No.213

LANDISKのソース請求のところに「対象製品」を追加すれば言いだけだと思うんだけど、何で項目作っちゃうかな…。

というか、本当にLANDISK準拠にしちゃって、担当者に必要要件メシおごるから教えてって頼んでみたらよかったんじゃないかと。

そうすれば「使ってますよ」って宣言と「権利はよそがもってますよ」宣言が抜けることはないはずなんだけど、ファイル名が同じでドキュメントが改定されて居たりしますかね?
請求権があるんですよーっていう公示も義務だし、他の製品ではやってるんだから、足りないのわかりそうなのに。

結局結構な大きさに膨れ上がってるんだから頂戴っていえば、普通にはメディアで送付って状況になってるはずですし、LANDISKの請求のFAQだって、先ずはサポートに問い合わせてねってなってるので、シリアルになるのかMACアドレスになるのかってそれは対応の方で調整できるんだし。

というか、むしろうちが作ったもんじゃないのはシラナイヨ。ソースは出すけどねってしたほうが、言い逃れも色々しやすそうな気がしなくもないけれど。

ただ、この製品については、似たような製品の状況は多分どれも場当たり的アップデートになってるはずなので、RockdiskNextだけが極端に同じ出自の物で悪いことになってるとは思えないです。
が、過去の中身としてもアップデートに失敗して中途半端なまま放置されてるファームのがありそうですし、ちゃんとした構成にする方法ないものですかね…。
一応最後の積もりなら、作業の数だけ問題の発生確率が上がることを思えば、累積的アップデートで適用できるファイルを用意したほうが安全な気はしますが…。

I-Oの製品は担当者がポンコツだととんでもなく地雷で、サポートセンターはガキの使いってのが露呈してるのがなんとも…。

最低限の工数で片付けようとして逆にムダに仕事増やして遠回りするのは何か意味があるのでしょうかね・・・。
めんどくさいナーって思うならちゃんとチェックするところ洗い出してもういいよね!って返事出したほうが速いしらくだと思うんだけど、ユーザーを丸め込むことこそが業務ってことになってそうで怖い…。

投稿者:たく  投稿日時:2016/01/28 00:57 親投稿 - 子投稿なし No.218

Takeshichさん

>あー。微妙なバージョン間での累積のアップデータがあるんですね。
>累積されてないアップデータもあるようですね。
>アップデータ6つあるのを4つにすればいいのにって話ですか?
>RockDiskNext-20140430
>RockDiskNext-20141023(RockDiskNext_tr_20140430-20141023)
>RockDiskNext-20150429(RockDiskNext_tr_20141023-20150429)
>RockDiskNext-20150807(RockDiskNext_tr_20150429-20150807)
>ってことかな

 そういう事なんです。
 自動更新のサーバーは、inXtron側のサーバーみたいです。
 なのでIO Dataにそのzipファイルごと渡されてると思うんですが。。。
 わざわざ差分を作って間違えるって、どういう事なんだろうね?

[root@ROCKDISK01 ~]# rpm -qip /home/Public/FW20150429/automatic/ntpdate-4.2.8p2-2.armv5tel.rpm
Name : ntpdate Relocations: (not relocatable)
Version : 4.2.8p2 Vendor: (none)
Release : 2 Build Date: Mon 18 May 2015 10:30:35 AM JST
Install Date: (not installed) Build Host: myNAS
Group : System Environment/Daemons Source RPM: ntpdate-4.2.8p2-2.src.rpm
Size : 66312 License: distributable

Build Date: Mon 18 May 2015 10:30:35 AM JST
作ったの5月だけどVer20150429。
 多分、ntpとntpdate差し替えになったんだろうけど
 ntpdateも入れ替えないといけないのを忘れたんだろうね。

>そもそもサポート自体が気づいていないのだから、
>minidlnaのフォルダ表記と同じ感じな残念な対応な気がする。

 そしてユーザーだけが困らされるのか。。。

>iodataでわかっている人いない可能性高いし、inXtronとの関係よくないのかなぁ。

 inXtronも我々と同じように頓珍漢な指示ばかりで困惑してたり。。。
 間に技術者がいればそんな事は無いと思うんだけど。
 指示出す側がGPLにしろ他の事にしろ、何も理解してないと思う。

>サポートへの問い合わせもう終わるかなと思ったら、まだだった。。。
 本当にご苦労様です。。。
 ユーザーからこの程度のミスの指摘を連発されたら、普通だったらメーカーとして恥じると思うんですが、懲りてない様ですね。

投稿者:たく  投稿日時:2016/01/28 02:13 親投稿 - 子投稿.1 No.219

え?さん

>結局結構な大きさに膨れ上がってるんだから頂戴っていえば、普通にはメディアで送付って状況になってるはずですし、LANDISKの請求のFAQだって、先ずはサポートに問い合わせてねってなってるので、シリアルになるのかMACアドレスになるのかってそれは対応の方で調整できるんだし。

 私の場合はメールで問合せたので、フォームにシリアルNo書いてOKでした。
 あと、切手500円分送ってねって感じでした。

 ただ、Webから誰でもバイナリをDL出来る状況なのでRockDiskNextの所有者以外でも、その一部パッケージのソースコードを請求する権利があり、それに応える義務がある事にIO Dataは気が付いているのだろうか?

 >というか、むしろうちが作ったもんじゃないのはシラナイヨ。ソースは出すけどねってしたほうが、言い逃れも色々しやすそうな気がしなくもないけれど。

 ん~でも自分の著作物だって宣言しておいて、それやったらダメじゃない?

>が、過去の中身としてもアップデートに失敗して中途半端なまま放置されてるファームのがありそうですし、ちゃんとした構成にする方法ないものですかね…。

 WebUIにチェック用のアプリとか追加して、それで確認と修正が出来るようになってればよかったんだけど、そんな物ないしね。。。
 今のところtelnetで~っとしか手段が無いのはね。。。
 真っ当な手段としてはメーカーに送るしかないけど、メーカーの手落ちなのに有償修理扱いにされそうで嫌だな。

>一応最後の積もりなら、作業の数だけ問題の発生確率が上がることを思えば、累積的アップデートで適用できるファイルを用意したほうが安全な気はしますが…。

 これで最後宣言されてましたっけ?最後なの?
 累積的アップデートも、それが正しく適用されたか確認するツールなり無いと意味が無くなるんじゃないかな。

 結局サポート自体、問合せ内容を良く判らずに適当やってるからミスばっかなんだよ。。。

投稿者:たく  投稿日時:2016/01/28 13:37 親投稿 - 子投稿.1 No.221

Takeshichさん

>自動更新のアップデータ:
>ntpdate-4.2.8p2-2.armv5tel.rpm

BBS:NFSサービスの保存ができません
http://bbs.ioplaza.jp/forum/index.php?topic_id=2697#post_id10303

NFSの為の修正をntpdateにさせたのかな?
/etc/rc.d/init.d/ntpdate の内容が
/sbin/hwclock --systohc から
/sbin/hwclock --systohc --utc
に変更されてた。



投稿者:Takeshich  投稿日時:2016/01/28 22:26 親投稿 - 子投稿なし No.222

たくさん

>NFSの為の修正をntpdateにさせたのかな?

時期的にも対応内容的にもその可能性が高そうですね。
SYNC_HWCLOCK=yes
にする意味ができたってことかなぁ。

それにしても
ntpdate-4.2.8p2-1.armv5tel.rpmのままのアップデータを公開し続けるのは
リスクしかないと思うんだけど、なんで変えないんだろう。
指摘してからもう丸2日そのままだけど。
外野から何言っても結局はiodataがどうにかすることですけどね。

>ただ、Webから誰でもバイナリをDL出来る状況なのでRockDiskNextの所有者以外でも、その一部パッケージのソースコードを請求する権利があり、それに応える義務がある事にIO Dataは気が付いているのだろうか?

私も気づいてなかった。
言われてみて、あぁそうだなと。

もともとは、miniDLNAのDSD対応に興味があったので、これに気づいていれば
RockDiskNextを購入しなくても、miniDLNA関連ぐらいの開示を請求することはできたんだね。。。
RockDiskNextを購入してしまったから、この一連のGPL対応のグタグタに巻き込まれてしまったとも。。。まぁ仕方ないw

投稿者:Takeshich  投稿日時:2016/01/28 22:55 親投稿 - 子投稿.1 No.214

え?さん

>LANDISKのソース請求のところに「対象製品」を追加すれば言いだけだと思うんだけど、何で項目作っちゃうかな…。

強く同意します。

GPL遵守に関してソースコード開示以外にしなければならないことについて指摘していて、
具体的には他のGPLを扱っている製品ではこうで、RockDiskNextでは同様のことをできていないから
指摘していること。
そして、具体的にはどう対応するかまでざっくりと指摘したのだけれども
Q&Aに、ぼんやりとした、んー?っていう項目が追加されただけでした。

LANDISKのソース請求のところに「対象製品」を追加すればとは言っていないんですが
他のGPLを扱っている製品でやっていることを見れば、わかると思ったんですけどね。

また、以前にも書いたと思いますが、ずっと指摘していたのは
著作物にソースコードを配布する旨が書かれた書面による申し出を添えることで
http://www.opensource.jp/gpl/gpl.ja.html
section3 b)についてです。

それを満たすには
そもそもRockDisk Nextにおいて著作物に添えられた書面は「はじめにお読みください」のみで
「はじめにお読みください」を適宜編集して、公知にし、HPにupすればと指摘したのですが
理解されず無視されたのか、あえて無視されたのかはわかりませんが、対応はありませんでした。
Q&Aに追加するよりもこっちで全部満たしてしまうこともできるはずなんですけど。

まぁ、GPLの条文と自分の会社の他のGPLを扱っている製品でやっていることを
見てるとは思えない謎対応なんですよね。
「今しばらく弊社内にて確認したいことがございまして追ってご連絡をさせていただきます。」と
回答されて2ヶ月待ったんですけどね。

投稿者:え?  投稿日時:2016/01/29 04:19 親投稿 - 子投稿なし No.220

> 私の場合はメールで問合せたので、フォームにシリアルNo書いてOKでした。
> あと、切手500円分送ってねって感じでした。

 これはLANDISKでも同じなんですよね。ただ、どうせわかってないなら、フローは共通化したほうがミスも問題も少ないはずです。
 対象商品のテーブルが一杯なら、既に抜けが幾つか出ているので、それも一緒に入れてあげて二つ目の「同じ内容の」FAQを作ればよかったんじゃないかと。
 新しいほうがドキュメントの不備を補うものなのか?というと、むしろ既存のFAQよりも説明が減ってくるらいでありまして、横着大好きのサポートにしちゃどうしてそうしたのかよくわからんのですけどね。

 ダウンロード云々はLANDISKも、リリースの後修正が大きくなったものは同じことが言えますね。大抵はスクリプトのパッチなんですが、多くはバイナリの修正も入ってしまうので、ファイルを上から書き込むLANDISKのアップデータは更に面倒なことになってる気がしなくもありません。
 この辺りは突くと「ダウンロードに要シリアル」って形で対処されてしまいそうで、ユーザーの手間が増えるだけで終わりそうです。
 基準はわからないのですが、流用できそうなものがそうなっているのか、そういう製品やサポートソフトもあるのですよね。

 責任の部分は「もうだめ」ですね。権利がないのも「俺のもの」っていっちゃった後なので。でも、リリースする前だったら、仕様表未満のことならちゃんと書いておいたほうが「逃げやすく」なるような気はします。

 チェッカは、rpmが信用できるならインストールされているべきパッケージをチェックすればパッケージでアップデートをしているので、確認することは出来そうな気はしますね。
 でも、あんまり小回りが利きそうな仕組みがない上に、作業が杜撰なので、それが必ずしもいいほうに転がらないかもしれないのが不安ではありますが。

 LANDISKの一部だと、出荷ファーム+最終アップデータが基準になって装置初期化をすると、それらが展開されたりします。ですから、最後のアップデータがしくじってなければ、途中で何かしくじってることがあっても、基準+アップデートのプロセスで最新版になるようになってるんですよね。

 まぁ、最後とは書かれて居ませんが、機能の追加もないでしょうし、他所の使い捨てっぷりを見ればキリがいいところじゃないかとはおもいます。
 開発元が少し仕様がちがうこれをいつまでついでに面倒見てくれるものかはわかりませんが。

投稿者:え?  投稿日時:2016/01/29 04:55 親投稿 - 子投稿なし No.215

 基本的に理解を伴ってないんですから、フローは統一したほうが間違いなく仕事が出来ると思うんですよね。
 扱いは違いますが、ioplaza専売と、iodataが挑戦者プレミアムの場合は分離されてないのでFAQのページで分割しておく意味がよくわからないんですよね。
 むしろドキュメントの整備が足りてないのに、説明は目減りする有様という。

 横着大好きなんですから、こういうところはちゃんといい意味で手を抜けば良いのに。

 公示の部分も権利を主張してしまっているので公開するなら修正が必要ですが、幸か不幸か「はじめにお読みください」がないので、修正について明示してある権利がらみのドキュメントを起こして提示して、可能な場所で公示すれば満たせるような気がしなくもないです。
 元のデータがなくても、そんなに部署間で調整が必要とも思えないんですけど、やっぱり「字面だけを追って、どうにかしようとしている」気がします。

 今後はこのようなことがないように…は普通はそれを確認したり履行されないことを証明する部分がないので飾りとして妥当なのですが、自分の行動に自信がないときには「書かないほうがマシ」なのは残念な話です。

 結局相手の思考が途中で止まっちゃって、多分クレームがついてるから対応しているだけなんですよね。
 伝えるのって難しいと思います。本当は、自分らの会社嘘つきですよって世界に公開している状態に気がついてそうならないように考えるべきところだと思うのですが……。

 そりゃあんまり何度もあるケースではないにしろ、矢面に立つのは自分らになるわけですから、少なくともサポートセンターではちゃんと共通の認識を確立しとかないとマズいと思います。
 同じ内容の問い合わせで、製品が違うだけで答えが違っちゃいけないんですけど、丁寧なのは表面だけっていうのはなんとも。
 わからんことに突っ込まれ続けるのが大変なのは心情的にはわからなくないけど、そこはちゃんと上の方にもっていって確認や資料をつくることをしないと駄目なところだと。

 どうせ面倒ごとに巻き込まれるんだったら、得られるものは搾り取っておけば良いのに、労力だけを相互に浪費する状況になってるのはなんとも悲しいところではありますね。
 だって、「リリースするときにちゃんとできて」りゃみんな凄く楽でニコニコはなしが終わるじゃないですか…。整理しておかないとポンコツ担当者がまた出たら、同じことになっちゃうのですが…。

投稿者:たく  投稿日時:2016/01/30 14:55 親投稿 - 子投稿.1 No.223

Takeshichさん

>SYNC_HWCLOCK=yes
>にする意味ができたってことかなぁ。

 /sbin/hwclock --systohc --utc
 を「nas-20150429-2.noarch.rpm」のインストールscriptに追記するだけでも良かったのではとも思う。起動毎に毎回必要でもないし。。。
 個人的にはntpdateにnfsの為だけに、それをさせる意味もないような気がするので、どちらでも良いのではと思います。

>それにしても
>ntpdate-4.2.8p2-1.armv5tel.rpmのままのアップデータを公開し続けるのは
>リスクしかないと思うんだけど、なんで変えないんだろう。

 リスクとして感じて無いとしか思えないですね。
 それとも、この程度の修正もinXtronに問い合わせて時間かかってるのかな?

 毎回、間違い探しのネタを提供することが担当者の義務になってるのかな?

>もともとは、miniDLNAのDSD対応に興味があったので、これに気づいていれば

 実はそうなんですよね。。。
 Takeshichさんが請求を始めてから、改めてGPLを勉強したら
 あぁ、これも頒布じゃないかと。。。
 IOもそこに気が付いて、ソースが揃ってからじゃないとWebにアップデータを公開しないのかなと思っていたので、多少GPLについて理解出来たんだなと。。。
 けどQ&A見て、あぁ ただ人手がなかっただけか。やはり理解してないんだなと思いました。


 サポートの杜撰な対応のせいで、このスレの本題の話から大分遠ざかってしまってしまいましたが、その後どうですか?
 安定稼働してれば良いのですが。

投稿者:たく  投稿日時:2016/01/30 16:57 親投稿 - 子投稿.1 No.225

え?さん

>これはLANDISKでも同じなんですよね。ただ、どうせわかってないなら、フローは共通化したほうがミスも問題も少ないはずです。

 サポートのフォームはLANDISKと共通ですので、行先は同じなのでQ&Aが分かれていても、その辺は大丈夫と思いたい。
 問合せフォームではシリアルNoは必須事項になってるので、それで判断してると思われます。
 所有してない人にまで、ソースコードの請求に応えなくてはいけないわけでは無いので、要シリアルNoで良いと思いますよ。

>同じ内容の問い合わせで、製品が違うだけで答えが違っちゃいけないんですけど、丁寧なのは表面だけっていうのはなんとも。

 そもそもLANDISK以外の製品ではGPLに関するQ$Aも無いので、LANDISKのサポートを経験した担当者以外はGPLが何だか知らないんじゃないのかな。
 RECBOXやルーターとかの説明書に弊社ホームページをって書いてあるけど、どこにあるのかな~、探す気もないけどね。
 おそらくサポート全体がGPLとかコンプライアンスに関する意識が低いんじゃないかな。
 これを機会に全体的に周知されればいいけど、無いんだろうな。。。
 

 同じNAS7821のKD20はUSBから修復できるツールを出してますね。

 USBフラッシュメモリーを用いた、ファームウェアの修復方法(KD20)
 http://www.shuttle-japan.jp/support/nas/517
 
 もう、まるごと上書きってのでも いいんじゃないかな。
 そろそろ、おかしくなった時の為にHDDブートとか確認しとくかな。。。
 

投稿者:たく  投稿日時:2016/01/31 17:52 親投稿 - 子投稿なし No.227

>そろそろ、おかしくなった時の為にHDDブートとか確認しとくかな。。。

http://archlinuxarm.org/forum/viewtop ... b55f103e468facd33d798c823

手順通りにやってみたら、一応起動した。
Arch Linuxのkernelとrootfsでテストしたんけど、RDNのコピーすればテスト環境で色々出来そうだ。

投稿者:Takeshich  投稿日時:2016/02/01 00:21 親投稿 - 子投稿なし No.224

たくさん

>毎回、間違い探しのネタを提供することが担当者の義務になってるのかな?

前からいろいろやらかしているから当方としてはきちんと確認するようになってしまったのですが、
それにしてもやらかしすぎで、担当者は相当やらかしていることに気づいていないような気もします。
または、やらかさないようにする術を知らないのかもしれません。

物理メディア開示からでも、すでに2度はやらかしているような気がします。今回で3度目。
対応する毎ですね。

開示した物理メディアに必要な物が入っていなくて、突っ込まれて
それに対応して送ったファイルの中身が微妙で突っ込まれてってことを
体験すれば、確実に適切なものであるという証拠とともにinXtronから提供を受ければいいと思うのですが
今回も仕込まれていたようし、証左もとってないようです。

inXtronのネタの仕込みも相当なものなのですが、iodata側のザルっぷりも同じくらいです。
まぁ、キチンとやれと言ってもiodataがザルな体制を直さず、inXtronがテキトーに対応しているのを
投げてきているんだと思います。

そういう仕組なので、毎回、間違い探しのネタを提供することができるのだと思いますよ。
ちゃんとやってくれと私は言っているので、iodata側が何らかの対応を取らなければならないはずですが
いつものように華麗にスルーするのが担当者の義務なんじゃないですかね。

inXtronとiodataのどちらかがちゃんとやれば、このような結果は避けられるはずですが、
どちらともちゃんとやらないので、この製品に関してはもし今後も何かある際にはこんな感じなのでしょうね。

>サポートの杜撰な対応のせいで、このスレの本題の話から大分遠ざかってしまってしまいましたが、その後どうですか?
 安定稼働してれば良いのですが。

RockDiskNextはメインで使っておらず、バックアップを取るという使い方になってしまって
あえてバグを再現するようなことをしていないので、安定稼働しているようです。
(必要最低限のサービスしか上げてないので、まぁ普通に稼働しているみたいです。)

付属のLANケーブルについては、他の機器で使用していたところ、IPアドレスが取得できない状況に
陥ることが何度かあり、別のケーブルに変えたところ問題なく取得できるようなので
やはり微妙なものだという結論になっています。

サポートの杜撰な対応のせいでソースコード開示までに時間がかかり、
いろいろ弄ろうと思っていた気持ちはとっくに冷めてしまいました。
そのうち気が向いたらいじるかもしれません。

投稿者:え?  投稿日時:2016/02/01 01:15 親投稿 - 子投稿なし No.226

 あー、いや、ファームのダウンロードが要シリアルになると、NASの場合は必ずしも手元に置いてなかったりするので、確認するのが面倒だったりするのです。
 で、要シリアルなツールや、ファームの製品もあるので、ユーザー側としては面倒が増えるだけなので、アップデータには「ソースのアーカイブも必要に応じて同時公開」が望ましいかなとおもうんですが、I-Oが楽をしたいと思えば、シリアルでダウンロード制限掛けてくるかなと。ただ差分に含まれるものだけになるので、この製品ほどじゃないですが、部署間の意思疎通でどうなるか…。
 サポートを受けるって部分では大差が無いんですが。

 LANDISK AVとか、RECBOXは、FAQには有りませんが、問い合わせるとLANDISKと同じフローで指示がきます。
 ルータは…此処の製品を持っては居ますが、手持ちのは書いてなかったけど、やっぱりFAQに無いだけ(まぁ、書面で書いてあるんですから、どっちにしろ一発目はサポートに問い合わせないといけないので、基本的には、言われりゃ出すけど個別対応扱いなんだと。)じゃないかと、REC-BOX辺りをみると思います。出てくるものは、LANDISKとほぼ同じ…だと思いますが、多分システムに暗号化が掛かってるので、ソースがあっても製品に手を入れにくくなってるように思います。が、ソースそのものは出てきます。

 今のような組織の構造にするなら、「サポートが優秀」じゃないとダメだと思うんですよね。旨く回れば部署が違っても起きてる問題についてはいち早く切り分け通知できるというメリットもあるのですが、適当なこと並べてユーザーを黙らせる部署じゃ機能しない。うまく使えれば結構役に立つ(半ば部署を超えた不具合のデータベースになるんですから)筈なんですが、インシデントを評価できてないと機能しませんね。なーんも知らない人たちが目の前だけ見てたら、似た部分があるから問題が発生する可能性を予見できませんし。

 丸ごと上書きが事故も少ないし作るのも楽そうですが、フルセットは単体でも動きそうですし、生き別れの多い製品ですからねぇ。
 思いついてもやれとは言い難い方法かもしれません。

 そういえば、SPAMは誰かが通報してくださったのかこの前ちょっと掃除されたようです。質問に偽装したこうこくがまた増えてそうですが。お疲れ様とおもうけど、「こっそり直したり良くしてくれる分」には頑張っていただいても構わないんですけどねぇ。

投稿者:たく  投稿日時:2016/02/07 11:37 親投稿 - 子投稿.1 No.228

Takeshichさん

>ちゃんとやってくれと私は言っているので、iodata側が何らかの対応を取らなければならないはずですが
>いつものように華麗にスルーするのが担当者の義務なんじゃないですかね。
>
>inXtronとiodataのどちらかがちゃんとやれば、このような結果は避けられるはずですが、
>どちらともちゃんとやらないので、この製品に関してはもし今後も何かある際にはこんな感じなのでしょうね。

 先程ファームの方 確認してみたのですが、まだそのまま放置してますね。。。

 購入当初にバグ連絡して修正されたの半年後だったかな、こっちには何も連絡してこなかったし
 適当な対応は時間が経っても変わらないみたいですね。

>RockDiskNextはメインで使っておらず、バックアップを取るという使い方になってしまって
>あえてバグを再現するようなことをしていないので、安定稼働しているようです。
>(必要最低限のサービスしか上げてないので、まぁ普通に稼働しているみたいです。)

 とりあえず安定してるようで、良かったです。。。
 付属のLANケーブルはSTPはさておき、品質も良くないかもしれません。使わない方が無難そうですね。

 私の方は何かあった時用にHDD Bootを色々試してみました。
 mtd内のstage1とu-bootとuImage(kernel)を取り出して使ってみたのですが、stage1とu-bootは作りなおさないとダメみたいです。
 時間あるときにネイティブビルド環境作って勉強用にしようかと思います。


え? さん
>あー、いや、ファームのダウンロードが要シリアルになると、NASの場合は必ずしも手元に置いてなかったりするので、確認するのが面倒だったりするのです。

 ファームのダウンロードの件だったのですね、すみません。また勘違いしてました。
 確かにそうなると面倒ですよね、今更無いと思いますが。。。

 「サポートが優秀」だけでは何もならないよね。
 営業、設計、サポートの連携がないとダメだし、立場が平等じゃないから大体サポートが泥かぶってんじゃないかな。
 これに関しても営業、設計から情報おりてきてなさそうだし全体的に適当にやってると感じるよ。
 ユーザーはサポートとしか接点ないだろうから、サポートだけがダメに感じてるだろうけど。
 
 三者三様の思惑や苦労があるのは判るけど、それにユーザーを巻込んで迷惑かけてしまうのは良くない。
 結局はIO DATAって会社の組織自体がダメだね~って事で

>丸ごと上書きが事故も少ないし作るのも楽そうですが、フルセットは単体でも動きそうですし、生き別れの多い製品ですからねぇ。

 生き別れの多い製品なんですが、微妙に使ってるデバイスが違うので兄弟のイメージ丸ごとだと動かなかったりします。確認用にはなるんですがね。
 NANDフラッシュ(MTD)は扱いが結構やっかいなので、ddコマンドとかでイメージをバックアップしてても挙動がおかしくなった頃には確実に戻せる可能性はそんなに高くないと思います。
 rootfsはubifsフォーマットなのでHDDブートしてtarかzipで固めておいた方が無難ですね。
 けど、大事なデータはHDDの中ですし、自分で復旧したいと思う人はいないと思ってます。
 
>思いついてもやれとは言い難い方法かもしれません。

 判ってる人は自分でやれると思うし、判らない人は素直にサポートへ連絡ですね。
 この辺のツールはメーカーが用意しておいてくれてても良かったと思うんですけどね。。。

投稿者:Takeshich  投稿日時:2016/02/08 22:11 親投稿 - 子投稿なし No.229

たくさん

>先程ファームの方 確認してみたのですが、まだそのまま放置してますね。。。
>
> 購入当初にバグ連絡して修正されたの半年後だったかな、こっちには何も連絡してこ
>なかったし
> 適当な対応は時間が経っても変わらないみたいですね。

連絡して1週間経っても、返事も問題のあるファームウェアをダウンロードできないようにする
措置もないようなので、残念ながらこのままのような気もします。
iodataさんはそういう感覚の対応なんでしょう。

>mtd内のstage1とu-bootとuImage(kernel)を取り出して使ってみたのですが、stage1とu-
>bootは作りなおさないとダメみたいです。
> 時間あるときにネイティブビルド環境作って勉強用にしようかと思います。

DC10のSDKを32bitなlinuxで展開すると簡単にビルド環境ができるはずです。
不確かな情報なので中身を見て判断してください。

まぁ、この製品、遊ぼうとすれば遊べるんだけど、あまりにも酷い仕打ちされまくったので
製品に対する愛着が全くなくなっていて。。。
いじろうとして購入したのに。。。
これはホント仕方ないですね。

投稿者:たく  投稿日時:2016/02/09 13:17 親投稿 - 子投稿.1 No.230

Takeshichさん

>iodataさんはそういう感覚の対応なんでしょう。

 ホント残念な対応ですね。。。

>DC10のSDKを32bitなlinuxで展開すると簡単にビルド環境ができるはずです。

 勉強がてらVirtualBoxと「ubuntu-ja-12.04-desktop-i386-vhd」でクロス環境は作ってはみたのですが、
 理解が追いついてなくて、まだまだ勉強しなくてはといった感じです。
 
 SdKの手順通りにやってみたのですが、RDN用にはmakeのオプションを変更しないと駄目みたいですね。
 テストで作ったのはNAND用だったので、時間あるときにでもHDD用を作っておこうかと思います。
 (pogo用のはmemory128MBまでしか認識しないけど、それ以外は動作したのでHDDからBootは可能と判りました。)

>まぁ、この製品、遊ぼうとすれば遊べるんだけど、あまりにも酷い仕打ちされまくったので
>製品に対する愛着が全くなくなっていて。。。
>いじろうとして購入したのに。。。
>これはホント仕方ないですね。

 1年半以上かかりましたから、お気持ちお察しいたします。

 私はもう少し勉強しながら、遊んでみようかと思います。

投稿者:Takeshich  投稿日時:2016/02/09 14:31 親投稿 - 子投稿なし No.231

たくさん

放置かと思ったら、どうも治ったというより正しくしたのかな。
http://archive.is/iObLT#selection-2631.0-2631.6

なんかここの内容少しは見ているような修正の仕方ですね。
ファイル名のレギュレーションとかないのかな。。。
それにしても記載外のバージョンのファームを使っている人が悩むような書き方だね。

投稿者:たく  投稿日時:2016/02/11 19:02 親投稿 - 子投稿.1 No.232

Takeshichさん

>放置かと思ったら、どうも治ったというより正しくしたのかな。

 とりあえずファイルの中身は大丈夫そうですね。

>なんかここの内容少しは見ているような修正の仕方ですね。
>ファイル名のレギュレーションとかないのかな。。。

 ファイル名は過去に出してしまったアップデータに揃えるしかなかったんでしょう。

 ■提供開始日:2014年1月22日 Ver20131121(たしか累積)
 http://www.ioplaza.jp/cl2/rdnext/fw/R ... ext-20131121-20121220.zip

>それにしても記載外のバージョンのファームを使っている人が悩むような書き方だね。

 そうですね~
 いいかげんコピペしての加筆修正はやめた方がいいと思うんですけどね。。。
 毎回それでミスしてるのに。
 
 (Ver20131121のファームだってソースのコピペの消し忘れがバグの原因だったのにね~。)
 こりてませんね。。。

投稿者:Takeshich  投稿日時:2016/04/12 12:05 親投稿 - 子投稿なし No.233

IO DATAのサポート気持ち悪い。怒りと気持ち悪さが混じった感覚だけど
気持ち悪さが強い感じ。

2ヶ月半ぐらい前の2016/01/26に

20150429の手動アップデータ、自動更新のアップデータと内容が微妙に違うんだ的なことで
で触れていた件、
http://bbs.ioplaza.jp/forum/index.php?topic_id=2398#post_id10852

今更、回答が来た。1ヶ月程度で回答が来なかったし、2/9頃に指摘していたところも
直していたようだから、スルーで、フェードアウトな感じで終了なんだろうと思っていた。

催促もしてないし、組織として腐ってるからまぁこんな感じだよねと思ってたので
回答が来たことにびっくりしたし、きちんと答えるならもっと早くに回答来るはずだし
本当に意図がわからなくて気持ち悪かった。

それだけなら良かったんだけど、回答が

<アップデータの名称の違いにつきまして>
「ntpdate-4.2.8p2-1.armv5tel.rpm」と
「ntpdate-4.2.8p2-2.armv5tel.rpm」の違いにつきましては弊社公開の便宜上異なった
名称となっておりますが、ファイル自体は同一でございます。

だった。

何をどう確認すれば、このような回答ができるのだか本当にわからない。
ファイルサイズを比較すると異なっている。
そもそも、

たくさん が指摘されているように
/etc/rc.d/init.d/ntpdate の内容がちがうし、
http://bbs.ioplaza.jp/forum/index.php?topic_id=2398#post_id10858

以前当方が指摘したように
/etc/sysconfig/ntpdate の内容もちがう。
http://bbs.ioplaza.jp/forum/index.php?topic_id=2672#post_id10538


今更蒸し返して、イライラさせられて、それよりもなんか気持ち悪くて
寝付きが悪かった。

サポートに対して、ひどいとかを過ぎて、気持ち悪いという感情を覚えたのは初めてだ。

誰かに吐き出さないと腐ってしまいそうだったので。。。

投稿者:たく  投稿日時:2016/04/12 19:28 親投稿 - 子投稿.1 No.234

Takeshichさん

今更ですか。。。
ホントにしようもないですね。

>何をどう確認すれば、このような回答ができるのだか本当にわからない。

 あいかわらず、ごまかす事だけしか出来ないみたいですね。
 問題が無いのなら何でアップデータを差し替えたんですか?って質問したら
 何て返答してくるんだろう?
 よけいに気分を害されてしまいそうなので、聞く気は無いですけどね。。。

>誰かに吐き出さないと腐ってしまいそうだったので。。。

 心中お察しします。
 こんな連中はほうっておいて、一休みして忘れましょう。
 

投稿者:Takeshich  投稿日時:2016/04/13 23:01 親投稿 - 子投稿なし No.235

たく さん

訂正きました。

> 「ntpdate-4.2.8p2-1.armv5tel.rpm」と「ntpdate-4.2.8p2-2.armv5tel.rpm」につき
>ましては、手動アップデータのファイルの公開時に十分確認が取れておらず自動アップ
>データとの相違が生じておりましたが、既に修正をさせていただき、現在は自動アップ
>データと同一のファイルがダウンロード可能となっております。

外から見てもこれしかないよね。。。

で、実はインチキ回答と同時に

><ソースコード配布に関する記述について>
> ご指摘のとおり商品に同梱されている「はじめにお読みください」にはソースコード
>配布に関する記述がございませんが、弊社といたしまして先日公開させていただきまし
>たweb上のご案内によりGPLに対応しているとの認識でございます。

って回答も来てたんだけど、
インチキ回答と同じ感じで回答してきたから、黙らすための確認なしのテキトー回答なんだろう。
(俺黙ってたんだけどなー)

放っておこうと思ったのだけど、就寝時に電気を消して、ベッドに入って
目を瞑るとフツフツと怒りがこみ上げてきて、ホントに寝付きが悪いのでw

RockDiskNext以外のGPLなのを含む製品の取説にある
GPLのソースコード配布に関する記述がなくていいことになるから
回答してきた根拠を具体的に示せと突っ込んでおきました。

私としては
著作物にソースコードを配布する旨が書かれた書面による申し出を添えなければならない
と考えているので、RockDiskNextではできておりませんが、
唯一製品に添付されていた「はじめにお読みください」にソースコードを配布する旨を追記する
修正を行い、電子的な形で公開するということが、最低限なラインではないかと考えています。

それにしてもホントに今更こじらせて何がしたいのだろう。。。
一度はもういいやと思って黙ってたのに。

投稿者:たく  投稿日時:2016/04/14 01:24 親投稿 - 子投稿なし No.236

Takeshichさん

>訂正きました。
 もう何ていうか、時間たってから返答するならもう少し考えて出しなよって感じですね。

>私としては
>著作物にソースコードを配布する旨が書かれた書面による申し出を添えなければならない
>と考えているので、RockDiskNextではできておりませんが、
>唯一製品に添付されていた「はじめにお読みください」にソースコードを配布する旨を追記する
>修正を行い、電子的な形で公開するということが、最低限なラインではないかと考えています。
 私も同意ですね。
 まだ販売側の責任を理解してないんでしょうね。何かOEM側の責任で自分達は悪くないって思ってる感がただよってますね。
 購入者の情報は持ってるのでしょうから、本来なら書面なりメールなりで通知、謝罪するのが、あたりまえかと思うのですが
 その程度が出来ないのであれば、ユーザやコンプライアンスに対する考えが、かなり低いメーカーと捉えるしかなさそうですね。

 間違いやバグがあるのは、しょうがないと思うのですが
 その後の対応でメーカーの姿勢は図れるものですが、ここまでごまかす事に必死なメーカーは初めてかもしれません。

>それにしてもホントに今更こじらせて何がしたいのだろう。。。
>一度はもういいやと思って黙ってたのに。

 ユーザーの事を理解出来ないのでしょう。
 なんとかに付ける薬はないという事なんでしょうね。。。

投稿者:たく  投稿日時:2016/04/21 21:40 親投稿 - 子投稿.1 No.237

Takeshichさん

その後、何か連絡ありましたか?
マニュアルのところに1個ふえてますね。。。

http://www.ioplaza.jp/shop/contents/rdnext.aspx#manual

投稿者:Takeshich  投稿日時:2016/04/21 22:56 親投稿 - 子投稿なし No.238

たく さん

>その後、何か連絡ありましたか?
>マニュアルのところに1個ふえてますね。。。

なんか指摘の意味を理解していない回答が来たものだから、キレ気味に返信してたんだけど、その成果かも。まだ、置いたよとは連絡はないです。購入者にメールするのかな?

でも、これまた突っ込むというかLinuxカーネル使ってるんだから、GPLv2もいれないと。。。

投稿者:たく  投稿日時:2016/04/21 23:15 親投稿 - 子投稿.1 No.239

Takeshichさん

>でも、これまた突っ込むというかLinuxカーネル使ってるんだから、GPLv2もいれないと。。。

 ですね。。。
 あと自分の著作物の範囲も変わってないね。
 あれだとGPLの物も自分の著作物で複製、改変することは法律で禁じられてますって読めるんだけど。。。
 やはり判らないんだなぁ

投稿者:Takeshich  投稿日時:2016/04/21 23:47 親投稿 - 子投稿.1 No.240

たく さん

>あと自分の著作物の範囲も変わってないね。
>あれだとGPLの物も自分の著作物で複製、改変することは法律で禁じられてますって読めるんだけど。。。
>やはり判らないんだなぁ

これは、RockDiskNext以外の取説でもそうですからね。
GPLに基づくソフトウエアが含まれていることを示しておきながら、そう来るか!って思いますよね。

投稿者:Takeshich  投稿日時:2016/04/23 18:13 親投稿 - 子投稿なし No.241

この「はじめにお読みください」、2016/4/19 15:12:01ごろに更新されたようなんだけど、
その後の4/20にもらった返信に

> ご指摘をいただいている点につきましては、弊社として対応できる内容を検討協議さ
>せていただいた結果、webページへの記載という形を取らせていただいた次第でござい
>ます。

ってあって、
http://www.iodata.jp/support/qanda/answer/s19384.htm
については触れたけど、
このPDFについては全く触れてなかった。
で、指摘の意味を理解していない回答だったものだから、キレ気味に返信した。

今回
> ソースコードに関するご案内につきましては弊社としてもできる限りの対応を検討し
>てまいりましたが、先日以下のように、公開しておりますマニュアルにも追記させてい
>ただきました。
>
>RockDiskNext「はじめにお読みください」
>http://www.ioplaza.jp/cl2/pdf/CL2-005 ... kNext_M-MANU201169-03.pdf

って回答来た。

対応がすごく気持ち悪い。サポートと対応している人別なんだろうけど意思疎通図ってないの???
言ってることとやってこること時系列的に、チグハグ。
結果的に回答として問題なくなったけど、なんなんだろうね。

それと最後までRockDiskNextを販売するためにやらなければならないことをして
いなかったという認識は全くない。ライセンスに関する認識がおかしい。
「弊社として対応できる内容を」「弊社としてもできる限りの対応を」ってなんだよ。
しなければならないことを対応するだけだろ。

まぁ、去年の9月に指摘して以来、11月末に再指摘して認識させてから、検討はじめて
対応するのに何ヶ月かかってんだよと思います。結局、クレーム対応として捉えているんですよ。
こちらから言って対応して、内容不十分で更に対応って感じで。
ソースコードの開示の時も同じでしたね。
(「はじめにお読みください」を修正して、購入者全員に郵送しろってゴリゴリ押せば、ある程度費用が発生したはずだから、責任について少しでも理解できたのかな。)

LinuxカーネルはGPL v2でRockDiskNextにはLinuxカーネルが含まれ、GPL v2に基づいたソフトウェアも
含まれていることになること突っ込んでおいたので、そのうち変更されるんじゃないですかね。。。

一連の対応について「ひどい」とかいう言葉じゃ足りなくて、言い表せる適切な言葉がなくて
困るほどですね。

投稿者:Takeshich  投稿日時:2016/04/28 17:01 親投稿 - 子投稿なし No.242

>LinuxカーネルはGPL v2でRockDiskNextにはLinuxカーネルが含まれ、GPL v2に基づいた
>ソフトウェアも
>含まれていることになること突っ込んでおいたので、そのうち変更されるんじゃないで
>すかね。。。

この件、28日に回答するからと返信が来ていたけど、昨日返信があって、

>ご指摘をいただきま
>した点に対して、明日回答とのご連絡をさせていただきましたが、恐れ入ります暫くお
>時間をいただき確認させていただきたい事項がございますので、申し訳ございませんが
>改めてご連絡をさせていただきます。

ってあったんだけど、これinXtronに確認する必要があるってことだと思う。
そもそもの話で当方としては、ずっとGPLv2を元にその条項とかFAQとかをさしながら
指摘してきたわけなんだけど、その前提となるGPLv2を使っているとかどうやら把握してなかったぽい。

IODATAは対象が不明確なのに今まで何を根拠にして対応、回答してきたのか?
これで、これまでの対応は、根拠を確認しての対応や回答ではなかった可能性が高いということがわかった。
もちろんGPLv2とGPLv3で重なる部分はあるけれども。。。

ライセンスが書かれたリストがIODATAから出てきたので、てっきり把握しているものと思っていた。
https://drive.google.com/file/d/0B1Tfr ... DckY4NmM/view?usp=sharing
中身見てみるとまあGPL2.1って何?って感じだけど。。。

余談だが
GPLを理解しているかという点では、どうも私も理解が足りなかったところがあるようで、

https://www.allbsd.org/~hrs/diary/201108.html#d1501
を見ると
>GPLv2 Section 4 によると、ソースコード配布義務等の GPLv2 が規定する義務に一度でも違反した場合、その GPLv2 で保護されたソフトウェアの使用権、複製権、配布権等々を自動的に失う、とされている。

>「違反してましたごめんなさい、今はちゃんと守ってます」という言い訳が使えない。

とある。
この言い分が通った場合もあるよう。
https://osdn.jp/magazine/10/08/05/1045202

投稿者:たく  投稿日時:2016/04/28 21:45 親投稿 - 子投稿.1 No.243

Takeshichさん

>IODATAは対象が不明確なのに今まで何を根拠にして対応、回答してきたのか?

 inXtronに丸投げだったんでしょうね
 これからは主語を明確に「”IO Dataは”GPLを正しく理解してるんですよね?」っと聞かないとダメみたいですね。
 ま、また嘘言ってごまかすんでしょうけど。。。

>ライセンスが書かれたリストがIODATAから出てきたので、てっきり把握しているものと思っていた。

 前から思ってたんですが、これ「rpm -qi ~」で表示される情報のコピペですよね。
 ただrpmリストアップしただけで根本は理解してないみたいですね。
 GMACの時みたいに。。。

>>「違反してましたごめんなさい、今はちゃんと守ってます」という言い訳が使えない。

 確かにGPLv3ではごめんなさいして、違反した行為をやめれば回復するけど
 v2にはその項目ないですね。ちょと怖いかも。。。
 v2の場合、その違反行為を著作権者が許すか許さないかなんだね。
 許されなかったら永久にライセンス失うのかぁ。

>この言い分が通った場合もあるよう。

 この時、IOはやられなかったけど他の日本企業は結構な損失があったんじゃないかな?
 一回、相当痛い目みないと懲りないんだろうね。というか理解出来ないのか。。。
 過去に学ばないなぁ。。。


# 関係ないですが、フロントのUSB殺してUARTに配線直結してみました。
# テスト中ですが、私にとっては結構便利かも。

投稿者:Takeshich  投稿日時:2016/04/28 23:12 親投稿 - 子投稿.1 No.244

たく さん

>ま、また嘘言ってごまかすんでしょうけど。。。

いつまでそれで通すのか。。。
RockDiskNext以外のマニュアル見るとOpenSSLの謝辞とかもキチンと載せてるから、いわゆるライセンス対応のチェックリストみたいなものは絶対社内にあると思うんですよ。

それに早く到達して欲しいんですが、無理なんでしょうね。

>一回、相当痛い目みないと懲りないんだろうね。というか理解出来ないのか。。。

Linuxの著作者の人が許さんといって民事で訴えたら、普通に損害賠償しなきゃならなくなる案件ですよね。。。
損害賠償額よりも信用のほうがリスクなんだろうけど。

># 関係ないですが、フロントのUSB殺してUARTに配線直結してみました。
># テスト中ですが、私にとっては結構便利かも。

いらないUSBケーブル切って、アダプターのようなものを作れば、ケース開けなくてもシリアル接続できて楽チンという話ですか?

投稿者:たく  投稿日時:2016/04/29 01:18 親投稿 - 子投稿.1 No.246

Takeshichさん

>それに早く到達して欲しいんですが、無理なんでしょうね。

 どこの会社もかと思うんですがOEM製品は、ほぼ自社開発のチームとかは助けてはくれません。(普通、助けられません)
 間を取り持ってる人がよほど強くないと、こんな結果になるんだと思います。
 今回の場合だとinXtronのごまかしを間違ってるとサポートが理解できず、ユーザーに突っ込まれまくって。。。
 IO Dataのサポートレベルはこんな物って事ですね。
 何も勉強しないサポートだったら無くていい。必要ないよね?これじゃぁ

>Linuxの著作者の人が許さんといって民事で訴えたら、普通に損害賠償しなきゃならなくなる案件ですよね。。。
>損害賠償額よりも信用のほうがリスクなんだろうけど。

 海外で訴えられたら、裁判費用かかりそうですね。
 向こうの法律で判断されるかもしれないし、日本基準で考えてたら驚く請求額が。。。
 ってなってくれた方がIO Dataにとっていい勉強になったかもしれませんね。
 信用は元から低かったけど、今私の中では最底辺かな。

>いらないUSBケーブル切って、アダプターのようなものを作れば、ケース開けなくてもシリアル接続できて楽チンという話ですか?

 その通りです、楽チンです。
 部材が余ったので、フロントのLED基盤上の5pinのケーブルを新たに作りました。
 黒がPowerSWのGPIOみたいなので、それだけメイン基盤の元のピンに戻し
 後の4つのピンはUSBでコントローラはメイン基盤上なので、そのままUARTのJ7へ、ちょうど線が5本です。
 ピンアサはこんな感じです。
 (PowerSW) <-> 黒:(LED基盤)J2-pin1(▼) <-> J3-pin1(▼)
 (USB端子)pin1(VBus) () <-> 黄:(LED基盤)J2-pin2 <-> nc(J7-pin1 VCC(3.3V)(▼))
 (USB端子)pin4(GND) <-> 白:(LED基盤)J2-pin3 <-> J7-pin4(GND)
 (USB端子)pin3(D+) <-> 赤:(LED基盤)J2-pin4 <-> J7-pin2(TX)
 (USB端子)pin2(D-) <-> 緑:(LED基盤)J2-pin5 <-> J7-pin3(RX)

 FTDIのUSBシリアル変換アダプターを(FRISKのケースに詰め込んで)使っています。
 USBからのVCCとかぶるので、今回はRDN側のVCCは結線してません。
 https://www.switch-science.com/catalog/1032/

 コネクタはRDN内ははJST(日本圧着端子製造)のPHコネクタの4pinと5pin×2
 線材(ケーブル)はAWG26を30cmぐらい
 USBケーブルにはQIコネクタの6pin(オス)でFTDIシリアル変換に接続しています。
 圧着工具とか慣れとか必要なので、あまりお勧めはしませんが
 PHコネクタは失敗しやすいので初心者はコンタクト(ピン)は倍ぐらい買っておいたほうがいいと思います。

投稿者:Takeshich  投稿日時:2016/04/30 18:31 親投稿 - 子投稿なし No.247

たく さん

>どこの会社もかと思うんですがOEM製品は、ほぼ自社開発のチームとかは助けてはくれません。(普通、助けられません)
> 間を取り持ってる人がよほど強くないと、こんな結果になるんだと思います。

まぁ、普通に考えればそうなんですけど、ここの管理人だった?ヒラッキーさんいわく

>RockDiskNextは挑戦者でもCL2-xxxの型番がついている通り、アイ・オー製品ですので、
>バイヤーの私が勝手に買ってきたものではありません(笑)。中身は海外メーカーのOEM
>で、ソフトウェアや回路基板は流用ですが、ACアダプターや筐体は当社用にカスタマイ
>ズされており、実はこのfidataのハードウェア設計者が監修しています。
http://archive.is/9gOLY#selection-509.3-509.169

とのこと。
こんなことも公開して残しちゃっているわけです。
過去に自社開発のチームの関わりがあったわけで、今回の指摘は文書に関するところですから、
ソースコードに関しては、inXtronのごまかしを間違ってると自社開発のチームが助けれられないのは、
逐一チェックを自社開発のチームがするのは、難しいですから、理解できるんですけど、
製品のコンプライアンス対策のために参照する共有文書のポインタは、自社開発のチームならRockDiskNextの担当者に示せるわけで。。。

また、ハードウェア設計者が監修したのはハードウェア部分のみでソフトウェアについては関係ないんじゃないの?
とあるかもしれませんが、ユーザーからしてみれば自社開発のチームが関わったのにできないのはダメですよ。

販売も終わっておそらく担当者はいないのだろうけど、外から見ても明らかに
製品のコンプライアンス対策のために参照する共有文書にたどりつけるとわかるのに
今回担当している人がたどりつけないのは意味がわからない。(今までの対応から無理なんだろうなと漠然と思いはするけど)
組織として狂ってる、腐っていると思いますよ。
それでいて真摯に回答しているふりをし、中途半端な対応をしているわけですから。。。

> 部材が余ったので、フロントのLED基盤上の5pinのケーブルを新たに作りました。
> 黒がPowerSWのGPIOみたいなので、それだけメイン基盤の元のピンに戻し
> 後の4つのピンはUSBでコントローラはメイン基盤上なので、そのままUARTのJ7へ、ち
>ょうど線が5本です。
> ピンアサはこんな感じです。

もし可能でしたら、写真あげていただけませんか?
これ本スレッドの件、切り分けするのにも役立ちそうですね。まだまだハマっている方のブログを時折見かけますし。。。
実はちょっとやってみたくなっています。ブレッドボード経由でシリアル接続してたので、面倒でw
圧着工具ないんで揃えなきゃダメか。。。
通販で一式を購入するにあったって、おすすめのサイトとかありますか?

投稿者:たく  投稿日時:2016/04/30 21:42 親投稿 - 子投稿なし No.248

Takeshichさん

>とのこと。 ~

 あぁ確かに。。。
 これでは、ヒラッキーさんや設計の人のミスですね。
 OEM製品といえどIOブランドで出したわけなので、明確な基準があるはずなのにこうなってしまったという事は
 GPLに関しては内部文書に含まれてないのかもしれませんね。
 開発に携わった人次第なのかと疑問に思ってしまいますね。
 しかし間違いに気づいたらもう少し勉強するだろうに、自分たちがメーカーである事に何も感じないのだろうか。。。

>もし可能でしたら、写真あげていただけませんか?
>これ本スレッドの件、切り分けするのにも役立ちそうですね。まだまだハマっている方のブログを時折見かけますし。。。
>実はちょっとやってみたくなっています。ブレッドボード経由でシリアル接続してたので、面倒でw
>圧着工具ないんで揃えなきゃダメか。。。
>通販で一式を購入するにあったって、おすすめのサイトとかありますか?

 了解しました。
 少しまとめますので少々時間下さい。

投稿者:え?  投稿日時:2016/05/02 00:42 親投稿 - 子投稿なし No.245

此処の場合は、サポートが大抵の製品の窓口になっているので、本来は俯瞰から状況を確認できるはずなんですよね。
考えながら仕事していれば、最初は製品担当者に問い合わせても、突っ込まれてる内容を見れば、「他の製品の自社の扱いどうだっけ?」と確認してみたりするんじゃないかと思うんですよね。
基本がクレームとしての対応のままなのが不味くて、仮にクレームでも、「とっとと問題を解決して黙ってもらったほうが」相手にデタラメ吹き込んで呆れさせたり、煙に巻くよりどう考えても安く付きます。基本的に言われてることは、他の製品と同等の水準で満たされることで、普通はそれをやった上で、「何か足りてませんか?」ってところで場合によってはすり合せとか、確認が発生すると思うんですよね。これらが別物になってるのは、FAQに追加すればいいのに別で項目が出来上がっていたりする辺りに出てる気がします。
強いて考えると、実作業が担当者レベルで行うことになってるので、気がついて指示を出しても当事者が自分がすべき作業を認識も出来てないのでダメ仕事がループしてる…とか?

間違いは人間のすることですからおきても仕方が無い部分もあるのですが、うちの会社何かやらかしたかな?と確認はしてみないと、万が一本当に大きな問題だったときにどうにもならなくなります。そういう意味ではサポート自体が構造的にポンコツだとは思います。

ただ、ものを考えてくれないので、途中からは「こうしてください。」っていう要件とその根拠と理由を投げてしまうほうが早く済んだかもしれませんね。

該当製品については、どっちかといえば「他所だと対応すらしない形でポイ(マクセルとかならソースすら出たかどうか怪しいし、下手すりゃまともな返事も無かったかも)の可能性も高く、OEM元がそもそもちゃんと仕事しろって感じなのは確かで、それこそ、兄弟分の製品だってオンラインマニュアルや、パッケージを見る限り此処と大差が無いので、認識の状況は似たようなものだとは思われます。

内製の製品でこの有様ならまぁ、痛い目見て少しはと思うのですが担当者次第なら、技術的素養が皆無に近い人が表に出てきて技術まで語るような間抜けな割り振りに問題があるんじゃないかと思います。むしろ、此処より売るだけ売って逃げちゃったところの方が此処より酷い有様の気はしますが、だからといってみんなそうだもんで許されるわけでもないですし。

上手くいきました自慢の記事が通ることからいって口八丁な部署が言ったことがレビューもされずに表に垂れ流されちゃう出口の甘さがやばいんじゃないかと。件の記事も、音が変わる理由ってのが「周辺機器メーカーとしての信頼捨てる気?」って危なさで、「わかんねーならわかんねー」って言う勇気は必要だと思うんですよね。もっともらしい捏造をするから致命的なオカルトに変わるのであって。

http://www.iodata.jp/fidata/story.htm#minagawa
自称優秀なこだわりのある人たちが作っててこれに関わってる人たちが参画している一桁まちがってんじゃないかって値段の商品のWebカタログが、それなりに更新され、それなりに時間も経過しているのに、
「他にもノイズ対策として、楽曲データの伝送を毎秒1ギガバイトから毎秒100メガバイトに落とせる機能も装備。」っていまだになってる。
仕様に関わる部分なので、広告として嘘が書かれてる(ビットとバイトの単位の違いがわからんってどんな素人よ…。)上に誰も気が付かないし直さないし、気にもしないし多分自分らすら読んでも居ない。
実害は無いかもしれないけれど、「信頼」って何かあったら直したり、注意を払うことで積み上げるのだと思うけど。そういう意味では、内製とか、親ブランドも実はどうだろうと思う部分はあるのですよね。自信を表に出すのは構わないんですが、表に出したものの名誉や評価は俺の物、瑕疵は人のせいって人前に出しちゃいけない人ですよね。ほっとくと場合によっては周りや組織が酷い目見ます。

普通は高価な商品で信頼と大きく出てれば、結構注意を払って何度もいろんな人が確認すると思うし、気がつけば直すと思うんですけどね。

そういう意味では、この会社で音周りに関わってるのはろくなやつがいないなって印象しかないです。というか、無責任な人しか居ないのかと。普通自分の作った製品ならカタログくらいは見ると思いますし、自分のツラが表示されて一緒に書かれた文言を確認もしないってどんだけ無責任で成果物に何の思いも無い人たちなんだろう。
何か部署間で制限があるならサポートはかわいそうな事になってる可能性もあるのですが、外部からは関係の無い事ですしね。
ちゃんと処理したら外と折衝しても半年も掛からないしやり取りは上手くすれば1桁で済んだはずで、その分他のインシデントを処理できたはずなのですが。

スティックPCもWindows10に云々ってやっちゃってて記事も残ってますが、th2であちこちで問題が出てたりします。これも被害出てないかなと余計なことを思ったりも。

中途半端に反応だけはしてくれるってのは誠意があるのか逆効果しかないのか微妙なところではありますね。

投稿者:たく  投稿日時:2016/05/02 20:19 親投稿 - 子投稿.1 No.249

Takeshichさん

お待たせして、すみません。
写真のついでに簡単な手順書とか資料まとめましたので
アップしておきますので、参考にどうぞ。

パスワードは rockdisk になります。

Fast-Uploader File名:rockdisknext_frontUSB_to_UART.zip
http://fast-uploader.com/file/7017742068368/

デジカメで撮影しようとしたら
電池切れとSDカードが入ってなく、探すのに時間かかってしまいました。。。

とりあえず、こんな感じです。


投稿者:Takeshich  投稿日時:2016/05/02 22:00 親投稿 - 子投稿なし No.250

たく さん

>お待たせして、すみません。
>写真のついでに簡単な手順書とか資料まとめましたので
>アップしておきますので、参考にどうぞ。

いえいえ、ご丁寧に手順とか資料までありがとうございます。

>デジカメで撮影しようとしたら
>電池切れとSDカードが入ってなく、探すのに時間かかってしまいました。。。

お手数おかけしてしまったようで、すみません。

連休中に試してみたいですが、発注しても物が届くかどうか。。。
とりあえず試してみようと思います。不明な点が出たら相談させてください。

投稿者:たく  投稿日時:2016/05/02 23:58 親投稿 - 子投稿.1 No.251

Takeshichさん

>お手数おかけしてしまったようで、すみません。

 いえ。大丈夫ですよ~
 たまに戻すの忘れてしまうんですよね。。。
 
>連休中に試してみたいですが、発注しても物が届くかどうか。。。
>とりあえず試してみようと思います。不明な点が出たら相談させてください。

 そうですね連休中は店によってはお休みなのでタイミングが悪かったですね。
 この件、興味持たれるとは思ってなかったので資料もあまりまとめてなかったので。。。
 もう少し早く情報出ししとけば良かったですね。

 秋葉原に行けばすぐ揃うんですが、連休中のあの人込みの中には行きたくないなぁ。

 もし圧着を試されるのでしたら、PHコネクタのピンは練習用に沢山買っといた方がいいですよ。
 あと、J7は1本だけになるので空いたところに2本ケーブルを追加して
 反対側を片結びしてわっかを作っておくとコネクタを抜くときに便利になりますよ。
 うまくいったらTakeshichさんのブログのネタにでもしてください。
 その方が他の方達が知る機会が増えそうですので。

投稿者:Takeshich  投稿日時:2016/05/20 22:02 親投稿 - 子投稿.1 No.252

#倍の数のPHコネクタのピンを購入しましたが、さらに購入しなければならない状況に陥り凹んでいますw

さて、
http://www.ioplaza.jp/cl2/pdf/CL2-005 ... kNext_M-MANU201169-03.pdf


「本製品には、GNU General Public License Version3(GPL v3)に基づいた
ソフトウェアが含まれています。」
と書いてあるけど
LinuxカーネルはGPL v2でRockDiskNextにはLinuxカーネルが含まれ、GPL v2に基づいたソフトウェアも
含まれていることになること突っ込んでからおおよそ1ヶ月経ちましたが、
まだiodataのサポートから返信がありません。

突っ込まれていることの意味をわからないようですから、おそらくinXtronにもうまく伝わらない質問をしているのでしょう。

おそらく、担当者は、RockDiskNextでは、GPLv2もしくはGPLv3が使用されていることを把握できていないのでしょう。

LinuxカーネルはGPL v2なことは検索すればLinusがそう言っている動画とかLinuxはGPLv2だという文書を見つけることが
容易ですし、
また、
GPLv3については、

https://drive.google.com/file/d/0B1Tfr ... DckY4NmM/view?usp=sharing

で、v3になっているものを本当にそうか検索すれば、容易に真であることを見つけられます。

上記より、RockDiskNextではGPLv2もしくはGPLv3が使用されていることを簡単に知ることができるのに
担当者は何らかの障壁によって知ることができないのでしょうね。

指摘しているところの問題は、versionを指定してしまって、限定してしまっているところにあるということには
担当者は理解できないので当たり前ですが気づけてないようですし、versionを指定しないようにすればGPLについて言及されている
ことについては終息することも理解できないのでしょう。

え?さんがおっしゃるように
>ただ、ものを考えてくれないので、途中からは「こうしてください。」っていう要件と
>その根拠と理由を投げてしまうほうが早く済んだかもしれませんね。

これは、1月の段階で行っていたのですが、流石に手取り足取りな感じでは投げられず、
指摘しておりますGPL遵守に関してソースコード開示以外にしなければならないことについては
著作物にソースコードを配布する旨が書かれた書面による申し出を添えることで
http://www.opensource.jp/gpl/gpl.ja.html
section3 b)についてです。
とか
GPL遵守に関してソースコード開示以外にしなければならないことについては
貴社で販売しているGPLを扱っている製品と同様の対応をすればよろしいのではないでしょうか?
RockDiskNextに添付されていた書面の「はじめにお読みください」を適宜編集し、
書面について紙でなければならないと判断するのであれば、購入者全員に郵送すればいいわけですし、
電子的なものでいいと判断するのであれば、公知しHPに掲載し、
対象のソースコードを配布する旨が書かれたFAQのページを追加すればいいのではないですか?

伝えていたのですが・・・

これ以上懇切丁寧に伝える必要ないでしょう。。。と判断したのですが、
できていないので、もっと丁寧に伝える必要はあったようですが、それはiodata内でやることであって
当方がやることではないとも思えます。

>当事者が自分がすべき作業を認識も出来てないのでダメ仕事がループしてる

これなんでしょうね。
何度も言っていますが、iodataの組織としての問題なんでしょうね。

この一連のGPLに基づいて対応できていないことについては、

>サポートセンターのみではなく、弊社全体の問題として確認させて頂いております。

と回答をもらっていますが、弊社全体の問題として認識しているのであれば、
これほど時間をかけないでしょうから、サポートの口先だけなのでしょう。

>中途半端に反応だけはしてくれるってのは誠意があるのか逆効果しかないのか微妙なと
>ころではありますね。

中途半端な対応はどっちつかずなので、真摯に対応する意思がないのであれば、
対応しなければそれでいいと思うのです。
2ヶ月半以上放置しておいて、さらにテキトーに回答してくるあたりに
誠実さもないことを証明しつつも、なんか対応しますよと言いつつ
さらに1ヶ月も回答に間をおいても問題ないと思えるのは、かなりの異常な対応だと思います。

投稿者:Takeshich  投稿日時:2016/06/03 20:40 親投稿 - 子投稿なし No.253

まだ、終わりません。

返信マダー?って突っ込んだら、2016/05/24に
「指摘されている点については、修正することになった」という返信をもらいました。

で、2016/06/03現在、まだ修正されていない状態です。
確かに、状態について回答しているわけで、
いつ修正するかは回答していないのだから、10日程度経って修正していなくても
修正することになったという回答は嘘ではないのですが、
今回指摘していることは、

http://www.ioplaza.jp/cl2/pdf/CL2-005 ... kNext_M-MANU201169-03.pdf


「本製品には、GNU General Public License Version3(GPL v3)に基づいた
ソフトウェアが含まれています。」
と書いてあるけど
LinuxカーネルはGPL v2でRockDiskNextにはLinuxカーネルが含まれ、GPL v2に基づいた
ソフトウェアも含まれていることになること
であって、

これを修正することになったのであれば、「本製品には~含まれています。」を
指摘したことであるGPL v2に基づいたソフトウェアも含まれているを加味して
修正する必要があると判断したわけです。

修正内容としては、
「本製品には、GNU General Public Licenseに基づいたソフトウェアが含まれています。」

「本製品には、GNU General Public License Version2(GPL v2)もしくは、Version3(GPL v3)に基づいた
ソフトウェアが含まれています。」
のように
ほんの一行を修正するだけなのです。

にもかかわらず、2016/06/03現在、まだ修正されていない状態で
修正マダー?とさらに突っ込んでいるにもかかわらず、3営業日以内に返信もない状態です。

PDFの修正作業は5分とかからないでしょうし、確認も同様です。
社内作業でWEBへの更新に1日程度時間を要しても遅くても2日あればできる作業でしょう。

io-dataのサポート対応は、相変わらずのようです。

おそらく、指摘したことを外部に確認しているのだけど、まだ返信がきちんとないのでしょうね。
それで当方からのツッコミに外部からの返信がないのにもかかわらず、修正することになったと
返信し、その返信から1週間以上経過しても修正が完了できないのでしょうね。
修正することになって、いろいろと指摘され続けている件について早急に対応しないのは
普通ではないですもの(io-dataのサポートならあり得るか・・・)。
いつも思うことだけど、何が起こっているのだろう。。。
自分がすべき作業を認識も出来てないのでダメ仕事がループして、ブレイクできないだけか?

投稿者:たく  投稿日時:2016/06/04 22:04 親投稿 - 子投稿.1 No.254

Takeshichさん

この件、なかなか終わらないですね。。。
ご苦労様です。

>「本製品には、GNU General Public Licenseに基づいたソフトウェアが含まれています。」

 これだけで良いのにね。
 わざわざ誤解を与える書き方して誰も気づかないとは、正しく理解されてないのかな?

>io-dataのサポート対応は、相変わらずのようです。

 本当に相変わらずみたいですね。

>おそらく、指摘したことを外部に確認しているのだけど、まだ返信がきちんとないのでしょうね。

 以前から思ってたのですが、inxtronの後ろにもう1社 とろいのがいそうな感じがしますね。

>いつも思うことだけど、何が起こっているのだろう。。。
自分がすべき作業を認識も出来てないのでダメ仕事がループして、ブレイクできないだけか?

 担当者の知識レベルが低いから言ってる意味が理解出来ないのでしょう。
 質問されてから勉強してるんじゃないのかな?

 別の機器の件でこのサポートに確認する事が出来てしまったんだが
 まともな返事くれるかな。。。

投稿者:Takeshich  投稿日時:2016/06/07 10:37 親投稿 - 子投稿なし No.255

たく さん

サポートに電話してみました。
担当者出ました。

「文言については検討している最中で、いつまでに修正できるとはっきりと言えない」と
回答をもらって、なんか力が抜けました。
修正対応以前に考えてすらいないっていう雰囲気プンプンだったので。

何言っても無駄なことがわかりましたが、

「本製品には、GNU General Public Licenseに基づいたソフトウェアが含まれています。」
にしたらいかがですか?と提案しておきました。

あの雰囲気にはホント毒されたくないです。

>担当者の知識レベルが低いから言ってる意味が理解出来ないのでしょう。

知識レベルはよくわかりませんが、理解するという行為をしようとしてません。

> 質問されてから勉強してるんじゃないのかな?

理解しようと思ったり、勉強してくれれば、もっと早く片付いているはずですよ。
考える行為を諦めていました。

>別の機器の件でこのサポートに確認する事が出来てしまったんだが
> まともな返事くれるかな。。。

テンプレ以外なことで、担当者がアレだと残念になりそうですが、
この件と違って低いなりにもある程度のレベルの回答はもらえるんじゃないですか?

あぁ、すごい闇を見たわ。。。

投稿者:たく  投稿日時:2016/06/07 12:35 親投稿 - 子投稿.1 No.256

Takeshichさん

>何言っても無駄なことがわかりましたが、
>あの雰囲気にはホント毒されたくないです。

 本当にご苦労様です。残念な対応は変わらずでしたか。。。

>テンプレ以外なことで、担当者がアレだと残念になりそうですが、
>この件と違って低いなりにもある程度のレベルの回答はもらえるんじゃないですか?

 ルータなんですけどね、このメーカーのネットワークの知識は一般人以下なんではと思ってしまいそうです。
 USB機能にNASモードってあるんですが、無効にしてもDHCPでWINSはオレだってアナウンスするし
 nmbdも落ちてるからタイムアウト待ちで、Windowsのエクスプローラーでの表示が遅かったり、表示されなかったりで。。。
 ま、問い合わせても時間かかるので、先にraspberry piでwins、dhcpサーバー構築する事にしました。
 

そんな事をしていたら、Takeshichさんの状況とは少し違うのですが
RockDiskNextに接続出来なくなってしまいました。
segments retransmited = 180 で送信に失敗しっぱなしでsamba,web,telnet接続不可状態です。。。

[root@ROCKDISK01 ~]# netstat -s
Ip:
1171259 total packets received
2 with invalid headers
1 with invalid addresses
0 forwarded
0 incoming packets discarded
1171256 incoming packets delivered
517015 requests sent out
~省略~
Tcp:
1906 active connections openings
1950 passive connection openings
11 failed connection attempts
16 connection resets received
0 connections established
1161722 segments received
513997 segments send out
180 segments retransmited
0 bad segments received.
1 resets sent
~省略~

参考:netstat ~ホストのネットワーク統計や状態を確認する
   (ネットワーク統計情報 Linuxでの使用例のところ)
http://www.atmarkit.co.jp/ait/articles/0201/30/news003.html

送信バッファが何かおかしいのかな?
HDD(SSD)ブートでテスト中だったので、メモリが少ないのが原因かもしれませんが、
何かの参考になるかもしれないので、色々調べてみます。

# 今日はせっかくの休暇だったんだけどなぁ。

投稿者:Takeshich  投稿日時:2016/06/07 13:14 親投稿 - 子投稿なし No.257

たく さん

>そんな事をしていたら、Takeshichさんの状況とは少し違うのですが
>RockDiskNextに接続出来なくなってしまいました。
>segments retransmited = 180 で送信に失敗しっぱなしでsamba,web,telnet接続不可状
>態です。。。

ついにたく さんも遭遇しましたか!

>送信バッファが何かおかしいのかな?

繋がらなくなった時にパケットキャプチャとかして、RDNのトランプポート層での
送信に問題があったと判断した記憶があります。
私の場合は、TSOでNICにデータを渡す際になにか起きてたんじゃないかと想像しています。

受信は問題ないように見えました。

>HDD(SSD)ブートでテスト中だったので、メモリが少ないのが原因かもしれませんが、
>何かの参考になるかもしれないので、色々調べてみます。

メモリ不足がつながらなくなるようにみえる障害の発生頻度を高める原因である可能性も
高いと思っています。256MBじゃなくて128MBなんですよね?
無理のない範囲で調査してください。

投稿者:たく  投稿日時:2016/06/07 20:46 親投稿 - 子投稿.1 No.258

Takeshichさん

>ついにたく さんも遭遇しましたか!

 ついに遭遇してしまいました~
 web管理画面にアクセスしたところ、こんな感じになりました。
 繋がらない状況は似てますが原因が同じか、ちょっと判らないですけどね。









index.htmlの分割パケットの最後(No245)が遅すぎて、再送が始まってしまっています。
上のログはRDNのNICをミラーリングして取ったもので、クライアントPC側も同様のログでした。
minidlnaの8200番ポートにアクセスした時は、FIN ACKの返事がRDNから帰ってこない状況でした。

トランプポート層とアプリケーション層の間で何かが起きてるっぽいですが
原因が判れば回避策が検討できるのですが、調べる手段を探すので時間かかりそうです。

topとvmstatを見る限り暴走はしてないようです。
samba,minidlna,lighttpdの停止とキャッシュのクリアまでしてみましたが変化が無いようなので
他も確認しながら落としてみます。
winsサーバーの設定を色々変更してたので、その辺で何かあったのかな。。。

何かアドバイスありましたら、よろしくお願いします。

投稿者:Takeshich  投稿日時:2016/06/08 16:18 親投稿 - 子投稿なし No.259

たく さん

なんか私の場合とか
http://bbs.ioplaza.jp/forum/index.php?topic_id=2669
でのログと微妙に違うので、似てないようにも思えるのですが、ちょっと良く分からないですね。

>何かアドバイスありましたら、よろしくお願いします。

1年以上前のことでちょっと思い出せないのもあるし、
再現性があるなら、TSO ON/OFFとかいろいろと考えられるのですが、現状では
力になれそうにもなく、すみません。

しかし、ちょっと疑問点もありまして、

1)
クライアントPC側のログでも
HTTP/1.1 200 OK
RDNからクライアントPC側に返っているのでしょうか?

2)
>minidlnaの8200番ポートにアクセスした時は、FIN ACKの返事がRDNから帰ってこない状
>況でした。

とのことですが、キャプチャにはないようですが
web管理画面にアクセスした時も
80 → 50364 [FIN,ACK] ~
って感じのFIN ACKの返事がRDNからないのでしょうか?

パケット分割のところがおかしそうなら、やっぱりTSOでパケットの分割をCPUではなくて
NICでやっているところでの不都合のような気もしています。

トランスポート層とネットワーク層のあたりで、うまくいかないからその上の層の
やり取りがきちんとできないようですよね。

投稿者:たく  投稿日時:2016/06/09 22:29 親投稿 - 子投稿.1 No.260

Takeshichさん

アドバイスありがとうございます。

ethtoolでtso,scatter-gather,tx-checksummingの順にOFFにしたところ回復してしまいました。
また、この3つをONにしたところ接続できなくなるのが確認できました。
今回のケースは送信側に何か不具合が起こってたみたいだと思います。
(tx-checksummingをOFFするとtso,sgも連動してOFFに、sgをOFFにすると連動してtsoもOFFになりました)

いまひとつ原因が不明なのが腑に落ちないのですが、疲れたのでまた後日発生した時に考える事にします。
(ksoftirqd/0が急に動きが活発になったので、その周辺が関係あるのかな。。。)

他とりあえずやってみた事
・ntp,cups,nas,jetdirect,他 OFF #効果なし
・kill -SIGHUP dbus-daemon #効果なし
・sysctl -w net.ipv4.tcp_timestamps=0 #効果なし
・sysctl -w net.core.netdev_max_backlog=5000 #効果なし

>1) RDNからクライアントPC側に返っているのでしょうか?

 クライアントPC側にも「HTTP/1.1 200 OK」は返ってきてました。
 けどIEでは反応なかったので、プロセスの途中でドロップされてしまったみたいですね。
 WireSharkがプロミスキャスモードだったので、NICまでは届いてたけど後は届かなかったのかな?
 としか確認できませんでした。

>2) 80 → 50364 [FIN,ACK] ~って感じのFIN ACKの返事がRDNからないのでしょうか?

 下にminidlnaの異常時(上)と正常時(下)のキャプチャ貼ります。
 頭が混乱ぎみだったので間違ってしまってたのですが「FIN,ACK」の返事はクライアントPCから返ってきてなく、
 WireSharkには記録されてたのだけど、RDNからの「FIN,ACK」がクライアントPC側(IE)ではドロップされてしまってたみたいです。
 7行目の「FIN,ACK」に対する「ACK」が返ってこないので終われない状態だったようです。





投稿者:Takeshich  投稿日時:2016/06/10 12:57 親投稿 - 子投稿なし No.261

たく さん

>ethtoolでtso,scatter-gather,tx-checksummingの順にOFFにしたところ回復してしまい
>ました。
>また、この3つをONにしたところ接続できなくなるのが確認できました。
>今回のケースは送信側に何か不具合が起こってたみたいだと思います。

今回のケースでは、不具合が起きている箇所が特定できて、何よりです。
ただ、何らかの影響で、NICの送信側の不具合が起き、結果として、サーバがダウンしているように見える
というこの現象、解決まで解決までたどり着くの難しいですね。
やっぱり、GMACのソース見てデバッグとか何でしょうかね。

>いまひとつ原因が不明なのが腑に落ちないのですが、疲れたのでまた後日発生した時に
>考える事にします。

モヤモヤするのはよくわかりますが、あまり無理なさらず。。。

パケットキャプチャのスクショありがとうございました。
通信に齟齬がある状態が発生していたということですよね。

OSレベルで検知できない現象のようですから、対策としては
起動時にethtoolでtsoをOFFにしておくのがいいのかなぁ。
でも、どこかのブログで起動時にethtoolでtsoをOFFにしても
サーバがダウンしているように見えるという現象は解決しないという記述も見たことある。。。
まぁ、結局はNICを定期的に再起動させれば、もし現象が発生していても
再起動で解決するし、遭遇確率も低くできそうではあるけど。

投稿者:たく  投稿日時:2016/06/10 23:42 親投稿 - 子投稿なし No.262

Takeshichさん

>今回のケースでは、不具合が起きている箇所が特定できて、何よりです。
>ただ、何らかの影響で、NICの送信側の不具合が起き、結果として、サーバがダウンしているように見える
>というこの現象、解決まで解決までたどり着くの難しいですね。
>やっぱり、GMACのソース見てデバッグとか何でしょうかね。

 kernelのnet/ipv4/tcp_output.c とか見てるとMSSとか見てセグメントの分割するポイントを決めてからPHY(GMAC,RTL8211D)に送っている様にも思えます。
 なのでGMACでは受取ったキューと分割ポイントでセグメントを分割して送信するだけで、計算まではしてないのかもしれません。
 また、nagleアルゴリズムのバグかメモリ不足から来るスキャッタ ギャザーの遅延かもとか、色々と思えてきています。

 今回ある程度 絞り込めたのは幸いだったけど、発生する条件が不明のままですね。
 次に出た時にどうやってデバッグするか、私の知識が追いつかない状態です。
 kernelをデバッグするとなると、kgdbでするのかな?
 リビルド無しで出来るのかな。。。
 勉強する事が増えてきたなぁ

>モヤモヤするのはよくわかりますが、あまり無理なさらず。。。

 お気遣いありがとうございます。
 しばらく休憩してから、考えてみる事にします。

>通信に齟齬がある状態が発生していたということですよね。

 そうですね、WireSharkではキャプチャーされてますがWindowsのkernelかアプリケーション(IE)では無効なパケットとして破棄されてしまったのではないかと思うのですが、何が悪いのかまでは判らないので困ったものです。
 一見 問題なさそうなのですが。。。

>OSレベルで検知できない現象のようですから、対策としては
>起動時にethtoolでtsoをOFFにしておくのがいいのかなぁ。
>でも、どこかのブログで起動時にethtoolでtsoをOFFにしても
>サーバがダウンしているように見えるという現象は解決しないという記述も見たことある。。。

 そうですね、とりあえずudevにethtoolのルール追加して暫く休憩モードにしましたw

 どこかのブログは私が見た所と同じかと思いますが
 そのブログでの問題はWindows側にもあると思うのですが、WireShark等で調査、確認はしてないみたいです。
 win10でもWireSharkは動作するようになったので、キャプチャーすればおおよその検討はつくと思います。
 というか状況把握せず、設定だけいじっても本当に正解だったのか判らないんじゃないのかなぁ?と思う。

>まぁ、結局はNICを定期的に再起動させれば、もし現象が発生していても
>再起動で解決するし、遭遇確率も低くできそうではあるけど。

 一番手軽な回避策ではあるんですけどね。
 根本的な解決にはならないし、モヤモヤは晴れなさそうです。。。

投稿者:たく  投稿日時:2016/06/20 12:05 親投稿 - 子投稿.1 .2 No.263

Takeshichさん

http://bbs.ioplaza.jp/forum/index.php?topic_id=2321#post_id11098
より確認のためテストです。

投稿者:Takeshich  投稿日時:2016/06/20 12:12 親投稿 - 子投稿.1 No.264

あれ?
できるんですね。
もしかして、内容にゴニョゴニョできちゃうの含まれてた?

投稿者:Takeshich  投稿日時:2016/06/20 12:15 親投稿 - 子投稿なし No.265

やっと更新されたみたい。

はじめにお読みください

http://www.ioplaza.jp/cl2/pdf/CL2-005 ... kNext_M-MANU201169-03.pdf
から
http://www.ioplaza.jp/cl2/pdf/CL2-005 ... kNext_M-MANU201169-04.pdf

FAQは
http://archive.is/bonGR
から
http://archive.is/WMSQS

明確に指摘してから8ヶ月?、修正の対応で、2ヶ月?長かったねぇ。
普通のところなら指摘後数日で対応だよね。

GPL絡みはこれで終了かな。たぶん。
まさかの対応完了までにほぼ2年。お疲れ様でした。

#終了したけど、ここに投稿できないとか当方とIODATAとの相性めちゃくちゃ悪いな。
#何か呪われているのかと思うほどに。

投稿者:Takeshich  投稿日時:2016/06/20 12:17 親投稿 - 子投稿.1 No.266

たく さん

ご協力ありがとうございました。

ttp://archive.is/http://www.iodata.j ... t/qanda/answer/s19384.htm

が駄目なみたいです。

投稿者:Takeshich  投稿日時:2016/06/20 13:24 親投稿 - 子投稿なし No.267

お騒がせしました。

原因については、
この掲示板を構成するCMSはXOOPS Cube Legacy 2.1.5より前のバージョンが使われているみたいで、
URLのParseに問題があって、URLencodeされていない文字列を含むURIだとうまくいかないみたいですね。
https://sourceforge.net/p/xoopscube/mailman/message/19389910/

XOOPS Cube Legacy 2.1.6に脆弱性があるけど、対応されてるのかなぁ?
http://xoopscube.jp/news/463

投稿者:たく  投稿日時:2016/06/20 19:01 親投稿 - 子投稿.1 No.268

Takeshichさん

>明確に指摘してから8ヶ月?、修正の対応で、2ヶ月?長かったねぇ。
>普通のところなら指摘後数日で対応だよね。
>
>GPL絡みはこれで終了かな。たぶん。
>まさかの対応完了までにほぼ2年。お疲れ様でした。

 ようやく。。。
 時間かかりましたね、本当にご苦労様でした。
 購入前に出せますと言ってから解決するまで2年、法人相手だったら普通に出禁+賠償ものなんですがね。
 メーカー側はもう少し対応を良くする様に努力してほしいものです。

>#終了したけど、ここに投稿できないとか当方とIODATAとの相性めちゃくちゃ悪いな。
>#何か呪われているのかと思うほどに。

 お祓いが必要かなw
ちなみに私は今年 前厄なので年始に行ってきました。。。


>この掲示板を構成するCMSはXOOPS Cube Legacy 2.1.5より前のバージョンが使われているみたいで、
>URLのParseに問題があって、URLencodeされていない文字列を含むURIだとうまくいかないみたいですね。

 なるほど"http://"の後の"//"で引っかかったのかぁ。
 でもこのBBSリニューアルしたの2011年頃だったような、それ以前は知らないけどそんなに古いので構築したのか、その時にパッチ当て忘れたのかな?

# そういえば他製品の所はスパムでひどいね。
# スパム防止の認証もアルゴリズム解析されてるぽいね?
# あんまりセキュリィティがざるだと、信用なくなるよ。

投稿者:Takeshich  投稿日時:2016/06/20 22:20 親投稿 - 子投稿なし No.269

たく さん

> お祓いが必要かなw
>ちなみに私は今年 前厄なので年始に行ってきました。。。

調べてみたら、私も前厄のようなので、行こうw

>>この掲示板を構成するCMSはXOOPS Cube Legacy 2.1.5より前のバージョンが使われてい
>るみたいで、
>>URLのParseに問題があって、URLencodeされていない文字列を含むURIだとうまくいかな
>いみたいですね。
>
> なるほど"http://"の後の"//"で引っかかったのかぁ。

説明が下手なのと示したURLが微妙でした。
"http://" が2つ以上あるURIをparseする際に問題があるようです。
postすると真っ白になって、応答がないように見えますが、どうもdebugがoffになっていて
そう見えているようです。エラーハンドリングされてないのかな?

> でもこのBBSリニューアルしたの2011年頃だったような、それ以前は知らないけどそん
>なに古いので構築したのか、その時にパッチ当て忘れたのかな?

普段なら全然気にならないですが、これだけいろいろな面でやられると
悪い方に疑うことしかできないですね。。。

># そういえば他製品の所はスパムでひどいね。
># スパム防止の認証もアルゴリズム解析されてるぽいね?
># あんまりセキュリィティがざるだと、信用なくなるよ。

ランダムではないような気がしますね。同じ文字列を何度か入力したことありますし。
それだけ投稿してたのか。。。

投稿者:Takeshich  投稿日時:2016/06/23 23:38 親投稿 - 子投稿なし No.270

一連のGPL違反に関する件、まとめました。

http://takeshich.hatenablog.com/entry/2016/06/22/164814

購入時は、まさかこんなに長いの3回も書くことになるとは思わなかった。

このスレッドに投稿する

投稿者名
投稿本文

※入力支援機能(引用・画像挿入)をご利用の場合は返信ボタンを押してください。
※メールアドレス等、個人情報にかかわる情報の掲載・取扱については十分に注意してください。

 
CAPTCHA Image 画像を替える読みづらい場合は画像を替えてお試しくださいスパム防止のため画像認証を設置しています
画像内の文字をボックスに入力してください