lwfinger / rtl8192du

Source code for RTL8192DU device
77 stars 52 forks source link

Issue during pinging. #37

Open anjalikrishnak opened 8 years ago

anjalikrishnak commented 8 years ago

I am using rtl8192du Wi-Fi Driver for Android Lollipop. All the basic Wi-Fi operations are working fine. But I am facing a ping issue in the following scenario. I connected my Freescale board with the driver to an AP . And connected my PC to the same AP . Pinged PC and the board. Pinging is happening without any issue until I give a scan command from my board side. The pinging with the PC and the board hangs and then restarts with a huge pinging time like below

64 bytes from 192.168.0.16: icmp_seq=15 ttl=64 time=1.36 ms 64 bytes from 192.168.0.16: icmp_seq=16 ttl=64 time=1.32 ms 64 bytes from 192.168.0.16: icmp_seq=17 ttl=64 time=1.35 ms 64 bytes from 192.168.0.16: icmp_seq=18 ttl=64 time=1.34 ms 64 bytes from 192.168.0.16: icmp_seq=19 ttl=64 time=1.64 ms 64 bytes from 192.168.0.16: icmp_seq=20 ttl=64 time=1.32 ms

64 bytes from 192.168.0.16: icmp_seq=23 ttl=64 time=7209 ms 64 bytes from 192.168.0.16: icmp_seq=24 ttl=64 time=6208 ms 64 bytes from 192.168.0.16: icmp_seq=25 ttl=64 time=5207 ms 64 bytes from 192.168.0.16: icmp_seq=26 ttl=64 time=4207 ms 64 bytes from 192.168.0.16: icmp_seq=27 ttl=64 time=3205 ms

64 bytes from 192.168.0.16: icmp_seq=31 ttl=64 time=48.4 ms 64 bytes from 192.168.0.16: icmp_seq=32 ttl=64 time=1.28 ms 64 bytes from 192.168.0.16: icmp_seq=33 ttl=64 time=1.39 ms 64 bytes from 192.168.0.16: icmp_seq=34 ttl=64 time=1.37 ms 64 bytes from 192.168.0.16: icmp_seq=35 ttl=64 time=3.67 ms 64 bytes from 192.168.0.16: icmp_seq=36 ttl=64 time=1.14 ms 64 bytes from 192.168.0.16: icmp_seq=37 ttl=64 time=1.39 ms 64 bytes from 192.168.0.16: icmp_seq=38 ttl=64 time=1.42 ms

This occurs every time when I issue an "iwlsit wlan0 scan" command. Anything can be done for these so that a smooth ping operation occurs.

lwfinger commented 8 years ago

Looking at the code, I see that the scan allows 300 ms per channel. With only 2.4G to be scanned, that would not take long; however, when you add the 5G channels, that takes a while. Perhaps that is what you are seeing.

I do not know the details of how the driver performs the scan other than it seems to block out other RX operations during the scan. It should be possible to rewrite the scan, but such a project would not be high on my list of things to do. Sorry.

If you want to play with the scan times, RTW_STAY_AP_CH_MILLISECOND could be reduced from 3. Alternatively, SURVEY_TO could be reduced from 100. The goal would be to minimize the product of those 2 quantities without missing APs in the scan.