Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

jasnw

macrumors 65816
Original poster
Nov 15, 2013
1,074
1,140
Seattle Area (NOT! Microsoft)
My basic problem is that the DHCP I'm running via Apple Server (Mavericks) on a mini isn't releasing IPs to new systems. Every new system (like a visitor's iPhone) has to be entered as a static connection. I've got an overly-complicated setup, with a COMCAST cablemodem/router (an SMCD3GNV) that is supposed to be in bridge mode to a LinkSys router (LRT214). DHCP has been disabled on the LinkSys, but it's active on the COMCAST beast and there appears to be no way to shut it off via the web interface (!!!). As a side issues, the WiFi on the COMCAST box is also enabled, which I also don't want running and cannot turn off.

I think my first question is whether the COMCAST box should be running DHCP or WiFi if it's in bridge mode, with a follow-up of how to shut down DHCP and WiFi on it if they can run in bridge mode. (I still have the COMCAST box because I get phone service through it as well).

If the COMCAST box behavior shouldn't be messing up the DHCP behavior on the mini server, any ideas as to what's going on there? When I first set this up it connected fine to four devices. Those are still showing as dynamic IP assignments, but it won't connect any more up via dynamic IP assignment.
 
My basic problem is that the DHCP I'm running via Apple Server (Mavericks) on a mini isn't releasing IPs to new systems. Every new system (like a visitor's iPhone) has to be entered as a static connection. I've got an overly-complicated setup, with a COMCAST cablemodem/router (an SMCD3GNV) that is supposed to be in bridge mode to a LinkSys router (LRT214). DHCP has been disabled on the LinkSys, but it's active on the COMCAST beast and there appears to be no way to shut it off via the web interface (!!!). As a side issues, the WiFi on the COMCAST box is also enabled, which I also don't want running and cannot turn off.

I think my first question is whether the COMCAST box should be running DHCP or WiFi if it's in bridge mode, with a follow-up of how to shut down DHCP and WiFi on it if they can run in bridge mode. (I still have the COMCAST box because I get phone service through it as well).

If the COMCAST box behavior shouldn't be messing up the DHCP behavior on the mini server, any ideas as to what's going on there? When I first set this up it connected fine to four devices. Those are still showing as dynamic IP assignments, but it won't connect any more up via dynamic IP assignment.

deleted.
 
Last edited:
The Comcast device doesn't sound like it's really in bridge mode.

In my experience it takes a call to any particular internet provider to have them put their device in bridge mode...if it can be done. If not, perhaps Comcast can let you swap for a "modem only" model. If those aren't available another option is that you can purchase a cable modem and get it set up with a call to Comcast.
 
I ran through this with COMCAST already once, and it was at one time in bridge mode. It looks like COMCAST has reset it back to doing-everything mode. This includes Wi-Fi, which I REALLY want turned off. I'm going to contact COMCAST again to have then take another shot at this.
 
My basic problem is that the DHCP I'm running via Apple Server (Mavericks) on a mini isn't releasing IPs to new systems. Every new system (like a visitor's iPhone) has to be entered as a static connection. I've got an overly-complicated setup, with a COMCAST cablemodem/router (an SMCD3GNV) that is supposed to be in bridge mode to a LinkSys router (LRT214). DHCP has been disabled on the LinkSys, but it's active on the COMCAST beast and there appears to be no way to shut it off via the web interface (!!!). As a side issues, the WiFi on the COMCAST box is also enabled, which I also don't want running and cannot turn off.

I think my first question is whether the COMCAST box should be running DHCP or WiFi if it's in bridge mode, with a follow-up of how to shut down DHCP and WiFi on it if they can run in bridge mode. (I still have the COMCAST box because I get phone service through it as well).

If the COMCAST box behavior shouldn't be messing up the DHCP behavior on the mini server, any ideas as to what's going on there? When I first set this up it connected fine to four devices. Those are still showing as dynamic IP assignments, but it won't connect any more up via dynamic IP assignment.

I don't understand why you have this setup overly complicated as you put it. Since the Linksys isn't doing anything, but overly complicating your setup, I do not understand why it is involved.

I would begin by preparing the the SMC gateway to offer a small DHCP range. Set it to be something like 10.0.1.1 - 10.0.1.50. Then you want the Mini Server outside your DHCP range on the SMC to avoid issues. Essentially set it for a static config to the SMC. The bad news is that there is issues using Bridge Mode in the latest firmwares on the latest Comcast modems. You could order a quality simple modem like the Motorola SB6141 and have it just be a modem.

If I understand correctly, the Linksys is doing nothing but acting as a very expensive switch. At which point you could run Ethernet from the SMC to the Mini and from the Mini to the switch or AP for wireless if you want it. That would turn the Mini as the DHCP server and cut the cord with the Linksys.

Granted, I could be completely wrong, but if I have the way your set up is correctly, that is how I would do it.
 
My basic problem is that the DHCP I'm running via Apple Server (Mavericks) on a mini isn't releasing IPs to new systems. Every new system (like a visitor's iPhone) has to be entered as a static connection. I've got an overly-complicated setup, with a COMCAST cablemodem/router (an SMCD3GNV) that is supposed to be in bridge mode to a LinkSys router (LRT214). DHCP has been disabled on the LinkSys, but it's active on the COMCAST beast and there appears to be no way to shut it off via the web interface (!!!). As a side issues, the WiFi on the COMCAST box is also enabled, which I also don't want running and cannot turn off.

I think my first question is whether the COMCAST box should be running DHCP or WiFi if it's in bridge mode, with a follow-up of how to shut down DHCP and WiFi on it if they can run in bridge mode. (I still have the COMCAST box because I get phone service through it as well).

If the COMCAST box behavior shouldn't be messing up the DHCP behavior on the mini server, any ideas as to what's going on there? When I first set this up it connected fine to four devices. Those are still showing as dynamic IP assignments, but it won't connect any more up via dynamic IP assignment.

I would turn ON DHCP on the Linksys, turn it OFF on Mavericks. Make sure the Linksys is not relaying the DHCP from the Comcast box, and that should fix your issues. Well, and obviously have the Linksys in a different subnet from the Comcast box. The Mini is seeing the Comcast DHCP server and stops functioning. Be glad it's doing that. I've had people build their own networks with stupid devices that all give out addresses and cause major headaches.

But from the dates if this thread, you probably already have fixed the issue... Cheers...
 
But from the dates if this thread, you probably already have fixed the issue... Cheers...

I may have, at least part of it. The "ghost" IP assignments appear to be gone after many hours spent trying to find out where OS X hides this sort of stuff. Still have to put in static DHCP assignments for new hardware, which is clearly wrong, but that's a battle for the weekend involving trying to figure out what Apple has layered over the top of plain-vanilla BSD networking and where they've hidden everything. Documentation for OS X Server is limited and quite often out-of-date, even the online non-Apple stuff.
 
I may have, at least part of it. The "ghost" IP assignments appear to be gone after many hours spent trying to find out where OS X hides this sort of stuff. Still have to put in static DHCP assignments for new hardware, which is clearly wrong, but that's a battle for the weekend involving trying to figure out what Apple has layered over the top of plain-vanilla BSD networking and where they've hidden everything. Documentation for OS X Server is limited and quite often out-of-date, even the online non-Apple stuff.

My limited experience has been that the internal BSD stuff is still there, and *looks* like it's working, but it's been neutered at some higher level, and no one at Apple can tell why, where, or in some cases how to get the same functionality with the augmented NextStep wrapping. All their long haired BSD/Mach types left apparently...
 
The problem has become clearer, but the solution still evades. It looks like a new box put on the network via wire gets assigned a dynamic IP address, but anything that ties in via wireless gets ignored. In order to bring a new wireless client into the network I have to make a static DHCP entry for it, which is NOT what should be happening. Oddly enough, when I first set the server up I did get three clients to hook up with dynamic links (two iPhones and an iPad). They still have dynamic links, but no further dynamic assignments have been established.

The pertinent parts of my LAN are a COMCAST router in bridged mode (COMCAST says it is, anyway) with its wireless turned off feeding to my Linksys wired-only router (DHCP disabled). There’s a cable from the Linksys to a Mac Mini that’s running OS X Server, and a cable from the Linksys to an Airport Extreme. The AE, and an Airport Express configured to extend the AE wireless network, serve the upstairs and downstairs areas with wireless coverage.

The DHCP is set up with the static assigned addresses beginning at x.x.x.100 (which is the Server’s IP address) and the router is assigned the static address x.x.x.0. The three dynamic clients that did work have x.x.x.1, .2, and .3. When a new wireless client tries to get an IP address the password is accepted by the wireless boxes, but when I look in the DHCP log I only see the DHCP DISCOVER requests and no response from the DHCP server. When I finally set up the client as a static IP address the full DHCP conversation then goes as expected and the client receives the assigned IP address.

Any ideas?
 
Final chapter, I hope. The culprit became more clearly the COMCAST modem/router. It was hijacking DHCP requests from wireless clients and assigning IP addresses from its own internal (and unviewable by mere customers) pool. I went once again through the process of begging (no asking of Overlords) COMCAST to put my COMCAST modem/router into bridge mode AND to make sure that WiFi and DHCP are disabled. After that was done I did a power-off reset of my own wireless routers and flushed caches (as much as I could) on various servers and systems on the LAN, and was finally able to get a wireless client assigned the appropriate dynamic IP address from the DHCP daemon runnning on my server. (I think part of this hijack process was enabled by one or the other of my two Airport wireless boxes, but that's another issue.)

I don't know why the COMCAST router went back into unbridged mode, and I refuse at this point to go all paranoid about COMCAST and their nefarious desires. I am going to keep an eye on the COMCAST box to make sure it doesn't go all undead on me again.
 
....

The DHCP is set up with the static assigned addresses beginning at x.x.x.100 (which is the Server’s IP address) and the router is assigned the static address x.x.x.0. The three dynamic clients that did work have x.x.x.1, .2, and .3. When a new wireless client tries to get an IP address the password is accepted by the wireless boxes, but when I look in the DHCP log I only see the DHCP DISCOVER requests and no response from the DHCP server. When I finally set up the client as a static IP address the full DHCP conversation then goes as expected and the client receives the assigned IP address.

Any ideas?

Based on what your are saying, it sounds like the Comcast modem is handing out IP addresses. But because it appears to partially bridge, it fails with your wireless clients (since Wifi and possibly DHCP is still enabled on that device) If Mavericks server was properly handling the DHCP, you would get IP addresses of X.X.X.100,X.X.X.101, etc...

I personally experienced this myself to where I had two DHCP servers on the network my Airport Extreme and OS X server. To make a long story short, it had to do with DHCP and DNS issues with handling both the primary AP and the guest AP. So I had to have DHCP on the AP extreme, but automatically fail over to the OS X Server

Here is my suggestion, put in DHCP reservations. I believe I had that router a long time ago and you should be able to do it. Anyway, here is my suggestion. You will want to put in a "dummy reservation". So, you can put in 00:00:00:00:00:00 as the MAC Address and the IP address to be X.X.X.5. Now this is going to be a pain, but you would do this for the entire range up to X.X.X.100. To make a quick test, you could try lowering the range on the server to X.X.X.20 or something like that.

Once you set it up, here is what should happen. A client connects in and attempts to get an ip address from the Comcast router. It exhausts it IP address range due to it's reservations. Then what should happen is that the next DHCP server should be accessed. In this case, it is the OS X server DHCP. Then you should get an address for X.X.X.100 range. In my personal situation, I made valid reservations for items below the X.X.X.100 range. I done this for items I want a valid IP address. Examples were my IP phones, cameras, and airplay speakers throughout the house.

As a sidenote, although this should resolve your issue, you really shouldn't be seeing a wireless AP for the bridged router. You have an extra AP that takes up a wireless channel bandwidth. Although my suggestion should help, you really should be looking at getting your own modem in the long term.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.