...There are going to be two net topos for LMCE deployments: an entry level setup with no IP PNP net devices, often on a reused existing PC HW to try it out with just the existing single NIC, and an existing DHCP and router. With no IP PNP devices to support (excluding storage shares, which don't need LMCE DHCP), LMCE does not need to be the DHCP server. LMCE never really needs to be the router (even the 2-NIC default can sit behind a separate router on the outside LAN segment), though of course firewall features do require 2 NICs. When people want to support IP PNP devices, they can upgrade to a 2-NIC PC or install a second NIC, though some people will start with that full version.

So yes, the LMCE Network Settings page should expose the dhcpd.conf "routers" (and maybe even the "next-server" for hosting the bootfile outside the Core) option that's already in the file. The Wizard should offer a high-level switching option between the two scenarios, which the initial installer should also accept.

LMCE is supposed to serve a home audience, not (necessarily) a hacker audience. Even when pro installers are deploying at a customer's site, the time saved and mistakes avoided with such automation will lower costs. And of course nontech consumers will find that significant barrier to entry dropped. Which is the main benefit of using competitor products like Windows MCE: it's really simple, in usage terms that the mass market can easily understand.

You are wrong, in many cases Linux MCE does need to be the router and the DHCP server. This setup is there for a reason, that it does not suit you personally as the default scenario is a different problem.

When people do not want all these features they can be turned off. Furthermore LinuxMCE != WindowsMCE, try to remember that.

Networking issues are the biggest timesinks in many installations. Especially mixed installs with Linux, Win XP Win Vista and Mac systems sharing the network. If all of those systems behaved perfectly it would be more straightforward to make it all work. Add some other networked devices and getting them all to communicate is tough.

The other question is the performance hit from using the core to route through or directing to an external hardware router. And having separate nets or one net. I'm using a single NIC install, fixed IP to my external home gateway (Trendnet router) on 192.168.0.1 and DHCP to my internal network on 192.168.80.XXX. This allows me to point a machine that doesn't need to be part of the network to another address on the 0.XXX subnet and it still works even when the core is down. I can't see a performance problem with this arrangement and can pretty consistently get 10+ Mbps D/L speed from Comcast on the internal net. And the internal net is all Gigabit in which I get better than 300 Mbps throughput on the Windoze machines (Their usual limits). Am I missing something? I'm no network wiz.

I would like to see a simple UI accessable from the advanced screen allowing selection of the options available-1 NIC2 NIC's

Get core IP from DHCP on which NIC OR Set Fixed core IP on which NICInternal DHCP on /offDHCP on which NIC (inside/ outside)PPOE setupVPN setup

Plus Firewall configuration with some help notes like which ports support which services in the system (With VOIP and remote access etc. there are a lot of details to sort out) Perhaps instructions on setting for an external router for ports DMZ etc. if relevant.

On the point of lease renewals and 2 DHCP servers on the same physical segment...

This is *not* a design flaw of DHCP!! DHCP has no requirement to allow for 2 different DHCP servers serving different functions - serving the same function, certainly, ie providing redundancy - this is in fact a very common configuration on larger networks. Usually with a local DHCP server and a redundant, centralised, remote DHCP server backing it up. It is very easy to configure - all the same scope options except each has only a part of the complete subnet range, not overlapping. This way they collaborate perfectly well, and do not conflict. If one fails, the other can take over seemlessly - just the router needs its DHCPHelper option set so clients can reach the remote DHCP server.

The fly in the ointment here is that both DHCP servers are not serving the same function, LMCE uses DHCP for much more than assigning IP addresses, so this type of configuration doesn't work for us. This isn't a reflection on the design of DHCP!!! It is fine, we are just trying to use it for something very specific which it wasn't designed for.

Also - yes, you can add/extend the DHCP schema however you want, it is already Very large and I would be surprised if you couldn't find a scope option to suit by default, to pass out any info you wanted.

With Lowspirits config, no there is nothing to prevent the real router providing the leases - and it is probably true that it was just luck that nas's, etc were served by the core. As for MDs, they are looking for PXE scope options, so probably ignore the real router's offers because they don't contain them. Both DHCP servers will respond with an offer, it is then up to the client which it chooses. The only way around this would be a packet filter on the real router (tried this on mine, didn't work!) or an ACL on the switch ports (probably requires a layer 3 switch in most cases!)

But once the devices have been "lucky" the first time, the reason this continues has nothing to do with the lease expiration times or the half lease renewal requests. DHCP clients remember their server they received after the first broadcast, and when requesting renewal of a lease direct it straight to that server, not broadcast. So as long as that server stays responsive, they will always get their renewals from it not the real router, and the IP address will remain the same.

