DHCP Reservation issues

7 posts / 0 new

Mon, 06/12/2017 - 17:04

WD6EBY

Hello All,

I am having an addressing issue. I have my Node setup as 13 Host Direct with DHCP Enabled. I have my Grandstream PBX setup for DHCP. I get an address and add this to the DHCP Reservation list. Seams to work, well...most of the time. I have found after just setting there or rebooting the Node and/or the PBX the PBX will get assigned a NEW DHCP address. So I go back and see that the old address is still reserved with the MAC address of the PBX. I can also see an NEW DHCP 'Current DHCP Lease and the PBX (identified aith the proper MAC address) has been given a NEW IP address. (See attached) You can plainly see the same MAC address has two address, one in the NEW Pool and one that is reserved.

I have run into issued like this before and it seams that this is because of the NODE. I don't understand this. Perhaps you can shed some light on this.

If at all possible, I would like to see a feature / option that I could easily have x amount of static address out of the pre defined POOL. I could then assign the static address to items like my PBX and Winlink computer without having to use the DHCP method. On my Router I can create a DHCP pool of address along with Static address and I would like to see this type of operation carried through to the MESH technology.

This issue is preventing me form deploying the Ventura County Wide PBX system so any assistance would be most welcome.

BTW if you cant tell, I am NOT a big fan of DHCP..

Respectfully,

Paul...
WD6EBY

Mon, 06/12/2017 - 17:10

WD6EBY

Added jpg

Image Attachments:

Mon, 06/12/2017 - 23:21

AE6XE

Paul, Give the PBX a static

Paul, Give the PBX a static address the same as the reserved IP address. There's a particular model of a SirCam ipCam where the DHCP times out before the node is fully booted to issue an address and the ipCam falls back to some default 192.168.x.x address (so it doesn't work). A number of people including me were scratching their head for a while. I setup the ipCam with the static address the mesh node knows about--it worked.

The screen shot has a little loss of resolution, but I trust the MAC address of the reservation and the MAC of the issued (adn different) IP address are identical MAC addresses. This seems like a DHCP bug. Can you telnet/ssh into the mesh node and send the output of:

1) arp
2) cat /etc/ethers

Then also send the support data download?

Joe AE6XE

Tue, 06/13/2017 - 01:32

