webOS Forums - форум пользователей телевизоров на webOS

[R14]

Когда захожу на телефон по ssh, такое ощущение, что захожу на удалённый хост по диал-апу. Соединение очень нестабильное, иногда может "затыкаться" на несколько секунд.
Статистика ICMP-ответов телефона тоже не радует:

65мс TTL=64
76мс TTL=64
таймаут
168мс TTL=64
130мс TTL=64
239мс TTL=64
1580мс TTL=6
155мс TTL=64
96мс TTL=64
110мс TTL=64
91мс TTL=64
73мс TTL=64
таймаут
134мс TTL=64
249мс TTL=64
таймаут
87мс TTL=64
100мс TTL=64
31мс TTL=64
55мс TTL=64
2027мс TTL=6
3мс TTL=64
19мс TTL=64
41мс TTL=64

SSH-сервис на 22 порту появляется, только если попинговать телефон (который начинает отвечать после того, как пропустит несколько пакетов). Сама wi-fi сеть работает нормально, проблема именно в телефоне.
Что это, агрессивная политика энергосбережения? Можно ли это подкрутить?

[R14]

Просьба - попингуйте свои телефоны, при подключении по wi-fi. Насколько быстро и стабильно они откликаются?

[t-IX]

Если в ожидании.

$ ping 192.168.1.7
PING 192.168.1.7 (192.168.1.7) 56(84) bytes of data.
64 bytes from 192.168.1.7: icmp_req=1 ttl=64 time=444 ms
64 bytes from 192.168.1.7: icmp_req=2 ttl=64 time=34.6 ms
64 bytes from 192.168.1.7: icmp_req=3 ttl=64 time=55.5 ms
64 bytes from 192.168.1.7: icmp_req=4 ttl=64 time=82.5 ms
64 bytes from 192.168.1.7: icmp_req=5 ttl=64 time=107 ms
64 bytes from 192.168.1.7: icmp_req=6 ttl=64 time=24.7 ms
64 bytes from 192.168.1.7: icmp_req=7 ttl=64 time=52.4 ms
64 bytes from 192.168.1.7: icmp_req=8 ttl=64 time=72.4 ms
64 bytes from 192.168.1.7: icmp_req=9 ttl=64 time=610 ms
64 bytes from 192.168.1.7: icmp_req=10 ttl=64 time=17.9 ms
64 bytes from 192.168.1.7: icmp_req=11 ttl=64 time=48.0 ms
^C
--- 192.168.1.7 ping statistics ---
12 packets transmitted, 11 received, 8% packet loss, time 11000ms
rtt min/avg/max/mdev = 17.989/140.923/610.012/187.118 ms

При снятой блокировке.

$ ping 192.168.1.7
PING 192.168.1.7 (192.168.1.7) 56(84) bytes of data.
64 bytes from 192.168.1.7: icmp_req=1 ttl=64 time=168 ms
64 bytes from 192.168.1.7: icmp_req=2 ttl=64 time=88.2 ms
64 bytes from 192.168.1.7: icmp_req=3 ttl=64 time=9.54 ms
64 bytes from 192.168.1.7: icmp_req=4 ttl=64 time=32.9 ms
64 bytes from 192.168.1.7: icmp_req=5 ttl=64 time=55.8 ms
64 bytes from 192.168.1.7: icmp_req=6 ttl=64 time=77.9 ms
64 bytes from 192.168.1.7: icmp_req=7 ttl=64 time=100 ms
64 bytes from 192.168.1.7: icmp_req=8 ttl=64 time=21.3 ms
64 bytes from 192.168.1.7: icmp_req=9 ttl=64 time=44.9 ms
64 bytes from 192.168.1.7: icmp_req=10 ttl=64 time=62.0 ms
64 bytes from 192.168.1.7: icmp_req=11 ttl=64 time=84.9 ms
64 bytes from 192.168.1.7: icmp_req=12 ttl=64 time=5.66 ms
64 bytes from 192.168.1.7: icmp_req=13 ttl=64 time=31.9 ms
64 bytes from 192.168.1.7: icmp_req=14 ttl=64 time=54.9 ms
64 bytes from 192.168.1.7: icmp_req=15 ttl=64 time=77.0 ms
^C
--- 192.168.1.7 ping statistics ---
15 packets transmitted, 15 received, 0% packet loss, time 14017ms
rtt min/avg/max/mdev = 5.666/61.077/168.129/40.116 ms

Энергосбережение виновато.

Включена зарядка, ждущий режим.

