when I use address=/#/127.24.2.1, the internet requests that go from
internal scripts also fail
It seems that your internal scripts use to resolve DNS names the same local dnsmasq server as you wifi clients.
Check your /etc/resolv.conf configuration and if there is present your dnsmasq server address (127.24.2.1 or 127.0.0.1 or other) - remove it. ...
Of course the performance will be degraded after so many traversals. Radio is a shared medium (half-duplex), collisions can happen and to avoid them Wi-Fi uses CSMA/CA. Your performance will at least be degraded more than in half. Every client adds to the latency
In case anyone is curious about an update (in 2017) to this question... I was able to recreate the issue and figured out a solution.
Disable dnsmasq from resolving for the loopback interface (in /etc/dnsmasq.conf):
Add to the tail file of resolvconf (in /etc/resolvconf/resolvconf.conf.d/tail)
You are making a few different mistakes in your configuration. First of all site-local addresses have been deprecated for many years. Any documentation telling you to use addresses starting with fec0 is outdated and needs to be updated.
The replacement for site-local addresses is called unique local addresses. These are constructed by using fd as the first ...
Try to set
this configuration worked for me
The issue is with rtl8192cu (the driver). It doesn't support AP mode properly at the moment. It may seem to work, showing the device in master mode, but you won't get any beacons or traffic moving through.
Read through this thread - http://www.spinics.net/lists/linux-wireless/msg96070.html - hopefully one of the developers will pick up on what is missing to ...
You need to specify dnsmasq which interface to use what network. You can do this with below change in your dnsmasq.conf file:
If in-country connectivity is good, then the bottleneck is most likely your ISP. It's definitely not related to your AP. It's either the connectivity between your country and others, or your ISP may just not have good connectivity to foreign sites. You may be able to narrow it down by doing some traceroute tests to foreign sites to see if there's an obvious ...
In man page of dnsmasq there is a option saying
Use the specified file to store DHCP lease information.
So, you can use a file to log it. And the format of the file is:
946689575 00:00:00:00:00:05 192.168.1.155 wdt 01:00:00:00:00:00:05
946689522 00:00:00:00:00:04 192.168.1.237 * 01:00:00:00:00:00:04
I suggest you to use radiotap
you only need in this case to assemble packets manually
To see how what's going on - use
I met the similar problem with hostapd_1.0-3+b1_armhf.deb several days ago, when i setup wpa on my ap (raspberry pi), evenif the passpharse was inputted correctly, the connection always failed by password authentication.
After trying a newer version(hostapd_2.1-0ubuntu4_armhf.deb), the problem is gone. I don't know the reason of this issue, looks like it ...