タグ: FreeBSD

FreeBSD で PPPoE + NAT (2024年版)

職場のルータはずっと FreeBSD なのだけど、自宅に新しく入れた Wi-Fi ルータのルータとしての挙動がどうも怪しかったので、自宅のルータもすごく久しぶりに FreeBSD にすることにした。

で、昔取った杵柄で PPPoE の設定を書いて、natd を起動する。ハマったのは以下の2点。

  1. なんか一部のウェブサイトにつながらないし、外部へ ssh もできない
  2. natd が起動するときに tun0 がまだない (ppp の認証に時間がかかるから?) ので、natd が起動しない

1 はやっかいだった、port 80 への telnet も通るし、openssl s_client -connect www.somewhere 80 みたいなのも通るところは通るけど、通らないところは “CONNECTED(00000005)” と出たっきり、タイムアウトするまで何もできない。netstat でみると ESTABLISHED になっている。

MTU discovery の問題かなー、とか思ったのだが、FreeBSD の PPPoE にはかなり昔から TCP ヘッダの mss フィールドを調整する機能がついており、そんなことはないはずなのだ。

で、FreeBSD ハンドブックの当該セクションとかを眺めていると、”set mtu” とか “set mru” とか書いてないの。もしかしていまどき自動？と思って、この2行を消したらあっさり動いた。

2. は /etc/rc.d で natd_options に “-dynamic” をつけたら解決した。これ、動的にアドレスが変わるのに対応するだけかと思ったら、-n で指定したインタフェイスが動的に生えてくる場合にも気長に待ってくれるのね。

というわけで解決です。Wi-Fi ルータはただの有線-無線ブリッジになった。

FreeBSD + LDAP + tcsh

SunOS4と386BSDでUnixを使い始めて20年ちかく、csh/tcshを使ってきたのですが、研究室の環境をFreeBSD 10.2に更新してから、ctrl+cでシェルが死ぬ、という問題が起こるようになりました。入力しかけのコマンドをキャンセルしたいときとかにもつい押しますし、これすげー困りますよ。

それでちょっと検索してみると、

といったように、どうやらうちの研究室固有の問題ではないということに気づきました。こまったこまった。

ということを Facebook に書いたら、学生時代の研究室の先輩方に「おまえまだ tcsh 使ってんのかよはやく zsh にしろよ」といわれまして、つい乗り換えてしまったのですが、root とかはデフォルトの csh のままなわけでして、難しい作業やってるときにシェルが死ぬと集中力きれて困るわけで。

それで、新しい端末をセットアップしていたときに、ports に nss-pam-ldapd というのが入っていることに気づいて、これを使ってみたら ctrl+c おしても平気。nss_ldap や pam_ldap の派生プロジェクトだそうです。

これにてどうやら解決です。めでたい。

panic: No BIOS smap info from loader!

研究室の端末 PC はほとんどが hp 製品で、PentiumD 以降のプロセッサは EM64T なので、FreeBSD/amd64 を動かそうと思って準備している (いまは FreeBSD/i386 だが、diskless なので、親玉サーバでユーザ環境を作って DHCP の設定を変えるだけだ)。

ところが、最新の dx7400 を除くモデル (PentiumD な dc7600 や、Core2Duo な dx7300) では FreeBSD/i386 は起動するものの、FreeBSD/amd64 は kernel panic してしまう。

SMAP、というのはキムタクのあれではなくて、BIOS からもらえる System Memory mAP なのだが、これが hp のちょっと前の世代のマシンではうまく取得できないらしく、google で探すとかなりいろいろでてくるのだが、解決した気配はない。わかったことは、
– FreeBSD/i386 なら起動する、というマシンは loader prompt で smap コマンドを叩いても、何も出ない。つまり、FreeBSD/i386 でもちゃんと取得できていない (loader は同じみたいだしね)
– FreeBSD/amd64 がちゃんと起動するマシンは smap コマンドを叩くとちゃんとリストが出る
ということだ。

