Avahi / wifi AP mode


#1

Any hints on getting avahi-daemon to work (to list available services) when wifi is configured in AP mode? If possible at all.
When using wifi in STA mode it works well. It seems to be multicast related as all udp unicast and tcp traffic is handled properly.

Using the latest OE build.


#2

Do you confirm avahi listens multicast on wlan0:
cat /var/log/messages | grep avahi

Could you also check you have multicast enabled on the interface:
ifconfig
wlan0 Link encap:Ethernet HWaddr 02:00:2D:4C:25:28
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1


#3

Sure, already checked that and all seems to be ok:

root@dragonboard-410c:~# journalctl |grep avahi
Aug 16 10:35:46 dragonboard-410c avahi-daemon[2487]: Found user 'avahi' (UID 995) and group 'avahi' (GID 995).
Aug 16 10:35:46 dragonboard-410c avahi-daemon[2487]: Successfully dropped root privileges.
Aug 16 10:35:46 dragonboard-410c avahi-daemon[2487]: avahi-daemon 0.6.32 starting up.
Aug 16 10:35:46 dragonboard-410c avahi-daemon[2487]: Successfully called chroot().
Aug 16 10:35:46 dragonboard-410c avahi-daemon[2487]: Successfully dropped remaining capabilities.
Aug 16 10:35:46 dragonboard-410c avahi-daemon[2487]: Loading service file /services/test.service.
Aug 16 10:35:46 dragonboard-410c avahi-daemon[2487]: Network interface enumeration completed.
Aug 16 10:35:46 dragonboard-410c avahi-daemon[2487]: Server startup complete. Host name is TestHostName.local.    Local service cookie is 1843612241.
Aug 16 10:35:46 dragonboard-410c avahi-daemon[2487]: Service "TestHostName" (/services/test.service) successfully established.
Aug 16 10:35:59 dragonboard-410c avahi-daemon[2487]: **Joining mDNS multicast group on interface wlan0.IPv4** with address 192.168.42.1.
Aug 16 10:35:59 dragonboard-410c avahi-daemon[2487]: New relevant interface wlan0.IPv4 for mDNS.
Aug 16 10:35:59 dragonboard-410c avahi-daemon[2487]: Registering new address record for 192.168.42.1 on wlan0.IPv4.
Aug 16 10:36:01 dragonboard-410c avahi-daemon[2487]: Registering new address record for fe80::e4ff:fe7c:e01f on wlan0.*.

root@dragonboard-410c:~# ifconfig
lo        Link encap:Local Loopback  
      inet addr:127.0.0.1  Mask:255.0.0.0
      inet6 addr: ::1%4817440/128 Scope:Host
      UP LOOPBACK RUNNING  MTU:65536  Metric:1
      RX packets:2 errors:0 dropped:0 overruns:0 frame:0
      TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1 
      RX bytes:78 (78.0 B)  TX bytes:78 (78.0 B)

wlan0     Link encap:Ethernet  HWaddr 02:00:E4:7C:E0:1F  
      inet addr:192.168.42.1  Bcast:192.168.42.255  Mask:255.255.255.0
      inet6 addr: fe80::e4ff:fe7c:e01f%4817440/64 Scope:Link
      UP BROADCAST RUNNING **MULTICAST**  MTU:1500  Metric:1
      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
      TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:0 (0.0 B)  TX bytes:4250 (4.1 KiB)

root@dragonboard-410c:~#

#4

I had the same problem. it seems udp broadcast and multicast can not work on ap mode, or our network config is not correct. is anybody know that?
some network info, like below:

