NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: dhcpcd failure



On Feb 21,  4:30pm, Roy Marples wrote:
} On 21/02/2019 16:18, triaxx wrote:
} > <cisco_syslog>
} > 3    2019/01/16 5:55:46 PM    info    udhcpd[1154]: sending OFFER to 
} > 255.255.255.255 with 192.168.0.11
} > 
} > <host_tcpdump>
} > 16:13:56.468169 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto 
} > UDP (17), length 576)
} >      192.168.0.1.bootps > 192.168.0.11.bootpc: [udp sum ok] BOOTP/DHCP, 
} > Reply, length 548, xid 0x66ec8de4, Flags [none] (0x0000)
} >        Your-IP 192.168.0.11
} >        Server-IP 192.168.0.1
} >        Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown)
} >        Vendor-rfc1048 Extensions
} >          Magic Cookie 0x63825363
} >          DHCP-Message Option 53, length 1: Offer
} >          Server-ID Option 54, length 4: 192.168.0.1
} >          Lease-Time Option 51, length 4: 86400
} >          Subnet-Mask Option 1, length 4: 255.255.255.0
} >          Default-Gateway Option 3, length 4: 192.168.0.1
} >          Domain-Name-Server Option 6, length 4: 192.168.0.1
} >          Domain-Name Option 15, length 11: "atlas.local"

     Can you do the tcpdump with "-e" to show the ethernet header.
I'm wondering if it's sending to the layer 2 broadcast address of
ff:ff:ff:ff:ff:ff?

} What cisco says it's doing and what it's actually doing are different.
} It's claiming sending offer of 192.168.0.11 to 255.255.255.255 (which is 
} correct) but in reality it's unicasting to 192.168.0.11.
} 
} I don't see how any DHCP client can work with that.

     Yet, clearly it does, so there must be something else going
on that we haven't figured out yet.

} You might try getting dhcpcd to send the broadcast option using the -J 
} flag. That's non standard though and I doubt it will fix the issue.
} 
}-- End of excerpt from Roy Marples


Home | Main Index | Thread Index | Old Index