(Reply to #3) #4

kg6wxc

This kind of goes back to

This kind of goes back to something I was saying before. And not to "poo-poo" Joe's comments (which *do* seem to be somewhat related) I had that same problem it seemed Joe, with an Apache installation, DHCP would just take a bit too long to assign an address and the interface would not get an IP, which would then cause Apache (and other things) not to start due to not having an interface address to listen on. (apache was set to listen to that IP). I set that particular server to use a static address and all was fixed, but I still had to create a lease in the node for that address to be propagated out, and in that case it was not a problem. It's really odd that Paul can't seem to do that same thing, he's tried, and for some reason his PBX is getting a different address from DHCP, but only after the lease expires. Before that I think it's ok (correct me if I am wrong Paul). I still think it would be nice to have the ability to "set aside" certain addresses out of the nodes DHCP pool, but, and this is the key part, still have the ability to assign those particular IP's host names as well. If I go into the node and add one line to the olsrd.conf file I can get a hostname assigned to an IP without having to create a DHCP lease. That hostname will get propagated out to the rest of the mesh, but that's a hack and shouldn't be necessary. To deal with Pauls issue, one could probably go and manually take away a couple of IP's out of the dnsmasq.conf file as well, but again that is a total hack. Neither of those hacks will survive an update. Some aspects of them do not even survive "Save Changes" in the GUI. Why does the GUI have to require a MAC address in /etc/ethers to be able to assign a service to a hostname? (I do get why, sort of, it's partially to ensure the host is there and within the olsr HNA block) There has to be another way with more flexibility. (I'd bet that when Paul gets back with that info that the entry *will* be in /etc/ethers, and if not that would explain it right there) Maybe a drop down list that simply allows one to exclude a certain IP from being assigned? Perhaps another field that would allow one to assign a hostname to that IP? Then we could have services that will always have the same IP (but perhaps different host names all pointing at that IP). Some of the more "dumb" clients out there still want IP addresses in their config files for whatever reason... Some people just like to use IP's still because they have not yet embraced DNS... Sometimes not having to resolve a hostname is faster... I'm sure there are other reasons I'm just not thinking of right now... I don't know. More flexibility in the local network DNS would *very* be useful tho. And Paul, one thing I forgot to tell you to try, you can use a bunk MAC address for the IP assignment. (AA:BB:CC:DD:EE:FF or something) Once you do that, you can assign services to that IP and they'll get propagated, but that's still sort of a hack and not really a great way to deal with this... One thing that is strange in your image is the "*" for all the names in your current leases field... IIRC, that happens when the client is not identifying itself correctly to the DHCP server. (something like the client is not sending the domain after the first .) (Please someone correct me on that if needed) That still doesn't explain why the DHCP server is ignoring the MAC address though... Don't want to upset anyone, just adding my $0.25, I know Paul, he asked me about this issue and it's a strange one. 73 all!

Tue, 06/13/2017 - 03:47

KG6JEI

"I am having an addressing

"I am having an addressing issue..."
All bug reports should be submitted into Bloodhound. The forum is no longer used for bug handling. If this is believed to be a node flaw please raise a bug ticket and it can be worked through the official channels.

"I still think it would be nice to have the ability to "set aside" certain addresses out of the nodes DHCP pool, but, and this is the key part, still have the ability to assign those particular IP's host names as well."

That is the current purpose of performing an address reservation. In theory it could be split up among multiple pages, but at the moment its all combined into one area so you only have to look at one place on the node to know what is configured.

"Then we could have services that will always have the same IP (but perhaps different host names all pointing at that IP)." Just remember every name advertised would take up additional network resources. This would be very inefficient use of the HAM spectrum. Not techncialy impossible to do, just inefficent use of resources.

"Maybe a drop down list that simply allows one to exclude a certain IP from being assigned? Perhaps another field that would allow one to assign a hostname to that IP?"
Feature requests need to be raised via Bloodhound.

"And Paul, one thing I forgot to tell you to try, you can use a bunk MAC address for the IP assignment. (AA:BB:CC:DD:EE:FF or something) Once you do that, you can assign services to that IP and they'll get propagated, but that's still sort of a hack and not really a great way to deal with this..."
That is actually the official method for right now of reserving an IP address when you don't want to put in the real MAC address. Though if you know the MAC its a good idea to use it, since if the device ever does fall back to DHCP you have a chance at getting in on the correct IP address.

"would then cause Apache (and other things) not to start due to not having an interface address to listen on" An alternative is to listen on 0.0.0.0 instead if your not statically set IP on the server interface. Otherwise I believe systemd (which is becoming more common on Linux OS's) supports a "delay start until after networking is available"

"One thing that is strange in your image is the "*" for all the names in your current leases field... IIRC, that happens when the client is not identifying itself correctly to the DHCP server. (something like the client is not sending the domain after the first .) (Please someone correct me on that if needed) That still doesn't explain why the DHCP server is ignoring the MAC address though..."
There is a chance if the client is not submitting a name that it is also refusing the DHCP lease. A client can REFUSE to accept an address given to it and request a different address (DHCPDECLINE) if it detects the address is in use, its possible its failing to correctly process, or that some other system has taken the IP address. All this discussion is however better suited as a ticket.

Thu, 06/22/2017 - 18:20

WD6EBY

Sorry for the delay. I am

Sorry for the delay. I am not a command line person and had to learn how to do this. Here goes.
Thank you for looking at this.
Paul...

root@WD6EBY-VC-Sulphur-ResourceServer:~# arp
IP address       HW type     Flags       HW address            Mask     Device
10.109.26.89     0x1         0x2         00:0b:82:ac:63:1d     *        eth0
10.108.213.198   0x1         0x2         dc:9f:db:6c:d5:c6     *        wlan0
10.255.3.22      0x1         0x2         24:a4:3c:ff:03:16     *        eth0.2
10.151.5.116     0x1         0x2         24:a4:3c:97:05:74     *        eth0.2
10.243.29.135    0x1         0x2         24:a4:3c:f3:1d:87     *        eth0.2
10.109.26.82     0x1         0x0         00:00:00:00:00:00     *        eth0
10.109.26.90     0x1         0x2         00:0b:82:62:48:a9     *        eth0
10.109.26.86     0x1         0x2         00:0b:82:ac:63:1a     *        eth0
10.89.57.58      0x1         0x2         68:72:51:59:39:3a     *        eth0.2
10.91.252.79     0x1         0x2         dc:9f:db:5b:fc:4f     *        eth0.2
10.139.71.117    0x1         0x2         00:27:22:8b:47:75     *        eth0.2
10.138.71.117    0x1         0x2         00:27:22:8a:47:75     *        wlan0
10.107.154.60    0x1         0x2         68:72:51:6b:9a:3c     *        eth0.2
10.243.25.124    0x1         0x2         24:a4:3c:f3:19:7c     *        eth0.2

Support File Attachments:

supportdata-WD6EBY-VC-Sulphur-ResourceServer-201703191147.tgz

Thu, 06/22/2017 - 23:28

(Reply to #6) #7

AE6XE

The reserved IP address for

The reserved IP address for the PBX is "10.109.26.82". However the arp table shows this IP address in a "failed" arp state (all '0's MAC address). Can you post the other command, "cat /etc/ethers". I'd suspect the PBX is not handshaking correctly. At one point maybe an IP conflict, but different arp state than failed at the time.

Something to try if not already: remove the PBX 10.19.26.82 IP reservation. Then add it back in with the current 10.109.26.90 lease. Reboot everything and see what happens. If you've been down this path already, then back to something whacky with the PBX interacting with the mesh node.

Joe AE6XE

Amateur Radio Emergency Data Network

Menu SF

You are here

DHCP Reservation issues

Amateur Radio Emergency Data Network

Search form

Menu SF

You are here

DHCP Reservation issues