root@linaro-developer:~# ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 9137  bytes 562040 (548.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9137  bytes 562040 (548.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.1  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::8aff:fe23:573a  prefixlen 64  scopeid 0x20<link>
        ether 02:00:8a:23:57:3a  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1507  bytes 142387 (139.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@linaro-developer:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0
root@linaro-developer:~#

root@linaro-developer:~# cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
#source-directory /etc/network/interfaces.d

auto lo

iface lo inet loopback

allow-hotplug wlan0

iface wlan0 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255

post-up service hostapd restart
post-up service dnsmasq restart

root@linaro-developer:~# cat /etc/hostapd/hostapd.conf

macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0

wpa=2
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
wpa_passphrase=12345678

#ieee80211n=1
#wmm_enabled=1

interface=wlan0
driver=nl80211
hw_mode=g
channel=11
ssid=DB410C
logger_stdout=-1
logger_stdout_level=2

#5

Indeed. Did some more testing, and it seems problem is that multicast doesn’t work at all in AP mode. I tried to send multicast using iperf and gstreamer to no avail. Used commands work well on other systems.


#6

yes, even i add the default gateway route :

route add default gw 192.168.1.1 dev wlan0

but it still not work. do you test the broadcast?


#7

Did some quick tests with broadcast, and it seems the packet’s don’t make it as well.

I used this script http://svn.python.org/projects/python/tags/r32b1/Demo/sockets/broadcast.py (with bind specifying wlan adapter ip) to send some packets.
When packets are send from STA to AP (db410c) I can see them in iptraf arriving in AP. When they are sent from AP (db410c) to STA I cannot see them in the STA.


#8

Correct me If I’m wrong, but If I want to summarize a bit:

  • When DB410C is in STA mode everything works as expected
  • When DB410C is in AP mode:
    incoming multicast/broascast is OK.
    outcoming multicast/broadcast is NOK.

#9

Hi Loic, yes that is correct.


#10

I’ve just tested on my side and I’m able to send/recv broadcast pkt (I used your script).
For quick testing, I applied the following config:

File /etc/hostapd.conf (for AP conf):
interface=wlan0
driver=nl80211
ssid=test
channel=1

File /etc/dnsmasq.conf (for dhcp):
interface=wlan0
dhcp-range=192.168.0.50,192.168.0.150,12h

Commands:
$ systemctl stop wpa_supplicant
$ /etc/init.d/dnsmasq restart
$ hostapd /etc/hostapd.conf
$ ifconfig wlan0 192.168.0.1

Wireshark/tcpdump shows pkts in/out on STA and AP side.

However this is on debian, I’m going to try on OE.
Any diff with your setup ?


#11

Interesting, for some reason this only works when AP is open (no auth/encryption).
Could you try to remove all your wpa2 stuff in your hotapd.conf and let me know.


#12

I tested with WPA enabled (and on OE):

wpa=2
wpa_passphrase=123456789012
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP CCMP
rsn_pairwise=CCMP

Interestingly, when I disabled WPA I could see the avahi services appear. When running the broadcast script, I only see some packages make it to the STA.


#13

Yes, with wpa enabled seems that the broadcast pkt is correctly passed to the driver (cf following debug) however, using a sniffer I don’t see the pkt in the air, so it looks like an issue with the firmware.
We should open an issue.

[ 1128.022630] wcn36xx: tx skb ffff8000348e0a00 len 77 fc 4208 sn 583 low bcast
[ 1128.022661] wcn36xx: 00000000: 08 42 00 00 ff ff ff ff ff ff 02 00 6c 31 ad e8 02 00 6c 31 ad e8 70 24 aa aa 03 00 00 00 08 00
[ 1128.022680] wcn36xx: 00000020: 45 00 00 2d 02 67 40 00 40 11 77 b0 c0 a8 00 01 ff ff ff ff df 8f c3 50 00 19 00 96 31 35 30 37
[ 1128.022694] wcn36xx: 00000040: 30 33 36 31 30 30 2e 31 33 36 38 34 0a
[ 1128.022710] wcn36xx: DXE TX
[ 1128.022734] wcn36xx: DESC1 >>> 00000000: 45 8a 30 00 28 00 00 00 90 09 0a b8 17 00 00 00 60 e4 0b b8 00 00 00 00 00 00 00 00 00 00 00 00
[ 1128.022758] wcn36xx: BD >>> 00000000: 19 00 00 80 00 00 00 00 00 00 00 00 18 28 20 00 00 4d 20 00 00 01 40 00 bd bd bd bd 00 00 00 00
[ 1128.022773] wcn36xx: BD >>> 00000020: 00 00 00 00 00 00 00 00
[ 1128.022799] wcn36xx: DESC2 >>> 00000000: 4d 8a 32 00 4d 00 00 00 30 9c 14 b5 17 00 00 00 80 e4 0b b8 00 00 00 00 00 00 00 00 00 00 00 00
[ 1128.022819] wcn36xx: SKB >>> 00000000: 08 42 00 00 ff ff ff ff ff ff 02 00 6c 31 ad e8 02 00 6c 31 ad e8 70 24 aa aa 03 00 00 00 08 00
[ 1128.022837] wcn36xx: SKB >>> 00000020: 45 00 00 2d 02 67 40 00 40 11 77 b0 c0 a8 00 01 ff ff ff ff df 8f c3 50 00 19 00 96 31 35 30 37
[ 1128.022851] wcn36xx: SKB >>> 00000040: 30 33 36 31 30 30 2e 31 33 36 38 34 0a
[ 1128.022864] wcn36xx: wcn36xx_dxe_write_register: addr=400, data=843e8b4d
[ 1128.022899] wcn36xx: wcn36xx_dxe_read_register: addr=20, data=1
[ 1128.022918] wcn36xx: wcn36xx_dxe_read_register: addr=404, data=a004
[ 1128.022930] wcn36xx: wcn36xx_dxe_write_register: addr=30, data=1
[ 1128.022941] wcn36xx: wcn36xx_dxe_write_register: addr=34, data=1
[ 1128.022949] wcn36xx: dxe tx ready low


#14

Hi Loic, you happen to know if there’s any news on this?
It seems I’m running into it again but this time for ipv6 compliance. When in AP mode, the (dnsmasq) RA packets don’t make it to the STA so it doesn’t know the network address. I can see in the log that dnsmasq sends them, but they’re not showing up in wireshark on the STA. Running OE 18.01.


#15

Hello @Thors, unfortunately no much progress on this specific point, we mostly focused in improving STA/client mode for now.


#16

Thank you @Loic, we have also noticed improvements in the AP mode between 18.01 release and current state (4.14 release branch).
Previously we could quite easily crash the kernel by having a wifi client on the edge of wifi range for some time. Fortunately that seems to not happen anymore with latest kernel. Keep up the good work.