Develop Reference

Can't connect to WiFi - CTRL-EVENT-ASSOC-REJECT, status code = 1, ASSOC_REJECT 12 - wpa_supplicant

I am trying to connect to my Wifi router with my Xiaomi Mi Max 2. I can connect to every router, but not to this one. Also, every other phone can connect to that router. I already tried changing protocols or resetting the router / phone.
Looking at logcat, I get the following:
wpa_supplicant: wlan0: Event ASSOC_REJECT (12) received
wlan0: CTRL-EVENT-ASSOC-REJECT bssid=6c:99:24:0f:51:d2 status_code=1
wpa_supplicant: Continuous association failures - consider temporary network disabling
wpa_supplicant: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED [...]
Does anyone know what's going on and how I can solve this?
Best,
Trim

wlan Loopback throughput via usb is only 273 Mbps when bus speed is 480 Mbps

I have a STB 7445 device to which our wlan chip is connected via usb.
After loading driver and firmware for wlan0 interface, IP address is assigned to wlan0 interface.
IP Address:
# ifconfig wlan0 192.168.1.2
Thereafter I am running loopback throughput test on a dummy address added in arp entry.
ARP Entry:
# /system/xbin/busybox/arp -s 192.168.1.4 11:22:33:44:55:66
Run iperf to measure UDP TPUT:
# iperf -c 192.168.1.4 -i1 -w2M -b1000M -t 60
.
.
[ 3] 4.0- 5.0 sec 32.5 MBytes 273 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 59.0-60.0 sec 32.5 MBytes 273 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.0 sec 1.90 GBytes 273 Mbits/sec
[ 3] Sent 1390851 datagrams
[ 3] WARNING: did not receive ack of last datagram after 10 tries.
root#bcm_platform:/system/bin/amar/43569a2 #
I am getting throughput of only 273 Mbps, whereas the bus speed is 480 Mbps.
usb bus speed:
#cat /sys/bus/usb/devices/usb1/speed
480

The ip stack will notice that the destination is the same machine, so no packets are sent out to the hardware. You are just measureing the software performance of the linux IP stack, and your CPU is a bit slow.
USB 2.0 high speed is 480 MBit/s, but it cannot send and receive at the same time. That means if you send packets to hardware and receive them again, you cannot exeed 240 MBit/s - in practice even lower since there will be some overhead.

Android 4.2.2+ Hotspot

