Why do some WiFi routers block multicast packets going from wired to wireless

Source: http://superuser.com/questions/730288/why-do-some-wifi-routers-block-multicast-packets-going-from-wired-to-wireless

It's usually due to bugs in the Wi-Fi home gateway routers (APs), or sometimes in the wireless client chipsets/drivers/software. On Wi-Fi, sending multicasts from the AP to the wireless clients (this is known in the standard as "From the Distribution System" or "FromDS") is tricky, so there are lots of ways it can fail, and it's easy to introduce bugs. Even though the radio medium is unreliable enough that 802.11 unicasts are required to have link-level acknowledgements (ACKs) and get retransmitted several times if there's no ACK, FromDS multicasts are never ACKed because they'd need to be ACKed by all the wireless clients of the AP, which could be quite an "ACK storm". So instead, FromDS multicasts have to be sent at a low data rate; using a simpler, slower, easy-to-decode-even-at-low-signal-to-noise-ratios modulation scheme, that can hopefully be received reliably by all the clients of the AP. Some APs let the administrator set the multicast rate, and some administrators unwittingly set it too high for some of their clients to receive reliably, breaking multicast delivery to those clients. When WPA (TKIP) or WPA2 (AES-CCMP) encryption is in use, FromDS multicasts have to be encrypted with a separate encryption key that is known to all of the clients (this is called the Group Key). When a client leaves the network, or every hour or so, just for good measure, the Group Key needs to be changed so that the client that left no longer has access to decrypt the multicasts. This "Group Key Rotation" process sometimes has problems. If a client doesn't acknowledge receipt of the new group key, the AP is supposed to de-authenticate that client, but if it fails to do that due to a bug, a client could have the wrong group key and thus be "deaf" to multicasts without realizing it. When WPA2 "mixed mode" is enabled (that is, when both WPA and WPA2 are enabled at the same time), the FromDS multicasts typically have to be encoded with the TKIP cipher, so that all clients are guaranteed to know how to decode it. FromDS multicasts have to be queued up by the AP and only transmitted at times when all clients who care about multicasts can be expected to have their receivers powered on. The time between the "safe to transmit FromDS multicasts" periods is called the "DTIM interval". If the AP or clients screw up their DTIM interval handling, it could result in clients unable to receive multicasts reliably. Some APs have features to keep wireless clients from being able to talk directly to each other, to maybe keep your wireless guests from hacking your other wireless guests. These features usually block multicasts from WLAN devices to other WLAN devices, and could well be implemented in a naive way that even blocks multicasts from LAN to WLAN. The crazy thing is, "ToDS" multicasts are done just like ToDS unicasts, and so they rarely break. And since ToDS multicasts (not FromDS multicasts) are all that are needed when a wireless client gets a DHCP lease and ARPs to find its default gateway, most clients are able to get connected and surf the web, check email, etc. even when FromDS multicasts are broken. So a lot of people don't realize they have multicast problems on their network until they try to do things like mDNS (a.k.a. IETF ZeroConf, Apple Bonjour, Avahi, etc.). A couple other things to note, regarding wired to wireless multicast transmissions: Most LAN multicasts, such as mDNS, are done using special multicast address ranges that are not meant to be routed across routers. Since Wi-Fi-capable home gateways with NAT enabled count as routers, mDNS is not meant to cross from WAN to [W]LAN. But it SHOULD work from LAN to WLAN. Because multicasts on Wi-Fi have to be sent at a low data rate, they take up a lot of airtime. So they're "expensive", and you don't want to have too many of them. That's the opposite of how things work on wired Ethernet, where multicasts are "less expensive" than sending separate unicasts to each machine "tuning into a multicast video stream" for example. Because of this, many Wi-Fi APs will do "IGMP Snooping" to watch which machines are sending Internet Group Management Protocol (IGMP) requests, expressing their desire to tune into a given multicast stream. Wi-Fi APs that do IGMP Snooping won't automatically forward some classes of multicasts onto the wireless network unless they see a wireless client try to subscribe to that stream via IGMP. The documents that describe how to do IGMP Snooping properly make it clear that certain classes of low-bandwidth multicasts (mDNS fits in this category) are supposed to always be forwarded even if no one has explicitly asked for them via IGMP. However, I wouldn't be surprised if there are broken IGMP Snooping implementations out there that absolutely never forward any kind of multicast until it sees an IGMP request for it. tl;dr: Bugs. Lots of opportunities for bugs. And occasional poorly-designed features and configuration errors. Your best defense is to buy high-quality APs from companies that care about making sure multicasts work. Since Apple loves Bonjour (mDNS) so much, Apple's APs are probably the most consistently excellent at passing multicasts reliably, and Apple's Wi-Fi client devices are probably the most consistently excellent at receiving multicasts reliably.

