| 1 |
> > The main correlation I've seen so far is with dhcpcd. Sometimes at my |
| 2 |
> > work I get a 192. IP (which doesn't work), and other times I get a |
| 3 |
> > 133. IP (which is correct). In fact, sometimes dhcp is giving me an |
| 4 |
> > IP address and resolv.conf related to a university I was visiting like |
| 5 |
> > a month ago. |
| 6 |
> |
| 7 |
> It sounds like someone at your work might be (accidentally) running a |
| 8 |
> rogue DHCP server... |
| 9 |
> |
| 10 |
> |
| 11 |
For the 192 address - yeah, someone has probably plugged a WLAN or ADSL |
| 12 |
router into the local network, and other people will be have the same |
| 13 |
problem. If they were purposely running a rogue DHCP server to perform a Man |
| 14 |
In the Middle attack you wouldn't notice any connectivity problems (assuming |
| 15 |
they set it up correctly). |
| 16 |
|
| 17 |
When dhcpcd fails to get a response from a DHCP server it will typically |
| 18 |
fall back to Zeroconf/RFC3927 behavior and assign a a169.245.x.y address. |
| 19 |
|
| 20 |
Getting the university address is very odd. AFAIK dhcpcd has no function to |
| 21 |
fall back to the address from an expired lease. |
| 22 |
|
| 23 |
Grep your logs for dhcpcd and post the result. |
Archives