I hooked into the /system/bin/netd binary to log all of the commands that are sent by the Android framework when it puts up a hotspot via clicking buttons in the system settings menu. (I needed to be able to bring up the hotspot up from shell & ADB without bringing up the settings menu.)
This returned all of the commands that are used to put up the hotspot.
interface clearaddrs wlan0
interface ipv6 wlan0 disable
resolver flushif wlan0
bandwidth setglobalalert 2097152
bandwidth setglobalalert 2097152
softap fwreload wlan0 AP
softap set wlan0 asdfa wpa2-psk 12345678
softap startap
interface getcfg wlan0
interface setcfg wlan0 192.168.43.1 24 running multicast broadcast up
tether interface add wlan0
ipfwd enable
tether start 192.168.42.2 192.168.42.254 192.168.43.2 192.168.43.254 192.168.44.2 192.168.44.254 192.168.45.2 192.168.45.254 192.168.46.2 192.168.46.254 192.168.47.2 192.168.47.254 192.168.48.2 192.168.48.254
tether dns set 8.8.8.8 8.8.4.4
Seems OK.
When I issue those commands through /system/bin/ndc from shell, nothing returns an error and claims that it succeeded. Great. Fantastic. Wonderful.
200 0 Interface IP addresses cleared
200 0 IPv6 state changed
200 0 Resolver command succeeded
200 0 Bandwidth command succeeeded
200 0 Bandwidth command succeeeded
200 0 Softap operation succeeded
200 0 Softap operation succeeded
600 Iface linkstate wlan0 down
600 Iface linkstate wlan0 down
200 0 Softap operation succeeded
213 0 44:33:4c:3d:98:dc 0.0.0.0 0 down broadcast multicast
200 0 Interface configuration set
200 0 Tether operation succeeded
200 0 ipfwd operation succeeded
200 0 Tether operation succeeded
200 0 Tether operation succeeded
Super! Except for the little trivial fact that the hotspot cannot be seen afterwards and it doesn't even kick me off the wireless connection, so obviously I am missing something.
It might be useful to note that in Android 4.1.1 the following works (as expected), but in 4.2.2 it does not; I have tried endless combinations of the logged commands and the 4.1.1 commands to very little avail.
softap stopap
softap stop wlan0
softap fwreload ap0 AP
softap start wlan0
softap set wlan0 ap0 SSID wpa2-psk 12345678 11 0 8
softap startap
interface setcfg ap0 192.168.2.254 255.255.255.0 up
Here is what happens when the hotspot is taken down via the system settings menu, maybe it will be helpful:
interface getcfg wlan0
interface setcfg wlan0 0.0.0.0 0 running multicast broadcast up
tether interface remove wlan0
tether stop
ipfwd disable
softap stopap
softap fwreload wlan0 STA
softap fwreload wlan0 STA
interface getcfg wlan0
interface setcfg wlan0 0.0.0.0 0 multicast broadcast down
interface ipv6privacyextensions wlan0 enable
interface getcfg p2p0
interface setcfg p2p0 0.0.0.0 0 multicast broadcast up
interface ipv6 wlan0 enable
interface route add wlan0 default 192.168.2.254 32 0.0.0.0
interface route add wlan0 default 0.0.0.0 0 192.168.2.254
resolver flushif wlan0
interface route add wlan0 default 192.168.2.254 32 0.0.0.0
bandwidth setglobalalert 2097152
interface route add wlan0 default 0.0.0.0 0 192.168.2.254
bandwidth setglobalalert 2097152
This is what is logged during system startup before any user input is possible:
interface list
interface getcfg eth0
interface ipv6 wlan0 disable
interface list
bandwidth enable
softap fwreload wlan0 STA
firewall disable
interface getcfg wlan0
interface setcfg wlan0 0.0.0.0 0 multicast broadcast down
interface ipv6privacyextensions wlan0 enable
bandwidth setglobalalert 2097152
firewall disable
interface setthrottle rmnet0 -1 -1
interface getcfg p2p0
interface setcfg p2p0 0.0.0.0 0 multicast broadcast up
interface ipv6 wlan0 enable
resolver setifdns wlan0 192.168.2.254
resolver setdefaultif wlan0
interface route add wlan0 default 192.168.2.254 32 0.0.0.0
interface route add wlan0 default 0.0.0.0 0 192.168.2.254
resolver flushif wlan0
interface route add wlan0 default 192.168.2.254 32 0.0.0.0
interface route add wlan0 default 0.0.0.0 0 192.168.2.254
The only thing I do know for sure is that I can trigger the hotspot to come up in 4.4.3 when I issue commands to netd prior to the bootanimation completion.
Where did I go wrong?

Android NDK - socket closing when using localhost

I'm having issues with using some sockets in C++ code with Android NDK. Two sockets are created, and one reads from the other. This works with a network connection on Android, both with and without a network connection on another machine, but NOT on Android without a network connection.
Here is a netstat output before the socket closes. The line of interest is
tcp 0 0 127.0.0.1:32993 127.0.0.1:46810 ESTABLISHED
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:32993 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:45549 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:5037 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5555 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:46811 127.0.0.1:32993 ESTABLISHED
tcp 0 0 127.0.0.1:32993 127.0.0.1:46811 ESTABLISHED
tcp 0 0 127.0.0.1:46810 127.0.0.1:32993 ESTABLISHED
tcp 0 0 127.0.0.1:32993 127.0.0.1:46810 ESTABLISHED
tcp 0 0 10.0.2.15:5555 10.0.2.2:34217 ESTABLISHED
udp 0 0 10.0.2.15:49667 10.0.2.3:53
udp 0 0 0.0.0.0:60262 0.0.0.0:*
I then attempt to read 10 bytes from the socket 127.0.0.1:46810 (header_length - filled = 10):
bytes = read(fd, header, header_length - filled);
However, 0 bytes are read. TCP_NODELAY has been set on the socket. This is the netstat output after the read.
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:32993 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:5037 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5555 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:46811 127.0.0.1:32993 FIN_WAIT2
tcp 0 1 127.0.0.1:32993 127.0.0.1:46811 CLOSE_WAIT
tcp 0 0 127.0.0.1:46810 127.0.0.1:32993 FIN_WAIT2
tcp 0 0 127.0.0.1:32993 127.0.0.1:46810 CLOSE_WAIT
tcp 0 0 10.0.2.15:5555 10.0.2.2:34217 ESTABLISHED
udp 0 0 0.0.0.0:60262 0.0.0.0:*
There are no problems when there is a network connection, and the addresses used are still 127.0.0.1. Why would it fail to read any bytes on localhost when there is no network connection?

