Hi!

I'd like to multicast over wireless on a WRT54GL.
Sounds simple, but apparently, it is not.
Did anyone succeed in this?

Multicasting between ethernet vlans (e.g. eth0.0 and eth0.1) works by using igmpproxy
and a recompiled 2.4 kernel with multicast support. If somebody needs help on this, just
drop me an email!

However, multicasting over the wireless interface does not work. Two choices:

a. multicast routing over wireless
I broke up the bridge and tried to route multicast over wl0 as a downstream interface
for igmpproxy, just like e.g. eth0.1. Unfortunately kamikaze freezes when I  run igmpproxy
so I'd suspect a kernel problem.

b. multicast bridge over wireless
Here I bridge the wl0 interface to the upstream ethernet interface (the multicast source).
igmpproxy is not needed then but does not freeze the system if run either. It could still be
used to route multicasts to another ethernet interface (e.g. eth0.1).
Multicasts are apparently delivered (tcpdump shows multicast udp packets on the bridge and
the wl0 interface and the wlan LED is flashing) but the wireless is effectively dead. Almost no
packets are received on the client side. If you ping the client, you get 99% packet loss with
an avg. RTT of 20 or more seconds. Multicasts packets do not arrive at all.
This is not a bandwidth problem because the multicast packets would just need about 1/4
of the wireless net rate and traffic shaping does not help either. Therefore, I'm suspecting
a kernel (driver?) problem here too.

Any hints to get this to work are appreciated! Thanks!

Hi hondo20,

multicast over wireless doesn't work.

You can increase default rate (which is 1mbps) and you will get something better
# wl mrate X (with X the rate in the basic set rate : 1, 2, .., 11, ...54)

But it's still an unreliable stream since there is no ack in multicast.

Interesting. Do you know _why_ multicast over wireless does not work?
I cannot see why it should not. After all, it is usually just a stream of udp packets.
Bandwidth and reliability (packet loss) are related to any packets, not only to multicast, right?

Unfortunately, changing the settings of 'wl mrate' did not help. Wireless is effectively dead.

Therefore, is it a limitation of the proprietary broadcom driver for the 2.4 kernel or a bug in the 2.4 kernel elsewhere?

If so, I could probably wait for the 2.6 kernel/b43 driver to work on the WRT54GL.
Otherwise, I'd need to move to a different platform.

Thanks in advance for any comments helping me in my decision whether to stay with the WRT54GL or not.

Update: multicast can be transmitted over wireless but apparently not received.

I've configured the WRT54GL with kamikaze 8.09.1 (2.4 kernel with multicast support enabled) in AP mode with WPA2 security.
Wireless is bridged to an vlan (eth0.0) which is the upstream multicast source.

So far I've tried another WRT54GL with kamikaze too to create a wireless bridge to receive multicasts.

Now I've tried a different wireless client (Linksys WUSB54G v4 under OpenBSD 4.5) and the multicast packets
were received without a problem. Logging in via ssh over wireless to kamikaze worked too. In fact, some
bandwidth measurements using iperf showed about 14,5 Mbit/s available bandwidth, all while receiving mulitcast.

Update 2: "wl mrate 54" on the AP does help a little: It makes the WRT54GL work as a wireless client again.
I can now login from/to both wireless clients while the AP is multicasting.

There is just one problem left:
On the WRT54GL client, I do not see any multicast packets arriving on the wireless interface (LED does not blink either).
Maybe some other magic wl command required?

Hi,

It's not that multicast doesn't work at all, it's that multicast doesn't work very well because of how it's design in IEEE802.11.
If you look at IEEE802.11 specifications, you can see that there is no ack mechanism in the MAC protocol for multicast.

- It means that you don't know if the frame has been received correctly. (in unicast there is an ack mechanism so it's more reliable)
- That means also the contention window keep the minimum size either there is collision or not. And if multicast doesn't increase its contention window and unicast does, multicast stream will be likely sent first.

