「Yosemite」カテゴリーアーカイブ

アプリを開けない

CarbonCopyCloner (CCC)を無料の時(つまり開発時)から愛用しているのだ。このバックアップアプリはイメージファイルとして保存するのではなく、そのままバックアップ(クローン)するので、ファインダーレベルで、昔のファイルを取り出すことができる。
仕事で使っているMacも、管理しているMacサーバも、TimeMachine と併用してバックアップしている。つまり異なった方法でのバックアップHDDが2台あるのだ。
有料になって、最新バージョンを購入したとき(去年の10月だ)、端末のMacでアンインストールに失敗したのか、新しいのがインストールできない状況のまま放置しちゃったのだ。
最初のアンインストールを間違えたようなので、アンインストール方法のページにしたがって、フアイルを捨てたんだけど、新規インストールできないのね。よくわからないので放置していたのだ。
1年も立っちゃって、改めて、先週末に、開発元にHelp me メールを、Webページ経由で出したら、きちんと返信されてきた。開発元が英語圏なので、返事は英語と自動翻訳した日本語だ。Web サイトが日本語表示だったので、日本語で問い合わせたから、向こうも自動翻訳で英語にして解釈して返信してきたのだろう。自動翻訳の日本語は何をいっているかよくわからん。

私はあなたが持っているもののトラブルわからないんだけど、それはあなたがCCCをアンインストールしようとしたように聞こえる、と今あなたがCCCを開くことができません。次のことをお試しください:

最初の返信メールは、トラブルの状況の確認だった。多分、自動翻訳では不十分だったんだろうね。「起動すると、開けません。」というがトラブルだ。
20151006CCC_Boot
やっぱし、画面でみるのが早いのだろう。画面のコピーを添えろと指示されたので、この画面のハードコピーと英語と日本語の説明を付けた。
つぎのメールは、Mac本体のsystem.log を送付しろということなので、添付した。system.log の場所も示していたので親切だ、というか、普通はわからないから当たり前か。この日本語も自動翻訳でよくわからん。

おそらく、我々は、なぜOS Xの意志ではないオープンCCCを記録システムから決定することができます。あなたはここにSYSTEM.LOGファイルを添付することはできますか?あなたは/アプリケーション/ユーティリティ/コンソールアプリケーションでそれを見つけることができます。ファイルを明らかにするために、ファイルメニューの「Finderで表示」を選択した後、サイドバーにある「system.logに」をクリックします。

英語のほうは;

Perhaps we can determine from the system log why OS X will not open CCC. Can you attach the system.log file here? You can find it in the /Applications/Utilities/Console application. Click on “system.log” in the sidebar, then choose “Show in Finder” from the File menu to reveal the file.

なので、英語のほうがわかりやすい。
3回目のメールで「It looks like the application is getting quarantined by GateKeeper:」といってきて、「xattr -c -r “/Applications/Carbon Copy Cloner.app”」をターミナルで実施すればいいと指示してきた。 この日本語の指示は;

アプリケーションがゲートキーパーによって隔離きているように見えます
アプリケーションの「検疫」の属性を削除するには、ターミナルアプリケーションに次のように貼り付け、それを開くために、再試行してください:

だ。ま、Gatekeeper が何であるか知っているのならなんとなくわかるよ。
その通り実施して、新しいCCCを開くことができて、問題がなくなった。
ダウンロードしたアプリケーションはMacOSXが怪しいかどうかチェックする。そのアプリがGatekeeper で、普通のアプリではないからアプリケーションやユーティリティにはない。怪しいと隔離するわけだ。この隔離にあってしまったということだ。アンインストールに失敗したわけではなかった。隔離するとそのファイル(フォルダ)の拡張属性に隔離のタグがついてしまう。この拡張属性とは、ターミナルでファイル名を見ると権限属性のあとに@がついているやつだ。この@が拡張属性ついたファイル・ディレクトリで、MacOSだけが理解できるメタ情報なので、これをつけたまま、サーバにアップロードしたりWinに移すと読めなくなってしまう可能性がある。Macで作成したファイルをWin で見ると._hoge とかいうファイルが見える。これはこの拡張属性 が取り除かれた結果だ。
何故、隔離されちゃったのかは今となってはわからない。一度、隔離のフラグが立っちゃうと、これを捨てて新しいものをダウンロードしてもフラグが立ったままのようだ。「App Store から購入したものじゃないから開けないよ」というときはコントロールキーを押して開くと、開くことを選択できる。このとき開くのをやめると隔離されちゃうのかな?ちがうだろ。
ダウンロードしたアプリを開こうとしたとき、「壊れているから開けません」なんていうプロンプトがでてきたら、隔離されちゃったことを意味する場合がある。隔離を解除するかどうかは自己責任ですな。
この拡張属性を削除するコマンドがxattr なのだ。ターミナルで man xattr とすればコマンドの意味と使い方がわかる。

