<div dir="ltr">Hi everybody,<br><br>although I am apparently not the only one with problems like these. Still, I have not found a solution by looking through the list - that's why I am posting this mail. Sorry, if I should have overseen any important hint - feel free to point me to the right direction...<br><br>So, here is my issue:<br><br>I have set up my (Debian based) Kali system (Linux kali 3.18.0-kali3-amd64 #1 SMP Debian 3.18.6-1~kali2 (2015-03-02) x86_64 GNU/Linux) to provide a wireless access point with hostapd (v1.0). To provide clients with IP addresses, I am using dnsmasq (version 2.62).<br><br>The configured SSID gets advertised and when I connect to it (e.g. with my smartphone) the device will be briefly authenticated and immediately deauthenticated.<br><br>tail -f /var/log/syslog<br>Jun  3 18:33:04 kali hostapd: wlan1: STA d8:96:95:27:30:b4 IEEE 802.11: authenticated<br>Jun  3 18:33:04 kali hostapd: wlan1: STA d8:96:95:27:30:b4 IEEE 802.11: associated (aid 1)<br>Jun  3 18:33:04 kali hostapd: wlan1: STA d8:96:95:27:30:b4 RADIUS: starting accounting session 556F807A-00000000<br>Jun  3 18:33:06 kali hostapd: wlan1: STA d8:96:95:27:30:b4 IEEE 802.11: disassociated<br>Jun  3 18:33:07 kali hostapd: wlan1: STA d8:96:95:27:30:b4 IEEE 802.11: deauthenticated due to inactivity<br><br>Apparently this deauthentication is due to the device not getting an IP address via DHCP. When I look for network traffic on the wifi interface, I will see the DHCP requests:<br><br># tcpdump -i wlan1 ip<br>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode<br>listening on wlan1, link-type EN10MB (Ethernet), capture size 65535 bytes<br>18:33:04.694155 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from d8:96:95:27:30:b4 (oui Unknown), length 300<br>18:33:04.694254 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from d8:96:95:27:30:b4 (oui Unknown), length 300<br>18:33:06.172565 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from d8:96:95:27:30:b4 (oui Unknown), length 300<br>18:33:06.172641 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from d8:96:95:27:30:b4 (oui Unknown), length 300<br><br>In the dnsmasq log I can see the corresponding requests:<br><br># tail -f /var/log/dnsmasq.log<br>Jun  3 17:57:59 dnsmasq[11398]: exiting on receipt of SIGTERM<br>Jun  3 17:58:01 dnsmasq[11511]: started, version 2.62 cachesize 150<br>Jun  3 17:58:01 dnsmasq[11511]: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack<br>Jun  3 17:58:01 dnsmasq[11511]: warning: no upstream servers configured<br>Jun  3 17:58:01 dnsmasq-dhcp[11511]: DHCP, IP range 10.0.0.10 -- 10.0.0.250, lease time 12h<br>Jun  3 17:58:01 dnsmasq[11511]: read /etc/hosts - 5 addresses<br>Jun  3 18:33:04 dnsmasq-dhcp[11511]: 151532460 available DHCP range: 10.0.0.10 -- 10.0.0.250<br>Jun  3 18:33:04 dnsmasq-dhcp[11511]: 151532460 client provides name: iTC<br>Jun  3 18:33:06 dnsmasq-dhcp[11511]: 151532460 available DHCP range: 10.0.0.10 -- 10.0.0.250<br>Jun  3 18:33:06 dnsmasq-dhcp[11511]: 151532460 client provides name: iTC<br><br>So, the DHCP requests apparently reach the dnsmasq daemon - however this guy is not responding in any way. But why???<br><br>Here is my dnsmasq config:<br><br># cat /etc/dnsmasq.conf<br>log-facility=/var/log/dnsmasq.log<br>interface=wlan1<br>dhcp-range=10.0.0.10,10.0.0.250,12h<br>dhcp-option=1,255.255.255.0<br>dhcp-option=3,10.0.0.1<br>dhcp-option=6,10.0.0.1<br>log-queries<br>log-dhcp<br><br>iptables is configured to forward traffic from the wifi interface to eth0, but has no other restrictions:<br><br># iptables -L -v<br>Chain INPUT (policy ACCEPT 6784 packets, 9546K bytes)<br> pkts bytes target     prot opt in     out     source               destination         <br>Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)<br> pkts bytes target     prot opt in     out     source               destination         <br>    0     0 ACCEPT     all  --  wlan1  eth0    anywhere             anywhere            <br>Chain OUTPUT (policy ACCEPT 6900 packets, 923K bytes)<br> pkts bytes target     prot opt in     out     source               destination         <br><br>Is there any way to get more debugging information? Or does anybody on this list have a solution to this strange behaviour?<br><br>Any help is greatly appreciated!<br><br>Regards,<br>Tom<br><br></div>