On that note - the core also remembers where a device was in its DHCP config file. And will allow a lease to be renewed at the same IP address EVEN IF that IP address is not in the configured subnet scope! This caused me a lot of pain trying to work out why my Windows PC share media was no longer available. Briefly I turned on my router DHCP server and it got an IP address from it, outside the core's DHCP range. I then turned it off again and got my PC to renew again. As it couldn't find the router DHCP server any more it went back to broadcasting and the core responded. But it seems that the PC didn't only broadcast for a new lease, it requested a renewal of the existing IP address. Even though this was outside the core's scope, because it was in the config file it allowed it to keep that address!! No amount of releasing and renewing or rebooting would stop this because even then, the core's DHCP server still remembered this IP and kept giving it out.

Because it is outside the correct range, the core just didn't seem to want to "see" that share and its media any more. I had to manually remove the entry from DHCP3 server's conf file and release/renew - then it got a valid IP in the range and presto the media was back.

I am turning on and off my router's DHCP server regularly as I test my core in VM, so if anybody else is doing this, beware of stray leases screwing up things like this. Because I can't run the VM all the time, I can't switch over permanently to LMCE as DHCP, but once I set up a proper physical core, that's what I will be doing!

On the point of lease renewals and 2 DHCP servers on the same physical segment...

This is *not* a design flaw of DHCP!! DHCP has no requirement to allow for 2 different DHCP servers serving different functions - serving the same function, certainly, ie providing redundancy - this is in fact a very common configuration on larger networks. Usually with a local DHCP server and a redundant, centralised, remote DHCP server backing it up. It is very easy to configure - all the same scope options except each has only a part of the complete subnet range, not overlapping. This way they collaborate perfectly well, and do not conflict. If one fails, the other can take over seemlessly - just the router needs its DHCPHelper option set so clients can reach the remote DHCP server.

The fly in the ointment here is that both DHCP servers are not serving the same function, LMCE uses DHCP for much more than assigning IP addresses, so this type of configuration doesn't work for us. This isn't a reflection on the design of DHCP!!! It is fine, we are just trying to use it for something very specific which it wasn't designed for.

Also - yes, you can add/extend the DHCP schema however you want, it is already Very large and I would be surprised if you couldn't find a scope option to suit by default, to pass out any info you wanted.

With Lowspirits config, no there is nothing to prevent the real router providing the leases - and it is probably true that it was just luck that nas's, etc were served by the core. As for MDs, they are looking for PXE scope options, so probably ignore the real router's offers because they don't contain them. Both DHCP servers will respond with an offer, it is then up to the client which it chooses. The only way around this would be a packet filter on the real router (tried this on mine, didn't work!) or an ACL on the switch ports (probably requires a layer 3 switch in most cases!)

But once the devices have been "lucky" the first time, the reason this continues has nothing to do with the lease expiration times or the half lease renewal requests. DHCP clients remember their server they received after the first broadcast, and when requesting renewal of a lease direct it straight to that server, not broadcast. So as long as that server stays responsive, they will always get their renewals from it not the real router, and the IP address will remain the same.

On that note - the core also remembers where a device was in its DHCP config file. And will allow a lease to be renewed at the same IP address EVEN IF that IP address is not in the configured subnet scope! This caused me a lot of pain trying to work out why my Windows PC share media was no longer available. Briefly I turned on my router DHCP server and it got an IP address from it, outside the core's DHCP range. I then turned it off again and got my PC to renew again. As it couldn't find the router DHCP server any more it went back to broadcasting and the core responded. But it seems that the PC didn't only broadcast for a new lease, it requested a renewal of the existing IP address. Even though this was outside the core's scope, because it was in the config file it allowed it to keep that address!! No amount of releasing and renewing or rebooting would stop this because even then, the core's DHCP server still remembered this IP and kept giving it out.

Because it is outside the correct range, the core just didn't seem to want to "see" that share and its media any more. I had to manually remove the entry from DHCP3 server's conf file and release/renew - then it got a valid IP in the range and presto the media was back.

I am turning on and off my router's DHCP server regularly as I test my core in VM, so if anybody else is doing this, beware of stray leases screwing up things like this. Because I can't run the VM all the time, I can't switch over permanently to LMCE as DHCP, but once I set up a proper physical core, that's what I will be doing!

