고지 사항: Pi 3에서 Raspbian Light를 사용하는 Linux의 새로운 기능입니다. SSH 액세스만 가능합니다.
ping/arp를 사용하여 mac 주소를 찾으려고 합니다.
ping 192.168.1.7
arp 192.168.1.7
다음을 반환합니다.
Address HWtype HWaddress Flags Mask Iface
192.168.1.7 ether 02:0f:b5:ed:9e:5c C eth0
HWaddress는 Windows에 표시되는 Mac 주소와 다릅니다.
ping 192.168.1.7
arp -a 192.168.1.7
그 결과는 다음과 같습니다.
Internet Address Physical Address Type
192.168.1.7 c0-ee-fb-ed-9e-5c dynamic
네트워크 토폴로지
Pi on cable(.27) → 스위치 on cable → 라우터(.1)
Phone on wifi(.7) → 라우터(.1)
Windows on wifi(.30) → 라우터(.1)
Pi가 동일한 Mac을 반환하도록 하려면 어떻게 해야 합니까?
참고: 'vendor' 부분이 다른 것 같습니다. 그럼 '거의' 맞나요?
답변1
최선의 추측: RaspPi는 LAN을 통해 라우터에 연결되어 있고 "대상" 전화와 Windows PC는 WLAN을 통해 연결되어 있습니다. 이는 휴대폰과 Windows PC가 동일한 세그먼트에 있고 ARP가 의도한 대로 작동하는 동안 일반적으로 LAN과 WLAN은 동일한 세그먼트에 있지 않음을 의미합니다.
이후 그들은~인 것 같다동일한 세그먼트(동일한 /24 접두사)에 있으려면 라우터가 MAC NAT를 통해 작동하도록 하는 몇 가지 멋진 작업을 수행한다고 가정합니다.ebtables. "스푸핑된" MAC 주소는 공급업체 접두사만 다르고 공급업체 접두사는 유효하지 않은 것 같다는 사실도 이를 나타냅니다.
LAN(케이블)을 통해 Windows PC를 라우터에 연결하여 이를 테스트할 수 있으며, 이 경우 어떤 MAC 주소가 보고되는지 확인할 수 있습니다.
이를 테스트하는 또 다른 방법은 라우터에 대한 루트 액세스 권한을 얻고 내부에서 무슨 일이 일어나고 있는지 살펴보는 것입니다.
편집하다
이 추측이 맞다면, 그것은 순전히라우터문제는 Linux와 Windows의 문제가 아닙니다. 또한 Windows PC가 LAN을 통해 연결되어 있고 대상 전화가 WLAN을 통해 연결된 경우 Windows는 "잘못된" MAC 주소를 찾습니다.모든WLAN을 통해 연결된 장치는 "잘못된" MAC 주소를 보게 됩니다.모든LAN을 통해 연결된 장치 또는 그 반대의 경우.
그리고 라우터를 비활성화하도록 구성하지 않는 한 "해결"할 수 없습니다. 이 경우 LAN과 WLAN의 서브넷이 다를 수 있으며 LAN의 RaspPi는 WLAN에 있는 모든 장치의 MAC을 볼 수 없습니다.조금도(그 반대도 마찬가지) 하지만 서로 통신할 수는 있습니다.
이것이 바로 네트워킹이 작동하는 방식입니다.
문제는 애초에 왜 "올바른" MAC 주소가 필요한가입니다. 그럴 필요는 없습니다.
답변2
이 arp명령은 rpi 네트워크 인터페이스의 올바른 mac 주소를 제공하며 다음과 같이 확인할 수 있습니다.
ssh [email protected]
sudo cat /sys/class/net/eth0/address
c0-ee-fb-ed-9e-5cOne Plus 휴대폰의 Mac 주소입니다 .