請教i-040gw中出現的相關WIFI或是DHCP客戶端的相關問題

因為201708 040gw的韌體更新，所以也更新一下。
Win7、Win10電腦及分享器都直接連到040gw的LAN。分享器關閉了DHCP及UPNP(應該是沒有預設NAT)。
040gw預設是: DHCP分配192.168.1.101-200，本身是192.168.1.1，分享器是設定成192.168.1.201。

040gw-系統狀態-DHCP 租借時間中
一台Win7電腦及分享器的Wan?不顯示本身的hostname。會顯示成其他獲得DHCP IP設備的Hostname：比如說另一台Win10電腦、IPAD、Android手機、網路攝影機。

[COLOR="#FF0000"]20170825-0901 約下午1點10幾分，大概有3-4次，以及夜間近12點1次(這個應該不可能是太熱吧!)，自動重新開機。
封包統計中WIFI，接收的廣播遠大於單播的狀況，但不知道究竟是為何? 傳送的就是單播大於廣播! 而且同一時間，WIFI接收的廣播封包數量會大於電腦所在的Lan port看YOUTUBE接收的! (不過整體上，WAN的傳輸與接收是比LAN(及WIFI)的傳送與接收少的，那這到底是表示甚麼? 無線設備頻繁彼此交流?)
中間幾天試過幾種設定的排列組合，不過沒有辦法持續，都是短暫的(感覺是不是只是某種功能被當掉或是才正常)，重開就又會是WIFI接收的廣播遠大於單播!
有懷疑過大陸牌子的攝影機(因為有搜尋到會影響MOD的相關(幾年前的)文章，只是家中(韌體是今年初的版本)該攝影機於該版本應該已經沒有網路直播的功能)，一個mac有兩個IP 一個是192.168.1.128，另一個是DHCP的變動的IP。
不過有時單獨IPAD連上的時候居然也會廣播大於單播... ...?

只是如果通過分享器連上，似乎就不會有問題... ...

20170907 約下午1點10幾分，又自動重開機了
20170909 約中午12:30 自動重開機
20170910 約中午12:50 自動重開機

