Joe wrote: > Pol Hallen wrote: > > Sometimes I see inside the arp table (from wlan0) a strange IP like: > > > > 10.168.245.246 or similar > > > > what does it mean? > > Could be a PC with static IP goes inside my lan (via wireless) or > > what? > > Yes. A WAP may relay packets before it knows that the sender is > authenticated, as many authentication mechanisms involve TCP exchanges > and therefore need a valid local IP address. Your DHCP logs may well > show addresses being handed out to these outsiders, but presumably your > other logs do not show anyone actually being authenticated at the time > you see these addresses. Not quite. > I don't believe that wireless encryption methods are relevant at the > DHCP level, Exactly! That is what usually happens in this case. > so even though your WAP uses WPA2 and a long password, which will > stop anyone being authenticated, this doesn't affect DHCP > negotiations. Eactly correct. The WiFi encryption is a separate layer. This does not affect anything IP (as in TCP/IP but also applies to TCP/UDP and TCP/ICMP and so forth) related. The first layer is the WPA/WPA2. That controls access to the WiFi. If the client device connects then they are on the network. And that includes any configuration of IP addresses they may or may not have at that moment. If they are configured for a static IP then they will use that static IP configuration. More often it is a device with DHCP but just woke up and is still using a previously assigned IP address from a different network. > Let's put it this way: in a network belonging to one of my clients, > I often see DHCP addresses being handed out to machines that do not > belong in the network, but there is never a sign of any further use > of those addresses. There is certainly a strong WPA2 passphrase set > there. In a busy small company environment with a lot of people coming and going I also often see foreign IP addresses immediately after a device connects to the network. I think this is a bug in the client device configuration. It shouldn't be emitting packets before it has negotiated a valid LAN address by DHCP. But many devices do. At least it appears that way. You can track down the device by crosschecking the ethernet address with the address assigned by dhcp and logged to /var/log/syslog. But tracking down random people's hardware just isn't productive. You wouldn't be able to fix them anyway. > I believe that during DHCP negotiations, the addresses 0.0.0.0 and > 255.255.255.255 can be used, but I don't think there is much checking, > as DHCP traffic works on MAC addresses until an IP address is assigned. The client will broadcast a dhcp request on 255.255.255.255 the all ones broadcast address. In that packet if the device had a previous IP assignment it will request to be assigned the same address it had before. The dhcp server may or may not assign the same address. Certainly if the address came from a different network then it will not be able to assign the requested address. The client requesting its previous address means that you will also see a lot of foreign addresses in the syslog from the dhcp server. Bob
Attachment:
signature.asc
Description: Digital signature