LinuxMCE as DHCP server, NOT gateway!

[shaz]

One of the functions that DHCP performs is detecting new devices, particularly as you turn Orbiters on and off. Another, and critical one, is enabling MD functionality. Without DHCP, no MDs. full stop. If you are not using HA or multiple MDs, then I suspect that LinuxMCE is not the product for you. Try MythTV, VDR or XBMC....

Shaz - you haven't said anything at all about why you want to turn off the firewall. Quite simply, Why?? If you want to use another firewall, then do so! Why do you feel this implies you need to turn off the one in LinuxMCE? Are you afraid of being too safe?! Just leave it on, as it too performs other functions in LinuxMCE.

You are talking about turning off the firewall and DHCP, loosing Orbiter, MDs, pnp, QoS, having to manually edit DHCP at various intervals, etc, but I don't see any reason for doing any of this. Just leave both on. If you want also to use your own firewall, then do so. But don't make this any more complicated than you need to.

No, if I were to turn one of my routers into a gateway/dns and leave linuxmce to dhcp I would turn the firewall off on linuxmce and let the routers firewall be enabled. I will still have a firewall up, just one. What Oatz was talking about was the easy use of the dd-wrt interface and I also enjoy using its interface to handle my network. I don't want to turn off the dhcp service on linuxmce, that would just make things way to overly complicated and is not my intentions.

[colinjones]

That is workable, just be aware that turning off the firewall means you loose the QoS features for VoIP and NATing to the internal network, but that may not concern you. Note, you don't actually need to NAT internally if the firewall is off, because of course, it will just route... however, for the reference of others.... with many broadband routers, their NAT/PAT/PortForward/VirtualServer (call it what you will) is only able to NAT to a local subnet address on its internal LAN interface. Thus these devices will not be able to NAT through the 192.168.1.x subnet into the 192.168.80.x network. So if you have a sevice you want to reach on the LMCE internal network for inbound Internet connections (eg Bit Torrent client, web server, etc) you will need to leave the LMCE firewall on. Use the broadband client to NAT to the external interface of the core, then use the core's NAT to complete the connection to the internal device. This works very well and is very easy to set up... note this is a limitation of those particular broadband routers, nothing to do with LMCE.

[unsolicited]