20170910 約11:20 12:50 下午2:00 4:00 6:20 09:50 自動重開機 (約2點10分有請中華電信重整線路，其表示應該是瞬斷，客服有提出，如果明天還是這樣，需要報修。 )
(關閉硬撥IPV6 似乎沒幫助(應該是約20170805開啟的，不過中午重開是大約20170825開始，
20170911重開了5次。 有看開機時間，確實是有重開。)，不過網路攝影機的流量有大幅降低(難道該網路攝影機有支援IPv6)。
目前已經懷疑到cfos speed beta、040gw，比如MTU自動變動衝突之類的... ... 因為移除後到目前還沒有自動重開，所以嚴重懷疑真的是cfos speed beta跟數據機不合! (不過為什麼是8月25日才開始?)
(在搜尋一直都有的mini httpd 錯誤訊息，以及QOS功能的時候，突然發覺，似乎類unix，本來就有自動調整MTU以及QOS類似的功能，只是看有沒有加進去!)

20170913 晚上10:00左右自動重開! 目前懷疑到040gw部分恢復預設值，似乎把NAT ALG 各種passthrough 都enable, 因為改成Disable之後，溫度就有暫時回到之前49.99999度左右?

20170914 早上10:10 及10:20 左右自動重開2次 下午3:16 下午05:50 11:15自動重開2次
(而且此時是已經覺得，有嘗試排除的都試過了，應該是數據機硬體的問題，準備報修，所以就嘗試戳了RESET，結果是連SLID一起重置。且此期間居然還是會自動重開機! 應該就能確認是數據機硬體或線路或電源等的問題吧! 預約隔天早上保修!)

20170915約10點，師傅來測試，進行更換。相關設定感覺沒甚麼變化，(比如NAT各種passthrough)都是開啟狀態，不過，剛開機是44度，現在跟之前(關掉一堆東西)一樣是49度近50度，中午後到(之前也是的) 53度多。 而且還是有很怪的無線訊號? 因為當時DHCP紀錄看起來應該沒有連上的無線設備(除了使用MAC禁止連線的攝影機，但還是有感覺有相當數量的無線訊號流量與封包)
另，數據機log，跟之前一樣還是有一堆 似乎是mini httpd 錯誤的訊息! 希望不要再自動重新開機! (雖然說相關訊息看起來其實都跟之前一樣，似乎沒甚麼不同?)
Sep 15 11:54:14 I-040GW daemon.warn mini_httpd[14135]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:54:04 I-040GW daemon.warn mini_httpd[13556]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:54:04 I-040GW daemon.warn mini_httpd[13557]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:52 I-040GW daemon.warn mini_httpd[13126]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:52 I-040GW daemon.warn mini_httpd[13125]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:52 I-040GW daemon.warn mini_httpd[13124]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:52 I-040GW daemon.warn mini_httpd[13123]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:52 I-040GW daemon.warn mini_httpd[13121]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:52 I-040GW daemon.warn mini_httpd[13119]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:52 I-040GW daemon.warn mini_httpd[13118]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:52 I-040GW daemon.warn mini_httpd[13117]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:52 I-040GW daemon.warn mini_httpd[13116]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:52 I-040GW daemon.warn mini_httpd[13115]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:52 I-040GW daemon.warn mini_httpd[13113]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:52 I-040GW daemon.warn mini_httpd[13112]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:52 I-040GW daemon.warn mini_httpd[13111]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:52 I-040GW daemon.warn mini_httpd[13110]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:52 I-040GW daemon.warn mini_httpd[13109]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:52 I-040GW daemon.warn mini_httpd[13108]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:52 I-040GW daemon.warn mini_httpd[13107]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:52 I-040GW daemon.warn mini_httpd[13106]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:49 I-040GW daemon.warn mini_httpd[13045]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:49 I-040GW daemon.warn mini_httpd[13025]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:43 I-040GW daemon.warn mini_httpd[12849]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:43 I-040GW daemon.warn mini_httpd[12848]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:43 I-040GW daemon.warn mini_httpd[12844]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:42 I-040GW daemon.warn mini_httpd[12827]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:42 I-040GW daemon.warn mini_httpd[12824]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:42 I-040GW daemon.warn mini_httpd[12822]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:42 I-040GW daemon.warn mini_httpd[12821]: sendfile() failed (errno:22 - Invalid argument) - reverting to
Sep 15 11:53:42 I-040GW daemon.warn mini_httpd[12815]: sendfile() failed (errno:22 - Invalid argument) - reverting to
PS. 經維修師傅告知，原來數據機後面有寫相關燈號說明(可是平常根本看不到，因為不會去動)
原來電源開關是建議關閉一分鐘後再開啟。以及電源燈旁的pon綠燈正常是恆亮，慢閃是韌體資料下載，快閃是韌體更新，此時千萬不要亂動。(不過也有說明相關動作通常是在少人的凌晨進行)
[/COLOR]

因此想請教
1.應該要如何找出那個MAC是甚麼設備?
有在Win7 及Win 10電腦上使用getmac及ipconfig all都只有一個MAC

2.還是說Win7有甚麼可以網路跟MAC或是hostname或是多餘IP有關的重設的方式。。
(曾經，明明沒有無線設備，但是被用網路相關流傳的指令開啟hosted network，出現過600多個6to4 adapter #???，跟網路網路連線#??、以及某些其他網路相關卡 #???，但是發現的當時，沒有找到修正檔(似乎也只是修正)。
微軟的修正程式[url]https://support.microsoft.com/en-us/kb/980486[/url]

因此最早是用手動於registry刪除
以及後來是還使用相關網路流傳程式(6to4remover，Ghostbuster ([url]https://ghostbuster.codeplex.com/[/url] ))等刪除。
最後才找到修正程式安裝。

也曾開啟過ICS，因為之前數據機還沒有辦法直接PPOE的時候，某牌手機的電腦端程式，一定要有區域網路連線才能更新，不能用寬頻連線的... ...

直到最近才想到:
才有再以指令嘗試關閉hosted network，雖然顯示無網路設備，但是還是會顯示已關閉。
以及嘗試打開ICS再關閉。但是不知道是否有作用，所以又到系統-服務-關閉ICS。

因為有些網路討論似乎是提及，如果開啟過相關動作，但是該網路裝置移除了，可能部分設定無法跟著移除。比如說DHCP相關可能會留著，但是沒找到如何單純關閉。)

有嘗試使用wireshark 但是不太會用，應該是只能搜瞄區網(沒有設定vlan。但是040gw的封包統計，WIFI跟4個PORT的也是單群廣播也各自分開的。似乎沒有互通(沒有禁止互ping的時候也是這樣)。)，沒有辦法由區網電腦掃描無線。(可能要用無線設備掃描吧!)

有用過netscan 掃描:
攝影機會有兩個IP:一個DHCP發的IP，跟一個相對固定的192.168.1.128，因為mac是一樣的!
然後如果再掃一次，會出現一堆IP但是沒有MAC。

Net scan DHCP server discovery的結果是只有一個 (不是直接顯示040gw ，而是Win10電腦的網路卡):
"Replied DHCP servers on intel... .. 217-v"
內容是DHCP server (及Gateway & DNS都是) 192.168.1.1 ，offered address 192.168.1.10x(一個不在DHCP租借時間內的IP)

Win7電腦手動開過寬頻連線的ICS，但目前是關閉的，且IP似乎應該是192.168.137.*。
有查到某些手機的分享，會是192.168.1.137，但似乎也不是每個手機都是這樣

PS.
040gw，或是分享器，的Wi-Fi 客戶端資訊通常都是既有的無線設備。
不同MAC，重複2-3個hostname的狀況只有出現在040GW的DHCP租借時間上。

兩台電腦在更早之前執行過這些
nbtstat -R
nbtstat -RR
ipconfig /flushdns
ipconfig /registerdns
ipconfig /release
ipconfig /release6
ipconfig /renew
ipconfig /renew6
arp -d *
netsh interface ip delete arpcache
netsh interface ip delete destinationcache
netsh interface ip delete neighbors
netsh interface ipv6 delete destinationcache
netsh interface ipv6 delete neighbors
netsh interface ip reset
netsh interface ipv6 reset
netsh interface tcp reset
netsh winsock reset

[COLOR="#FF0000"]PS. 因為越來越頻繁的自動重開，而更換了數據機之後:
那台沒有辦法顯示hostname 的電腦，似乎已經可以穩定顯示空白hostname 而非重複任一台的Hostname! (雖然還是沒有顯示原本設定的hostname)
而且封包統計的數字看起來變正常了(之前看起來，傳送跟接收的，感覺沒有對齊，比如說軟撥BR-XXXX跟硬撥WAN1的傳送看起來對不上，是交錯的。 因為通常是軟播的接收多，但卻是硬撥的傳送多)
而且目前恢復自動開啟的IP HELPER服務(但是有手動關閉teredo、isatap、6to4)，網路卡內容中的相關協定都打勾回預設(沒有使用MICROSOFT相關2個選項)，網路也沒有變慢![/COLOR]

[COLOR="#FF0000"]10/22 有嘗試將網路攝影機的 MAC 封鎖，的確廣播有變少。
然後因為有時WIFI的接收，還是會突然出現廣播大於單播，最近才想到反過來的，只開放相關MAC，然後，也嘗試開放了攝影機的。
感覺廣播又更少了一點! 會比較集中在單播! 而且似乎比只阻擋網路攝影機時，WIFI網路速度快一點!
難道是有甚麼WIFI間的廣播互通或干擾嗎? (無線鍵盤滑鼠，之前接收器插在USB 3.0。(滑鼠壞掉，重買)也改移到USB 2.0，可能也有影響。)
因為擺放的區域，的確是有偵測到數位鄰居的WIFI，雖然其訊號相對微弱![/COLOR]

嘗試關閉了firewall-layer3 UDP 的進出(似乎只有IPv4的?)，WIFI收到的廣播感覺增加地比較慢(就算沒有限定可連線的的MAC的設備，還是會有不少廣播)，感覺WIFI(APP下載更新)有顯著變快，而且電腦端似乎沒甚麼變化，所以又嘗試也關閉了ICMP的進出(似乎只有IPv4的?)，電腦端也沒甚麼變化? (而且感覺蠻特別的是，如果開啟家中的分享器，040gWIFI收到的廣播感覺會變少?)

1108
因為Wlan接收的廣播封包，居然會比看YOUTUBE的電腦還多，所以嘗試各種防火牆封鎖的排列組合，結果關到TCP，就進不去了!
因為有先記下SLID，然後戳重設，重新拔插光纖，重設之前記下的SLID!
但使用WIFI.hinet.net的WIFI連不上(可以由線路申請人以免付費電話詢問客服得知此不與小額付費連結的帳號密碼。數據機中顯示的有加密，而且加密方式可能依韌體版本而變化。)，以hinet.net的連上去，但是至目前3次，每天早上的手動開關電源重開機，看起來並不會有WLAN廣播飆很大的狀況? 難道說，使用不同的帳號撥號也有影響? (取得的IP當然是隨機的。 040gw有開啟IPv6。)

PS.
SLID跟附掛號碼一樣。可以查詢。
[url]https://ccs.hinet.net/month_status_cht_big5.htm[/url]
附掛號碼
[url]https://ccs.hinet.net/month_status_cht_big5.htm[/url]

1117
觀察了幾天，突然發現，以MAC位址白名單方式管制WIFI後 (也有設定無線密碼)，有一台詭異的設備，即使不在，但還是會出現在040gw的WIFI客戶端統計上。可是住家周邊，無線信號所及之處，應該不會有這麼無聊的使用者，還模擬MAC位址?

1120
嘗試把WIFI TX 功率降到最低(1-4)。(因為沒有RX的選項)，似乎有點幫助?

2018 0628
DHCP DNS server 由proxy 改成 relay
因為看網路的狀態的時候，突然發現，DNS server IPv4 是寫192.168.1.1 (IPV6 應該是正常的 )，所以大概查了一下，嘗試改，結果網路用起來，尚未發現差在哪?

2018 0629
WIFI的部分 一直接收到大量廣播封包! 少量寄送單播封包，但是有很大的遺失率!
於沒有WIFI客戶端的時候也會這樣!
已經懷疑到其他各種東西，比如說藍牙(但是只有無線滑鼠鍵盤，而且就算沒開也有。手機等無線設備都沒有藍牙! 機上盒之類的也沒有無線網路或藍牙!)
20180702
但是此時WIFI燈並不會閃爍! 難道說其實只是統計圖表有問題?
20180702
改成一個沒用過的WIFI密碼，還是會一直接收到，不知道是甚麼的封包!
20180710
突然覺得，該不會另設DNS就會比較快的原因(包含之前1703版本?時，無法自動取得IPv6DNS)，是因為原本是DHCP proxy，040gw還要負責DNS proxy? (因為區域網路中會顯示DNS是192.168.1.1)
另設DNS是指，在網路上查詢到的，進階設定-LAN設定，CHROME瀏覽器F12，點選右方視窗左上角，再點選DHCP Subnet Mask 的最後一欄，右方視窗中，有兩個display:none，刪除後，可見，原本一個是192.168.1.1 另一個是空白。 改成想要的DNS (只影響IPv4的)，包含HINET本身，似乎都會變快! (如果使用Hinet 本身，應該就跟把DHCP Proxy 改成DHCP relay一樣。)