【無線LAN】OpenWrt/LEDE【強化ﾌｧｰﾑ】15
■ このスレッドは過去ログ倉庫に格納されています
>>676
503〜505zt辺りではやったことあるよ。
同じように、光回線を一時的にモバイルルーターで使った。
外部とセッションを張ってたけど、1日に一回は切断されてしまうのが気がかりではあった。回線の問題だと思うけど。 >>680
ウチのはソフトバンクから借りてる601ZT。
色々調べたらやはりドライバCD-ROM
偽装機能絡みっぽいけど、usb-modeswitchも入れたんだけどなー。
WebUIの隠しコマンドからもRNDISモードに
設定できるみたいなので、
まずはそっちでやってみる。 >>679
デザイン変わりすぎw
CPUも変わったみたいだし無印とは別物かな 凶真の戦利品
WHR-1166DHP 500円 (本体・ACアダプタのみ wifi設定カード無し)
製品名 WHR-1166DHP Ver.1.00(R7.56/B1.03)
http://driver.buffalo.jp/buf-drv/lan/whr-1166dhp_r756_crc_root_uimage_jp.bin
/etc/config/mac.datを書き換えて US にしよう
ファーム自体は日本のやつを使う (USファームはGUIデザイン変わってる) >>680-681
601ZT繋がった。
対策としては、openwrt入れたルータを別の機種にしてみたのと、
usbストレージのサポートを足してみたくらい。
601ZTにwifiで直接つないだ場合、無線部の仕様の関係で
実効速度が60Mbpsくらいに制限されるから、
それならって言ってusbテザリングでopenwrtルータで受ける
ようにしたんだ。
んでも、そもそもSBの回線自体が混んでるみたいで、
対して速度上がんねーな…。 >>683のやつ
ocnの接続アカウント設定済みで割り当て割れたIPのリモホからしてうちと同じ契約っぽい
次こそは
WHR-300HP2 (箱入り・ACアダプタ無し) 500円 と CATVモデム 500円 を購入する
CATVモデムの方は管理画面(?)へのアクセス方法が分かれば元が取れるけど
シリアル端子がなければゴミ確定 不要で里子に出す機種のスペックが11abgnの機種から1167(5GHz/867Mbps,2.4GHz/300Mbps)へ
シフトしつつあるのに、300台の機種集めてﾋｬｯﾊｰしてる時期でもあるまい
コレクションをズラリ並べた私設のお宝館でも開きたいならいざしらず >>685
前言撤回。複数端末から
同時アクセスする場合は、
やっぱopenwrtにいったん集約したほうが
パフォーマンス落ちないね。 14chで11n使える功績は大きい
これ、機種によっては表示上11nだけど実際は11bだったりすることがあったり
電波が出てなかったなんてこともある 「ぼくの/わたしの なつやつみのじゆうけんきゅう」
としてWN-AX2033GRに挑んでみようと考えております
現状、少なくとも、MT7615で動かす5GHzの無線が動かないことは承知の上です
IO-DATAへGPL対象ソースコードの提供を申し込んで手配をかけています
(実費で切手500円分負担させやがってクソッタレ)
..が、WN-AX2033GRに既に取り組んでいる方がいらっしゃるのをご存知でしたら御教えください
こちらは辞退します 同じことをやってもムダなので
そしたらWSR-2533DHPLの方へ... >>674,690
長期間放置していてすみません
もし可能ならWSR-2533DHPLの方に突撃していただけるとありがたいです
近日中にpatchや請求したソースコード(ver 1.12)を公開する予定です >>691
>>173さんが移植対応作業をされたんですね
それでしたら済みの機種に重複作業しても無意味なのでやめておきます
返信どうも
..ということでWSR-2533DHPL(WSR-2533DHPから製品名を変更しただけ)について重複検知を
こっちはまだ牛がソースコード公開してないんですよね
早く値下がりしろ!! WSR-2533DHP2のcpuを調べたくて、1.35GHz soc dual coreで検索してみるんだけど、
amdのEシリーズというのしかヒットしないけど、まさかねえ。 >>685
さらに自己解決。一応自分用メモとして残しておく。
ZTEルータの場合はkmod-usb-storage入れて
一度ストレージとして認識させないと、ZTEルータ側のrndisのサービスが
動きださない模様。
usb-modeswitchは、たぶんいらなさそう。 >>694
順当にMT7622なんじゃないの？
https://www.mediatek.com/products/homeNetworking/mt7622
>Powered by a 64-bit dual-core ARM Cortex-A53 processor clocked at 1.35GHz
って書いてあるよ ついにMediatekの無線LAN SoCもARMかあ MT7623(Cortex-A7/4cores)も市場に出てますけどね
MT7622が2coresということはそれの廉価版の位置付けっぽい
MIPSはドナドナされ続けてるからなぁ もう虫の息 仮に同クロックだとしたら
A7 4coreとA53 2coreどっちが性能いいんだろうね あ... MT7622はA53か
廉価版とはとんでもない勘違いでした...別物だ 陳謝 m(_ _)m >>696
ほんまや。ありがとうございます。
armで64bitかー
近い将来RISC-VのSOCになるのかな。 ぷーたーろーが片っ端から手つけてるから
あとはもう七難八苦しか待ち受けてないドマイナーな機種を探してチャレンジするしかないね luci-app-samba4ってのが入ったけど、samba4なんかあったっけ？
openwrtでactive directory運用できるようになるのか？ >>703
プータローにジャンクルーター恵んで
ROM焼ク中にしてる黒幕がおるんやで。 WHR-1166DHPはどうやってOpenWrtにするんですか？
OpenWrtファームのヘッダいじったり、一旦DHP-600DのDD-wrtを経由する方法はやってみたんですが上手くいきませんでした dd-wrtスレのpart11で成功例あったのでやってみますわ はい、また延期きました。
https://openwrt.org/releases/18.06/start
Roadmap
Below is a preliminary schedule for the evolution of the 18.06 release. The dates are subject to change. 24 June 2018 - Release v18.06.0-rc1 test images available
13 July 2018 - Release v18.06.0-rc2 test images available
31 July 2018 - Final release binaries available for v18.06.0
September 2018 - Start preparations for v18.06.1, the first service release for the 18.06 series
History
27 Jul 2018 - Final release postponed by three days
17 Jul 2018 - Final release postponed by one week
16 Jul 2018 - Binary v18.06.0-rc2 images are ready.
15 Jul 2018 - The v18.06.0-rc2 tag has been created.
6 Jul 2018 - Final release postponed by two weeks
28 Jun 2018 - Final release postponed by a week
23 Jun 2018 - Binary v18.06.0-rc1 images are ready.
22 Jun 2018 - The v18.06.0-rc1 tag has been created.
18 Jun 2018 - Tagging of rc1 postponed by a week
15 May 2018 - The openwrt-18.06 branch has been created. ちなみに、意味不明なエラーが出て書き込めないのでレス分割しました。
↓以下は単語単位で後ろの方を削っていって書き込める限界を調べました
はい、また延期きました。
https://openwrt.org/releases/18.06/start
Roadmap
Below is a preliminary schedule for the evolution of the 18.06 release. The dates are subject to change. はい、また延期きました。
https://openwrt.org/releases/18.06/start
Roadmap
Below is a preliminary schedule for the evolution of the 18.06 release. The dates are subject to change.
24 June 2018 - Release v18.06.0-rc1 test images available なんですかね？空行多いとエラーになるんですかね？
はい、また延期きました。
https://openwrt.org/releases/18.06/start
Roadmap
Below is a preliminary schedule for the evolution of the 18.06 release. The dates are subject to change.
24 June 2018 - Release v18.06.0-rc1 test images available
13 July 2018 - Release v18.06.0-rc2 test images available
31 July 2018 - Final release binaries available for v18.06.0
September 2018 - Start preparations for v18.06.1, the first service release for the 18.06 series
History
27 Jul 2018 - Final release postponed by three days
17 Jul 2018 - Final release postponed by one week
16 Jul 2018 - Binary v18.06.0-rc2 images are ready.
15 Jul 2018 - The v18.06.0-rc2 tag has been created.
6 Jul 2018 - Final release postponed by two weeks
28 Jun 2018 - Final release postponed by a week
23 Jun 2018 - Binary v18.06.0-rc1 images are ready.
22 Jun 2018 - The v18.06.0-rc1 tag has been created.
18 Jun 2018 - Tagging of rc1 postponed by a week
15 May 2018 - The openwrt-18.06 branch has been created. なんですかね？空行多いとエラーになるんですかね？
それなら全角空白文字で対処できそうですね
はい、また延期きました。
https://openwrt.org/releases/18.06/start
Roadmap
Below is a preliminary schedule for the evolution of the 18.06 release. The dates are subject to change.
24 June 2018 - Release v18.06.0-rc1 test images available
13 July 2018 - Release v18.06.0-rc2 test images available
31 July 2018 - Final release binaries available for v18.06.0
September 2018 - Start preparations for v18.06.1, the first service release for the 18.06 series
History
27 Jul 2018 - Final release postponed by three days
17 Jul 2018 - Final release postponed by one week
16 Jul 2018 - Binary v18.06.0-rc2 images are ready.
15 Jul 2018 - The v18.06.0-rc2 tag has been created.
6 Jul 2018 - Final release postponed by two weeks
28 Jun 2018 - Final release postponed by a week
23 Jun 2018 - Binary v18.06.0-rc1 images are ready.
22 Jun 2018 - The v18.06.0-rc1 tag has been created.
18 Jun 2018 - Tagging of rc1 postponed by a week
15 May 2018 - The openwrt-18.06 branch has been created. >>695
さらに追試。
UQでHUAWEIのwimax2+ルーター借りて
同様の設定のままいけるかと試したが、
そのままではrndisが動き出さんね。
それどころか、dhcpも止まって
wifi側も繋げられなくなる。
これこそusb-modeswitch入れて
conf書き換えが必要かも、とは思うのだが、
誰か試したことのある奴居る?
しかしこれ…
wifiがスリープモードになっても
ルータ本体のボタン操作なく
自社スマホアプリ経由で
復帰できるようにするために、wan(wimax2+)側に起動状況の情報送ってるみたいだし、
気持ち悪いルータだな…。 また延期か
アキレスと亀みたく永遠にリリースされない疑惑 スケジュール厨 心底うっとおしい
自分のブログでも作ってそこでやってください 書いてくれるのはありがたいのだけど
こう何度も何度も書かれちゃうとね
試し書きは別のところでやっていただけるとありがたいですなぁ >>705
黒幕ですw
転居で置けなくなったから
インストール検証用に保持してたのを
某氏に押し付けましたー
同じSoCの類似機種があると開発進むかと思ったんですよねー
それ以外も多くを処分したので
活用wikiの18.06のインストール実績は
今までみたいには書けないです
このスレの住人による
正式リリース後のインストール実績の投稿ヨロシクですー >>687
11acの866はHT80 HT40にすると433
それにAC1200ながら有線が100Mbpsなんて機種も珍しくない elecom NSB NAS(Cortina CS75xx)をOpenWrtへ取り込んでもらうべく移植に挑んでいる者です
ここ3ヶ月ほど進みが悪く、それに伴いやる気が萎えておりました
ここらでちょっとだけ状況を
最重要の周辺デバイスであるEthernetドライバのポーティングで重篤な問題が甘い山積みの状況です
linux-4.9.xでかろうじて導通する状態まで漕ぎつけてはいますが
・大量の送信(ftpputで約100Mバイト)を行うと、途中でpanicする : panicログから得られる情報が少なく状況が見えにくい
・大量の受信(ftpgetで約100Mバイト)を行うと、受信したごとにファイルのmd5sumが異なる
ハードウェアオフロード的な機能の実装が大量に含まれていて
そんなものは訳が分からんのでビルドしないように取り除いて移植対象のコード量を減らす作業をして
そのコードを元のlinux-3.4.xカーネルの方へ取り込んで通信させる分には上記の大不具合は出ていないです
動いてくれないデバイスがUSBやSATAだったら捨ててかかってパッチ提出まで進めるんですが
Etherが動かないっつうんでは..ダメですもんね >>724
それ、SoCなんだっけ？
>725
退場!! >>726
Cortina CS75xx、このハードウェアでいうとCS7542というのがSoC
プロセッサコアはARM Cortex-A9 デュアル 採用してる物少ないな
https://wikidevi.com/wiki/Cortina
結論 (そのうち分かる)
・最新版のLinuxでは(安定して)使えない
・常に最新版を要求する openwrt(18.xx)へのマージは不可 >>720
黒幕たんはルータじゃなくて
仕事を恵んであげなよ。 >>728
>・最新版のLinuxでは(安定して)使えない
>・常に最新版を要求する openwrt(18.xx)へのマージは不可
その理屈だと「OpenWrtは安定して使えない」になっちゃうねぇ >731
「古いハードでは」を付け加えてやってくれ >>724
途中報告乙
実績が少ないSoCへのLinuxカーネル移植は非常に大変なんですね
果敢に挑まれた勇気に敬意を評します >>720
単純な18.06の実績はwikiでもいいけど、機種ごとの詳細なインストール方法は
https://openwrt.org/supported_devices/ にまとめたほうがいいと思うんだよね >>730
うちも異業種（このまえ人が死んだところ）だけど、
来るんだったら人事に口利きはするけど。
ACKとNACKを見分けて次に伝える力があればおｋ。 彼はまだ若いしスキルもあるから
最初はガチで開発やってみるのがいいと思う susucoin:SbKUGwrpzCpopvfWkH7LH4AJXxadRyFoHv >>738
そういう地味にコード書く領域は中国に持って
いかれてるから、国内では難しいんじゃ。
別業種を目指してほしい。 >>736
それやると
公式に (いすらむの) みみずがのた打ち回った文字 とかあれが登場するぞ >>743
だね。
openwrt users group japan がないのは、かえって不自然じゃないかな？ >>743
そのドメインはsrchackさんが登録されてますね。同じく期待! 何とかユーザーグループって気持ち悪いから好きではない
英語でやりとりする本体のグループに混じることができなくて
そうやって日本だけで集っちゃうのが悪癖なんですよね
私も英語は不得意で気軽にやりとりできんのですが 日本国内でしか展開していない物・事以外ぜんぶです ぜんぶ
英語でやりとりしている本体に入って普通にやりとり、
国内の連中だけでやりとりするのはカンファレンスのような実際に顔合わせる機会についての
打ち合わせとかそういうのだけですよね? 違いますか? じゃぁなんでお前は本体に入ってやりとりせずにこういうとこにいるのか?
って問われたら英語できない恥ずかしい人だからです と即答 OpenWrtに関しては電波法とか色々あるから
日本国内での堂々としたユーザーグループとしての活動に難がありそうですよね
openwrt.jpはいきなりそこを目指すのではなく、
各種wikiよりはしっかりした形の
日本国内向けの情報集積と言う事で
まずは良いのではないでしょうか BCM3349A0
MemSize: ......................... 8M
Flash detected @0xbe000000
Signature: a008
Broadcom BootLoader Version: 2.1.6d_R3 release Gnu
Build Date: Aug 29 2006
Build Time: 18:39:54
Image 1 Program Header:
Signature: a008
Control: 0005
Major Rev: 0003
Minor Rev: 0000
Build Time: 2009/12/2 07:55:13 Z
File Length: 786227 bytes
Load Address: 80004000
Filename: 77TCM7-v2.14.bin
HCS: e1a2
CRC: 264be1a0
Enter '1', '2', or 'p' within 2 seconds or take default... "p"押すと
Board IP Address [0.0.0.0]: <phyまで そのままエンターキー>
Board IP Mask [255.255.255.0]:
Board IP Gateway [0.0.0.0]:
Board MAC Address [00:10:18:ff:ff:ff]:
Internal/External phy? (i/e)[i]
Init EMAC, DMA, and MII PHY...
MAC setup for HalfDuplex
Main Menu:
==========
d) Download and save to flash
g) Download and run from RAM
c) Store icePROM bootloader to flash
b) Boot from flash
e) Erase flash sector
m) Set mode
s) Store bootloader parameters to flash
i) Re-init ethernet
r) Read memory
w) Write memory これ、スキャンして信号が見つからなければ再起動しやがる ついに来た
https://downloads.openwrt.org/releases/18.06.0/
現時点で targetsは
ar7、ar71xx、ipq40xx、layerscape、sunxiしかないけど、
例によって出そろうまでにしばらくかかるかと >>755
Maspro 77TCM7ってケーブルモデム 500円
これ、MACアドレス変更不可っぽい
発行元: ASUS Cable Modem Root Certificate Authorityって署名つき
なんとなくGPLライセンスのような気がする 77TCM7
SoC: BCM3349
フラッシュ: 2MB (パラレル)
RAM: 8MB (IC42S16400F)
WHR-G54Sの半分しかない
90〜770MHzは通して0〜90MHzをカットする物があればつなげてみたい ギリギリまで延期を繰り返すのは、
バグが修正しきってない可能性が高いな
18.06.1まで待ったほうが良さそう >761
修正可能であればいいけど
修正不可って事もありえる >731 ( >728 ) > Maspro
見えすぎちゃって こまるのぉ〜
見えすぎちゃって こまるのぉ〜よ 開発中の現行ツリーLOVEが基本姿勢の超アグレッシブな開発チームなので
"stable"ってつけちゃったので一応次のリリースまではちょびちょび修正を反映
永遠のベータ版、ぐらいにおもっといたほうが気が楽 どーも、黒幕ですw
OpenWrt 18.06 動作報告テンプレ案を考えてみました
こんなのでどうでしょうか？
メーカー/ベンダー:
機種:
OpenWrtバージョン:
target名:
使ったimageファイル名:
インストールメソッド(方法):
動作確認した機能:
HWリビジョン(わかれば):
備考:
―― 以下は過去の事例報告ない場合(わかれば) ――
Flash容量:
メモリ容量:
コア数/スレッド数:
CPUコア最大周波数:
USB規格/ポート数:
無線規格/アンテナ数:
有線規格/ポート数:
その他IF規格/数: >>756
targets に mediatek というのがあって
おぉ呼称変わったのか！…と思ったら
>699のARM版SoCをまとめたものみたいですね >>764
最新LTSカーネル追従には
旧機種切り捨ての意味合いもあるんですかねぇ？ >>768
切り捨てられたのは旧機種ではなく誰もメンテナンスしていないtargetです
半年以上猶予期間があったわけですし、開発リソースが限られていることを考えると切り捨ては妥当だと思います >>765
機種 → 製品名・型番 に変更
下段のメモリ容量とコア数/スレッド数の間に
SoC/CPU名称 を入れるといいかな 切り捨てられたのはユーザーがいない機種ではなく誰もメンテナンスしていないtargetです
これがオープンソースの限界なんだよな
使ってる人がいても、メンテナンスする人がいなければ
切り捨てられる そういう意味では、
ath79に取り組んでくれる大破の人の存在は貴重 ArcherC7 v2に18.06入れてみた
Luciがお洒落になった！ というとりあえず薄い感想(´・ω・｀)
https://i.imgur.com/HVfNr7R.png >>771さんのいうメンテナンス(保守)はどんどん更新されていく新カーネルへの追従のことでしょう
カーネル内でドライバ向けAPIやドライバを駆動するための制御フレームワークが変更されたら
それに合わせるよう各ドライバを修正しないとビルドすら通らない場合も出てくる
いじったらレグレッション/エンバグが起きていないか、最低限の動作確認もしなきゃいけないですし
device treeへの対応はARMから始まったのが波及してきてMIPS系のプラットフォームでも
対応せざるをえなくなった その手間だって数が多いからバカにならないと思いますよ 1) OpenWrtプロジェクトがあくまでも有志の志でOSS開発
2) Qualcomm Atheros、Mediatek、Marvell、などSoCベンダーは自社SoC用のSDKをOpenWrtベースで仕立てている
その成果の一部でもOSSへ反映させてくれりゃいいけど、隠したままがおおい
ガチガチだったQualcommが最近はCodeAuroraへかなり出してくれている これはいいこと
3) プロダクトベンダー各社はそれらをNDA締結下で供給してもらって実際の製品に移植して商品化
ただ実際のコード移植はOEM/ODMで委託された側でやっているだけ
その人たちは継続的に手を動かしているので手馴れている
製品ベンダー各社が脆弱性修正とか頑張って作業して、それをSoCベンダーへ「とりこめ」と投げて、
をすべきなんだけども、中身ほぼ商社な日本の周辺機器総合ベンダーは実装をOEM/ODM任せにしてるから
できる人材もおらず不可能
SoCベンダーもカーネル追従が遅いんですよね
2016年秋発売のWSR-2533DHPでもファームウェア覗いたらカーネルはいまだに3.10.xだし
Mediatekは終生そのバージョンを使いつづけるつもりなのか、と
3.10はLTSだったしその分の不具合修正をちゃんとマージしてりゃいいんだけどしてねぇだろうな >>773
stable releaseは普通にインストールできるのね
うちもArcher C7 v2で2-3年更新してないから更新したいけど
freeradius使ってるからpackageのビルド済みが出そろってこないと
面倒なことになるのでもちょっと待ちますわ >>774-775
エンベデッド開発の立場だと
最新LTSカーネルへの追従って必要なんでしょうか？
サーバ用途だとRHELなんて
大昔のカーネルを10年以上も保守してるし
安定稼働の側面ではやむを得ないかと思うのですが >>777
外界と通信するネットワーク機能を使う機器では脆弱性対策・修正が必要ですよね
その他の機能については、機器ごとの使い方で問題にならないのであれば
更新する必要はないのですが
問題がない箇所を変えない触らない、も大事なことなので、製品現場での対応では
脆弱性の勧告(CVE)が出たうちの危険度が高いものについて当該の修正パッチを
適用する、というアプローチになるんじゃないでしょうか
ただ、SoCベンダー側のSDKについてはそのまま製品に使うわけではなく
製品化するベンダー側で何らかの評価検証をする前のものなので
LTSとして更新され続けている間は随時その修正を取り込んでほしいものです >>774
> >>771さんのいうメンテナンス(保守)はどんどん更新されていく新カーネルへの追従のことでしょう
> カーネル内でドライバ向けAPIやドライバを駆動するための制御フレームワークが変更されたら
これがWindowsだったら、バグだけ直せ。余計な機能を増やすなって
言われるところだろうなｗ ■ このスレッドは過去ログ倉庫に格納されています
