Connman prevents AP/Wifi and STA/eth working together

Trying to run WIFI-Featherwing as AP on separate net to USB-LAN.
I am trying to run hostapd and dnsmasq for wlan0/wifi as AP and retain USB/eth0 connection for debugging and configuring.

Connman controls port 53 for DHCP comms and conflicts with dnsmasq.
Running $ sudo netstat -tulpn | grep LISTEN I get:
tcp6 0 0 ::1:53 :::* LISTEN 322/connmand

I want to run wlan0/wifi with 192.168.4.x and the ethernet eht0 on 192.168.1.x
How can I configure connman to restrict its access to the ethernet only.

In /var/lib/connman/settings the only parameters are:

What can I do to modify connman so the eth0 still works but I can use dnsmasq and hostapd on the wifi?

Note that i can do this on the Omega and Rpi, but neither of these uses connman.

You can try to disable or uninstall connman, I only use that to make it easier to setup wifi. I’ve not tried what you want to do, but if try to do it how it works on your pi or omega it should work the same on the giant board. It’s also possible to manage this sort of setup using connman.

Thanks for the link. i did not see the reference previously regarding disabling the DNS proxy.
All works fine now with eth0 on local network and wlan0 as an access point.

1 Like

I was hasty in saying things work ok. SSH works ok.

The Web Server DOES NOT WORK.

I am running web server on nodeJs. A client via the Access point connects ok for the first 3-4 files but then slows down and stops. Using iperf3 i get a 3MBps link each way so the data speed is not a problem it is simply that the AP stops delivering data. The same server works extremely well concurrently on the ethernet port.

I am using the same software and same configuration for the Access Point that works fine on the RPIZero. I have even used the same USB Wifi adapter as I used on the RPI so it is nothing to do with the WIN1500. I have even added haveged to provide additional entropy but that does not change anything.

Any ideas why the Access Point would stall after a few seconds?

I would try checking over your settings in hostapd.conf. I used the AP mode a while back to control a robot from my phone, I didn’t experience dropping/stalling. It might also be worth trying to diable power saving mode on the WiFi. This docment from microchip has a lot of useful information. If you keep having issues, I’ll try and setup my board similar and see what happens.

I have reproduced the problem exactly with a USB Wifi device, so I dont think the problem is with WINC1500. I will try again with another USB Wifi device with a different chip. If I have the same problem with a third device, I will provide my settings for connman, dhcpcd, hostapd and dnsmasq.

When dnsmasq service comes on line, the wlan device is not yet available, so I have to configure it post boot with an autoexecute file.

At present I have not been successful in getting the WIN1500 to go into low power mode. Anything I do it still draws almost full current.

I will try the other USB wifi device later today as I have to rebuild the kernel with the correct USB drivers.

I have built the image from source to include extra drivers for USB LAN/Wifi.
I have nodeJs Webserver that works perfectly using the WIN1500 in Station mode.
Using iperf3 when the WIN1500 is in AP mode, I get a transfer speed of around 3Mbps each way.
When I run the access point, it provides about 5-6 files quite quickly and then stops.
The same problem occurs when I run an atheros usb wifi adapter instead of the WINC1500.

Here are the main configurations for hostapd and dnsmasq (these are dumps of real files so the contents are exact).

Any ideas would be greatly appreciated.

**** Disable DNS Proxy on connman and disable connman wifi
$ sudo vi /etc/systemd/system/connman.service.d/disable_dns_proxy.conf
ExecStart=/usr/sbin/connmand -n --nodnsproxy

$ sudo connmanctl disable wifi

$ sudo vi /etc/hostapd/hostapd.conf


$ sudo vi /etc/default/hostapd

$ sudo systemctl unmask hostapd
$ sudo systemctl enable hostapd

$ sudo vi /etc/dhcpcd.conf
interface wlan0
static ip_address=
static routers=
static domain_name_servers=
nohook wpa_supplicant

$ sudo vi /etc/dnsmasq.conf

// To prevent dnsmasq error due to wlan0 not being availalbe when service started
$ sudo vi /lib/systemd/system/dnsmasq.service
[Unit] // added // added
# rest is default

$ sudo ifconfig wlan0 netmask

I don’t have it in front of me to give you the exact command, but it might be worth while to try and check the MTU. If it’s set too high, you may run into connection stability issues. I would recommend trying to adjust it to 1400.

2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether f8:f0:05:ea:c0:d3 brd ff:ff:ff:ff:ff:ff
inet brd scope global wlan0
valid_lft forever preferred_lft forever
inet6 fe80::faf0:5ff:feea:c0d3/64 scope link
valid_lft forever preferred_lft forever

The value is 1500.
This works fine when in station mode?
If it is too high?

I’ve have ran into some situations where 1500 MTU was too high for my router, causing some stability issues. Its definitely worth a try, not sure what else would cause it to drop.

Set MTU to 1400 with the exact same result?

Just to clarify your setup so I can test. The access point is hosted by the giant board and you share the connection through the giant boards USB Ethernet?

My application is for the WINC /giantboard to be a stand alone access point to provide sensor data to a mobile web client in a remote location where there is no internet/3G etc. There is no need to bridge and no need to have STA and AP modes concurrently and there is no shared connection via WINC. However, I do use a separate Atheros USB LAN connection for ssh/gdb while setting up and configuring the device before deployment.

After doing a bit of reading, I think this github issue is the problem you’re experiencing maybe.

Thanks for the reference but I don’t beleive this is the same issue

Referencing the comment by tsifb on 12 Mar 2019

WILC1000 (station mode) to a distant TPLink AP, … results in much lower wilc - > AP performance than would otherwise be seen if the initial tx was closer to the rate
Using the WILC module in AP mode has not been investigated to see if the same behaviour occurs in this reversed configuration, but this would be an interesting experiment.

For me, I am using the WILC in AP mode wherease the post referest to STA mode.

Referencing the comment by Mateusz-Gwara on 5 Apr 2019

In both cases, the clients still show a good signal quality but data transfer comes to a halt at a distance of ~10-15m. There are no bandwidth issues when standing right next to the AP.

For me, the WILC works fine in STA mode when 10m from the AP, but does not work in AP mode when the client is only 30cm from the WILC.

Referencing the comment by Mateusz-Gwara on 30 Oct 2019

Simply make an AP (WPA enabled) running on wilc … Connect any kind of client to it … and stream for a couple of hours … eventually lead to a system freeze.

For me the problem occurs at exactly the same point each time and after the client has been connected for about 3-4 seconds

In addition, I experience the same problem EXACTLY with the Atheros USB wifi adapter in AP mode so the problem is not with the Wifi chip. Also, because I am using the same hoatpad/dnsmasq configuration that works fine with Debain on rpi, then it is likely that the problem is with Linux 5 or with the configuration of the Linux system.

Thanks for the details. I did see it was for STA mode but it did sound almost identical. If you’re still have the problem with the atheros, then it’s definitely something in the software. I’ve been planning to bring the Giant Board up to kernel 5.4, but there’s been a couple minor issues I need to fix. I’ll work on the kernel here shortly and see if I can sort those out. If you don’t need the LCD drivers the Giant Board will happily run 5.4.

When will the new Kernel by available as part of giantboard-tools so that the kernel can be build with additional drivers. I need to add USB-LAN for debugging and USB-Wifi for testing this specific problem.

I just pushed up a few updates to the giantboard-tools. Initial testing seems to be fine and I also got the other issues sorted out. I need to do a little more testing before I push up an image, but you can pull the new updates and give it a try.