LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 07-26-2015, 01:43 PM   #1
spikeygg
Member
 
Registered: Dec 2004
Location: America
Distribution: Ubuntu
Posts: 42

Rep: Reputation: 0
Question dhcpd complains "Failed to send 300 byte long packet over fallback interface."


I'm getting these messages in my /var/log/syslog occasionally. They happen immediately after the DHCPACK but sometimes the DHCPACK happens and the error messages don't appear.

Code:
Jul 26 08:16:57 routeitx dhcpd: DHCPINFORM from 192.168.0.12 via eth0
Jul 26 08:16:57 routeitx dhcpd: DHCPINFORM from 192.168.0.12 via eth0
Jul 26 08:16:57 routeitx dhcpd: DHCPACK to 192.168.0.12 (6c:f0:49:e1:78:21) via eth0
Jul 26 08:16:57 routeitx dhcpd: DHCPACK to 192.168.0.12 (6c:f0:49:e1:78:21) via eth0
Jul 26 08:16:57 routeitx dhcpd: send_packet: Operation not permitted
Jul 26 08:16:57 routeitx dhcpd: dhcp.c:1324: Failed to send 300 byte long packet over fallback interface.
another instance:

Code:
Jul 26 08:24:44 routeitx dhcpd: DHCPINFORM from 192.168.0.11 via eth0
Jul 26 08:24:44 routeitx dhcpd: DHCPINFORM from 192.168.0.11 via eth0
Jul 26 08:24:44 routeitx dhcpd: DHCPACK to 192.168.0.11 (1c:6f:65:d5:5e:c6) via eth0
Jul 26 08:24:44 routeitx dhcpd: DHCPACK to 192.168.0.11 (1c:6f:65:d5:5e:c6) via eth0
Jul 26 08:24:44 routeitx dhcpd: send_packet: Operation not permitted
Jul 26 08:24:44 routeitx dhcpd: dhcp.c:1324: Failed to send 300 byte long packet over fallback interface.
I've done some googling and most people suggest iptables is too strict but I have already opened both 67 and 68. These are the first rules on the INPUT and OUTPUT chains.

$IPTABLES -I INPUT -i $INTIF -p udp --sport 67:68 --dport 67:68 -j ACCEPT
$IPTABLES -I OUTPUT -o $INTIF -p udp --sport 67:68 --dport 67:68 -j ACCEPT