The xattr command can be used to display, modify or remove the extended attributes of one or more files, including directories and symbolic links.

というわけだ。extended attributes=拡張属性だ。オプションの -c は;

the -c option (“clear”), causes all attributes
(including their associated values), to be removed.

で、 全て削除だよということで、-r は;

If a file argument is a directory, act as if the entire contents of
the directory recursively were also specified (so that every file in
the directory tree is acted upon).

ということで、単一ファイルでなくdirectoryの場合は -r を付けなさいということだ。-R とかと同じ意味だ。CCC.app はアイコンになっていて、見かけ一つのファイルだけど実はdirectory(フォルダ)だからね。
まともと思われるアプリが開けなかったら、自己責任でやってみる価値がある。
開けないときCCC.appに @ が付いていたかどうか確認して見ればよかったが、

Mac:Applications hoge$ ls -al

を実施すると @ のついたアプリがいっぱいある。だからCCC  にも@がついていたのだろう。xattr を実施したあとだから、今はついていない。@が付いているほとんど全部が購入後にインストールしたアプリだ。でも隔離したというフラグが立っているわけではない。App Store から購入したアプリ(OSのインストーラなど)には付いていない。

こいうことはトラブルになって、始めて知ることになる。

例えば ImageJ をダウンロードし、解凍してできた ImageJ というフォルダをApplications 内に置き、su になって

sh-3.2# pwd
/applications
sh-3.2# xattr -c -r ImageJ
sh-3.2#

とすればいい。

El Capitan のインストーラ

どのバージョン(調べればわかるだろうけど)からか、MacOSXのインストールはネット経由で、インストール終了後、インストーラがなくなってしまうことになった。
El Capitan のインストーラも同じなので、インストーラを保存しておくことにする。いままではダウンロードするとインストーラがアプリケーションにできていたのだが、El Capitan はよくわからん(結局同じだ。ファイル名がわからんだけだ。下記)。そこで、MacOSX拡張(ジャーネリング)でフォーマットした8 GBのUSBフラッシュメモリを用意する。App Storeからダウンロードが終了したら

20151003El_Capitan_Installer-1

指示されるように進まないで、そのままで、ターミナルを起動し、
sudo /Applications/Install OS X El Capitan.app/Contents/Resources/createinstallmedia –volume /Volumes/[USBメモリの名前] –applicationpath /Applications/Install OS X El Capitan.app –nointeraction
をターミナルで入力して実施する。ここを見た

Mac:~ hoge$ sudo /Applications/Install OS X El Capitan.app/Contents/Resources/createinstallmedia –volume /Volumes/El_Capitan_Installer –applicationpath /Applications/Install OS X El Capitan.app –nointeraction
Password:
Erasing Disk: 0%… 10%… 20%… 30%…100%…
Copying installer files to disk…
Copy complete.
Making disk bootable…
Copying boot files…
Copy complete.
Done.
Mac:~ hoge$

とする。このUSBメモリがら起動するときは Option キーを押しながら起動して、起動メディアを矢印キーで選べばいい。
いままでと同じで、TimeMachineからの復元、ディスク・ユーティリティなどが付属したインストーラだ。
ダウンロードしてインストールしないと、アプリケーションにインストーラが存在する。これをコピペするのでいいのでは?
20151003El_Capitan_Installer-2

Yosemite でHosterを有効に

