Up

Задолбался, одним словом... Поставил модем в режим Bridge. Аська не вылетает, онлайн видео не обрывается, всё стабильно. Но чёрт возьми, хочется же всё-таки, чтобы устройство, специально сделанное для этого, работало так как положено .
Значит получается всё дело в прошивке, так как в режиме Bridge всё идеально и работу прошивки модема выполняет операционная система компьютера. Так почему же ОС идеально с этим справляется, а прошивка, которая специально для этого сделана, абсолютно глючная?

_________________
DSL-2500U/BRU/D (H/W D2) | F/W 1.58 | Укртелеком ОГО! - Лёгкий (5 мегабит)

Та же проблема. Что только не делал, куча прошивок, разнообразных сочетаний настроек, прочитал уйму постов на форумах, а результата ноль.
Лог, f/w 1.52

Странно как модем сумел отработать стабильно один год.
Что с ним делать сейчас - даже не представляю.

Во-во, как только Аська обрывается в логе модема пишеться ACS Conect Failed

_________________
DSL-2500U/BRU/D (H/W D2) | F/W 1.58 | Укртелеком ОГО! - Лёгкий (5 мегабит)

Как сотрудник провайдера скажу что такая проблема на модемах фиксируется при работе на дискамах Зуксель IES-1248 и Алкатель 7324.
Сейчас проверяем эти модемы в ревизии 3, пока результатов нет.

ep 30 21:37:42 user debug syslog: route add default gw 84.204.116.1 2>/dev/null
Sep 30 21:37:42 user debug syslog: iptables -A FORWARD -o ppp_0_0_100_1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Sep 30 21:37:42 user debug syslog: iptables -A FORWARD -i ppp_0_0_100_1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Sep 30 21:37:42 user debug syslog: echo > /proc/net/ip_conntrack
Sep 30 21:37:42 user debug syslog: echo "600" > /proc/sys/net/ipv4/ip_conntrack_max
Sep 30 21:37:42 user debug syslog: echo 2000 > /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout
Sep 30 21:37:42 user debug syslog: echo 600 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
Sep 30 21:37:42 user debug syslog: echo 1400 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
Sep 30 21:37:43 user debug syslog: echo 2000 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
Sep 30 21:37:43 user debug syslog: echo 4096 > /proc/sys/net/ipv4/ipfrag_high_thresh
Sep 30 21:37:43 user debug syslog: echo 1024 > /proc/sys/net/ipv4/ipfrag_low_thresh
Sep 30 21:37:43 user debug syslog: echo 5 > /proc/sys/net/ipv4/ipfrag_time
Sep 30 21:37:43 user debug syslog: iptables -t nat -D PREROUTING -i br0 -d 192.168.1.1 -p udp --dport 53 -j DNAT --to 128.9.0.107 2>/dev/null
Sep 30 21:37:43 user debug syslog: iptables -t nat -D POSTROUTING -o ppp_0_0_100_1 -s 192.168.1.0/255.255.255.0 -j MASQUERADE 2>/dev/null
Sep 30 21:37:43 user debug syslog: iptables -t nat -A POSTROUTING -o ppp_0_0_100_1 -s 192.168.1.0/255.255.255.0 -j MASQUERADE
Sep 30 21:37:43 user debug syslog: iptables -t nat -D PREROUTING -i br0 -d 192.168.1.1 -p udp --dport 53 -j DNAT --to 217.195.65.9 2>/dev/null
Sep 30 21:37:43 user debug syslog: iptables -t nat -A PREROUTING -i br0 -d 192.168.1.1 -p udp --dport 53 -j DNAT --to 217.195.65.9
Sep 30 21:37:48 daemon debug user: dns_lookup(AcsURL) = 0.0.0.0
Sep 30 21:37:48 daemon err user: ACS Connect Failed: Could not resolve host AcsURL
Sep 30 21:42:30 daemon debug user: dns_lookup(AcsURL) = 0.0.0.0
Sep 30 21:42:30 daemon err user: ACS Connect Failed: Could not resolve host AcsURL

Проблема аналогичная, я так понимаю выделенная строка это значение ставится по умолчанию, если меняю на 1024 в логе ничего не отображается, есть способ проверить "сработала ли" команда?

Ситар, значение зависит от версии прошивки, у меня на 1,52 и 1,30 установка 1024 и выше - результата не дает.

Вот, да интересно, у меня тоже ДСЛАМ зюхель,а какой пров..если можно в личку, и результаты тестов, заранее спасибо!

Провайдер Уралсвязьинформ.

есть прошивка 1.53 от Нижегородского филиала
http://slil.ru/28050245
проблемы не решает, хотя появились дополнительные элемента настройки констант...

ftp://ftp.dlink.ru/pub/ADSL/DSL-2500U_B ... 3_10012009

