#12654 HIGH Not Tri: Unexpected IP address change

[Zarro Boogs per Child]

#12654: Unexpected IP address change
--------------------------------+-------------------------------------------
           Reporter:  wad       |       Owner:  shep         
               Type:  defect    |      Status:  new          
           Priority:  high      |   Milestone:  Not Triaged  
          Component:  wireless  |     Version:  not specified
         Resolution:            |    Keywords:  XO-4 WLAN    
        Next_action:  diagnose  |    Verified:  0            
Deployment_affected:            |   Blockedby:               
           Blocking:            |  
--------------------------------+-------------------------------------------

Comment(by pgf):

 Replying to [comment:9 wad]:

 > And then the problem happens:
 >
 >  Apr 10 02:20:20 cerberus dhcpd: DHCPDISCOVER from 20:16:d8:1e:89:5f via
 eth1
 >  Apr 10 02:20:20 cerberus dhcpd: Abandoning IP address 172.24.0.230:
 pinged before offer
 >  Apr 10 02:20:42 cerberus dhcpd: DHCPDISCOVER from 20:16:d8:1e:89:5f via
 eth1
 >  Apr 10 02:20:43 cerberus dhcpd: DHCPOFFER on 172.24.0.232 to
 20:16:d8:1e:89:5f via eth1
 >  Apr 10 02:20:44 cerberus dhcpd: DHCPREQUEST for 172.24.0.232
 (172.24.0.1) from 20:16:d8:1e:89:5f via eth1
 >  Apr 10 02:20:44 cerberus dhcpd: DHCPACK on 172.24.0.232 to
 20:16:d8:1e:89:5f via eth1

 here's the crux, i think:  if the client still has the address, then it
 shouldn't be doing a DHCPDISCOVER.  if it doesn't still have the address,
 then it shouldn't be responding to the ping.

 of course, if it was some other client that responded to the ping
 (unlikely, IMHO), then the server is doing the right thing.  it's too bad
 that the MAC address of the ping responder isn't logged.  (from a network
 management perspective, it should be, since from the server's POV it's a
 rogue client that you might want to track down.)

-- 
Ticket URL: <http://dev.laptop.org/ticket/12654#comment:10>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system