MacにHoster というアプリがある。これは、ノートで色々な環境下でネットに接続するとき、ドメイン内からドメインのサーバにアクセスするのにドメイン名ではアクセスできない場合に便利だ。
外に公開しているWebサーバなどはDMZにprivate ip addressを割り当てて設置する。サブネットの外からはサブネットのglobal ip addressへのアクセスがルータでサーバのprivate ip addressと結びつけてあるのでサーバにアクセスできるのだが、サブネット内でサーバの名前の解決をDNSに問い合わせると、global ip address が返ってくきて、この返されたアドレスはサブネット内からはルータのことなので、サブネット内ではサーバにアクセスできない。サブネット内ではprivate ip addressでしか接続できないので、hosts というファイルにprivate ip addressとドメイン名を対応させて記入しておく必要があるのだ。ただしこのhostsファイルはサブネット内だけで使うわけだ。
サブネット内とか外からとか場所の異なるところでアクセスするときは、hosts をいちいち書き換えるのはやってられないので、アプリであらかじめ設定したhostsファイルを選択するようにすればいいのだ。このようなアプリがHosterというわけだ。
管理者は複数のサブネット内からMacbookでそのサブネット内のサーバにアクセスするので使っているのだ。
ところが、Yosemiteの10.10.4 にしたら使えなくなった。その原因はhostsの権限が変わってしまったから、Hosterで変更できなくなってしまったということだ。だからターミナルで:

[Macの名前]:~[ユーザ名]$ su
Password:
sh-3.2# cd /private/etc
sh-3.2# sudo chgrp admin hosts
sh-3.2# sudo chmod 664 hosts
sh-3.2#

アクセス権を変更しないといけないのだ。su でルートになれるようにする方法は、Merverics の時と同じだ。

同時に出したメールが同時に届かない

同じサーバの2つのメーリスに投稿した。なかなか届かない。最終的に届いたのだが、2通の届く時間がエライ違う。数分の時差がある。数分ちがうと、メーリスのサーバがおかしい?とか心配になる。なんでだ?というわけで届いたメールを見たら;

メールA メールB
メールを出したPCの時刻 10:14:00 10:14:00
最初のsmtpが受け取った 10:14:08 10:14:08
最初のsmtoから中継のsmtpが受け取った 10:14:09 10:14:09
中継のsmtpからメーリスのサーバが受け取った 10:14:09 10:14:09
メーリスのサーバから中継smtpが受け取った 10:14:10 10:14:10
中継smtpからkddi.ne.jpが受け取った 10:14:10 10:14:11
kddi.ne.jpから.secure.ne.jp受け取った 10:14:11 10:14:11
secure.ne.jppからPOPサーバのSMTPが受け取った 10:15:33 10:19:42

管理人のPCから、最初のsmtpサーバまで8秒もかかっている。管理者のPC の時刻がずれていた可能性がある。アップデートしたあとntpサーバにちゃんとアクセスしていなかったようだ。日付と時刻で「日付と時刻を自動的に設定」にチェックが入っていなかったからな。yosemite にアップしたときに外れたに違いない。
Mavericks のとき、/usr/local/sbin にntpd をインストールしたから
/etc/ntp.conf をみたらMervericks 時に書いたのが変更されている。各サーバについてminpoll 6 maxpoll 10がない

sh-3.2# cat ntp.conf
server ntp.nict.jp minpoll 6 maxpoll 10
server ntp1.jst.mfeed.ad.jp minpoll 6 maxpoll 10
server ntp2.jst.mfeed.ad.jp minpoll 6 maxpoll 10
server ntp3.jst.mfeed.ad.jp minpoll 6 maxpoll 10

だから上記のように加筆した。さらにインストールしたntpd を使うために、yosemiteにアップデートしたときの本来のntpd を殺し、
mv /usr/sbin/ntpd /usr/sbin/ntpd~
あとから加えたntpd を使えるようにシンボリックリンクを張る。
mv /usr/sbin/ntpd /usr/sbin/ntpd~
確認する。sh-3.2# pwd で  /usr/sbinにいることを確認し、sh-3.2# ls -alでフアイルを見ると;
lrwxr-xr-x 1 root wheel 20 12 2 13:04 ntpd -> /usr/local/sbin/ntpd
-rwxr-xr-x 1 root wheel 66016 9 10 08:09 ntpdate
-rwxr-xr-x 1 root wheel 138240 9 10 08:09 ntpdc
-rwxr-xr-x 1 root wheel 382464 9 10 08:09 ntpd~
-rwxr-xr-x 1 root wheel 2029 9 10 08:09 ntptrace
となっていてこれでいいはず。
メーリングリストが動いているサーバでの処理は2秒以内だ。十数個のメーリスに同時に投稿すると30秒位かかるようだ。この大学のメールサーバはKDDIが請け負っている。さらにウイルスフィルタのサーバがあるようだ。KDDIまでの時間はさほどかかっていない。そこからウイルスフィルタのサーバsecure.ne.jpへ送られ、そのサーバが処理する時間がエライ長い。タイミングがあるんだろうが1分22秒あるいは5分31秒もかかっている。なんてこった。大学外からくるメールを見たらこのアンチウイルスフィルタを通る時間が結構かかっている場合がある。しかし5分かかると、なんかおかしいと思って調査はじめるよな。

