There's a lot of assertions in your post @OzBrickie, and while I appreciate the effort, I don't agree on everything you say. Networking can be very complex if you dive into enough detail, although at the level most people interface with it it's actually much simpler than people tend to believe.
I didn't know about the "wireless isolation" setting, as I tend to stay as far away as I can from the type of "consumer products" that make all the decisions for you. This is a good example of why I dislike the concept, "wireless isolation" is actually a firewall function in the router whose rules are invisible and unconfigurable to the user. Although I see the need to isolate networks into different zones (which is one of the fundamental concepts of traditionsal firewalls), it would be much better if the configuration was transparent on what it did and and that it was possible to define the traffic rules manually. I guess that's Apple's legacy that we all will have to suffer from for many years to come, the fact that removing choice and freedom has somehow been celebrated as "user friendly" by ignorant people. What I don't understand is why it's so difficult to do both with a system of templates that applies actual rules that can be viewed and configured. The ignorant could then simply apply templates (for example "wireless isolation") while those that bothered to spend more than 2 minutes researching the subject could make more intelligent and tailored decisions. But, that's a different discussion
What is relevant to UMS is simply that any shape or form of firewall that blocks the traffic that's needed between UMS and the renderer, will create problems. Thus, putting UMS and a renderer on separate sides of a "wireless isolation" firewall won't work.
When it comes to unstable/buggy routers it's certainly not something that can be ruled out, but it can be very difficult to pinpoint. That's why I prefer that people connect UMS and the renderer to wired networks just separated by a switch when trying to diagnose problems. But, that's not always possible either because ethernet ports aren't available or because it would require a great deal of wiring. People should try to temporarily move some of the equipment so that they can be connected with wires if at all possible when diagnosing, it could quickly reveal if it's a UMS or a network problem. In my experience unstable/buggy routers is most common in the cheapest routers, and can be caused both by buggy firmware or failing hardware. In most cases, the router won't reveal anything in logs. I've for example seen routers that slowly consume their state table, and when it's full it starts doing all kind of weird stuff (because it can no longer track the different connections it's handling). A restart will make it work well again - until the state table is full again. If no firmware update fixing the problem is available, such a router belongs to the bin unless it's possible to install dd-wrt or another custom firmware on it. The "unofficial" firmwares generally gets much more attention and bug fixes.
When it comes to subnets I agree that it's easy once you understand it. The problem is that the terms used is foreign to most people, and that subnet masks only make sense to people that's used to "binary math" - which is mostly confined to developers of fairly low level software/firmware. The fact that there's
two different notations and the fact that there seems to be fairly random which notation is used in a given configuration makes it even more confusing. The fact that IPv6 use a lot more bits and use hexadecimal notation instead of decimal makes this even more of a mess, not to mention the
"short forms" implemented in IPv6 which implies values "impossible" to guess for those that doesn't know it. In short, there's a lot of reasons why the really simply underlying system of IP addresses and subnets are obscured and made difficult to grasp.
To try to explain it simple I'd say that a subnet mask is a set of numbers that limits the allowed values for the corresponding IP address numbers. The problem is that since this restriction is on a binary level, it's not obvious the a person thinking in decimal. The fact that the first "value" of a subnet is used to describe the subnet it self and isn't a valid IP address is also something that can confuse. The easiest way to know the effect of a given mask, is to use a
subnet calculator. In IPv4, 192.168.10.10 with a subnet mask of 255.255.255.255 is confined only to that address itself. You could say it's a subnet of only 1 address. On the other extreme, 10.0.0.0 with subnet mask 255.0.0.0 describes all addresses from 10.0.0.1 to 10.255.255.254. It's easier to see why in binary notation, the first example is in binary:
Code: Select all
1100 0000.1010 1000.0000 1010.0000 1010 with subnet mask 1111 1111.1111 1111.1111 1111.1111 1111
The second example is in binary:
Code: Select all
0000 1010.0000 0000.0000 0000.0000 0000 with subnet mask 1111 1111.0000 0000.0000 0000.0000 0000
The subnet mask simply allows any bit with a "0" in the mask to change, while any bit with a "1" in the mask is "frozen".
Thus, is the first example all bits are frozen and only the one address itself is allowed, while in the second example only the first value (10) is frozen and the rest can be anything, meaning that the described range is:
Code: Select all
0000 1010.0000 0000.0000 0000.0000 0000 to 0000 1010.1111 1111.1111 1111.1111 1111 (10.0.0.1 to 10.255.255.255)
But, since the last address of any subnet is reserved for broadcast, the allowed range is
Code: Select all
0000 1010.0000 0000.0000 0000.0000 0000 to 0000 1010.1111 1111.1111 1111.1111 1110 (10.0.0.1 to 10.255.255.254)
Because of the broadcast address reservation, the subnet described in my first example isn't a valid subnet, as the one available address would be the broadcast address. It's still used though, as a broadcast address isn't relevant in a single IP context (there's nobody to broadcast to). The smallest "valid" subnet therefore has a mask of 255.255.255.252, which mathematically gives an address space of 4 - of which the first is lost to the "subnet description address" and the last is lost to the broadcast address, ending up with and effective range of only 2 addresses. Thus, 192.168.0.0/255.255.255.252 allows IP addresses 192.168.0.1 and 192.168.0.2.
As a consequence, what you're saying about Windows automatically setting the correct subnet mask isn't correct. There is no "correct" subnet mask, it's up to whoever that defines the subnet (address range) what the subnet mask should be. What Windows does is to suggest the "default" subnet mask for the
private IPv4 address space the value you enter belongs to. It works well for the 192.168.x.x range (as the 255.255.255.0/254 address/class C subnet has become a de-facto standard subnet for home networks), but it is in my opinion completely useless for the 10.x.x.x range where it suggest a subnet of 16777214 addresses. I'd like to see the home, or business, where that's a reasonable address space. As such, the range you suggest of 10.0.0.1 - 10.0.0.254 doesn
not correspond to the 255.0.0.0 subnet mask you describe for that subnet. The subnet confined to addresses 10.0.0.1 - 10.0.0.254 is actually 10.0.0.0/255.255.255.0.
When it comes to the default gateway I also disagree. The default gateway is simply an address to which the NIC will send request for all addresses for which is doesn't already know where to find. As such, it should be your router if you have a single subnet and a single router because that means that the router will be queried for any addresses not belonging to the local subnet that doesn't have a defined route. However, when there are multiple subnets and routers involved, it might not be so obvious where the default route should be. There are multiple ways to configure this, so I won't go into the defails here, I'd just like to state that it shouldn't "always be your router's IP", and that it could very well have to do with your media server and renderers if your network isn't a single subnet, single router configuration.
When it comes to DNS that's a chapter in itself, where many things come into play. Usually you'd not want to use your ISP's DNS if you don't want to be sensored or watched by your government. DNS has nothing to do with UMS and DLNA though, as DLNA forbids the use of name resolution and requires the use if IP addresses in all but a few rare circumstances. UMS and the renderers will therefore communicate without DNS being configured or working at all. To give a very short description of what DNS is, it stands for Domain Name System and what it does is to translate to domain names into IP addresses (e.g
http://www.universalmediaserver.com -> 65.23.155.8). Think of the domain names as names of people or businesses, IP addresses as phone numbers and DNS servers as the phone directory which translates a given name into a phone number. A networked device always use IP addresses (phone numbers) to make the actual connection/request, so it always first has to query DNS to "translate" a domain name into an IP address. This is why governments love to both sensor and record DNS'es, it allows them to tell your ISP which names they are forbidden to give out the numbers to and the log of your DNS queries can tell them a lot of what internet resources you access. It's very easy to use other DNS servers though, the problem can be to find one that you know you can trust not to report your activity to the government or sensor you. One big problem with DNS is that the standard doesn't support encryption, so all your queries are sent out on the internet readable to everyone that can get their hands on your packet (which is anyone controlling any of the routers you have to pass to get to the DNS server and those controlling the DNS server itself). If you run your own DNS server (some routers do, although most only implement a DNS proxy which only forwards your DNS requests to the DNS servers configured in your router) you can avoid this alltogether, because your query never leaves your local network. DNS servers themselves has to get the information from the internet though, but it's done in a different way where your DNS server will contact one of several pre-defined "root DNS servers" that will forward it to one of the DNS servers responsible for the domain name in question. Once your DNS server has retrieved this information, it will store it and won't query the same information again until the value has expired (a given amount of time has passed, which is defined per domain). The traffic is still unencrypted and possible to track, but it's more difficult to both sensor and get a complete picture of which internet resources you visit. The only way to be able to use DNS to resolve resources (like your home computers) on a private network, is to run your own DNS server - and even then it might not be straight forward.
When it comes to the WINS settings I disagree as well. There is no "danger" in changing the WINS setup, in most circumstances it won't make any difference though, as you need to have access to a WINS server for it to work. Ironically WINS is short for Windows Internet Name Service, although to my knowledge it has never actually been used on the Internet. It was one of Microsoft's solutions for name resolution, but it was beated by DNS. It has some major disadvantages for use on the internet, it doesn't have the well known dotted "scope" notation that DNS does (foo.bar.com), so instead of "
www.universalmediaserver.com" it would be just "universalmediaserver". While this is simpler to use, it doesn't go well with all the different jurisdictions that the real world consists of where different entities control different "top level domain names". It has no encryption or authentication just like DNS, but unlike DNS it also allows clients to register for a given IP address. On the internet that would mean complete anarchy, e.g anyone could claim "universalmediaserver". On a private network on the other hand, it's perfect as I see it. You don't have a problem with your devices trying to steal eachothers names on a private network, neither do you have the need for different entities controlling different parts of the name space - and the fact that every device that supports it automatically registers its address makes it more or less "maintenance free". Normal DNS requires manual registration and configuration, which means any name that is to be resolved has to be put there by someone. There is something called dynamic DNS that allows the same kind of automatic registration as WINS, but in my experience it's not well enough standardized or commonly enough implemented to be really useful outside corporate Windows networks. However you put it, if you want name resolution on your local network using WINS or DNS, you'll need to run a local DNS or WINS server. I love and still use WINS both because it requires so little configuration to work and because it's nice to be able to separate local name resolution from internet name resolution. The two will work simultaneously, allowing the network device to query both services, which nicely encapsulates your local name resolution and makes it completely independent.
I do agree with you that most people should disable their Windows firewall because their router should do the firewalling task. When private IP subnets are used, something called NAT is used in the router which "translates" your private address to the router's public/internet address. That means that any device going out on the internet looks like its your router, and it's not possible to contact them from the outside since the private addresses aren't routable from the internet. However, "port forwarding" limits this protection somewhat, and that what it actually does is to tell your router that any incoming traffic on the specified port or port range should be forwarded to a given private address, effectively exposing that or those ports to access from the internet. Depending on which ports are being forwarded and what services is listening to those ports on the target address, it might or might not pose any security threat. Normally it's quite harmless, but what I really dislike it routers with UPnP enabled. What it does is that it allows devices on the inside, to set up port forwarding without the user's knowledge. The rationale is that most people don't understand port forwarding and that it's the only way to get services that requires internet access to work. The downside is that it effectively allows any sneaky software or device connected to your private network to open up any "holes" they want in your router, exposing internal devices. It's like having a top quality lock on your house and then give away the key to anyone that visits the house. It's not something I'd recommend, so I'd say that assuming that you've disabled UPnP in your router, turning off the Windows firewall is safe. There is one more problem though, and that is IPv6. If your network is configured with IPv6 without NAT, your network might be reachable from the outside, again depending on how your router is configured. I don't see the need for IPv6 on private networks though, so if you just stick to IPv4 on your internal network, that won't pose a risk either. When it comes to laptops that you sometimes use to connect to other Wifi networks, it's a different matter. You have no control or knowledge of whether such a network is "secure", so running a local firewall under such circumstances is a must. To sum it up, if you:
- Use a private IPv4 network range in your home network and either has disabled IPv6 or your routers is configured to now allow any incoming IPv6 traffic.
- UPnP is disabled in your router.
- You don't travel and connect to other networks with the computer running UMS.
- You trust the other devices on your local network (i.e that there's noone there with malicious intent)
It should be safe to turn of your local firewall on the computer running UMS. I believe that the above applies, or can very easily be configured to apply, to most home networks - and thus the whole firewall headache could be avoided.
When it comes to your description of network discovery, file and printer sharing, share permissions and homegroups, this is completely unrelated to UMS. UMS only needs read access to the shared files locally (given that the files are stored locally), and it will share them using UPnP/DLNA. It's a completely independent system from all the other things mentioned. Be aware however, that UPnP/DLNA doesn't support authentication so it will share its content to anyone on the local network. There is no way to restrict sharing to only a given user, as the concept of a user doesn't exist. You can limit access to UMS per IP address, but in a typical home network with dynamically assigned IP addresses and no "enforcement" of IP address use, it's not much of a security barrier.
I'd also like to know that desktop OS'es use multiple processors just like server OS'es. In reality, there is little or no difference between a "server OS" and a "desktop OS". The core part of the OS is the same, and the difference is mostly what the OS maker allows on the different versions. A Windows "server" are bundled with a lot of "network software" like DNS, WINS permission and policy management tools, Active Directory etc, which Microsoft doesn't make available for a "desktop version" of Windows. In addition, a "desktop OS" usually has more "bloatware" (software you don't need or want) installed, and you can expect other defaults (generally assuming that you're stupid and that everything should benefit Microsoft, not you). If Microsoft did make those services available for download for a "desktop OS" and skipped the bloatware and the stupid defaults, it would be no difference between the two. That's why when you install Linux, you can often choose if you want to install a "server" or a "desktop". It simply a matter of which features/software are installed and what the default configuration is.
UPnP is simply a standard that define a set of protocols to use when network devices communicate with each other. It's not very strict, so it leaves a lot of room for incompatible implementations, and it makes some assumption about your network that limits under which circumstances it will work. There are different "sub standards" of UPnP, one of which is UPnP AV (Audio Video) which is what DLNA is based on. UPnP AV has nothing to do with UPnP used to configure routers except that the basic discovery and service scheme is the same. UMS or DLNA renderers cannot communicate with an UPnP enabled router any further than actually seeing that it's there. The "rest of the rules" for communications belong to different "sub standards" which makes them unable to actually interact in any meaningful way. The most "limiting" part of UPnP is the assumption is makes about all devices being on the same IP subnet. Because of the widespread use of wireless routers, that's often not the case anymore, and this is what causes the most trouble. "Normal" IP traffic is unicast, that is a communication from one address to another address. This communications isn't sent to all the other devices on the network. UPnP use multicast for discovery, which behaves differently. Multicast is sent to all devices, and anyone that listens will receive the information. Think of unicast as a normal phone conversation and multicast as a radio broadcast. Multicast is "one way", you can't reply directly to a multicast message (just like a radio broadcast). However, anyone receiving the information can either broadcast their own message (setting up your own radio station) which could works as a very inefficient way to reply, or the listeners interested in the message could contact the sender directly via unicast (like when someone makes a call to a radio show after they have broadcast something that the listener is interested in replying to) which is how UPnP actually work.
The problem with multicast is that since it doesn't have a destination address and is meant for "everyone", networks would quickly be heavily congested if routers forwarded multicast messages to other subnets. If would mean that if I send a multicast message while being connected to the internet, that message would travel to every other router on the internet and in the end to every device connected to the internet. It's easy to see how this would instantly overload the network and make it break down. As a consequence, multicast packages aren't routed by default, and many cheap routers doesn't even support routing multicast packages. In addition, it has to be configured how you want the multicast traffic to be routed. In short, this is way to difficult for the regular user, which is why I usually just state that "UMS and the renderers must be on the same subnet". It's not actually true, but because of the challenges with multicast routing (difficult configuration, often not supported) that is the reality for all but the tech savvy. To be able to correctly identify each other, multicast needs to work both from UMS to the renderers and the other way. Once the initial communication is estabilished, most of the communication is done using regular unicast that doesn't have any problems traversing subnets. Multicast is still needed after discovery though, as every device has to announce its presence at regular intervals, and the UPnP standard dictates what when the regular broadcast isn't received, a device is to assume that the other device isn't connected to the network anymore.