Which brings us back to a well reasoned earlier post - if the lmce firewall is doing no harm, why not leave it on / alone? (DHCP no longer in the picture, as it's being left on, here.)

That is workable, just be aware that turning off the firewall means you loose the QoS features for VoIP and NATing to the internal network, but that may not concern you.

Now that's interesting. I get the not wanting NAT in this situation. But the quote implies that either lmce firewall != iptables, or iptables (as used by the lmce firewall) is more than just a firewall. It implies it's doing some packet massaging too. No?

If the routers (ddwrt), switches (?), NICs, and so on and so forth are all QoS aware, why would the lmce firewall matter? Unless it, and not Asterisk, is the beastie flipping those flags on in the packets?

[colinjones]

Not sure I follow the "not wanting NAT" bit... personally I do want NAT, but perhaps you meant something else?

I have no idea what does the QoS, but I believed it was the firewall (certainly I have read in the past that disabling the firewall disables the QoS)...

If we assume that (TBC), then you need to understand that there is much more to QoS than "flags". Broadly the 2 halves of QoS are, "marking" and "enforcement". An application can certainly emit packets that are pre-marked, ie have their ToS or DSCP flags marked; a layer 2 switching device can mark the CoS flags based on policies, and a layer 3 routing device can mark ToS or DSCP flags based on all sorts of things. But marked packets on their own do nothing.

It is only when you enforce policies based on the markings (or override the markings with new markings and enforce based on those; or ignore the markings and enforce based on something else entirely) that the QoS concept has any effect. Prioritisation, queuing, bandwidth clamps, etc are typically how enforcing is implemented, and no application can directly influence that. Switches do the enforcing for CoS and routers to the enforcing for ToS/DSCP.

The first "concentration" point (potential congestion point) in a LMCE network is the core. If the internal interface is congested, particularly with very large payload video stream packets, downloads, etc.... then very small VoIP packets will suffer latency issues due to things like serialisation delays, queuing delays, etc on the external NIC. Asterisk marking packets and the "router" in the core enforcing these by placing them in a Strict Priorty Queue/LLQ type prioritisation will help resolve this. So yes, although I cannot definitively say what the core actually does or which component does it, it is certainly something you would want to do on the core to protect telephony, and is something that the core would have to do, not Asterisk.

[unsolicited]

Not sure I follow the "not wanting NAT" bit... personally I do want NAT, but perhaps you meant something else?

Agreed, you want NAT between your internal and public networks. But the network layout described in this thread is an openwrt / dd-wrt router connecting public and internal networks (and doing NAT), and multiple internal devices behind it. I have seen nothing to believe that the non-core computers present are behind and not beside the core. Yes, NAT is needed, but not on the core in this thread.

I have no idea what does the QoS, but I believed it was the firewall (certainly I have read in the past that disabling the firewall disables the QoS)...

Agreed, it's what I've been reading, but I don't understand why, to date. Part of the question I posed in my last then, is really "Is firewall a misnomer - turning on the lmce firewall is accomplishing more than what one at first blush expects a firewall to be doing?"

The firewall being more than a firewall is not intuitive as only firewall rules are specified under that tab. I can certainly see how nat / routing / firewall are all involved here in this thread, and how it is not one stop shopping in webadmin under firewall. And I can see how wanting to do anything different in webadmin to manage it would be a can of worms to open, without some serious reason to do so such that it would rise to the top of the priority list. [We may get there, but not today.]

If we assume that (TBC), then you need to understand that there is much more to QoS than "flags". Broadly the 2 halves of QoS are, "marking" and "enforcement"...

Thank you for your post - it reminds me / us that not only must the source app (or, given that the firewall enables / disables QoS, source machine) set the flags, all the points of network concentration (e.g. switch, router) between must honour those flags.

For brevity (because this gets long very quickly) ... you are assuming (in this thread) that all machines are behind the core, and that the core is doing the routing. The former may or may not be true, the latter is explicitly not true. Again, in this thread.

Whether or not the firewall is turned on, the flags should be honoured by the core (routing) [and the flags should be set by the app] - or the firewall is more than a firewall. (The question of which, is what started this branch of the thread.)

I'd guess that that is the cause of much forum traffic - many saying don't turn off the firewall as you'll lose functionality that is sort of the whole point of having lmce in the first place, and others saying 'I already have a firewall.' And I'd suspect made worse, when coming from a Kubuntu install up via CD, as such users would be more aware / sensitive to such fine points. Vs. black box DVD fire-and-forget installs.

Like I say above, I'm not sure another approach (within webadmin) is appropriate, given the complexity and inter-relationship of the concepts, but certainly it should be kept in mind should those areas see further work.

In the meantime, perhaps some relabelling of the 'firewall' tab may be warranted, and an explanatory note that more than a firewall is covered under it.

For myself, I'd like to see the current iptables listed in text under the new rule entry boxes, but I'll put that request in when I get back to that area. (Other things happening around me at the moment.) Certainly doing so would reveal that much more than just what we think of as firewall rules are being turned on/off with the firewall tickbox.

[unsolicited]

... then I suspect that LinuxMCE is not the product for you. Try MythTV, VDR or XBMC...

I'm not sure I agree with that. Here's why / my perspective ...

Asterisk/MythTV (etc.) is my initial goal, but given convergence, I don't think it is my / the end goal. From what I've seen, lmce is, or will be, the end goal. It's just that home control is not the first priority in my set of goals.

I'd rather go through the learning curve, once, with lmce, than twice - via Myth then lmce. I know I'm going to go through some pain, as I ignore or neuter some aspects of lmce, and have to work with / through others (dhcp, firewall), but I believe it will be worth it in the end.

But that's just me. Certainly this is not the first time I've heard that if all you want is an Asterisk/Myth box, then the learning curve of lmce may be more than you want.

But look, lmce opens up with "Tell me what you rooms are." ... imagine the possibilities.

_That's_ a perspective / approach _I_ want to be part of. It just makes so much sense.

YMMV.

[colinjones]

To both previous posts -

That maybe your priority, unsolicited, but not necessarily Shaz's. And my comments were directed at Shaz.

There is no specific indication that Shaz intended the network topology you are suggesting other than an inference from the presence in this thread. Either way, I absolutely will not recommend that topology ... all the more determinedly because Shaz provides no background whatever on why they might want to do that. In this instance, the response is clear - 2 NICs, 2 networks...

This is potentially a perfect example of what I have clearly outlined recently, of setting the wrong tone for newbies, by continually bringing up a single NIC config as a viable "option". It is NOT! For experienced users, it is a "last resort", that will not get supported currently. If we set the tone of this being an "option" people will inevitably want to take it without 1) understanding the difficulties involved, and 2) without understanding the simplicity that the as-designed approach can mean, as described here - http://wiki.linuxmce.org/index.php/Network_Setup

Be clear, 99% of all cases, there is no _real_ reason why the correct topology cannot be used, and thus be a simpler and more supportable solution. The issue is almost invariably that people do not understand the correct topology and incorrectly believe it means a major impact on their environment... which is precisely why I wrote that wiki article. This needs to be the united front of information presented to all newcomers... if there happens to be one of those very rare instances where a single NIC environment is the only realistic option, you can rest assured that will come out in the wash, and then contingent on an experienced user mentoring the newcomer, that can be addressed on a case by case basis.

Shaz - you most definitely need a new thread to discuss this. To start with a blank slate, outline your issue/concern/question, and allow others to come in without all the baggage and potential misunderstanding/misattribution from this thread.

This thread has been going around in circles, and off on tangents for some time now. I have allowed it to continue against my better judgement, based on the Charter's "light touch" principles... however, I can see now that the history of to'ing and fro'ing over several different topics, going in circles, etc, and general direction means that this thread is going to continue flaring, but without adding any value beyond the original discussion. For that reason, additional comments are not going to benefit in any way from the preceeding comments in this thread, and would be clearer and less ambiguous in a new thread, for the same reasons as my advice to Shaz.

Locking