Internet

Arduino uno を利用した温度測定システム

Internet

"Arduino uno"を利用した温度測定サーバを作ろうという事で、言わずと知れたマイコンボード "Arduino"、その最新版となるunoモデルと
イーサネットシールドを用いて気温測定サーバを作ってみました。

先ずは全体像から。イメージとしては下図な感じです。

■動作概要
Arduino uno(以下uno)がWebサーバとなり、httpクライアントからのリクエストをトリガーにセンサーからの温度を取得し結果をレスポンスする。
また、httpリクエストを受けてからレスポンスを返しセッションを切断するまでの間はLEDが点灯するといった、アクセスを視覚的に認識する機能も具備しました。

■使用した部材
1:メイン基盤
arduino uno本体

2:ネットワークカード
arduino Ethernetシールド

3:基盤
ブレッドボード(ミニブレッドボード BB601/秋月電子)

4:温度センサー
サーミスタ 103AT-11 

5:温度センサ用抵抗
3.3KΩ

6:LED
赤色LED (OSDR 5113A / VF:2.0V)

7:LED用抵抗
150Ω


■H/W構成と配線

☆各パーツの接続構成図


最終更新 (2012年 6月 10日(日曜日) 21:52)

 

RT57i PPTP で DNSサーバアドレスを配布する

Internet

名機rt57iでpptpをサーブした際に、接続クライアントにDNSサーバアドレスを配布通知する事ができない場合があります。
というか、デフォルトでは通知できません。

理由は、PPPのネゴシエーションにおいて、DNSサーバをクライアントに通知するためにPPP/IPCPのMS拡張オプションが有効に
なっていない事に起因しているそうです。

という事で、設定する場合は以下で。

> administrator
Password:
# pp select anonymous
anonymous# ppp ipcp msext on

 

IPv4アドレスの売買開始!?

Internet

IPv4アドレスの枯渇が着実に進み「在庫無し」という状況が改善されることは無いですが、とうとう売買(http://www.tradeipv4.com/)サイトが出現されました。RIR別に値段が若干違い、ARINは$3/IPでAPINCは$4/IPといった価格設定となっています。違法/合法はともかく、必要に迫られている人にとって本当に有用なのでしょうか。。

 

.COM が DNSSECを開始

Internet

最大のドメイン数を保持するgtldである com ドメインがDNSSECを導入しました。
レジストラの対応状況はまちまちなのでしょうが、これで拍車がかかる気がいます。

 


$ /opt/named/bin/dig @a.gtld-servers.net. com +dnssec

; <<>> DiG 9.7.3 <<>> @a.gtld-servers.net. com +dnssec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53184
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;com.                           IN      A

;; AUTHORITY SECTION:
com.                    900     IN      SOA     a.gtld-servers.net. nstld.verisign-grs.com. 1301714430 1800 900 604800 86400
com.                    900     IN      RRSIG   SOA 8 1 900 20110409032030 20110402021030 1793 com. B+er4RTy7opzFftMmihCEtRBYW34Xsr3sEXZD0IPThbYrvEx3CeZOo3O TCJMKk66Bb5ujZddGLbgNnhJumMecH5pm22+sKosL5Itcj7lewZWQdMf IXq4/b1qVXQ0cvhvHQMPxgOII0tJkxmwjJqBcfRhtYrcUnIhmqVQjqDz wuw=
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CKF818DLPC3J4EGETCIMOIOVEKKECP5G NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20110408225901 20110401214901 1793 com. Dj+SlXcZQUs50YPM5ujcDQObElQ5XBjA6adlnMVSyUAuZyV7jBFIlyzx 9YFdHaiZx/25Fy1k/Lo5NsBeIsjRqfLoriNQAf3W+9Grem+hbv4Zj4Y0 K5OkeIL44o+JWZhySELIQ6xNvVfMKkfjvRH99mQpRQLaa9JHAzms+lSm F68=


 

エンドサイトへのIPv6アドレスの割り当てに関して

Internet

RFC3177でエンドサイトへのIPv6アドレス割当は/48にすべきとされて来たが、これがObsoletesになりRFC6177(Best Current Practice)として発行されました。内容的には、

  • /128は推奨しない
  • RFC3177の推奨プレフィクス/48,/64,/128 はオペレーションやインプリ面でハードコードされてしまう危険性があるので、CIDRの考え方にすべき。
  • /48などのデフォルトサイズを推奨するという以前のやり方を変更する。エンドサイトは異なる形とサイズアサインとフリーサイズアプローチは必要でないか適切ではない。

むむぅーー。要するに、「具体的なサイズを推奨はしない。そして、適切に割り当てるべき」という事か。。

 

 
さらに記事を読む...
Login