$ ping 192.168.1.7
PING 192.168.1.7 (192.168.1.7) 56(84) bytes of data.
64 bytes from 192.168.1.7: icmp_req=1 ttl=64 time=32.3 ms
64 bytes from 192.168.1.7: icmp_req=2 ttl=64 time=57.4 ms
64 bytes from 192.168.1.7: icmp_req=3 ttl=64 time=78.8 ms
64 bytes from 192.168.1.7: icmp_req=4 ttl=64 time=102 ms
64 bytes from 192.168.1.7: icmp_req=5 ttl=64 time=24.4 ms
64 bytes from 192.168.1.7: icmp_req=6 ttl=64 time=48.3 ms
64 bytes from 192.168.1.7: icmp_req=7 ttl=64 time=72.3 ms
64 bytes from 192.168.1.7: icmp_req=8 ttl=64 time=96.5 ms
64 bytes from 192.168.1.7: icmp_req=9 ttl=64 time=22.4 ms
64 bytes from 192.168.1.7: icmp_req=10 ttl=64 time=43.5 ms
64 bytes from 192.168.1.7: icmp_req=11 ttl=64 time=67.5 ms
64 bytes from 192.168.1.7: icmp_req=12 ttl=64 time=91.2 ms
64 bytes from 192.168.1.7: icmp_req=13 ttl=64 time=12.7 ms
64 bytes from 192.168.1.7: icmp_req=14 ttl=64 time=36.5 ms
64 bytes from 192.168.1.7: icmp_req=15 ttl=64 time=60.2 ms
64 bytes from 192.168.1.7: icmp_req=16 ttl=64 time=87.6 ms
^C
--- 192.168.1.7 ping statistics ---
16 packets transmitted, 16 received, 0% packet loss, time 15000ms
rtt min/avg/max/mdev = 12.782/58.438/102.826/27.466 ms

Такое выдает тачпад. Ждущий режим.

Broadcast message from root (Sat Sep 17 01:08:23 2011):

powerd: System going to sleep now

Стоит только разблокировать или воткнуть зарядку, то всё становится нормально. Так что думаю подкрутить можно это дело.

[R14]

Вот к чему привели мои изыскания: (справедливо для webOS 2.1 на америкнаском Pre2 unlocked)

Телефон более-менее нормально доступен по сети, если его экран разлочен. Как только срабатывает таймаут гашения экрана или нажимается кнопка power, телефон пытается "заснуть" и отключить интерфейс, отнсящийся к wi-fi (eth0 ?). Если в этот момент открыта ssh-сессия на аппарат, который при этом не заряжаетя, то в консоли увидим сообщение вида:

Broadcast message from root (Sat Sep 17 15:00:14 2011):

powerd: System going to sleep now

Если телефон в момент гашения экрана заряжается, то такого сообщения он не покажет. Но интерфейс всё равно со временем попробует отключить. Однако, если заметит активность на интерфейсе - отключать его не станет, и когда телефон не на зарядке, он будет периодически просыпаться (экран не включается при этом), и через две секунды снова пытаться заснуть:

Broadcast message from root (Sat Sep 17 15:00:14 2011):

powerd: System woke up.


Broadcast message from root (Sat Sep 17 15:00:16 2011):

powerd: System going to sleep now


Broadcast message from root (Sat Sep 17 15:00:17 2011):

powerd: System woke up.


Broadcast message from root (Sat Sep 17 15:00:19 2011):

powerd: System going to sleep now


Broadcast message from root (Sat Sep 17 15:00:20 2011):

powerd: System woke up.

Как только активность на интерфейсе пропадает, интерфейс отключается. Если телефон не на зарядке, поднять интерфейс удалённо не получится никак. Только будить аппарат включением экрана. Если телефон на зарядке, то можно его попинговать и он проснётся (экрана не включит но интерфейс поднимет).
Если запустить бесконечный пинг с ПК на телефон, он никогда не потушит интерфейс. Если пинг запустить с телефона, интерфейс всё-таки отключится.

Энергосбережением занимается powerd. Если его погасить (stop powerd), то отключится вообще всё, что связано с энергосбережением, и в иконке батарейки в топбаре загорится вопросительный знак. Телефон будет работать до тех пор, пока не произойдёт первое событие, связанное с обращением к powerd (нажатие кнопки power, таймаут для затемнения экрана и т.п.). После этого аппарат перестанет реагировать на прикосновения. Если в этот момент открыта ssh-сессия, можно поднять powerd (start powerd), и аппарат тут же оживёт.
В-общем, решения, отключающее функции энергосбережения для сетевого интерфейса, пока не нашёл.