メーリングリストが動かない…

突然メーリングリストが動かなくなった。
25日(火)17:43の投稿は動作した。
26日(水)18:04の投稿は配信されていない。
この24時間に何が発生したんだろ?mailman のトラブルかと思ったが、違っていた。
上流のDNSサーバでもあるサーバを26日午前2時からアップデートするという連絡を受けていたことを思い出した、というか思い出すのに時間がかかったのだ。
26日午前0時ころのメールはメールサーバに届いている。それ以降のメールがメールサーバにとどいていないのだ。このメールサーバはメーリングリストが主な役割なので、メーリングリストしか見てないので、mailman の設定フィアルがこわれたのかな?という先入観の下にいろいろ調べてしまったのだ。その結果mailmanはきちんと動作していることがわかり、このサーバにメールが届いていないから配信されないということがわかったのだ。
ここまで分かるのにエライ時間がかかった。問題のサーバをSMTPサーバに指定すればメールはこのサーバにあるメールアカウントに届くが、他のサーバをSMTPに指定した場合このサーバにあるアカウントにメールが届かないのだ。このことに気づくのに時間がかかりすぎた。つまりサーバはなんともないがサーバにメールがこないのだ。
原因は上流にあるファイヤーウオールか?と思ったが、何も変更していない。再起動したが変化はない。
多分このサーバを登録しているサーバのMXレコードが消えちゃったんだ。まだ管理者さんに連絡した段階で返事がないからわからない。この推定が正しければいいのだが。
きたきた、これまでテストで送ったメールがどっと来たぞ。上流のDNSサーバ管理者さんが設定したんだ。きっと。
まだ管理者さんから連絡がないが、設定したんだろ。メーリスも動く。問題なくなった。
管理者さんからメールが来た。アップデートしたとき、メール転送の記述が昔のまま(当然だが)で、今度はキチンと記述しないといけなくなったのが原因だったようだ。
従来は
example.com:[123.123.123.123]
でよかったのが
example.com smtp:[123.123.123.123]
ときちんと明示する必要になったんだそうな。
実は、この上流のDNSサーバは、もうやめようということになっていて、DNSは大学中央のサーバを指定することになっているのだ。でも、いっぺんにDNS機能を削除すると、連絡はしたのだが、まだDNSサーバに指定しているユーザがかなりいるので、まだ動かしているのだ。これらを決めたのは、何を言おうかこのワタクシなのだ。どじだなぁ。大学にメールサーバとして新たに届けて大学のDNSにMXレコードを登録してもらえばいいのだ。この上流のサーバは昔はワタクシも管理者だったのでここに登録するのが一番簡単なので登録していたのだ。今はこのサーバの管理を他のヒト(業者)にまかせているのでワタクシはDNSやMXレコードの変更はできないのだ。自業自得というもんだ。

yosemite 10.10.1

Yosemite がバージョンアップされた。10.10.1  である。これまでの幾つかのバグが直されていることを期待する。
開いたウインドウの位置を覚えていないから、モニター2つで運用していると再起動するとウインドウの位置がかわっちゃう は解決されたようだ。
DHCP でないとVPN できない  まだだめだ
Dashboard の時計  まだだめだ

VPN 困った/解決した/まただめだ/繋がった