Code:
> sudo iptables -nvxL INPUT |head -n 3
Chain INPUT (policy DROP 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
     110    36431 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp spts:67:68 dpts:67:68
> sudo iptables -nvxL OUTPUT |head -n 3
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
     137    44936 ACCEPT     udp  --  *      eth0    0.0.0.0/0            0.0.0.0/0            udp spts:67:68 dpts:67:68
>
I have also enabled "complain mode" in apparmor for the dhcpd process to try to get more detail on this error but nothing additional appears in the log.

Anyone know how to troubleshoot this?

Thanks,
-Greg
 
Old 07-27-2015, 05:56 AM   #2
zhjim
Senior Member
 
Registered: Oct 2004
Distribution: Debian Squeeze x86_64
Posts: 1,748
Blog Entries: 11

Rep: Reputation: 233Reputation: 233Reputation: 233
Most tutorials about iptables include an allow stanca for the lo interface. Also this does not explain why it sometimes goes through lo and sometimes goes elseway.
To get rid of the error add
Code:
iptables -I INPUT 1 -i lo -d 127.0.0.1 -j ACCEPT
iptables -I OUTPUT 1 -o lo -s 127.0.0.1 -j ACCEPT
to your iptables.

To find out what is happeing install tcpdump and take a capture of the traffic. Or maybe dchp tries to update the dns record (if you have it installed on the same machine) and is not allowed though. Check your config of dhcp.
 
Old 07-28-2015, 12:26 AM   #3
spikeygg
Member
 
Registered: Dec 2004
Location: America
Distribution: Ubuntu
Posts: 42

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by zhjim View Post
Most tutorials about iptables include an allow stanca for the lo interface. Also this does not explain why it sometimes goes through lo and sometimes goes elseway.
To get rid of the error add
Code:
iptables -I INPUT 1 -i lo -d 127.0.0.1 -j ACCEPT
iptables -I OUTPUT 1 -o lo -s 127.0.0.1 -j ACCEPT
to your iptables.

To find out what is happeing install tcpdump and take a capture of the traffic. Or maybe dchp tries to update the dns record (if you have it installed on the same machine) and is not allowed though. Check your config of dhcp.
Thanks Zhjim but I've already got those in as the second item in my rules:

Code:
> sudo iptables -nvxL OUTPUT |head -n 4
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 ACCEPT     udp  --  *      eth0    0.0.0.0/0            0.0.0.0/0            udp spts:67:68 dpts:67:68
       0        0 ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0           
> sudo iptables -nvxL INPUT |head -n 4
Chain INPUT (policy DROP 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp spts:67:68 dpts:67:68
       0        0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
>
 
Old 07-30-2015, 03:05 AM   #4
zhjim
Senior Member
 
Registered: Oct 2004
Distribution: Debian Squeeze x86_64
Posts: 1,748
Blog Entries: 11

Rep: Reputation: 233Reputation: 233Reputation: 233
Actually i misread the error message. Its fallback interface not like i read loopback interface. A search on this came up with the vague information that the fallback interface is the one with an actually ip address (server-side). Most dhcp traffic is "broadcast" as you well known.

Coming to think do you have any icmp blocks in your iptables? If i recall correctly there is an dhcpd option to ping the ip that would be used as a lease. Maybe check your dhcpd.conf for this.
To get a hold of this maybe fire up tcpdump and just log the packets.
 
Old 07-30-2015, 08:32 AM   #5
spikeygg
Member
 
Registered: Dec 2004
Location: America
Distribution: Ubuntu
Posts: 42

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by zhjim View Post
Actually i misread the error message. Its fallback interface not like i read loopback interface. A search on this came up with the vague information that the fallback interface is the one with an actually ip address (server-side). Most dhcp traffic is "broadcast" as you well known.

Coming to think do you have any icmp blocks in your iptables? If i recall correctly there is an dhcpd option to ping the ip that would be used as a lease. Maybe check your dhcpd.conf for this.
To get a hold of this maybe fire up tcpdump and just log the packets.
I do have icmp blocks in my iptables but they are only on the external interface. The internal one is pretty much wide open.

Are you talking about the "ping-check" option inside of dhcpd.conf? I have not used that before and I don't see it in my dhcpd.conf file. Do you know if it is enabled by default? I couldn't find the answer to this in the manual.

I'll have to give the tcpdump a try, I've never used that before, do you suggest any specific switches to help narrow it down? It appears to be a pretty powerful debug tool.

Thanks for the help zhjim.
-Greg
 
Old 07-31-2015, 03:06 AM   #6
zhjim
Senior Member
 
Registered: Oct 2004
Distribution: Debian Squeeze x86_64
Posts: 1,748
Blog Entries: 11

Rep: Reputation: 233Reputation: 233Reputation: 233
Did you check /etc/default/dhcpd? file for the ping-check option? I don't think its enabled by default. But maybe set it to no explicitly?
Its just that I encountered "Operation not permitted" everytime that i block icmp stuff with iptables.

You can narrow down the interface tcpdump works on with the -i switch. I'd say at least include lo and your LAN interface. Depending on your traffic numbers you could record all of it to a file. And later narrow it even further giving the dhcp ports. Its a thin line between recording too much and not enough. Thus if you have some low traffic times I would try it then. Definitely use -s96 to only capture the first 96bytes of each packages. That should include all headers of ip+tcp|udp.

Something like this
Quote:
tcpdump -i eth0 -i lo -s96 -w your.log
But maybe iptables can save the day. Theres an process and owner option to it.
Quote:
iptables -I OUTPUT 1 -m owner --gid-owner $dhcp -j LOG --log-ip-options --log-prefix "DHCP: "
Might have to load a module for this. And put the right gid for the dhcpd server in.

If you can somehow reproduce the error message you might run dhcp in debug mode but yeah...
 
Old 11-13-2015, 09:00 AM   #7
Carlos Medeiros
LQ Newbie
 
Registered: Nov 2015
Posts: 1

Rep: Reputation: Disabled
I solved using the following!


-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -p udp -m udp --sport 137 --dport 137 -j ACCEPT
-A INPUT -p udp -m udp --sport 68 --dport 67 -j ACCEPT
 
Old 01-12-2016, 08:18 PM   #8
pmackinney
LQ Newbie
 
Registered: Jan 2014
Posts: 6

Rep: Reputation: Disabled
Carlos, if you care to share the source of your answer, I'd be interested. I haven't been able to find a working solution yet.

My dhcp server is running iptables.
It allows all traffic on the loopback.
It allows all icmp, tcp, and udp on the local subnet

Code:
-A INPUT -p icmp -s 192.168.1.0/24 -j ACCEPT
-A INPUT -p udp -s 192.168.1.0/24 -j ACCEPT
-A INPUT -p tcp -s 192.168.1.0/24 -j ACCEPT
This should cover every thing you're doing, right?

Last edited by pmackinney; 01-12-2016 at 08:23 PM. Reason: total rewrite
 
Old 05-02-2017, 12:06 PM   #9
enno.vet
LQ Newbie
 
Registered: May 2008
Posts: 5

Rep: Reputation: 0
Don't know if it's still of interest after such a long time. The point here however is to let the packet OUT not in. Does one need dhclient? If so, one should add a stanza like
Code:
iptables -A OUTPUT -p udp --sport 1024:65535 --dport 67 -j ACCEPT
iptables -A OUTPUT -p udp --sport 68 --dport 67 -j ACCEPT
Of course this has to be root¹). And if netfilter is compiled as modules add -m <proto>, too.
Rationale: dhclient (or similar agent) is configured to renew a dhcp lease, alas iptables doesn't let her connect to the outside's port 67 -- via which port? The documentation on bootp and dhcp unfortunately is not too clear about ports involved. Basically rfc-951 defines 67 as receiving server port and 68 as receiving client port for bootp, but does not define the originial source port. Hence the first sport stanza above. One could of course check with a tool like tcpdump what actually is going on, or search the source files of dhclient blah blah woof woof... if one had the time and energy.

So far dhclient can send its message out and don't clubber your logfiles anymore, but she won't get an answer (which doesn't necessarily matter AFAIK).

If you need the full DHCP thing you would of course have to open up the ports back inside to your box like so:
Code:
iptables -A INPUT -p udp --sport 67 --dport 68 -j ACCEPT
iptables -A INPUT -p udp --sport 1024:65535 --dport 68 -j ACCEPT
Again, the rfc does not define the answering server port.

And remember, if an error turns up in linux log files with "Operation not permitted" it is most often due to the packet filter.

Brgds, e.

¹) Possibly you could add -p tcp, as /etc/services claims the bootp ports for both protocols, even though due to the nature of the dhcp protocol tcp should be irrelevant.
 
  


Reply

Tags
dhcp server, error message, failed, network interface


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] "net rpc" "failed to connect to ipc$ share on" or "unable to find a suitable server" larieu Linux - General 0 11-09-2014 01:45 AM
gvim complains that it "failed to create input context" javascriptninja Linux - Software 2 09-05-2014 09:15 AM
scp command "failed to read binary packet data!" noochi01 Linux - Newbie 6 01-31-2014 01:39 PM
dhclient problem "interface name too long (is 22)" Cyberman Linux - Wireless Networking 1 08-07-2008 07:55 PM
Virtual PC 2004 and VWware Workstation - "interface eth0 [failed]" abijahboaz Linux - Newbie 8 10-16-2004 08:53 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 03:26 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration