Strange WiFi connection behaviour

I tried from android, there is 10% packet loss on 100% signal strength. But not always. I also had packet loss on ping turris. I thing this is not normal behaviour. Look at those times (from 1.06 ms to 967 ms):

hlavki@hlavkinb:~> ping turris
PING turris (192.168.10.1) 56(84) bytes of data.
64 bytes from turris (192.168.10.1): icmp_seq=1 ttl=64 time=967 ms
64 bytes from turris (192.168.10.1): icmp_seq=2 ttl=64 time=462 ms
64 bytes from turris (192.168.10.1): icmp_seq=3 ttl=64 time=704 ms
64 bytes from turris (192.168.10.1): icmp_seq=4 ttl=64 time=13.1 ms
64 bytes from turris (192.168.10.1): icmp_seq=5 ttl=64 time=1.82 ms
64 bytes from turris (192.168.10.1): icmp_seq=6 ttl=64 time=1.68 ms
64 bytes from turris (192.168.10.1): icmp_seq=7 ttl=64 time=11.7 ms
64 bytes from turris (192.168.10.1): icmp_seq=8 ttl=64 time=1.24 ms
64 bytes from turris (192.168.10.1): icmp_seq=9 ttl=64 time=58.0 ms
64 bytes from turris (192.168.10.1): icmp_seq=10 ttl=64 time=1.60 ms
64 bytes from turris (192.168.10.1): icmp_seq=11 ttl=64 time=850 ms
64 bytes from turris (192.168.10.1): icmp_seq=12 ttl=64 time=79.0 ms
64 bytes from turris (192.168.10.1): icmp_seq=13 ttl=64 time=3.36 ms
64 bytes from turris (192.168.10.1): icmp_seq=14 ttl=64 time=1.34 ms
64 bytes from turris (192.168.10.1): icmp_seq=16 ttl=64 time=73.5 ms
64 bytes from turris (192.168.10.1): icmp_seq=17 ttl=64 time=1.06 ms
64 bytes from turris (192.168.10.1): icmp_seq=18 ttl=64 time=18.7 ms
64 bytes from turris (192.168.10.1): icmp_seq=19 ttl=64 time=221 ms
64 bytes from turris (192.168.10.1): icmp_seq=20 ttl=64 time=101 ms
64 bytes from turris (192.168.10.1): icmp_seq=21 ttl=64 time=50.6 ms
64 bytes from turris (192.168.10.1): icmp_seq=22 ttl=64 time=0.946 ms
64 bytes from turris (192.168.10.1): icmp_seq=23 ttl=64 time=481 ms
64 bytes from turris (192.168.10.1): icmp_seq=24 ttl=64 time=173 ms
64 bytes from turris (192.168.10.1): icmp_seq=25 ttl=64 time=448 ms
64 bytes from turris (192.168.10.1): icmp_seq=26 ttl=64 time=380 ms
64 bytes from turris (192.168.10.1): icmp_seq=27 ttl=64 time=231 ms
64 bytes from turris (192.168.10.1): icmp_seq=28 ttl=64 time=491 ms
64 bytes from turris (192.168.10.1): icmp_seq=29 ttl=64 time=207 ms
64 bytes from turris (192.168.10.1): icmp_seq=30 ttl=64 time=207 ms
64 bytes from turris (192.168.10.1): icmp_seq=31 ttl=64 time=16.7 ms
64 bytes from turris (192.168.10.1): icmp_seq=32 ttl=64 time=69.7 ms
^C
--- turris ping statistics ---
32 packets transmitted, 31 received, 3% packet loss, time 31072ms
rtt min/avg/max/mdev = 0.946/204.352/967.870/263.205 ms

HUh? Wait a minute.

So you are pinging from your Linux Distro to your Omnia and you are experiencing those huge lags?

Could you do something.

use

ping 192.168.10.1

instead of the name. Then post the output.

EDIT: To also give you an answer about how come you see your ip instead of what you are pinging.

hlavki@hlavkinb:~> ping obluda
PING obluda (192.168.10.232) 56(84) bytes of data.
From 192.168.10.118 (192.168.10.118) icmp_seq=1 Destination Host Unreachable
From 192.168.10.118 (192.168.10.118) icmp_seq=2 Destination Host Unreachable
From 192.168.10.118 (192.168.10.118) icmp_seq=3 Destination Host Unreachable

When the you got no response, then it just shows you your own ip of your Linux machine. I am also a Linux user and that is normal.

As you can later on see, that when you do get a response, for example

64 bytes from 192.168.10.232 (192.168.10.232): icmp_seq=20 ttl=255 time=1144 ms

then it can be translated as

64 bytes has been received from 192.168.10.232, on sequence 20 (i forgot what ttl was) and it took 1144 ms

EDIT 2: BTW, do you have a STATIC ip addresses given to your clients which are connected to your Omnia?

I looked that link that you posted earlier about other people having the problem. One person said this…

It seems that they are losing wireless communication between Wi-Fi AP and the printer. Turning the PC would it not have any impact.
Not to set any printer saving? If so, try it off completely.

It indeed could also be that the printer is losing the connection. Which network are you using 2.4 or 5 GHz?

Also have you looked if you are using a wifi-channel that is less crowded?

Looks like changing channel helps. Response times are stable ~2ms and without packet loss. Will be monitoring longer and then I’ll write result.

Install this app to look how crowded the channels are and choose the recommended channel.

I switched from farproc’s Wifi Analyzer to VREM’s because it is open source and ad-free :wink:

Thanks for the tip. Gonna change it right a way :).

EDIT: “Your device isn’t compatible with this version” :(.

Samsung Galaxy S4 international edition - i9505 - Android 5.0.1 - Rooted

Yes, it needs API Level 22 aka Android 5.1. I may take on issue #57 (support older Versions) if i got my other projects finished but this will take some time.

Also available on https://f-droid.org/repository/browse/?fdid=com.vrem.wifianalyzer

So, are you saying that Wifianalyzer from vrem is ONLY available to like 40% of all the Android phones??

API level 22 + 23 = 40%

https://developer.android.com/about/dashboards/index.html

This i have never stumbled upon. Is there something in API level 22, so necessary that wifianalyzer should use? That is the only conclusion that i am coming up with.

They originally decided for Android 6 because it gives more info about the wifi networks. 20/40/80/160 informations are not available in 5.1 or lower.

As i though that was the only conclusion that i could come up with.Sadly not going to use it for now.

I am planning to use my Samsung Galaxy S 4 at least till 2020 if it makes it :P. Maybe if a stable Cyanogenmod version is available with maybe Android 6 or even 7 that i then try to put that on it.

I am still glad that i got marshmallow (6) on my phone. It started with 2.3.4. Sometimes i forget that not everyone gets updates.

My future smartphone will probably be a chineese phone running Android. Hopefully then running Cyanogenmod or something like that so i won’t be dependend on companies anymore for updates.

Ok, anyway problem is still there. After some time printer is temporary unaccessible. Same behavior from android and Linux. Printer is always accessible from router. It is possible to turn off firewall on turris? Maybe problem is there.

I THOUGHT that you already checked on the printer drivers, firmware and such…But my assumption was wrong. I guess you haven’t looked at them. Look at this…

Right now the firmware is:
All OS, 6.96 MB, zip, MULTI LANGUAGE
Version : V3.00.01.29
14 Jul, 2016

http://www.samsung.com/uk/consumer/it/printer-multifunction/black-white-multifunction-printers/SL-M2070W/SEE

Let me know how it went, also what version firmware you had.

Of course, I have latest firmware installed few days after release.
V3.00.01.29 JUN-17-2016

One thing that I think, you missed, is that ping always works from turris.

Yeah, but i have also though about that.

That is why i asked…

If you ping from your Android to your Linux Desktop

or

Linux desktop to your Android. Would you experience the same behavior? If not, then you could also say it is not the router at fault right?

You can off course disable the firewall in the router, but i THINK it will not change anything.

For disabling the firewall, sadly i cannot help you with that. I do not have my Omnia so i cannot help you step by step and although i have a OpenWRT in Virtualbox i am not sure if it is wise to show you that way, because Turris OS is also on some aspect a bit different. Go in to the webinterface and look around how to disable it.

EDIT: Sorry, i had read earlier that you also had done that and you experienced something similar, forgot about that. Well then disable the firewall.

I think that suggestion from Chromecast disappears after few hours solved this problem too.

Edit file /etc/config/network:

config interface 'lan'
    ...
    option igmp_snooping '0'

Finally SOLVED. I had to revert firmware version to previous (V3.00.01.26). In other words, it means Omnia is above suspicion.