Mac Yosemite ではVPNはクライアント機が固定ip address だと使えないというのは前に書いた。バグだが、解決策はあった。DHCPならばいいのだ。
ファイヤーウオール兼ルータ(以下ルータあるいはファイヤーウオール)を使ってサブネットを作成しているのだが、ファイヤーウオールでWindowsのファイル共有を遮断しているため、ファイヤーウオールの外にある学科共通のファイルサーバにアクセス出来ない。SMBを使っているからだ。しょうがないから、ファイヤーウオールに穴をあけてこの共通のファイルサーバだけにアクセスできるようにした というのも書いた。
学内のDNSサーバが知らないうちに変更されていたというのはこの前の記事だ。だから、ルータのDNS情報を書き換えてリセットしたら、このファイヤーウオールの設定がぶっとんでデフォルトにもどってしまった。共有ファイルサーバにアクセス出来ないのでわかった。ファイヤーウオールの設定を再度やったわけだ。
そこで気がついたのが…困った。
VPN(PPTP) で2箇所のネットワークに接続できるように設定してあったのだ。何故か、一方のネット(net Mとよぶことにする)にPPTPで接続できない。他方のネット(net Sと呼ぶことにする)には接続できるのだ。だからファイヤーウオール(ルータ)がパケットを落としているのではない と思っていた。
ルータの外のネットワークに接続すると逆にnet Sに接続できず、net Mに接続できるのだ。んん?なんだこりゃ。
どちらもYosemite のMac だ。理由がわからない。そこでルータやパソコンのすべての設定を見直した。パソコンの方でVPN 接続時のDNSの設定等が違っていたところがあるから、それぞれのネットのprimary と secondary DNS を正しく設定した。別に正す必要はなく空白でいいはずである。
Mac の場合 システム環境設定 → ネットワーク → 該当の接続 → 詳細… → DNS のタブ
Winの場合 コントロールパネル → インターネットオプション → 接続のタブ → 該当の接続を選択 → 設定 → プロパティ → ネットワークのタブ → インターネット・プロトコル バージョン4(TCP/IPv4) → プロパティ → 詳細設定 → DNS のタブ → DNSサーバアドレス(使用順)
接続の可否はDNS設定の正誤ではないはず。DNSがあやまっているのなら、接続ができてもブラウザが使えないとかいうことになる。
ファイヤーウオール兼ルータのフィルタの設定だ。
20141112FirewallLAN2
以前はポリシーも定めていたが、ポリシーなんか1つだけで、このフィルタの設定だけなのでOFF にした。

これでいいはず。
で接続したら、今度は

◯が接続できた。×が接続できない。DHCP&Fix とはDHCPで手入力というMacの独自の設定のことだ。

明らかに、接続先が拒否しているのではなく、接続元のルータの設定がおかしいという結果だ。悩んだ。解決しないので、帰って寝た。翌朝来たら、
20141112VPNconnection-2
と、めでたしめでたし なのだ。何故か?管理者のルータの設定の誤りではない。
んで、Win のデスクトップ機は接続できているのだが、インターネットオプションから、net Mのほうは古いDNSのままだったから、DNSを自動取得に変えて更新して、接続してみたら接続できない。今度は同じルータの下にあるMac もnet Mに接続できなくなった。んが。ルータが何かを記憶しているのか?この記憶をパージするのに時間がかかるのでは?というわけでルータを再起動。まだ接続できない。net S のほうは、ルータの外でも内でも接続できるのだ。
ルータの外からもnet MへはVPN接続できなくなってしまった。
いや、また変わった。ルータ内からはnet Sに接続できるが、ルータ外からは net S に接続できなくなった。なんか不安定だな。
なんてこった。どうやら設定はOKなのだが、何故か一度接続に何らかの理由でできないと、どっかに、管理者のルータではない、さらに上流のどこかに接続元と接続先が記憶されていて、一定時間接続できないのが続くのか?
講義、実習で5時間席を空けた。再度テストした。ルータ内外で問題なく接続できるようになった。いや、まただめになった。不安定だなぁ。
また5時間実習で席を空けた。再々度テスト。ルータ内で接続できた。これ以上わからない、Win 7 でも同じだからyosemiteのせいではない。少なくとも管理者の管理している部分は誤りがないようなので、また再現性がよくわからないので、原因の追求は止め。
【追記】 翌日の朝、全く問題なく接続できる。このまま様子見だな。
【追記2】11月13日。原因が判明。上流のDNSの問題だった。経緯は書かない。
関係ないだろうけどwinでは自分のDNS記録をクリアできる。コマンドプロンプトで ipconfig /flushdns を実行するのだ。

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:UsersUSER>ipconfig /flushdns
Windows IP 構成
DNS リゾルバー キャッシュは正常にフラッシュされました。
C:UsersUSER>

