DHCP reply not leaving machine
Hi, after multiple recompilation of FR (both version 2.2 and 3.0.1) i was not able to configure DHCP server so that clients would get IPs. I am currently testing on ubuntu 12.04.3 server which has connected Ubuntu 12.04 desktop version laptop on eth1 trying to get IP. I see multiple requests comming to server but no reply reaches the client (nor ethernet card). FR is built from source and following this configuration http://wiki.freeradius.org/guide/dhcp-for-static-ip-allocation (with exception of using mac2ip for IP filetable). Here is relevant info on server: eth1: inet addr:192.168.0.1 dhcp config: server dhcp { listen { ipaddr = 255.255.255.255 port = 67 type = dhcp interface = eth1 dhcp DHCP-Discover { update reply { DHCP-Message-Type = DHCP-Offer } # The contents here are invented. Change them! update reply { DHCP-Domain-Name-Server = 192.168.0.1 DHCP-Domain-Name-Server = 193.2.1.66 DHCP-Subnet-Mask = 255.255.255.0 DHCP-Router-Address = 192.168.0.1 DHCP-IP-Address-Lease-Time = 86400 DHCP-DHCP-Server-Identifier = 192.168.0.1 } mac2ip ok } dhcp DHCP-Request { update reply { DHCP-Message-Type = DHCP-Ack } # The contents here are invented. Change them! update reply { DHCP-Domain-Name-Server = 192.168.0.1 DHCP-Domain-Name-Server = 193.2.1.66 DHCP-Subnet-Mask = 255.255.255.0 DHCP-Router-Address = 192.168.0.1 DHCP-IP-Address-Lease-Time = 86400 DHCP-DHCP-Server-Identifier = 192.168.0.1 } mac2ip ok } dhcp { # send a DHCP NAK. reject } } radiusd -X output is here: http://pastebin.com/raw.php?i=yY1aNf6v i have used tcpdump to check port 67 and 68, but only requests come in, no reply is released to ethernet card. Any suggestions? Regards, Rok
Rok Kosir wrote:
after multiple recompilation of FR (both version 2.2 and 3.0.1) i was not able to configure DHCP server so that clients would get IPs.
Oops...
radiusd -X output is here: http://pastebin.com/raw.php?i=yY1aNf6v
Yup, that's wrong.
i have used tcpdump to check port 67 and 68, but only requests come in, no reply is released to ethernet card.
Any suggestions?
Do a "git pull" on "master". I've pushed some fixes. I'm not sure what's going on in 2.2.x, I haven't had time to look at that yet. Alan DeKok.
On 10/23/2013 08:47 PM, freeradius-users-request@lists.freeradius.org wrote:
radiusd -X output is here:http://pastebin.com/raw.php?i=yY1aNf6v Yup, that's wrong.
i have used tcpdump to check port 67 and 68, but only requests come in, no reply is released to ethernet card.
Any suggestions? Do a "git pull" on "master". I've pushed some fixes.
I'm not sure what's going on in 2.2.x, I haven't had time to look at that yet.
Doesn't seem to change anything, tried on two different machines, maybe it's just ubuntu and I need to try other system. new log of radius -X : http://pastebin.com/raw.php?i=0usgN44Z
Alan DeKok.
Br, Rok
Rok Kosir wrote:
Doesn't seem to change anything, tried on two different machines, maybe it's just ubuntu and I need to try other system.
It seems to work for me...
new log of radius -X : http://pastebin.com/raw.php?i=0usgN44Z
The server *thinks* it's sending the packet. Is there a FW rule preventing DHCP from leaving the box? Can you use gdb to track down what's going on? Maybe the send() call is silently failing? Alan DeKok.
On 10/25/2013 05:47 PM, freeradius-users-request@lists.freeradius.org wrote:
The server*thinks* it's sending the packet. Is there a FW rule preventing DHCP from leaving the box?
iptables are empty, i have completely removed ufw and apparmor, no change detected
Can you use gdb to track down what's going on? Maybe the send() call is silently failing?
when using gdb i once got this error: Sending DHCP-Offer of id 406a7a14 from 255.255.255.255:67 to 192.168.0.102:68 (5) Finished request 5. Waking up in 0.3 seconds. Waking up in 1.6 seconds. (3) Cleaning up request packet ID 3771922810 with timestamp +17 Waking up in 0.2 seconds. ASSERT FAILED src/main/process.c[498]: 0 == 1 Program received signal SIGABRT, Aborted. 0x00007ffff674b425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 The error doesn't happen always, so i'm not sure if it's connected to dhcp problem. i have tried different scenarios, direct cable connection, connection via switch, same result.. When I manually set IP on dhcp client machine it was able to ping/ssh the radius server. I have no idea what i could try next
On 10/28/2013 02:08 PM, Rok Kosir wrote:
On 10/25/2013 05:47 PM, freeradius-users-request@lists.freeradius.org wrote:
The server*thinks* it's sending the packet. Is there a FW rule preventing DHCP from leaving the box?
iptables are empty, i have completely removed ufw and apparmor, no change detected
Can you use gdb to track down what's going on? Maybe the send() call is silently failing?
when using gdb i once got this error:
Sending DHCP-Offer of id 406a7a14 from 255.255.255.255:67 to 192.168.0.102:68 (5) Finished request 5. Waking up in 0.3 seconds. Waking up in 1.6 seconds. (3) Cleaning up request packet ID 3771922810 with timestamp +17 Waking up in 0.2 seconds. ASSERT FAILED src/main/process.c[498]: 0 == 1
Program received signal SIGABRT, Aborted. 0x00007ffff674b425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
The error doesn't happen always, so i'm not sure if it's connected to dhcp problem. i have tried different scenarios, direct cable connection, connection via switch, same result.. When I manually set IP on dhcp client machine it was able to ping/ssh the radius server.
I have no idea what i could try next Ok, i think got correct debug now: http://pastebin.com/raw.php?i=f1umURzZ
Rok Kosir wrote:
when using gdb i once got this error:
As luck would have it, I just pushed a fix 5 minutes ago. Do a "git pull", and it should go away.
The error doesn't happen always, so i'm not sure if it's connected to dhcp problem.
Maybe...
i have tried different scenarios, direct cable connection, connection via switch, same result.. When I manually set IP on dhcp client machine it was able to ping/ssh the radius server.
I've been running tests myself. Virtual machines don't seem to work well for DHCP testing. Packets get randomly lost. A simple cross-over cable works best. I can get it to consistently reply, so that's a step. The next step is to bypass the normal socket code, and do the typical DHCP server thing of creating && sending raw packets. I may be able to get that in today. Alan DeKok.
On 28/10/13 13:28, Alan DeKok wrote:
The next step is to bypass the normal socket code, and do the typical DHCP server thing of creating && sending raw packets. I may be able to get that in today.
If you do add this, *please* leave it as an option, with normal UDP sockets there too. One of the most IRRITATING things about the ISC DHCP server (aside from it's crappy logging) is that it bypasses the OS IP stack - not only does this mean various tricks like policy routing don't work, but since the link-layer processing has to be hard-coded for each interface/link type, esoteric things (GRE, IP/IP) can't run an ISC dhcp listener. [One of the things I (eventually) want to use FR DHCP for is GRE tunnels.]
Phil Mayers wrote:
If you do add this, *please* leave it as an option, with normal UDP sockets there too.
Absolutely. If the server doesn't get broadcast packets, it should just do unicast UDP (from / to giaddr).
One of the most IRRITATING things about the ISC DHCP server (aside from it's crappy logging) is that it bypasses the OS IP stack - not only does this mean various tricks like policy routing don't work, but since the link-layer processing has to be hard-coded for each interface/link type, esoteric things (GRE, IP/IP) can't run an ISC dhcp listener.
Yes. It wouldn't be hard to do normal UDP sockets. But no... the ISC people are smarter than you. You don't need that! Alan DeKok.
Just installed another laptop with centos 6, built FR from git and i got same result.. It makes me wonder if i have my configuration correctly set, if anyone can confirm, here are my steps: - I did clean install of centos 6, installed required packages and built and installed freeradius from git - set IP on FR machine on eth0 to 192.168.10.1 with netmask 255.255.255.0 - cleared iptables and disabled selinux - added mac2ip to mods-enabled - created folder mods-config/passwd/ and edited file mac2ip with this content: 00:30:48:32:d7:5f,192.168.10.102 (this is the mac of ubuntu machine which is waiting for dhcp IP) - created file dhcp-static under sites-enabled with this content: server dhcp { listen { type = dhcp ipaddr = 255.255.255.255 port = 67 interface = eth0 broadcast = yes } dhcp DHCP-Discover { update reply { DHCP-Message-Type = DHCP-Offer } update reply { DHCP-Domain-Name-Server = 0.0.0.0 DHCP-IP-Address-Lease-Time = 7200 DHCP-DHCP-Server-Identifier = 192.168.10.1 } mac2ip ok } dhcp DHCP-Request { update reply { DHCP-Message-Type = DHCP-Ack } update reply { DHCP-Domain-Name-Server = 0.0.0.0 DHCP-IP-Address-Lease-Time = 7200 DHCP-DHCP-Server-Identifier = 192.168.10.1 } mac2ip ok } dhcp { reject } } started the server with radiusd -X and received dhcp requests, but no respose was gathered.
Rok Kosir wrote:
Just installed another laptop with centos 6, built FR from git and i got same result.. It makes me wonder if i have my configuration correctly set, if anyone can confirm, here are my steps:
- I did clean install of centos 6, installed required packages and built and installed freeradius from git - set IP on FR machine on eth0 to 192.168.10.1 with netmask 255.255.255.0 - cleared iptables and disabled selinux - added mac2ip to mods-enabled - created folder mods-config/passwd/ and edited file mac2ip with this content: 00:30:48:32:d7:5f,192.168.10.102 (this is the mac of ubuntu machine which is waiting for dhcp IP) - created file dhcp-static under sites-enabled with this content:
server dhcp { listen { type = dhcp ipaddr = 255.255.255.255 port = 67 interface = eth0 broadcast = yes }
That should be OK.
started the server with radiusd -X and received dhcp requests, but no respose was gathered.
Please do a "git pull". I've tested it on Mac OSX && Ubuntu. It works for me on most configurations. Where there are issues due to misconfiguration or platform functionality, it gives a descriptive error. You may need to run it as "root" in order for the ARP updates to work. If you don't run it as root, it will now tell you what's going wrong, and how to fix it. Alan DeKok.
On 10/28/2013 10:12 PM, Alan DeKok wrote:
Please do a "git pull". I've tested it on Mac OSX && Ubuntu. It works for me on most configurations. Where there are issues due to misconfiguration or platform functionality, it gives a descriptive error.
You may need to run it as "root" in order for the ARP updates to work. If you don't run it as root, it will now tell you what's going wrong, and how to fix it.
I have built the 3.1.0 (git #efb85c7) and now i'm getting ARP errors on ubuntu: (9) DHCP: Reply will be unicast to your-ip-address (9) Failed adding arp entry: Failed to add entry in ARP cache: Operation not permitted (1) rdb doesn't show any more details than this. I am runing this as root user,so permissions should't be a problem. Rok
Rok Kosir wrote:
I have built the 3.1.0 (git #efb85c7) and now i'm getting ARP errors on ubuntu: (9) DHCP: Reply will be unicast to your-ip-address (9) Failed adding arp entry: Failed to add entry in ARP cache: Operation not permitted (1)
rdb doesn't show any more details than this.
I am runing this as root user,so permissions should't be a problem.
(a) set "broadcast = no" or (b) find out why ARP updates aren't permitted. It works on my system, with Ubuntu 12.04, running as root. Alan DeKok.
On 10/29/2013 09:49 PM, Alan DeKok wrote:
Rok Kosir wrote:
I have built the 3.1.0 (git #efb85c7) and now i'm getting ARP errors on ubuntu: (9) DHCP: Reply will be unicast to your-ip-address (9) Failed adding arp entry: Failed to add entry in ARP cache: Operation not permitted (1)
rdb doesn't show any more details than this.
I am runing this as root user,so permissions should't be a problem. (a) set "broadcast = no"
or
(b) find out why ARP updates aren't permitted.
It works on my system, with Ubuntu 12.04, running as root.
There was user and group set in config and it ran under that user, so I assume that was the cause, when deleted it didn't post this error. I still wasn't able to make it send replies tho, i ran strace on radius and got this when it is sending dhcp reply. write(1, "\tDHCP-DHCP-Server-Identifier = 1"..., 44) = 44 write(1, "Sending DHCP-Offer of id 63e996d"..., 80) = 80 sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(68), sin_addr=inet_addr("255.255.255.255")}, msg_iov(1)=[{"\2\1\6\0c\351\226\331\0\0\200\0\0\0\0\0\300\250\ne\300\250\n\1\0\0\0\0pZ\266\232"..., 300}], msg_controllen=32, {cmsg_len=28, cmsg_level=SOL_IP, cmsg_type=, ...}, msg_flags=0}, 0) = -1 EINVAL (Invalid argument) write(1, "(1) Finished request 1.\n", 24) = 24 This was tested on version 2.2.3 (git #e7c7350) and I also get same error on newest checkout from branch v3.0.x - version 3.1.0 (git #b558972)
Alan DeKok.
Rok Kosir wrote:
On 10/29/2013 09:49 PM, Alan DeKok wrote: There was user and group set in config and it ran under that user, so I assume that was the cause, when deleted it didn't post this error.
I still wasn't able to make it send replies tho, i ran strace on radius and got this when it is sending dhcp reply.
write(1, "\tDHCP-DHCP-Server-Identifier = 1"..., 44) = 44 write(1, "Sending DHCP-Offer of id 63e996d"..., 80) = 80 sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(68), sin_addr=inet_addr("255.255.255.255")}, msg_iov(1)=[{"\2\1\6\0c\351\226\331\0\0\200\0\0\0\0\0\300\250\ne\300\250\n\1\0\0\0\0pZ\266\232"..., 300}], msg_controllen=32, {cmsg_len=28, cmsg_level=SOL_IP, cmsg_type=, ...}, msg_flags=0}, 0) = -1 EINVAL (Invalid argument) write(1, "(1) Finished request 1.\n", 24) = 24
My guess is that the IP addresses you're using are wrong. There's probably no route for the IP you're assigning. If you need to assign an IP address that isn't routable to the DHCP server, you need to use a gateway. Alan DeKok.
participants (3)
-
Alan DeKok -
Phil Mayers -
Rok Kosir