What is missing from the design of the standard DHCP protocol is precisely what is a problem for LMCE when there is an existing DHCP server on a LAN into which LMCE is installed. The existing DHCPd must be turned off, or the LMCE DHCPd must be turned off, because there can be only a single DHCP option set served to a single LAN segment. For redundancy DHCP does have failover directives as a rudimentary interserver protocol, but work on fuller DHCP interserver operations has not been completed. That is indeed a design flaw, that various people have done some work to correct for over 10 years, though it's not been fixed yet. Largely because failover support has met the needs of the most demanding networks so far. But the recent emergence of UPnP over LANs shows where the current DHCP design is missing that important functionality. But in the meantime if we want LMCE to work with a single NIC, we need to make LMCE work in that environment without DHCP itself supporting that setup.

Starting to use LMCE with a single-NIC machine is going to continue to be a popular option, increasingly so as more people want to try it out without supporting other devices than a simple hybrid, then switch later when they see it's other benefits. And also in general as an appliance. So I'm exploring it, and posting my results.

If other people's own personal preferences don't include that configuration, they're welcome to ignore the efforts, and spend their valuable time doing something else instead that does interest them.

I set it up with 192.168.1.2 external, and 192.168.1.10 as internal. Gateway is my wireless router as 192.168.1.1. I disabled DHCP on wireless router, and enabled on LMCE, but nothing is pulling an ip. Suggestions?

Thanks Snowglyder: I am a bit of a newbie on LMCE still, but I got my installation working Ok with your instructions.While there are many reasons for people wanting to use a single NIC and Core not as a router mine are the following:

-My core is not allways on, since the whole installation is for my own testing purposes only.-Keeping the core on all the time would waste a lot of energy (electricity bill has gone up 130% during this decade where I live and also we must remember the environment and not waste energy in wain)-I have a perfectly vell working switch/router/DHCP/Firewall device before my DSL box, which requires zero maintenance.

Now my system is the following: Zyxel Lan switch/firewall with gateway ip 192.168.1.1, DHCP off and the WAN port to the DSL modem.Core has DHCP on and external ip 192.168.1.2, internal ip 192.168.1.3 and with single NIC.DCHP is set up to give ip:s from 192.168.1.5 - 192.168.1.30.

Normal computers, while not booting from Core and acting as Media Directors, have static ip:s from 192.168.1.31 up and with gateway and DNS of 192.168.1.1 .

Works, no probs: I can use my computers as normal workstations and when I want them to act as Media Directors I just boot them from the network....

It looks like your core could end up booting off of itself. The internal and external NIC's are on the same subnet. It should work and it similar to what I have done. But the usual practice is to keep the internal net on the 192.168.80.X so it won't get mixed up with the external net. I'm doing this through a single NIC with no problems. If I need a PC to go around the system I put it on the same net as the router with a fixed IP (and set up windoze networking with a fallback fixed IP on that net).

....DHCP clients remember their server they received after the first broadcast, and when requesting renewal of a lease direct it straight to that server, not broadcast. So as long as that server stays responsive, they will always get their renewals from it not the real router, and the IP address will remain the same.

On that note - the core also remembers where a device was in its DHCP config file. And will allow a lease to be renewed at the same IP address EVEN IF that IP address is not in the configured subnet scope! This caused me a lot of pain trying to work out why my Windows PC share media was no longer available. Briefly I turned on my router DHCP server and it got an IP address from it, outside the core's DHCP range. I then turned it off again and got my PC to renew again. As it couldn't find the router DHCP server any more it went back to broadcasting and the core responded. But it seems that the PC didn't only broadcast for a new lease, it requested a renewal of the existing IP address. Even though this was outside the core's scope, because it was in the config file it allowed it to keep that address!! No amount of releasing and renewing or rebooting would stop this because even then, the core's DHCP server still remembered this IP and kept giving it out.

Because it is outside the correct range, the core just didn't seem to want to "see" that share and its media any more. I had to manually remove the entry from DHCP3 server's conf file and release/renew - then it got a valid IP in the range and presto the media was back.....

Interesting. I haven't been able to get my Core to give out IP's, and this seems like what might have happened to my setup. I'm going to check the conf file and see if I can't get this thing straightened out! I still don't have LMCE working correctly because of this DHCP problem and lack of time to figure it out, but now I have something to try! Thanks again!

Thanks Snowglyder: I am a bit of a newbie on LMCE still, but I got my installation working Ok with your instructions.While there are many reasons for people wanting to use a single NIC and Core not as a router mine are the following:

-My core is not allways on, since the whole installation is for my own testing purposes only.

....

I'm glad my setup helped you! It's funny that I have it setup correctly, but DHCP stopped working and the core isn't seeing my media. Colinjones had a seemingly good explanation, so hopefully I can get it up and working again...