思った通り関係ない。ちなみにMac ではターミナルで sudo dscacheutil -flushcache を実行するだ。

Last login: Wed Nov 12 07:31:55 on ttys001
You have mail.
MacPro:~ hoge$ sudo dscacheutil -flushcache
Password:
MacPro:~ hoge$

当然ながら関係ない。自分のパソコンの設定ではないからな。

Yosemiteの日本語入力

Yosemite にしたら、日本語入力はことえりでなくなったらしい。ところが、この日本語入力は、しょっちゅうハングアップする。特に、何故かWordpressで文書を書いていると止まっちゃう。多分、まだ十分にこなれていないのだ。
最新トレンド情報速報というサイトでGoogle日本語入力がいいと書いてあったので、ダウンロードしてインストールしてみた。
20141105GoogleInputJapanese

こっちのほうが、なんの問題もないようだ。ユーザ辞書もそのまま使えるし、手書き入力もある。

Yosemiteでは開いたファイルは再起動で…

2台のモニターをつかっているわけだが、yosemite では、再起動したとき、再起動前の開いたファイルの位置が保持されていない。デスクトップは保持されているのだが。
例えば、スティッキーズとかカレンダーが、シャットダウンしたときその位置を覚えていてくれないので1つのモニターに集まって表示される。隣のモニターに移動させないといけない。
カレンダーとかスティッキーズはメインのモニタではなくサブのモニタに常時提示しておきたいのだ。サブモニタに表示させておいて、再起動すると、メインモニタに開いちゃうから、サブモニタの方へ毎回移動させることになる。
よくわからないのだが、yosemite にアップグレードした直後は、カレンダーだけでスティッキーズはサブモニタの方に留まっていてくれたのだが、今日は、再起動したらカレンダーもスティッキーズもメインモニタに表示されてしまう。
システム環境設定 一般 「アプリケーション終了するときにウインドウを閉じる」 にチェックをいれた。再起動でカレンダーがだめだが、スティッキーズはサブのモニタに出現する。mi のウインドウはこのチェックの有無に関係なくサブモニターに置いておくとそのままサブモニタに出現する。どうやらアプリごとにばらばらばらのようだ。
再起動のプロンプトで「再ログインの時にウインドウをサイド開く」のチェックをはずすと、また様子が変わって、カレンダーはサブモニタに出現するがスティッキーズはサブモニタにでてこない。
組合わせがあるのか、再現性があるのかないのかよくわからなくなってきた。
何回もやっていたら、確実に、カレンダーやスティッキーズ、開いたフォルダのウインドウなどすべてが再起動時にメインのモニタにあつまって開くようになってしまった。どうやら、最後に閉じた時の位置とサイズが記憶されていないと思われる。どこに記録されているんだろ。
デスクトップのアイコンは .DS_Store に保存されているが、こっちは問題無い。サブのモニタに表示されていたフォルダなどがメインのモニタに集まっちゃうなんてことはない。もっぱら開いていたウインドウの位置を記憶していないことだ。

yosemite VPN(PPTP)接続できない

Mavericks で VPN 接続を PPTP で実施してきた。yosemite にアップグレードしたらPPTP接続ができなくなった。隣のWindows とか yosemite にした PowerBook Pro では問題無い。なぜかデスクトップのMac Pro はだめなのだ。
削除して、再起動して再設定してもだめ。あちこち探したら、固定ip address で運用しているとだめだというコメントを見つけた。
DHCP の環境にあるのだが、接続する機器の数は少ない(オフィスの個室内なので、デスクトップ2台とノートが3台くらい)し、固定ipでも管理は簡単で、Mac と Win の間でファイル共有を行うときは固定 ip addess のほうが楽だから、デスクトップは固定ipで運用しているわけだ。そこでDHCPでなおかつ固定ip address に変えてみた。

つまり、DHCPサーバを使うが ip address は手入力というわけだ。なぜ、Mac ではこんな選択があるのかよくわからないが、ともかく、DHCPサーバを使う あるいは 使ってなおかつ手入力で固定 とすると接続できる。バグだなきっと。アップデートしているといつの間にか治っているということだな、きっと。
yosemite にした PowerBook Proで接続できたのはDHCPサーバからip address を受け取るとしていたからだ。