Решает проблему с падением pppd сессии ( особенно актуально для прошивок 1.50,1.52).

Модемы, имеющие прошивку 1.50 с завода-изготовителя
( DSL-2500u/bru/d HW D3), рекомендуются к перепрошивке на эту версию сразу при получении.

Внимание! после перепрошивки необходимо сбросить настройки в заводские
(Management-Settings-reset to default settings) и уже затем заново настроить.


В данной прошивке,кроме того, в настройки соединения (в вэб) вынесены параметры, регулирующие буфер фрагментированных пакетов:
ipfrag_low_thresh
( нижний порог буфера)
ipfrag_high_thresh
(верхний порог буфера)
ipfrag_time
(время хранения фрагрметированных пакетов в сек)

P.S.Прошивка пока имеет статус беты. Поэтому просьба, по результатам снимать логи и отписываться в форум .

_________________
С уважением, Гакало Алексей

если это та же, что и у меня, то не работает...
http://slil.ru/28053977 - лог на 1.53 прошивке

не понимаю, если все матерятся на параметр
echo "600" > /proc/sys/net/ipv4/ip_conntrack_max
и считают его изменение руками действенным способом...
почему бы его не вынести в настройку и все б тестили с нужным им параметром?

У меня, к сожалений, без изменений http://notes.if.ua/files/log.txt
Странная точность во времени.

Ну что же. Смотрим лог.

10.05.2009 22:25:32 Daemon.Notice 192.168.1.1 pppd[276]: PAP authentication succeeded
10.05.2009 22:25:32 Daemon.Info 192.168.1.1 pppd[276]: Remote message: Authentication success,Welcome!
10.05.2009 22:25:29 Daemon.Warning 192.168.1.1 pppd[276]: Couldn't increase MRU to 1500
10.05.2009 22:25:29 Daemon.Notice 192.168.1.1 pppd[276]: Connect: ppp_0_0_33_1 <--> nas_0_0_33
10.05.2009 22:25:28 Daemon.Info 192.168.1.1 pppd[276]: Using interface ppp0_0_33_1
10.05.2009 22:25:28 Daemon.Info 192.168.1.1 pppd[276]: PPP session is 23995
10.05.2009 22:25:28 Daemon.Info 192.168.1.1 pppd[276]: Sent PADT
10.05.2009 22:25:25 Daemon.Notice 192.168.1.1 pppd[276]: Connection terminated....
10.05.2009 22:25:19 Daemon.Warning 192.168.1.1 pppd[276]: Couldn't increase MRU to 1500
10.05.2009 22:25:19 Daemon.Error 192.168.1.1 pppd[276]: PAP authentication failed
10.05.2009 22:25:19 Daemon.Info 192.168.1.1 pppd[276]: Remote message: Exceeded sessions limit.


Из него явственно видно что: модем разрывает pppoe сессию, а при повторном соединиении
PPPoE сервер ему отвечает "Remote message: Exceeded sessions limit"
что означает,что сессии для данного клиента закончились.

Т.е не вышел таймаут для повторного присоединения ( проще говоря модем "рано ломанулся").
После нескольких таких попыток и оконнчания таймаута модем повторно присоединяется.

Это происходит в частности от того, что в бэту не успели некторые наложить более ранние патчи, в частности этот :

"Изменены задержки между отправкой запросов при попытке установить PPPoE-соединение:
отправка PADI -> пауза 2 сек. -> отправка PADI -> пауза 4 сек. -> отправка PADI -> пауза 8 сек. -> отправка PADI -> пауза 16 сек. -> отправка PADI -> отправка PADT -> пауза 3 сек. -> отправка PADI -> пауза 2 сек. -> отправка PADI -> пауза 4 сек. -> и т.д."

Именно поэтому прошивка выложена в статусе бэты. Бэта 1.53 была создана как быстрая реакция на проблемы с pppoe на DSL-2500U/BRU/D hw d3..

По поводу /proc/sys/net/ipv4/ip_conntrack_max
к сожалению, вынужден огорчить вас и извинится за не совсем верное толкование данного параметра страницой ранее.
Параметр отвечает за количество сессий через NAT.
Если его выставлять в произвольное значение, у модема просто может кончиться память в самый неподходящий момент (зависнет).
Максимальное рекомендованное значение разработчиками для данного параметра на DSL-2500U/BRU/D - 1000.

P.S. Спасибо за тесты. Ваши логи будут учтены. Следующая бета будет ориентировочно на следующей недели.

_________________
С уважением, Гакало Алексей

Алексей, это всё хорошо. А что, модемы предыдущие(U-версии) выкинуть???
Я провожу тест на 3072 /proc/sys/net/ipv4/ip_conntrack_max ..ничего не заканчивается уже месяц, на 4000 падает регулярно.