Re: [Comm] Asus WL-148G - работает начиная с 2.6.25 std-def

["Владимир Гусев" <vova1971@narod.ru>]

On Thu, 7 Aug 2008 11:38:07 +0400
Владимир Гусев wrote:

> [..]
> Отметил одну особенность. Что вчера, что сегодня (буквально как только
> включил на работе ноут) - ip-адрес терялся при попытке SIM
> залогиниться. Логинится этот пейджер очень долго, вызывая большой
> трафик. Также отметил, что в последние дни стали хуже отправляться
> через него сообщения, с большой задержкой.
> 
> Вот и сегодня - включил ноут (wifi-карточка уже вставлена),
> загрузилась ось, все замечательно, запускаю почтовик, и, решив
> проверить гипотезу, запускаю SIM. Вызвав приличный для одной
> программы трафик, SIM так и не успел залогиниться, делал это секунд
> 20-25, пока не снова не отвалилась сеть (интерфейс - физич и
> канальный уровни - при этом живет и моргает линками). Закрыл SIM,
> передернул network, wlan0 получил адрес, и я запустил kopete. Все
> сразу залогинилось, и работает спокойно без отвалов.. Странно. МОжет
> трафик от SIM как-то все забивает и keepalive не доходят от сервера
> dhcp, буфер переполняется, таймауты или еще что-то.. не знаю..
> 
> Вчера вместо SIM в экспериментах участвовал Pidgin - тоже все
> нормально..
> 
> Одно смущает - в пн и во вторник SIM с трудом, но работал, и не
> вызывал потерю адреса интерфесом.. Может протокол icq снова поменялся
> - без понятия, как говорится..
> 
> Так что в чем причина - не знаю. В dhcpcd или в sim.. ПОсмотрю сегодня
> - если потери адреса wlan0 не будет - значит был виноват sim..
> 
> Жаль, мне он больше нравился, нежели другие.

Нет, все же не SIM.. 

А вот что говорит tcpdump в то время когда сетевая составляющая
интерфейса не работает (а сам интерфейс жив):

11:40:41.546080 00:13:7f:10:03:38 (oui Unknown) Unknown SSAP 0x70 >
00:12:80:a5:48:01 (oui Unknown) Unknown DSAP 0x36 Information, send seq
29, rcv seq 32, Flags [Command], length 216 11:40:41.585330
00:13:7f:10:03:38 (oui Unknown) Unknown SSAP 0x50 > 00:12:80:a5:48:01
(oui Unknown) Unknown DSAP 0x66 Information, send seq 42, rcv seq 32,
Flags [Response], length 216 11:40:41.606765 00:13:7f:10:03:38 (oui
Unknown) Unknown SSAP 0x58 > 00:12:80:a5:48:01 (oui Unknown) Unknown
DSAP 0x68 Information, send seq 89, rcv seq 32, Flags [Response],
length 216 11:40:41.624651 00:13:7f:10:03:38 (oui Unknown) Unknown SSAP
0x30 > 00:12:80:a5:48:01 (oui Unknown) Unknown DSAP 0x38 Information,
send seq 111, rcv seq 32, Flags [Command], length 216 11:40:41.646089
00:13:7f:10:03:38 (oui Unknown) ISO8208 > 00:12:80:a5:48:01 (oui
Unknown) Unknown DSAP 0x68 Information, send seq 107, rcv seq 32, Flags
[Response], length 216 11:40:41.663971 00:13:7f:10:03:38 (oui Unknown)
Unknown SSAP 0x10 > 00:12:80:a5:48:01 (oui Unknown) ISO8208
Information, send seq 1, rcv seq 32, Flags [Command], length 216
11:40:41.685435 00:13:7f:10:03:38 (oui Unknown) Unknown SSAP 0x3c >
00:12:80:a5:48:01 (oui Unknown) Unknown DSAP 0x64 Information, send seq
19, rcv seq 32, Flags [Command], length 216 ^C 555 packets captured 559
packets received by filter 0 packets dropped by kernel

Обычный обмен адресам второго уровня... Ибо Destination Service Access
Point — поле адреса доступа к службе получателя; Source Service Access
Point — поле адреса доступа к службе отправителя;

Все же дело в dhcpcd (или же во всевозможных обновлениях альтератора,
которые были позавчера и вчера). Попробую пересоздать сеть - заново
прописать key и т.д.

А не может быть так, что в результате какого-то бездействия по таймауту
отрубается сеть?..

-- 
С уважением,
Владимир Гусев