Failed to send 300 byte long packet over fallback interface.

[Simon Hobson]

kevinmsmith22 <kevinmsmith22 at roadrunner.com> wrote:

> Listers,
>   I recently started getting this error in my log. It doesnt seem to be
> be causing and major malfunctions yet, but I dont like random errors.
> This only seems to pop up with after a static address is assigned, not
> sure if thats related.
> 
> FYI I have googled the heck out of this, with only issues found no solutions, that Russian site looked promising, but I dont understand cyrillic.
> ---
> Heres an exerpt of the /var/log/dhcpd.log:
> Jul  4 15:50:26 server dhcpd: DHCPINFORM from 10.0.0.8 via eth1
> Jul  4 15:50:26 server dhcpd: DHCPINFORM from 10.0.0.8 via eth1
> Jul  4 15:50:26 server dhcpd: DHCPACK to 10.0.0.8 (deleted) via eth1
> Jul  4 15:50:26 server dhcpd: DHCPACK to 10.0.0.8 (deleted) via eth1
> Jul  4 15:50:26 server dhcpd: send_packet: Operation not permitted
> Jul  4 15:50:26 server dhcpd: dhcp.c:1324: Failed to send 300 byte long
> packet over fallback interface.Jul  4 16:18:54 server dhcpd: DHCPREQUEST
> for 10.0.0.21 from e4:25:e7:08:2a:2a via eth1

A quick look suggests that may be a result of too restrictive firewall (iptables) rules. Note that in the logs you've osted, it's only the response to the Inform packets that can't be sent. The Ack to the Request may have been sent via the raw sockets layer depending on the client state - thus bypassing iptables rules.

> Jul  4 16:18:54 server dhcpd: DHCPACK on 10.0.0.21 to  via eth1
> Jul  4 16:18:54 server dhcpd: DHCPACK on 10.0.0.21 to  via eth1



> Also note its seems to be giving out 2 IP'S to the same client...Can I
> assume the error is caused by one of the packets being rejected?

No, you can't assume that.


> DHCPD.CONF


> interfaces="eth1";

This isn't valid for dhcpd.conf - it's a command line parameter (though most distros allow it to be specified in a config file such as /etc/default/isc-dhcp-server.

> option subnet-mask 255.255.255.192;
> option broadcast-address 10.0.0.63;
> option routers 10.0.0.1;

I wouldn't specify these in the global scope, the only place they make sense is within a subnet. and two of them will be different for every subnet. IIRC subnet mask will be calculated automagically anyway.

> 
> 
> authoritative;
> default-lease-time 604800;
> 
> subnet 10.0.0.0 netmask 255.255.255.192 {
> allow-known-clients;
> option routers 10.0.0.1;
> 
> class "DirectTV" {
> match hardware;
> }
> subclass "DirectTV" 1:60:02:b4:cd:b7:49;#LR
> subclass "DirectTV" 1:70:85:c6:ea:7c:1c;#MBR
> subclass "DirectTV" 1:70:85:c6:ea:7c:51;#BR
> subclass "DirectTV" 1:70:85:c6:ea:7c:b9;#JR
> 
> 
> 		pool{
> 		allow members of "DirectTV";
> 		range 10.0.0.33 10.0.0.37;	
> 		allow known-clients;	
> 		default-lease-time 604800; #one_week
> }
> 		pool{
> 		range 10.0.0.46 10.0.0.50;
> 		default-lease-time 600; #10_minutes
> 		max-lease-time 1200;
> 		deny known clients;
> }

As far as i can see, you have declared your class within the subnet - move it to the global scope.

> Assigned Addresses follow.

Assuming this means a bunch of host statements with fixed addresses, these would also appear to be defined witin the subnet - again move them out to the global scope. Certainly host declaration, and IIRC classes, are global in scope no mater where they are defined - but if not defined in the global scope can cause some "interesting" inheritance issues that are very very unlikely to be what you want.

I note that neither of the addresses in your logs are within the pools - so does the host match two (or more) fixed-address statements ? Either two host statements, or one host statement with two addresses defined.