Turns out that this was being caused by another issue. Some time after resolving the IP address into a char array, delete[] was being called on the array. When there was no network connection, the pointer was being reassigned directly to 127.0.0.1, so the program was crashing on the delete[]. Copying the IP into the array using
strcpy(ip, "127.0.0.1");
means that the pointer still points at the array, and the program does not crash when calling delete[].

Android fails load driver touchscreen on Samsung Galaxy Tab 10.1

Can you help me with this:
My tablet Galaxy Tab 10.1, after reset pressing power button 15 seconds making a soft reset because freeze loading an app, not load touchscreen driver.
Dmesg message:
<6>[ 7.163493] mXT1386: mxt_probe
<6>[ 7.163501] maXTouch driver
<6>[ 7.163507] "sec_touch"
<6>[ 7.163513] addr: 0x004c
<6>[ 7.163519] irq: 220
<6>[ 7.163525] flags: 0x0000
<6>[ 7.163531] adapter:"Tegra I2C adapter"
<6>[ 7.163537] device: "(null)"
<3>[ 7.163685] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
<3>[ 7.169602] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
<3>[ 7.176023] tegra-i2c tegra-i2c.1: Packet status 0x00010009
<6>[ 7.182700] Warning: To wake up touch-ic in deep sleep, retry i2c communication!
<3>[ 7.222752] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
<3>[ 7.228727] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
<3>[ 7.235061] tegra-i2c tegra-i2c.1: Packet status 0x00010009
<3>[ 7.241798] sec_touch 1-004c: Failure accessing maXTouch device
<3>[ 7.247800] sec_touch 1-004c: Chip could not be identified
<6>[ 7.253434] p3_touch_exit_hw
<4>[ 7.253455] sec_touch: probe of 1-004c failed with error 255
<6>[ 7.253510] Successfully added driver sec_touch
How can I sure of if is a hardware issue or a configuration issue?
I clean cache, data, system folders from CWM and reinstall stock rom p7510uekmm and nothing happend

I had this problem with my Galaxy Tab and tried the ideas mentioned above but it just didn't work for me. I have, however, figured out what's really going wrong.
I always had this failure showing up in dmesg:
tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
So, it can't read from the touchscreen controller at address 0x4c because the chip isn't responding. One fix mentioned was to re-write the configuration, with the assumption that the device was somehow wedged. That doesn't work either, since you can't write to 0x4c - same lack of acknowledgement. So, if 0x4c is the right address, the chip must be dead, right?
I tried adding a reset. No change. Disconnected the battery overnight. Also no change.
Then, I realized what's going on. The MXT1386 has a "Firmware Update" mode. When you put it into update mode, the device address changes from 0x4c to 0x26! Once it gets into that mode, it doesn't respond to the original address. Since I don't have the docs for the device, and thus don't know how to get out of firmware update mode, I updated the Linux kernel to call the driver function that updates the firmware. Once that process is complete and the chip reset, it reverts to its original address. At that point (after a final reboot), all is well.
I have a replacement kernel that you can install and boot which re-enables the touchpad. I'd suggest making a nandroid backup first, installing my kernel, then restoring the nandroid once it's fixed.

It's trying to contact the touch controller over the I2C bus and failing. It does one retry and then gives up. The address 0x4C is correct for the mXT1386 on that unit.
You should try a hard power off/on by taking out the battery.
You could try taking apart the
unit and reseating the connector to the touch controller. It is
on a separate board connected with a flexi cable which might have become dislodged.
Another possibility is that the touch chip itself is damaged.