how to start/stop and disable/enable a service in Ubuntu

http://askubuntu.com/questions/19320/how-to-enable-or-disable-services

Look at the 2nd answer.

Backup:

Currently there are actually 2 different ways for software to be started as a service in Ubuntu. A service is defined here as a program run by the system in the background, as opposed to one started and run directly by the user.
The traditional way to start services in Linux was to place a script in /etc/init.d, and then use the update-rc.d command (or in RedHat based distros, chkconfig) to enable/disable it. This command, btw, uses some mildly complicated logic to create symlinks in /etc/rc#.d, that control the order of starting services. If you run ls /etc/rc2.d you can see the order that services will be killed (K##xxxx) and started (S##xxxx).
The issue with that was that when booting the system, everything had to be done in serial, one thing after another, making system boot times really slow. Attempts were made to parallelize this, but they were haphazard and hard to take full advantage of. This was the main reason that Upstart was created.
Upstart uses job definition files in /etc/init to define on what events a service should be started. So, while the system is booting, upstart processes various events, and then can start multiple services in parallel. This allows them to fully utilize the resources of the system, for instance, by starting a disk-bound service up while another CPU-bound service runs, or while the network is waiting for a dynamic IP address to be assigned.
You can see all of the upstart job files by running ls /etc/init/*.conf
Let me just stop here and say that if you don't know what a service is, or what it does, DO NOT disable it!
Not all services have been converted to upstart. While working on the server team at Canonical for the past few months, I've worked on a number of converted job files, and the nicest part is that it allows one to get rid of all the script "magic" and just put in a few commands here and there to define exactly how to start the service, and nothing more. But for now, only a handful of traditional network services, like squid and samba, have been converted.
In order to figure out if a service is upstart based, you can run the status command:

status servicename

If its an upstart job, it will show this:

$ status statd
statd start/running, process 942

But if its not, you'll see something more like this:

$ status apache2
status: Unknown job: apache2

In this case, apache2 has not been converted to upstart. So, to disable apache2 you just run

sudo update-rc.d apache2 disable
sudo service apache2 stop

Upstart job definitions do not have an update-rc.d command. To disable the job, you need to edit the job file directly to disable it. There are two ways to do this.
If you want to still be able to manually start it, then you need to comment out the 'start on' condition. Say you want to install samba, but not have it start automatically.. here is its job file (in natty):

description "SMB/CIFS File Server"
author      "Steve Langasek <steve.langasek@ubuntu.com>"

start on local-filesystems
stop on runlevel [!2345]

respawn

pre-start script
    RUN_MODE="daemons"

    [ -r /etc/default/samba ] && . /etc/default/samba

    [ "$RUN_MODE" = inetd ] && { stop; exit 0; }

    install -o root -g root -m 755 -d /var/run/samba
end script

exec smbd -F

To disable it, you can just put a # in front of the 'start on local-filesystems'. Note that while it won't start back up on boot, you still need to stop it this time with

sudo service smbd stop

If, however, you never want it to start, I'd suggest actually removing the package. If, however, you want it installed, but not startable, you can also do:

mv /etc/init/smbd.conf /etc/init/smbd.conf.disabled

Starting with the version of upstart that will be in 11.04, there is a new keyword that disables the 'start on' and 'stop on' stanzas, it is 'manual'. So another way to disable the service as of 11.04 is to do:

command using sudo
echo 'manual' | sudo tee /etc/init/mysql.override

command from root shell
echo manual >> /etc/init/mysql.override

And, hopefully real soon, you will be able to create an "override" file to disable a service without editing the job definition at all, by just putting the 'manual' keyword in it.