で、この panic を出しているのは
– sys/amd64/amd64/machdep.c の 898 行めで、loader が取得した値をそのまま使っている
– 対応するところは i386 だと、sys/i386/i386/machdep.c の 1751 行めあたりで、loader に頼らずに自力で取りにいっている
というわけだ。

さあて、どうするか。
私物の ThinkPad の SMAP table はこんな感じ。

SMAP type=01 base=00000000_00000000 len=00000000_0009d800
SMAP type=02 base=00000000_0009d800 len=00000000_00002800
SMAP type=02 base=00000000_000d2000 len=00000000_00002000
SMAP type=02 base=00000000_000e0000 len=00000000_00020000
SMAP type=01 base=00000000_00100000 len=00000000_bf5b0000
SMAP type=03 base=00000000_bf6b0000 len=00000000_0001c000
SMAP type=04 base=00000000_bf6cc000 len=00000000_00034000
SMAP type=02 base=00000000_bf700000 len=00000000_00100000
SMAP type=02 base=00000000_bf800000 len=00000000_00800000
SMAP type=02 base=00000000_f0000000 len=00000000_04000000
SMAP type=02 base=00000000_fec00000 len=00000000_00010000
SMAP type=02 base=00000000_fed00000 len=00000000_00000400
SMAP type=02 base=00000000_fed14000 len=00000000_00004000
SMAP type=02 base=00000000_fed18000 len=00000000_00001000
SMAP type=02 base=00000000_fed19000 len=00000000_00001000
SMAP type=02 base=00000000_fed1c000 len=00000000_00004000
SMAP type=02 base=00000000_fed20000 len=00000000_00070000
SMAP type=02 base=00000000_fee00000 len=00000000_00001000
SMAP type=02 base=00000000_ff000000 len=00000000_01000000
SMAP type=01 base=00000001_00000000 len=00000000_3c000000

http://www.uruk.org/orig-grub/mem64mb.html に、int 15h:e820h の説明がある。
Linux を dx7300 で起動してみると、

BIOS-provided physical RAM map:
BIOS-e820: 00000000_00000000 - 00000000_0009fc00 (usable)
BIOS-e820: 00000000_0009fc00 - 00000000_000a0000 (reserved)
BIOS-e820: 00000000_000e8000 - 00000000_00100000 (reserved)
BIOS-e820: 00000000_00100000 - 00000000_7efb1d00 (usable)
BIOS-e820: 00000000_7efb1d00 - 00000000_7f000000 (reserved)
BIOS-e820: 00000000_f4000000 - 00000000_f8000000 (reserved)
BIOS-e820: 00000000_fec00000 - 00000000_fed40000 (reserved)
BIOS-e820: 00000000_fed45000 - 00000001_00000000 (reserved)

みたいにちゃんと SMAP が取れているので、loader を hack すればなんとかなるかな?

FreeBSDのサイトの当該エントリもある。

portinstall

portinstall って、ps でみると、いくつインストールするものがあっていまいくつ目か、というのがわかるんだな。知らなかった。

applepie# ps ax | grep port
2488  p1  S+     0:02.21 ruby18: portinstall: [13/48] multimedia/libdvdread (ruby18)
65766  p1  S+     0:00.01 /usr/bin/script -qa /tmp/portinstall.2488.12 env make

root のお仕事

昨日から猛烈に root 仕事づいてしまって、あちこちのサーバのソフトウェアを一気に更新作業中。
家のサーバは Pentium3 なので、コンパイルとかが大変だ (笑)。
研究室の FreeBSD 6.2 なマシンで powerd を試してみたりもした。僕の ThinkPad X61 + FreeBSD 7.0-PRERELEASE では概ねうまく動いているんだけど、研究室の hp の、PentiumD や Core2Duo なマシンでは、sysctl で見える動作周波数リストに 66 とか 33 とか、そういうありえない周波数 (486 か Pentium か!) が出てくる。当然、そんな数字にしようとしてもエラーになるわけで。
CPU がヒマだと powerd がどんどん周波数を下げて OS ごと落ちてしまったり、あるいは忙しくなったことを認識した powerd が周波数をあげようとして失敗して、最低動作周波数のままになってしまったりする。ううむ。7 にすれば解決するかなー。