for update2:
there is other wl command... try `wl --help' hope it can help you.

Hi kirap! Thanks for you reply!

Probable packet loss because of the lack of acknowledge packets is not a concern for me.
I'd like to multicast an udp packet stream anyways where delivery isn't guaranteed either.

The problem is that I do not see any multicast packets _at all_ on the wireless interface (using tcpdump) when
I run kamikaze on a WRT54GL as a wireless client (station mode). As if they're filtered before they're fed to the kernel.
As written in update 1), the multicast packets are delivered over wireless in AP mode because I can receive them
with a different client.

I've already checked the 'wl -h' output. Nothing obvious. But then I would not have guessed that I had
to manually set the mrate parameter. The default value of 0 (auto) did not not work.
Therefore, thanks again for that hint, otherwise my AP would not multicast.

update 3: got multicast working on the client briefly (no stable stream, kamikaze froze) with broken up wireless-lan bridge and
igmpproxy in between (wl0 upstream, eth0.0 downstream). But at least I saw some udp multicast packets...
However, I'm still curious why I don't see any packets if the client is configured as a wireless bridge.

update 4: Scrapped the routed/igmpproxy setup on the client due to bad stability.
Got multicast over wireless working by tunneling through an OpenVPN bridge
(bridge of eth0.0, wl0 and tap0 on each side). I'll investigate a gre tunnel next.

Just in case someone finds this thread and is curious:
I got multicast over wireless working by using an openvpn tunnel.

Here's a brief description. If there a more questions, please be sure to also send me a PM!
This should work for whiterussian and kamikaze. I've used kamikaze 8.09.1.

The box setup is as follows:
IPTV-router <--cable--> WRT54GL (AP) <--wireless--> WRT54GL (STA) <--cable--> IPTV-Settopbox
In the end the settopbox should believe it is directly connected to the IPTV-router.

The steps that got multicasting over wireless working for me:
* break up the bridge between lan and wireless, i.e. use routed configuration
  (directly multicasting over the wireless bridge never worked for me).
* create a bridge with only the lan interface connected. Openvpn's tap interface will be
  bridged to it. The wireless interface is not connected to a bridge.
* setup (preferably encrypted) wireless network between AP and STA.
* install openvpn and setup a server on the AP and an openvpn client on the STA (configs follow),
  both using a tap interface bridged to the lan interface. The multicast packets will be captured
  there and tunneled over wireless, encapsulated within the openvpn packets.
  I also tried to use gre tunnels first, but gre interfaces cannot be bridged. That's why I turned to openvpn.
* make sure that both the lan and tap interfaces are set into promiscuous _and_ allmulti mode.

openvpn server config:

cd /tmp/openvpn
port 1194
float
proto tcp-server
dev tap0
up       /etc/openvpn/scripts/up.sh
down-pre /etc/openvpn/scripts/down-pre.sh
script-security 3
secret /etc/openvpn/secret.key
cipher none
auth   none
no-iv
no-replay
mute-replay-warnings
persist-key
persist-tun
status /tmp/openvpn/status.log 60
verb 4
mute 5
mssfix 1440
sndbuf 131072
rcvbuf 131072
txqueuelen 1000

openvpn client config:

cd /tmp/openvpn
remote 192.168.1.1:1194
remote 192.168.2.1:1194
float
proto tcp-client
dev tap0
up       /etc/openvpn/scripts/up.sh
down-pre /etc/openvpn/scripts/down-pre.sh
script-security 3
secret /etc/openvpn/secret.key
cipher none
auth   none
no-iv
no-replay
mute-replay-warnings
persist-key
persist-tun
status /tmp/openvpn/status.log 60
verb 4
mute 5
mssfix 1440
sndbuf 131072
rcvbuf 131072
txqueuelen 1000

Notes about the openvon configuration:
* The client tries to connect over lan (192.168.1.1) first, then over wireless (192.168.2.1). That way, I can connect the STA to the lan
  where available,
* I'm using a shared secret instead of a PKI with certificates to simplify matters as I only connect a single settopbox.
* Using tcp as a transport worked better for me (less hiccups). YMMV, though, so please also try udp transport.
* To lighten the CPU load on the WRT54GL, I run openvpn without _any_ encryption and _no_ authentication! Beware!
  The openvpn tunnel is _only_ used as a transport, so I'd recommend to secure the wireless link with at least WPA or better WPA2.
* Two scripts are run when openvpn connection is established (up.sh) and lost (down-pre.sh) to ensure the interfaces have the proper flags set
and to add the tap interface to the lan-bridge. The scripts contents (don't forget to make them executable):

up.sh:
#!/bin/sh
/sbin/ifconfig $1 promisc multicast allmulti up
/usr/sbin/brctl addif br-lan $1
/sbin/ifconfig br-lan multicast allmulti

pre-down.sh:
#!/bin/sh
/usr/sbin/brctl delif br-lan $1

Last but not least, I tuned the tcp stack a little because of the use of the tcp transport.
I've added this to /etc/sysctl.conf:
net.core.rmem_max = 262144
net.core.wmem_max = 262144
net.core.rmem_default = 131072
net.core.wmem_default = 131072
net.ipv4.tcp_rmem = 16384 131072 262144
net.ipv4.tcp_wmem = 16384 131072 262144
net.ipv4.tcp_mem  = 16384 131072 262144
net.ipv4.tcp_moderate_rcvbuf=1
net.ipv4.tcp_timestamps=1
net.ipv4.tcp_rfc1337=1
net.ipv4.tcp_frto=1
net.ipv4.tcp_dsack=1
net.ipv4.tcp_sack=1
net.ipv4.tcp_fack=1
net.ipv4.tcp_window_scaling=1
net.ipv4.tcp_westwood=1
net.unix.max_dgram_qlen=100

So, I hope this helps somebody.

PS: I've subscribed to this topic, so no need for a PM, just reply here.

hondo20 this is very good news. i will try today.
but what about another system configs ?
you change them ? or all configs the same as default ?

UPD: which mode you use for wl0 ? None ? loopback ? Bridge ?

(Last edited by zhecka on 22 Nov 2009, 09:46)

What do mean with "another" system configs? What exactly do you want to know?

That is, you setup regular wireless connectivity with wl0 in routed mode (no bridge attached, wl0 is an independent interface).
The multicast packets are tunneled over wl0 through openvpn.

wait
i'm install now 8.09.1
igmpproxy agais say
--- Cut ---
Debu: Physical Index value of IF 'br-lan' is 8
Debu: buildIfVc: Interface br-lan Addr: 192.168.200.1, Flags: 0x1043, Network: 192.168.200/24
Debu: Found config for eth0.1
ERRO: MRT_INIT failed; Errno(99): Protocol not available
--- Cut ---

brctl show two bridged interfaces
root@OpenWrt:/etc# brctl show
bridge name     bridge id               STP enabled     interfaces
br-lan          8000.001d7e43c6ba       no              eth0.0
                                                        wl0
what i need to do ?
delete wl0 from bridging or leave as is ?
or just up openvpn with your configs and all is be ok ?

libsopenssl eats all space at my filesystem how you resolve this problem ?

Either not to install libopenssl or add an external partition, i.e. SD card hack or a USB2 memory stick if your device has a USB2 port, etc., and make it to boot off from the external partition.

i have a new idea about iptv over wi-fi.

we have eth0.1 as external interface(uplink). my provider give nonroutable ip for each new user.
i'm trying create a bridge between eth0.1 and tap0. but i lost my internet connection

igmpproxy is not required anymore, as the settopbox is now "directly" connected (through the tunnel).
That is why I did not mention it in comment #10.

Regarding the space/openssl:
I've created a custom kamikaze by using the build system of the 8.09.1 version.
There I've added the additional packages, like openvpn and openssl.
Saves a lot of space because everything gets compressed.
However, if you want to recreate my setup, you should be able to get away by installing 8.09.1 and just
openvpn with the required packages (like openssl, liblzo). There should be enough space for that.
It seems to me you've got other additional packages installed which are eating your filesystem space.

Regarding the interfaces:
As I said before, you need to switch to routed wireless, i.e. break up the bridge eth0.0 wl0. You do this by
specifying the wireless interface name (e.g. wifi) in /etc/config/wireless, instead of the bridge name.

So, yes, you remove wl0 from the bridge but leave eth0.0 bridged:
Without openvpn running, _only_ eth0.0 is attached to the bridge. "brctl show" should list:
bridge name     bridge id               STP enabled     interfaces
br-lan          8000.001d7e43c6ba       no              eth0.0

With my setup, openvpn will run up.sh which will attach the tap0 interface to the bridge.
brctl show with active openvpn would show:
bridge name     bridge id               STP enabled     interfaces
br-lan          8000.001d7e43c6ba       no              eth0.0
                                                                        tap0

Regarding comment #17:
I'm not sure what you're trying to do. What is your IPTV upstream source?
Where would you connect the settopbox (if there is any) without the openwrt router?

One more note about igmpproxy:
You need it if you want to _route_ multicast and igmp packets. You would then also need to build a custom kernel with
kernel options CONFIG_IP_MROUTE, CONFIG_IP_PIMSM_V1 and CONFIG_IP_PIMSM_V2 enabled.

This is not required with the setup from comment #10 because here the multicast upstream source (eth0.0 on AP) is _bridged_
to the multicast downstream destination (eth0.0 on STA) by the openvpn tunnel. So, no igmp or multicast packets are routed but
anything over wireless, such as the openvpn packets, is routed.

Maybe you're confusing bridged and routed networking?

i love FreeBSD and PF
iptables routing algorithms is very very strange for me
Ofcourse i can read manuals and set up iptables as i need.
But i see some architectural problems for my understanding.

I have a idea, but cannot realize it.

We have some network interfaces eth0, wl0, lo0 and their surrogates eth0.0, eth0.1 and other. eth0.1 - uplink, eth0.0 - our lan. wl0 - our wireless.
We can create bridge br-wan interface with eth0.1 as single bridged interface. Then we up openvpn and add tap0 to this bridge interface. Now at tap0 interface we see all network traffic which comes to eth0.1.
OpenVPN which used as transport level can forward all this traffic to our computer(wireless router).
Now it is ok. But i can't change br-wan macaddress , can't nat and route packets over this br-wan interface.

i see traffic at my tap interface on my computer, but i lost internet connection. I see wan, but can't see any other resources. I think problem inside iptables rules, but not sure about this. Can you help me with this ?

upd: change wrong interfaces names.

(Last edited by zhecka on 22 Nov 2009, 18:36)

i'm found very simple method opkg install -d ram tcpdump
i don't need tcpdump anytime, but can run it when it needed for me.

I did not mention about the firewall or iptables in comment #10 because iptables firewalling is not an issue here.
You create a _bridge_ between the lan interfaces on the AP and STA. Therefore, to filter the packets, you'd
have to use ebtables to control the packets through the bridge. iptables is for _routed_ traffic only, i.e. you cannot
filter the packets through the bridge with iptables.
You basically build something like a "split" switch, it's ethernet ports both on the AP and on the STA.

Before you try to bridge your wan interface, you should try to create a basic _working_ wireless configuration first.
Then break up the bridge lan-wireless. Once that works, you can add openvpn.

If you simply _bridge_ tap0 to your wan interface, this should not change anything (like NAT, routing or firewalling)
because this is all about _routed_ packets. However, you should replace "wan"  with "br-wan" in /etc/config/firewall to
filter on the bridge itself (Note that eth0.1 of br-wan should not have an IP address assigned, only the bridge br-wan interface).

But honestly, I do not understand what you're trying to do.
What devices to you want to connect? What is multicast source and what is the destination?

hi,

i intend mx kamikaze box (asus500gp) to become a multicast router. after getting puzzled by dozens of outdated fragments of mcast docu, i'd prefer to take you by your words.
could you specify what you did to get multicast up and running before you encountered the wireless problem?

thanx,
/markus

To route multicast packets, you need:
a) a kernel which is capable of routing them (see comment #19). Recent kamikaze releases should already have this set, I think.
b) proper firewall rules. That is basically:
* allow forwarding of udp packets to 224.0.0.0/4
* allow forwarding of igmp protocol

However, I'd strongly recommend that you have a look at udpxy (see https://forum.openwrt.org/viewtopic.php?id=23807).
It is an multicast proxy (not only igmp), so you need neither igmpproxy, forwarding rules in your firewall nor worry about the kernel.
You only need to open your firewall to accept igmp and udp 224/4 locally (INPUT chain).

udpxy works very fine. Haven't tried over wireless yet, though.
Once launched, say on port 4022, visit http://ip-address:4022/status for a usage template.
To use, simply replace a multicast address like udp://239.0.2.67:8202 with http://ip-address:4022/udp/239.0.2.67:8208
ip-address is the IP or DNS name of the machine running udpxy, of course.

Hope that helps!

I'm using udpxy over wireless and it's working very well.