推 Schottky: 只是要當 bridge，開個 iptables 或 nftables 就好了 08/22 22:40
→ Schottky: 中間要截收封包做處理也沒問題 08/22 22:41
→ Schottky: 來源不是看 MAC Address 就好了嗎？ 08/22 22:43
※ 引述《Schottky (順風相送)》之銘言：
: ※ 引述《chigi ( )》之銘言：
: : 網路的話
: : 設備總共有三台，
: : eth0 eth1
: : PC1 <--------------> PC2 <----------------> PC3
: : IP: 192.168.1.200 192.168.1.105
: : 192.168.1.100 NA
: : 既然是bridge，其實PC2的eth0也可以不用IP
: : 試過不用IP，但是封包還是在那亂彈
: : 比較特別的是PC2的 ARP table
: : 192.168.1.200 <MAC> on eth0
: : 192.168.1.105 <MAC> on eth1
: : 192.168.1.105 <incomplete> on eth0 <====?????
: : 不過也有可能是程式亂跳讓系統誤以為那邊也有一台105，
: : 所以把ARP包往那邊丟 但是想當然耳，那邊什麼都沒有
: 我大概明白狀況了，
: promiscuous mode 本來就會收到本機所發出的 packet，判斷一下來源不要轉發即可，
: 畢竟會開 promiscuous 大部份狀況你會想同時收到本機其他 process 送出的 packet
: 印象中並沒有內建 promiscuous mode 禁收本機外送封包的功能。
這樣說起來，的確是..
promisc mode應該也要監看自己電腦其他process是否有丟東西出來
聽起來好絕望阿，有點難判斷來源呢..
如果不用promisc應該就沒辦法當bridge，
真苦惱
: 至於 APR table 的問題，我不是很確定原因，
其實他只要能當bridge，我也不太想管它(?
: 照理說
: 1. 無腦轉送 packet 的 bridge 應該不認得 APR protocol，
: 所以看 bridge 的 ARP table 也很奇怪
: 2. 目前看到的 ARP table 問題很可能是沒有正確回應 ARP 封包造成的
: 但同上，bridge 本來就不要求懂 ARP，他只要把 ARP forward 到另一邊就算盡責
: 3. 問題是你這台和真的 bridge 又有點不一樣，
: bridge 轉發時可不會更動來源 MAC Address
: 所以是不是得要 implement 到 IP 層，也就是 router 的層級才行
: 簡單講就是你要能回應 ARP/RARP 封包
其實是這樣 我也沒有要改動MAC，
而且我也沒有想要弄到router層級XD
所以才覺得這樣要搞定封包在那邊兩個socket中轉來轉去很苦惱
不然直接把自己mac的封包都drop掉，倒是蠻簡單的
因為照現在的寫法，就變成我只能跟後面固定的人收送封包，
因為他們的MAC我寫在filter裡
其他人的封包一來我就會爆炸 這樣這個bridge就太難用啦 哈哈
這樣都不知道怎麼改進了..寫個ip table嗎..
: 不過這也只是猜測，我沒有自己 implement 過 ARP
: 再說看你的動作模式還是比較像 bridge 的無腦轉發，
: 是不是不要理這個 ARP table 看起來不美觀的問題就好
沒錯 就是這樣 眼不見為淨XD
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.160.200.71 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1566376377.A.7E2.html