> Hello, > > I get a LOT of the following in my syslog: > > Jan 16 23:27:38 firewall dhcpd: DHCPREQUEST for 192.168.1.2 > from=20 00:80:c6:f8:62:c6 via eth1 Jan 16 23:27:38 firewall > dhcpd: DHCPACK on 192.168.1.2 to 00:80:c6:f8:62:c6= =20 via > eth1 Jan 16 23:27:38 firewall dhcpd: send_packet: Operation > not permitted Jan 16 23:27:59 firewall dhcpd: DHCPREQUEST for > 192.168.1.1 from=20 00:e0:29:2c:ba:6d via eth1 Jan 16 > 23:27:59 firewall dhcpd: DHCPACK on 192.168.1.1 to > 00:e0:29:2c:ba:6d= =20 via eth1 Jan 16 23:27:59 firewall > dhcpd: send_packet: Operation not permitted Jan 16 23:28:42 > firewall dhcpd: DHCPREQUEST for 192.168.1.2 from=20 > 00:80:c6:f8:62:c6 via eth1 Jan 16 23:28:42 firewall dhcpd: > DHCPACK on 192.168.1.2 to 00:80:c6:f8:62:c6= =20 via eth1 Jan > 16 23:28:42 firewall dhcpd: send_packet: Operation not permitted > > I suppose that I could simply change the two target machines > to use static = IPs=20 but I'd prefer not to do that, since > DHCP is more portable for various=20 network configurations. > > However my logs are all filled up with this and I'd really > like it to stop.= =20 The DHCPD package offers no visible > options for logging. The DHCPD man pag= es=20 do mention a > little bit about logging: the -d option to log to stdout. > Thi= s=20 means that there is one apparent way to stop logging: > > 1) Edit init.d script > 2) In the line to start dhcpd, type: "dhcpd -d 2&>1 > /dev/null" > > but that doesn't seem so nice. > > Any other ideas? Thank you, > > =2D-=20 > =2D- Arcana
You don't say what LEAF variant you are running. However, I saw this problem with my Bering box (early version, don't recall which one, probably RC2 or 3). Googling suggested that this was a firewall issue so I played about with that for a while - finally got it to stop by adjusting the Shorewall rules to ACCEPT UDP 67 and 68 between the Bering box and my LAN. The workstation that was operating through all the experimentation was trying to renew the IP every 64 seconds, and the message you see was being logged in daemon.log each time. Made for long logs. I tried UDP 67 first without effect, then tried 68 next. The next time the workstation made the attempt the log showed it to be successful and I haven't seen anything from this workstation since except after the normal interval. Odd that an IP is obtained at boot, but the renewal had issues without this rule change... Does anyone know if the original request is dealt with on different ports than the renewal? Brock ------------------------------------------------------- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
