Wifi – Multicast with wifi access points

First I add that some of these replies need clarification.

There are two kinds of overlap, one is channel overlap where the frequencies overlap, and the second being signal overlap.

You MUST have signal overlap for all devices to have coverage in all areas, or even most devices in most areas.

Secondly, there are various schools of thought for frequency overlap and some manufacturers even suggest putting all APs on a common channel. In the case of roaming IP phones this case becomes even stronger as a phone may hop across APs while in a call. This of course depends much on the hardwae of the phones and antenna placement and design.

Let us assume that we had a large open area that we wanted wifi coverage in. Now lets take a pole and place it in the middle of the area. Now we place 4 directional 90 degree antennas on the pole, each 90 degrees from the other . In this situation one may make a strong case for having all APs on the same channel to facilitate roaming. In theory there is little signal overlap but all frequencies overlap.

Now we have an open area with walls on four sides. and place an AP on each of the four walls. The signals WILL overlap from each of the 90 degree antennas , so we may want to consider using separate non overlapping channels on each AP , however there are only 3 non overlapping channels. 1, 6 , and 11. So instead we do the best we can in North America this might be 1, 4, 7, and 11 , each AP having SOME necessary frequency overlap. Of course in a perfect world this might be better accomplished with three APS in a triangular configuration.

In my home I have toyed with APs on Same channel and separate channels and in the end I see little coverage difference., I do see however that some devices such as wireless IP phones can more easily hop to another AP while in a phone call. I see that in most areas I do not have more than 2 overlapping signals and each on channel 4 at present. As I sit here I can launch wifi seeker on my android and see either of the 2 available APs and even connect to either. This of course is easier to test with separate SSIDs but more practical to use common SSIDs fopr everyday use.

In our instance, our problem was solved by sysctl parameters, one different from Maciej.

Please note that I do not speak for the OP (buecking), I came on this post due to the problem being related by the basic detail (no multicast traffic in userland).

We have an application that reads data sent to four multicast addresses, and a unique port per multicast address, from an appliance that is (usually) connected directly to an interface on the receiving server.

We were attempting to deploy this software on a customer site when it mysteriously failed with no known reason. Attempts at debugging this software resulted in inspecting every system call, ultimately they all told us the same thing:

Our software asks for data, and the OS never provides any.

The multicast packet counter incremented, tcpdump showed the traffic reaching the box/specific interface, yet we couldn't do anything with it. SELinux was disabled, iptables was running but had no rules in any of the tables.

Stumped, we were.

In randomly poking around, we started thinking about the kernel parameters that sysctl handles, but none of the documented features was either particularly relevant, or if they had to do with multicast traffic, they were enabled. Oh, and ifconfig did list "MULTICAST" in the feature line (up, broadcast, running, multicast). Out of curiosity we looked at /etc/sysctl.conf. 'lo and behold, this customer's base image had a couple of extra lines added to it at the bottom.

In our case, the customer had set net.ipv4.all.rp_filter = 1. rp_filter is the Route Path filter, which (as I understand it) rejects all traffic that could not have possibly reached this box. Network subnet hopping, the thought being that the source IP is being spoofed.

Well, this server was on a 192.168.1/24 subnet and the appliance's source IP address for the multicast traffic was somewhere in the 10.* network. Thus, the filter was preventing the server from doing anything meaningful with the traffic.

A couple of tweaks approved by the customer; net.ipv4.eth0.rp_filter = 1 and net.ipv4.eth1.rp_filter = 0 and we were running happily.