WL1835 in AP mode does not appear to pass Rx'd multicast traffic

I set up a new SDCard for the beaglebone and copied the prebuilt images to it.  The fault persists.

Put beagle into AP mode (in my case, I connected via USB-serial and deconfigured eth0 and configured wlan to AP with hostapd), then run:

iperf -s -u -B 224.1.1.1 -i 5

connect a client system to the AP (in our case, I used both a system running the WiLink8 as well as a separate test with a different wireless device), and run:

iperf -c 224.1.1.1 -u -T 32 -i 5

 (server and client can be swapped between the two hosts on other test runs, the result seems to be the same)

Drop AP configuration and bind the two hosts to an intermediate AP and run the commands again:

root@am335x-evm:/var/log# iperf -s -u -B 224.1.1.1 -i 5
------------------------------------------------------------
Server listening on UDP port 5001
Binding to local address 224.1.1.1
Joining multicast group  224.1.1.1
Receiving 1470 byte datagrams
UDP buffer size:  160 KByte (default)
------------------------------------------------------------
[  3] local 224.1.1.1 port 5001 connected with 172.16.10.105 port 44403
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0- 5.0 sec   204 KBytes   334 Kbits/sec  11.867 ms  310/  452 (69%)
[  3]  0.0- 9.9 sec   614 KBytes   507 Kbits/sec  15.072 ms  465/  893 (52%)
[  3]  0.0- 9.9 sec  17 datagrams received out-of-order
[  4] local 224.1.1.1 port 5001 connected with 172.16.10.105 port 44403

The number of dropped packets isn't the immediate concern here - the fact that the AP interface doesn't pass any of the multicast traffic is the chief concern, as mDNS relies on this in order to function.

No resolution of multicast between clients when the WiLink8 is the AP.  Associate the two client systems to a consumer router, and mDNS works.

I separately provided tcpdump files correlating to this activity to our TI App Engineer, Michael Questo.

beagle.messages.0.logbeagle.messages.log

I had set a manual route previously with no luck with multicast:

ip route add 224.0.0.0/24 dev wlan1

but your route command seems to work right now (using wlan1 interface for AP mode, not wlan0).

[18:46:51][envoy:~$] route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.11.1    0.0.0.0         UG    40     0        0 wlan0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
172.30.0.0      0.0.0.0         255.255.0.0     U     0      0        0 wlan1
192.168.11.0    0.0.0.0         255.255.255.0   U     0      0        0 wlan0
224.0.0.0       0.0.0.0         255.255.255.0   U     0      0        0 wlan1

This manual route is not necessary for any of the other interfaces or the USB WiFi device which still calls into question why it is necessary.  In prior testing I also took down eth0 and wlan0 configurations and still had the multicast issues on wlan1.

Although Monday is a holiday here, I will be checking mail throughout the weekend.

Thank you for your assistance.

For test, I duplicated your configuration on my Beagle, including that we're using wlan0 (not wlan1) for the AP mode.

With the usual wireless initialization script disabled, I rebooted the Beagle (so a clean slate for wiress config)

This config does appear to function unto itself.

As we need the multicast running on our device with the interface and network address, etc as we have them, we cannot simply adopt your init sequence and configuration files.  I migrated your configurations into the setup I had on the Beagle which mimics ours, and found that even with your specific configuration values, multicast remained non-functional.  The one standout difference was the sequence in which you configure the wlan interface address - we do it BEFORE launching hostapd (which has always worked with our other wireless adapters), but you're doing it after running hostapd.  The order has NO effect on hostapd running and providing non-multicast services, just (apparently) functioning of multicast Rx.

Further, if initialized in the order you present, setting the multicast route turns out to be unnecessary.

To reproduce, simply move your hostapd line down below your ifconfig command.

At this point, we've reworked our initialization around to accommodate this behaviour.  I greatly appreciate your assistance.

As this has not been an issue with our other wireless drivers, some understanding of what is going on would be appreciated - it would seem as if the driver is initializing differently if the hostapd is already running with the interface is brought up versus if the interface is up before hostapd is launched.  Why should it treat mullticast differently?

Thank you for this information.  It certainly appears as if you've run into the same core issue.

When I have an opportunity, I'll apply your patch into a build here and see whether it has an impact on our config.

I don't know if it actually directly applies to the situation we're having, in that this interface is never configured as a station: the WiLink8 has two radios, one we use for client (STA) connections, and the other as an AP - the wlan1 interface is generated solely for AP, and that's the interface we're experiencing this misbehaviour on.

iw dev wlan0 interface add wlan1 type managed

Yes, the interface is created based on an interface which may have been in station mode.

The exchange here with TI was using wlan0 in the test scripts, but our deployed environment uses wlan1, which is itself never configured as a station interface.

Seems to work here too. Thank you! :)