【無線LAN】OpenWrt【強化ファーム】16
■ このスレッドは過去ログ倉庫に格納されています
【無線LAN】OpenWrt【強化ファーム】16
あなたのワイヤレスルーターをもっと活用できるように解析や使い方を研究しませんか？
様々な追加パッケージをインストールすれば色々出来ます。
アンオフィシャルファームウェアであなたのルーターの可能性が拡がります。
▼公式サイト
OpenWrt
https://openwrt.org/
https://forum.openwrt.org/ ※フォーラム
https://openwrt.org/toh/start ※対応機種一覧
https://downloads.openwrt.org/releases/ ※正式版ダウンロード
※なお正式表記は OpenWRT ではなく『OpenWrt』です
▼関連サイト
「DD-WRT OpenWrt 適材適所で両方使いたい人向け」
http://www57.atwiki.jp/ddwrt_openwrt/
「OpenWrtインストール実績」
https://www57.atwiki.jp/ddwrt_openwrt/pages/57.html >USBメモリ起動
これ、新規にプロジェクト始める気なのか 書き換え回数制限はもちろんあるだろうけど気にしてる人なんてほぼいないんじゃね？
スマホだって気にしないやろ >>21
>イメージにipkが含まれているということは、
>パッケージの更新をした場合、それはイメージに含まれてるipkではなく
>/overlayディレクトリ以下に書き込まれるから、空き容量が減るという認識であってるよね？
ipkのversionupがあった場合はそうですね
>それ考えたらUSBメモリ起動にしたほうが良いのか、
>パッケージの更新は行わずイメージの更新で対応するのがいいのか悩むなｗ
ずっと以前のスレでUSBメモリを/overlay にマウントするようにしてた人がいたような気がする
>ファームウェアって書き換え回数制限とかないの？
WSR-600/1166DHPなんかに使われている
16MBの SPI NOR Flash MX25L12835F の場合、
データシートには平均10万回と書かれてる
この値はNAND FlashにおけるSLC相当ですな >>22
あぁ、ごめん。単にUSBメモリを/overlayをマウントするだけ
>>23
細かくログを記録したら比較的簡単に行くかなーと
>>25
> ipkのversionupがあった場合はそうですね
ですよねー。この間何気なくアップデート入れたら
依存パッケージも多くて空き容量結構減っちゃったので
で思ったんだけど、USBメモリを/overlayにマウントするには
USBやファイルシステム関連のパッケージをインストールしないと
いけないわけでインターネットに接続が必要になる。
となるとimagebuilderでそれを含んだイメージを作ったほうが良さそう
USBメモリを/overlayにマウントした状態でファームウェアの
アップデートをした場合/overlayの（設定以外の）データどうなるんだろ？
本体メモリを削除するからUSBメモリの/overlayは残るのか
それとも/overlayを削除するからUSBメモリであっても削除されるのか
古いパッケージが残ってしまうから後者であってほしいが前者な気がするな 下のレイヤのファイル配置が変わるから
overayは削除されないと不整合になっちゃう気がする wan6のeth0.2とeth0直結の違いが謎だな。 >>28
お前はスイッチングハブを間に入れるのと直結するのの違いの謎がわからんのか？ そう煽るなよ
プログラマブルswitchというのは
通常のLinuxでは出てこないから
理解が難しいのはやむを得ないと思う
>>28
前スレで紹介されてた以下blogがオススメ
https://nashippe.blog/network/wrt/tagged-vlan/ eth0 ---(ただのPHY)--- WAN RJ45
eth1 ---(switch)------- LAN RJ45 何個か
eth0 ---(switch)==eth0.2 (VLAN_ID=2)== WAN RJ45
?????? ==eth0.1 (VLAN_ID=1)== LAN RJ45 何個か
この違いですか? いや、CPU側の話だからeth0やeth1より左側の話。 >>30
サンクス。
このページの衝撃はvlanはタグの idじゃない事だな。 >>30
絵の方のポート4とポート5は逆になってない？ >>35
どれのことか知らないが、0～4でLAN、5～6でWANと
したいからそれであってるのでは？ vSphere Hypervisor(ESXi)の
仮想Switchと物理NIC、vmkernelポートの関係を
思い浮かべると
良いかも知れないですね
(厳密には少し違うけど) 『Cisco IOSなどではVLANインターフェース番号＝802.1QのVLAN IDだけど、
OpenWrtはそうはなってない』
『OpenWrtのswitch Configの
「vlan 」パラメータはOpenWrt内部でのみ利用されるVLANインターフェースの番号で
802.1QのVLAN IDは別途「vid」パラメータで指定する』
…という理解でいいよね
BIG-IPみたいにVLANパラメータが任意の文字列で指定できると良いのにねぇ 18.06.01インスコ完了。
atheros系だt、luciの設定に
オフロード関連のメニューさえ出ないんだな。
リリースノートではatheros系の
パフォーマンス改善したってあるけど、デフォでビルトインされてるってこと? SFEは組み込まれてない上、
カーネルも他よりは古い4.9系
ホントにパフォーマンス改善してるかどうか
誰か検証してほしいなぁ netfilter offloadのソフトウェア実装の方は
特定のプラットフォームと無縁の汎用実装なので有効にさせてくれてもよさそうなものだけど >>40
えっ、SoCによってカーネル違ってるんだ?
気づかなかったわ…
じゃあ、例えば蟹とかブロコムなんかも
soft flow offroadには対応してるの? >>40
一応ccとかよりはパフォーマンス
若干上がってる。 >>42,43
カーネル4.14から対応=汗もath79で自ビルドすれば使えるよ
とは言えよく使われる牛さん系のROM周りが厄介で
WZR-HP-AG300H/WZR-HP-G300NH2/WZR-HP-G450H 辺りが4.14移行が困難ポイ 古いカーネルソースに新しいカーネルソースを書いていけばいいんじゃね？
出来上がってるカーネル(バイナリ)使うほど困難なことはない >>45
そいつらは128Mbit(16MB)のSPIフラッシュを２個乗せて32MBにしてるけど、
複数まとめたflashをath79のkernelが読めない事態になってるんですよね？
大破氏が頑張ってくれているけど、今のところBuffalo系でath79が動いているのは
16MBフラッシュのBHR-4GRV2や4MBしかないWHR-G301Nぐらいですよね >>47
判りやすいのはこれか
ttps://forum.openwrt.org/t/ath79-support-for-bhr-4grv-like-wzr-hp-g450h/16842 eth0とeth0.xの違いはuntaggedかどうかか。 >>47-48
device treeの記述でMTD concatinationを設定するように整備されていないのが
原因なんですよね?
どの機種が該当するんですか?
いまMT7621Aのターゲットに挑んでいるので
(詳細は申しません 作業が遅いゆえ、先を越されると面白くないので)
それ終えたらMTD concatのdevice tree対応の拡張も含めて挑んでみたいところだけど
稀代の不器用なもので、シリアルポートの工作で失敗して「ああぁぁぁ...」
となることが多いので...
シリアルポートのスルーホールがハンダで埋まってないのが判明している機種から
チョイスして挑みたい >>49
SoCのEther MACを1口だけ使って、そこにスイッチチップをぶら下げて
Ether MAC <=> スイッチチップ間は802.1q taggedフレームで出し入れ、
eth0.1 をWAN、eth0.2 をLAN というように分別しているターゲットも結構あるんですよ
ハードウェアでtagged VLAN処理支援機能を持っているEther MACなら
tagged/untaggedの着脱処理のコストを気にしなくていいかもしれないですが
支援機能がないとオールソフトウェア処理なのでちょっともったいない
Ether MAC 2つをWAN、LANとつなげたハード構成の方がよりうれしい >>51
＞device treeの記述でMTD concatinationを設定するように整備されていないのが
＞原因なんですよね?
＞どの機種が該当するんですか?
2010年代前半発売で32MBフラッシュ搭載機は
だいたい該当するんじゃないですかねぇ
具体的にはWZR-HP-G300NH/同301NHやAG300H,G450H,BHR-4GRVなど
ただ、上記機種は大破氏は所有してると思われ
黒幕のせいだな ＞シリアルポートのスルーホールがハンダで埋まってないのが判明している機種から
＞チョイスして挑みたい
シリアルポートのスルーホールがハンダで埋められてたら
皆さんならどうやります？
私なら、
いったんハンダを盛った上で
先が尖ったハンダコテ先で表からホールに突っ込みつつ
裏からハンダ吸い取り器でシュッと吸い取る感じかな >>54
同じく
吸い取り器はバネ仕掛けで押したら撥ね戻りながら吸い取るような安物で頑張ってます
かつての勤め先にあったようなハンダ吸い取りポンプが欲しいけど万円単位なので買えない
毎度GNDだけは歯が立たない
こないだの作業でVccまで抜けなかったのが悔しくて仕方ない なるほど、ath79ベースにしない限り
atheros系のパフォーマンスアップは
限定的なんだね。
こりゃいよいよar7xxx番台もぼちぼち
引退世代かなあ。 >>51
>シリアルポートのスルーホールがハンダで埋まってないのが判明している機種
製造時期とかロットによって埋まってたり埋まってなかったりする ath79用の公式ビルドってまだないんですよね？
まだまだ登場しない感じですか？ 黒幕ですw
挑戦したい人がいらっしゃるのであれば
提供できますよ～
athの機種は提供できるのがもうないけど
BHR-4RV,WZR-RS-G54HP,WRT54GSv1,
WHR-G300N,WHR-1166DHPなどであれば ファームウェアだけならともかく、
パッケージを全部ビルドするの面倒くさい
どうせパッケージ用意されてないんでしょう？ >>62
>ぢぶんでやれ
ごもっともです
インスコが楽しくて
無計画に買っちゃったものばかり
スキルなくてやれずじまい
大変お恥ずかしい限り 大破氏に勝手に押し付けたので
何にも悪くないです
ご不興は私にお願いいたします >>51
ath79_register_m25p80_multiで探せば当該機種は
mach-alfa-ap120c.c
mach-qihoo-c301.c
mach-wzr-hp-ag300h.c
mach-wzr-hp-g300nh2.c
mach-wzr-hp-g450h.c
こんな感じでリネーム機も有るから結構みんな持ってるんじゃない?
ツイッタ見ると武蔵野さんも手詰まり気味っぽい >>54-57
うまく抜けないのはコテ先の選択ミス&熱量不足が殆どじゃないかな
コテ先に一般的なB型とか使ってると接触(伝熱)面積が少なくて温度をいくら上げても抜けにくい
概ね400度を超すとパターンの剥げ、基板の焦げ、フラックスの蒸発やら
コテ先の酸化がものすごく進むしと良い事一つもない
FX600辺りの温調コテで370℃以下、接触面積も蓄熱量も大な太めのC3辺りで
追いハンダ&フラックス後に吸取り線でルータ位の基板ならGNDでもいける >>61
うち
WZR-HP-AG300H, WZR-HP-G300NH, WZR-HP-G302H, WZR-300HP
WHR-G300N, WHR-HP-H300N, WHR-G301N,
WHR-600D, WHR-300HP, WHR-1166DHP,
WSR-600DHP, WSR-300HP
あるよ miss!!
×WHR-300HP
○WHR-300HP2 >>67
> FX600辺りの温調コテで370℃以下、接触面積も蓄熱量も大な太めのC3辺りで
> 追いハンダ&フラックス後に吸取り線でルータ位の基板ならGNDでもいける
具体的なアドバイスサンクスです
C3コテ先とかははんだ付け職人のサイトが詳しいですね
https://noseseiki.com/kisokouza/10.html GNDのハンダ抜きは業務で回路設計やっているハード屋さんでも苦戦する
コテ同様に加熱できるハンダ吸い取りポンプと、反対側からも他の人にコテであっためてもらって
吸い取っていた、ってな感じだった >>51です
持ってたズラ AG300H
ハードオフ巡りせんで済んだ >>71
多層基板で鉛フリー(厳守)だと確かにムズイ
ホットプレートでプレヒートするなりしなきゃ
家庭用ルータの少ないレイヤの基板ならそんな気合い入れんでも抜けない?
ダメなら有鉛なり低融点はんだなり追加盛りして融点下げてしまえばいい >>59
ワイヤーレートの半分以上も出るのであれば
サブルータに格上げとか、あとフレッツの
低速化に困ってる会社の同僚にIPoE用に
あげたりとか。 ペリフェラルインターフェースの多くがSoCに詰め込まれていて
パターン配線する規模は減っているご時世とはいえ、4層ぐらいは使ってるんでしょ?
持ってる機種の板を横から見て何層か数えたことないですけども
開けて紙エポキシの基板が出てきたら笑えますけど OpenWrtを使っている方々、
VPNゲートウェイ、簡易NAS・・・は定番として、
単純なNAT/PPPoE/IPoEルータ用途以外にどんな用途でお使いなんでしょうか？ 17.01.3-＞17.01.4のときはWIFIのKRACK騒ぎだったかの影響と理解してるけど、
今回18.06.0 -> 18.06.1がこんなに短期間なのはなぜなんでしょう？ >>79
宅内LANのIPv4/IPv6の権威DNS
v6アドレスなんて覚えてらんねぇからの >>79
>>80と似たり寄ったりりだが、WiFi APでありport/tagged VLAN可のスイッチHUB
うちはルータはPC Linuxで組んでいるのだが、ルータのLAN側と宅内LANの間に
そやつを挟んでいる
ルータ <=> OpenWrt AP間はtagged VLANで多重化
情報家電系や来客用のSSID(SSID内のWiFi端末間で導通させないようにしてある、
いわゆるisolated)はVLANとして分けて、ルータで各サブネットを捌く
PCルータ自身がWiFi I/F持ってればルータの中で捌けばいいんですけども
11ac 1300Mbps(3T3R)以上でAPになれるPC用のWiFiはそうそう市販されてないのでね >>81
>17.01.3-＞17.01.4のときはWIFIのKRACK騒ぎだったかの影響と理解してるけど、
>今回18.06.0 -> 18.06.1がこんなに短期間なのはなぜなんでしょう？
CVE-2018-5390対策じゃないの？ 国外ベンダ機種 :
この機能、使うかぁ?と思われるものも、とりあえずぶっこむ
難しい機能は、理解しているなら使ってください
国内ベンダ機種 :
ごく一般的な機能しか載せない。あとは全部機能をつぶす
サポートで問い合わせされてもまともに応えられない機能は最初から存在させない 国外ベンダ機種 :
GPL対象ソースは早々に開示 配布形式はもちろんダウンロード
国内ベンダ機種 :
基本出したがらない。Buffaloは遅延こそすれどが割とくまなく出してくれるが
・自分たちで手を動かしてなくて、GPL対象と非対象を仕分けできないから
・仕分けできるとしてもそこに工数を費やしても全く銭にならないから
・そもそも「GPLって何? ソースコード?んなもん出す必要があるの?俺らの製品じゃん」 【中庸はＮＧ、右か左】 世界教師マⅰトレーヤ「新時代を切開くため70億人を２つのグループに分ける」
http://rosie.5ch.net/test/read.cgi/liveplus/1534987219/l50
ＰＣとスマホのモニターを覗いている傍観者のみなさん、腹を決めてください。 >>79
透過型プロキシ
httpsが主流になってきてからやめた。 >>79
まだ使ってないけど、packagesのPRにあるこれらがもしマージされたら、使ってみたい
lora-gateway (lorawanのゲートウェイ実装)
https://github.com/openwrt/packages/pull/6808
suricata (snortじゃないIDS/IPS)
https://github.com/openwrt/packages/pull/6168 ロォーーーオォーーーラ!!
ヒデキ... (ﾟ´Д`ﾟ)ﾟ
>>90
LoWANってキーワードを聞いたことがあるだけなんだけど
もうバンバン使われているの? ルータはルータでええんよ
他のことまであれこれやらせようとするとどこかで無理が出て
仮にできても何から何までそいつに依存することになって壊れたときに困る >>92
わかる。
でも、openwrtの持ってるポテンシャルを広げるというのは、悪くないと思うで。
特に、機種によってはhwnatが可能になってきて、cpuのidleをみると、いろいろ
試してみたくなるわ。 >>91
バンバン使われているかはわからないなあ。
コンシューマ向けの商品がないから気軽に試すというのも難しいし。 >>79
付加機能より負荷対策、bufferbloat対策が目的 探せばほとんど事例が出てくる = 刈り取られてない場所がなくてぺんぺん草も生えてない
そんなもんいじっても面白くなかろう? WZR450HPにSFE試してた者ですがkmod-ipt-offloadにチャレンジ。
ar71xxに4.14適用可と聞いて450HPにて単純NATのテスト。
厳密にはやってない=LAN上に他の端末もいるので参考までのデータです。
測定は iperf3 -c [SERVER-IP]
公式18.06.1= 265/263/265Mbps
自前18.06.1= 311/311/311
自前18.06.1+SFE= 738/736/736
自前Snapshot4.14&Normal= 313/312/313
自前Snapshot4.14&Soft offload= 486/471/480
送受信同じ値なので省略で各3回テストでこんな感じ。
自前のはコンパイルオプションに-O2指定してるから多少早い。
ath系はSFEの方が良いっぽくない? >>98
18.06.1へのSFEはkernel 4.9に対してですかね
4.14へのSFE適用はさすがに難しい？ >>99
18.06.1はath71xxなので4.9+SFEです。
4.14へはたぶん単純に当てるだけじゃダメかなぁという風味。 >>100
今後もkernelバージョンはどんどん新しくなっていくだろうから
SFEもmaster入りしてくれると良いんですけれどねぇ 事例いろいろありがとうございます
信頼性の話が出てたので…
OpenWrtでのVRRPなどによるゲートウェイの冗長化とか
Linux-HAによるサービス冗長化に挑んでいる人はいますか？ keepalivedとか？
興味はあるけど経験はないなあ >>98
コンパイルオプションに-O2はどこに設定できるの？
これ？
Advanced configuration options (for developers) --->
Additional compiler options DS-Lite使おうず
IPv4でポートを外部公開させる経路を除いて v6 nat-ptでwanをv6&v4、lanをv6 onlyで
運用してる人って居ます?
暇だから一度試しにやってみようかと。 >>109
そう。internet側はv6、v4のデュアルスタックで、
openwrtでv4もv6に変換して、
lan側にはdhcpv6のみでv6アドレスしか
払い出さない、みたいな。
一応やれるこたやれるみたい。
ログ見てると、
同じマンションの上か下か横の住人が
知らずに使ってるっぽい
怪しい中華組み込み用wifiが
パスワード総当たりアタックかけて
きてるっぽいので、万が一破られてもv6は喋らないだろう、と。 分解したことがわからないように破損なく殻割りするのが最大のヤマ。
殻割り無しで純正ファームのmtdblock抜ける機種は楽でいいね。 uImage-initramfsを純正ファームから切り出せればなぁ >>71
WSR-1166DHPのシリアルコンソールのGNDのハンダ、なかなか抜けなくて苦しんだ。
盛り共晶ハンダにフラックスをべった塗りした基板をバイスで縦に固定して、
表からC3コテ先装備のFX-601(360℃)で加熱しつつ
裏から新品ノズルのFR-300(350℃)で吸い取ってようやく抜けた・・・ 半田苦手意識が抜けないわ
15万くらいのCDPのコンデンサ交換失敗
それがあったからルーターは手始めにG301でやったがそれも失敗した >>116
ハンダづけは 良いコテとコテ先、そしてフラックスがあるとだいぶ世界が変わるよ
>115はトータルで5～6万円はするアマチュア最強装備で挑んでるよねｗ gnd以外は楽にぬけるから
そしたらピン半差しで押しながら加熱してつうずるっこんでやる FX-601は非ステーション型の温調の中では安くて使い勝手がいい。
太陽電機(goot)のPXシリーズはWHRシリーズ並に微妙。 ■ このスレッドは過去ログ倉庫に格納されています
