This project is read-only.
1

Closed

DHCPの取得アドレス制限

description

SAKURAのみの問題かもしれませんが、PEACHでも同じでしたら対応をお願いします。

192.168../255.255.255.0

これ以外のアドレスをDHCPサーバーが返してくると、NetworkInterfaceのDHCP関連メソッドの設定&機能ではIPアドレスが取得できない。

らいしい。
Closed Mar 7, 2015 at 7:44 AM by matsujirushi

comments

matsujirushi wrote Feb 27, 2015 at 4:25 AM

本題とズレますが...

GR-PEACHの状況は不明ですが、早急に対応する必要あると思います。
一般家庭でも、255.255.255.0以外の場合があります。

知人宅(マンションの集中LAN)に某NTPキットを設置したときに、同じ事象を体験しました。
このときは、NTPキットのファームウェア変更で対応しました。

matsujirushi wrote Feb 28, 2015 at 5:25 AM

動作しない具体的なIPアドレス/サブネットマスク教えてください。
できれば、Wiresharkキャプチャもほしいです。

yoshidaken1 wrote Mar 1, 2015 at 1:11 AM

太田さんからいただいたTestSakuraプロジェクトで、DHCPでIPアドレスを付与されてbingにHTTPアクセスするサンプルです。うまくいくと200コードが返ってきます。
以下に具体的なIPアドレスレンジを示します。
パケットキャプチャは後日チャレンジしてみます。

【動作するIPアドレスレンジ】
  • 192.168.111.0/24 職員室 Baffaloのブロードバンドルータ
  • 192.168.11.0/255.255.255.0 実習室にIODataのブロードバンドルータを入れる
※ 192.168../255.255.255.0しか受け付けないようですね。

【動作しないIPアドレスレンジ】
  • 10.0.1.0/24 自宅のAirMac TimeCupsleルータ
  • 172.22.10.0/23 職場の実習室の校内LAN
CIDR /24 = 255.255.255.0
CIDR /23 = 255.255.254.0

matsujirushi wrote Mar 1, 2015 at 1:36 AM

この辺が絡んでいるのかな?
キャプチャよろしくお願いします。
  if (dhcp->subnet_mask_given) {
    /* copy offered network mask */
    ip_addr_copy(sn_mask, dhcp->offered_sn_mask);
  } else {
    /* subnet mask not given, choose a safe subnet mask given the network class */
    u8_t first_octet = ip4_addr1(&dhcp->offered_ip_addr);
    if (first_octet <= 127) {
      ip4_addr_set_u32(&sn_mask, PP_HTONL(0xff000000UL));
    } else if (first_octet >= 192) {
      ip4_addr_set_u32(&sn_mask, PP_HTONL(0xffffff00UL));
    } else {
      ip4_addr_set_u32(&sn_mask, PP_HTONL(0xffff0000UL));
    }
  }

HiroshiOta wrote Mar 1, 2015 at 8:38 AM

これは、IPアドレスのクラスA、B、Cに正しく則っているってことですかね。
http://keicode.com/netprimer/np13.php
に書かれていますが、サブネットマスクとIPアドレスが合っていないと受け付けない。
ってことですかね。

matsujirushi wrote Mar 2, 2015 at 4:47 AM

DHCPからのパケットにサブネットマスクが含まれていない場合に、IPアドレスからサブネットマスクを導出しているようです。
なので、まずはキャプチャした情報のDHCPからのパケットを確認したいと思っています。

matsujirushi wrote Mar 2, 2015 at 4:49 AM

余談ですが...
first octet rule と言うようです。

yoshidaken1 wrote Mar 2, 2015 at 3:35 PM

ファイル添付がうまくいかないのでパケット番号3から6を貼り付けておきます。この4つのパケットが何度も繰り返す流れです。

No. Time Source Destination Protocol Length Info
  3 0.001995000    0.0.0.0               255.255.255.255       DHCP     350    DHCP Request  - Transaction ID 0xabcd5a0b
Frame 3: 350 bytes on wire (2800 bits), 350 bytes captured (2800 bits) on interface 0
Ethernet II, Src: 1c:00:11:33:44:55 (1c:00:11:33:44:55), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: 68 (68), Dst Port: 67 (67)
Bootstrap Protocol (Request)

No. Time Source Destination Protocol Length Info
  4 0.004650000    10.0.1.1              255.255.255.255       DHCP     342    DHCP NAK      - Transaction ID 0xabcd5a0b
Frame 4: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Apple_00:66:e0 (90:72:40:00:66:e0), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 10.0.1.1 (10.0.1.1), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: 67 (67), Dst Port: 68 (68)
Bootstrap Protocol (NAK)

No. Time Source Destination Protocol Length Info
  5 0.023790000    0.0.0.0               255.255.255.255       DHCP     350    DHCP Discover - Transaction ID 0xabcd5a0c
Frame 5: 350 bytes on wire (2800 bits), 350 bytes captured (2800 bits) on interface 0
Ethernet II, Src: 1c:00:11:33:44:55 (1c:00:11:33:44:55), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: 68 (68), Dst Port: 67 (67)
Bootstrap Protocol (Discover)

No. Time Source Destination Protocol Length Info
  6 0.025662000    Apple_00:66:e0        Broadcast             ARP      60     Who has 10.0.1.6?  Tell 10.0.1.1
Frame 6: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
Ethernet II, Src: Apple_00:66:e0 (90:72:40:00:66:e0), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (request)

matsujirushi wrote Mar 4, 2015 at 12:13 PM

2つの事象を確認。対処してBuild 6Bとしてアップしました。

1.DiscoverとRequestで、Transaction IDが不一致
2.DiscoverにClient Identifier Optionを付加しているにもかかわらず、Requestに付加していない