Bug 91075
| Summary: | dhcpd.conf.sample range contains broadcast | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <marie> |
| Component: | dhcp | Assignee: | Daniel Walsh <dwalsh> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-06-16 19:37:42 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Fixed in dhcp-3.0pl2-6.2.src.rpm Thanks, Dan |
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; T312461) Description of problem: /usr/share/doc/dhcp-3.0pl1/dhcpd.conf.sample contains the line "range dynamic-bootp 192.168.0.128 192.168.0.255;" as in this example, 192.168.0.255 is the broadcast address ("subnet 192.168.0.0 netmask 255.255.255.0"), dhcp shouldn't give this address to anybody, i.e., the range should be for example 192.168.0.128 192.168.0.254 normally, no client should request a broadcast address for himself, but i've heard of one case where a windows xp machine would do just that, resulting in the following log: May 16 17:45:30 linux dhcpd: DHCPREQUEST for 192.168.0.255 from aa:aa:aa:aa:aa:aa (host) via eth0 May 16 17:45:30 linux dhcpd: DHCPACK on 192.168.0.255 to aa:aa:aa:aa:aa:aa (host) via eth0 May 16 17:45:30 linux dhcpd: send_packet: Permission denied May 16 17:45:39 linux kernel: martian source 255.255.255.255 from 192.168.0.255, on dev eth0 the client requesting 192.168.0.255 won't get the address, but doesn't try for another one, either. as far as i can backtrack, this problem is already present in redhat 7.0 / dhcp- 2.0-12 Version-Release number of selected component (if applicable): dhcp-3.0pl1-26 How reproducible: Didn't try Additional info: