Hello all, I have an internal fileserver that times out when attempting to get an IP from the dhcp server on startup.
From the log of the dhcp server:
warhead dhcpd: DHCPDISCOVER from 00:60:67:22:bf:2d via eth1 warhead dhcpd: DHCPOFFER on 192.168.1.4 to 00:60:67:22:bf:2d via eth1 warhead kernel: Packet log: input DENY eth1 PROTO=17 192.168.1.1:67 255.255.255.255:68 L=328 S=0x00 I=58791 F=0x0000 T=64 (#6) A Why is the client host sending a broadcast packet to the bootp port? (I think this is what is happening). It is not configured to use bootp. Even when the firewall is config'd to allow bootp, the problem persists due to the source address of the packet. Any Ideas?? Thanks, Gabriel Rivera
On Wed, Apr 25, 2001 at 12:57:56PM -0500, gabriel rivera wrote:
Hello all,
I have an internal fileserver that times out when attempting to get an IP from the dhcp server on startup.
From the log of the dhcp server:
warhead dhcpd: DHCPDISCOVER from 00:60:67:22:bf:2d via eth1 warhead dhcpd: DHCPOFFER on 192.168.1.4 to 00:60:67:22:bf:2d via eth1
But that's fine... why do you think dhcp is 'prevented'? Is it followed by a DHCPREQUEST and DHCPACK?
warhead kernel: Packet log: input DENY eth1 PROTO=17 192.168.1.1:67 255.255.255.255:68 L=328 S=0x00 I=58791 F=0x0000 T=64 (#6) A
Which host is 192.168.1.1?
Why is the client host sending a broadcast packet to the bootp port? (I think this is what is happening). It is not configured to use bootp.
Because dhcp and bootp use the same (bootp) ports. If you are concerned about the fact it is broadcast, that's the way it is because that's how a client finds a server. Subsequent (renewal) requests will be sent unicast by the client.
Even when the firewall is config'd to allow bootp, the problem persists due to the source address of the packet.
Don't understand what you mean here... what exactly is the problem? Gruesse, Peter -- +49-911-74053-340 ---------------------------------------------------------------------- Don't Be Jealous Of My Big Endian
Gabriel;; I do remember that there is a variable for providing DHCP services in the script, you may also look at which Inteface if you have two or more DHCP requests are being handled on.... Regards, Jon On Wed, 25 Apr 2001, gabriel rivera wrote:
Hello all,
I have an internal fileserver that times out when attempting to get an IP from the dhcp server on startup.
From the log of the dhcp server:
warhead dhcpd: DHCPDISCOVER from 00:60:67:22:bf:2d via eth1 warhead dhcpd: DHCPOFFER on 192.168.1.4 to 00:60:67:22:bf:2d via eth1
warhead kernel: Packet log: input DENY eth1 PROTO=17 192.168.1.1:67 255.255.255.255:68 L=328 S=0x00 I=58791 F=0x0000 T=64 (#6) A
Why is the client host sending a broadcast packet to the bootp port? (I think this is what is happening). It is not configured to use bootp.
Even when the firewall is config'd to allow bootp, the problem persists due to the source address of the packet.
Any Ideas??
Thanks,
Gabriel Rivera
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
On Wednesday 25 April 2001 19:57, gabriel rivera wrote:
I have an internal fileserver that times out when attempting to get an IP from the dhcp server on startup.
From the log of the dhcp server:
warhead dhcpd: DHCPDISCOVER from 00:60:67:22:bf:2d via eth1 warhead dhcpd: DHCPOFFER on 192.168.1.4 to 00:60:67:22:bf:2d via eth1
warhead kernel: Packet log: input DENY eth1 PROTO=17 192.168.1.1:67 255.255.255.255:68 L=328 S=0x00 I=58791 F=0x0000 T=64 (#6) A
Why is the client host sending a broadcast packet to the bootp port? (I think this is what is happening). It is not configured to use bootp.
Bootp and dhcp use the same port. If the client had no previous lease, it'd be even worse; then you would see a packet from 0.0.0.0:67 -> 255.255.255.255:68 (remember, a dhcp client can have no notion about the network its on, so it MUST work this way. You'll just have to allow all traffic from port 67 to port 68, before it would be dropped by some sanity-check rule(s) like source-spoofing etc. At least, I think so.
Even when the firewall is config'd to allow bootp, the problem persists due to the source address of the packet.
Change the order of the rules...? Greetings, Maarten
participants (4)
-
gabriel rivera -
Maarten van den Berg -
marsaro＠interearth.com -
Peter Poeml