D-Link • Просмотр темы - DSL-500T: Проблема с PPPoE или модем не дружит с линией

Сообщения без ответов | Активные темы

Список форумов » ADSL и последняя миля

Часовой пояс: UTC + 3 часа

DSL-500T: Проблема с PPPoE или модем не дружит с линией

Модераторы: Sergei Asmankin, Sergik, Vladimir Degtyarev, Davydov Denis

Страница 1 из 4

[ Сообщений: 50 ]

На страницу 1, 2, 3, 4 След.

Предыдущая тема | Следующая тема

Автор

Сообщение

BTL

Заголовок сообщения: DSL-500T: Проблема с PPPoE или модем не дружит с линией

Добавлено: Пт фев 09, 2007 00:10

Зарегистрирован: Вт ноя 21, 2006 18:44
Сообщений: 14
Откуда: Самара

Стал обладателем сего таинственного девайса в апреле прошлого года с залитой прошивкой v.2. С самого начала наблюдается долгое соединение по PPPoE (~2 часа, очень редко 10 мин.). После этого работа стабильная, без разрывов. Поскольку модем большее время был включён, это не доставляло особых неудобств, но когда срочно требовалась связь - её не было и приходилось выжидать у моря погоды. Роутеры других производителей THOMSON и ZyXEL схватывают сразу же.
В режиме моста соединение на этой же телефонной линии средствами ОС и, например, D-Link DI-804HV осуществляется мгновенно. Стоит также отметить, что на других линиях, порой даже худших по SNR и Att, данный аппарат работает.
Иногда модем зависает (было замечено при включенном PPPoEPassThrough). Отвисает только на время отсоединение линии.

Вот логи спустя два с половиной часа безуспешной попытки подключения:

Цитата:

# date
Sat Jan 1 14:27:38 UTC 2005
# ifconfig
br0 Link encap:Ethernet HWaddr 00:13:46:XX:XX:XX
inet addr:192.168.1.254 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ASYMMTU:1500
RX packets:1310 errors:0 dropped:0 overruns:0 frame:0
TX packets:21670 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:111679 (109.0 kb) TX bytes:1777775 (1.6 Mb)

br1 Link encap:Ethernet HWaddr 00:00:00:00:00:00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ASYMMTU:1500
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

eth0 Link encap:Ethernet HWaddr 00:13:46:XX:XX:XX
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ASYMMTU:1500
RX packets:1310 errors:0 dropped:0 overruns:0 frame:0
TX packets:21579 errors:78 dropped:78 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:111679 (109.0 kb) TX bytes:1772286 (1.6 Mb)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1 ASYMMTU:0
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

nas0 Link encap:Ethernet HWaddr 00:13:46:XX:XX:XX
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ASYMMTU:1500
RX packets:20670 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1027476 (1003.3 kb) TX bytes:228 (228.0 b)

Цитата:

Jan 1 12:00:11> NTP Polling Timer for DHCP Started succesfully.
Jan 1 12:00:11> DSL Polling Timer Started succesfully.
Jan 1 12:00:12> Firewall NAT service started
Jan 1 12:00:12> The firmware build date/time:20060818101726
Jan 1 12:00:13> starting on port 80
Jan 1 12:00:13> Bridge Created: br0
Jan 1 12:00:14> Bridge Created: br1
Jan 1 12:00:14> Bridge Interface Added: eth0
Jan 1 12:00:21> DSL Carrier is down
Jan 1 12:00:31> DSL Carrier is up
Jan 1 12:00:31> sar read trained mode (1)(ADSL_G.dmt)
Jan 1 12:00:31> pppd 2.4.3 started by root, uid 0

Всё это время Waiting for Response...

Цитата:

AR7 DSL Modem Statistics:
--------------------------------
[DSL Modem Stats]
US Connection Rate: 896 DS Connection Rate: 6976
DS Line Attenuation: 12 DS Margin: 24
US Line Attenuation: 2 US Margin: 20
US Payload : 1056 DS Payload: 2052288
US Superframe Cnt : 526853 DS Superframe Cnt: 526853
US Transmit Power : 12 DS Transmit Power: 11
LOS errors: 0 SEF errors: 0
Frame mode: 3 Max Frame mode: 0
Trained Path: 1 US Peak Cell Rate: 2113
Trained Mode: 3 Selected Mode: 3
ATUC Vendor Code: 50000000 ATUC Revision: 3
Hybrid Selected: 1 Trellis: 1
Showtime Count: 1 DS Max Attainable Bit Rate: 11712 kbps
BitSwap: 1 US Max Attainable Bit Rate: n/a
Annex: AnxA psd_mask_qualifier: 0x0000
ATUC ghsVid: b5 00 50 00 00 00 00 00
T1413Vid: 00 00 T1413Rev: 00 VendorRev: 00
ATUR ghsVid: b5 00 54 53 54 43 00 00
T1413Vid: 00 00 T1413Rev: 00 VendorRev: 00

[Upstream (TX) Interleave path]
CRC: 2 FEC: 68 NCD: 0
LCD: 0 HEC: 68

[Downstream (RX) Interleave path]
CRC: 0 FEC: 0 NCD: 0
LCD: 0 HEC: 0

[Upstream (TX) Fast path]
CRC: 0 FEC: 0 NCD: 1
LCD: 0 HEC: 0

[Downstream (RX) Fast path]
CRC: 0 FEC: 0 NCD: 0
LCD: 0 HEC: 0

[ATM Stats]
[Upstream/TX]
Good Cell Cnt: 22
Idle Cell Cnt: 18926923

[Downstream/RX)]
Good Cell Cnt: 42756
Idle Cell Cnt: 147316959
Bad Hec Cell Cnt: 0
Overflow Dropped Cell Cnt: 0

[SAR AAL5 Stats]
Tx PDU's: 4
Rx PDU's: 20915
Tx Total Bytes: 228
Rx Total Bytes: 1541115
Tx Total Error Counts: 0
Rx Total Error Counts: 0

[OAM Stats]
Near End F5 Loop Back Count: 0
Near End F4 Loop Back Count: 0
Far End F5 Loop Back Count: 0
Far End F4 Loop Back Count: 0

Проводка линии до коробки - витая пара UTP5. До АТС расстояние порядка 500 метров. Скорость соединения 6976/896 ограничена провайдером.

Удивляет при неплохих характеристиках затухания и шума наличие огромного количества неиспользованых ячеек и всего 4 отосланных пакета на запрос соединения.

Вернуться наверх

Davydov Denis

Заголовок сообщения:

Добавлено: Пт фев 09, 2007 11:48

Сотрудник D-LINK

Зарегистрирован: Пт апр 01, 2005 12:35
Сообщений: 8492
Откуда: Москва

В Вашем случае нужно попросить провайдера посмотреть логи подключений (приходят ли с вашего MAC адреса PADI пакеты и отвечает ли на них PADO пакетами PPP сервер).

_________________
С уважением, Давыдов Денис.

Вернуться наверх

BTL

Заголовок сообщения:

Добавлено: Вт фев 13, 2007 00:49

Зарегистрирован: Вт ноя 21, 2006 18:44
Сообщений: 14
Откуда: Самара

Davydov Denis писал(а):

Провайдер, проанализировав ситуацию, так и не особо понял в чём суть проблемы, но склоняется к выводу что проблема не в линии, а в модеме. На текущей прошивке (3-ей) проходит всего два пакета при включении. Дальнейшее решение спецалисты будут искать после открытия заявки, за которую сдирут с меня (в случае проблемы на моей стороне) три шкуры.

Проделав за выходные серию экспериментов можно подитожить о линке селующее. Принадлежащий мне модем - ADSL Router D-Link DSL-500T. Под словом "Подключается" подрузамевается мгновенное соединение по PPPoE, под "Не подключается" - соединение от 5 мин до 2 часов и более :shock:

.

Итак,

1. THOMSON 530 - Подключается.

2. ZyXEL P660R-T1 - Подключается.

3. Bridge (на DSL-500T) + PPPoE средствами Win XP - Подключается.

4. Bridge (на DSL-500T) + PPPoE средствами D-Link DI-804HV - Подключается.

5. D-Link DSL-500T - Не подключается. Были проверены 3 аппарата с разными прошивками и соответственно из разных партий.

6. Всё выше перечисленное на 3-х других линиях - Подключается.

Из чего делаем вывод, что не соединяются только 500-е и только на этой линии.

Логи модема с прошивкой v.3 преведены в предыдущем сообщении. Вот лог с первой прошивки 500T:

Код:

Sep  8 12:00:06> Valid Configuration Tree
Sep  8 12:00:10> Firewall NAT service started
Aug  9 12:01:00> Bridge Created: br0
Aug  9 12:01:00> Bridge Interface Added: eth0
Aug  9 12:01:01> pppd 2.4.1 started by root, uid 0
Aug  9 12:01:03> DSL Carrier is up
Aug  9 12:01:12> Connecting PPPoE socket: 00:00:00:00:00:00 0000  0x1000d3b8
Aug  9 12:01:12> Couldn't get channel number: Transport endpoint is not connected
Aug  9 12:01:12> Doing disconnect
Aug  9 12:01:12> pppd 2.4.1 started by root, uid 0
Aug  9 12:01:12> Unexpected packet: Ether addr: 00:11:5c:ba:e6:1b  (PPPOE Discovery)  PPPoE hdr: ver=0x1 type=0x1 code=0x07 sid=0x0000 length=0x002e (PADO)  PPPoE tag: type=0103 length=0004 (Host Uniq) data (bin):  b8 d3 00 10 PPPoE tag: type=0101 length=
Aug  9 12:01:21> Connecting PPPoE socket: 00:00:00:00:00:00 0000  0x1000d3b8
Aug  9 12:01:21> Couldn't get channel number: Transport endpoint is not connected
Aug  9 12:01:21> Doing disconnect
12.02.2007 2:04:54  cfgmgr(pppoe1): Aug  9 12:01:21> System Call Error
Aug  9 12:01:21> pppd 2.4.1 started by root, uid 0
Aug  9 12:01:31> Connecting PPPoE socket: 00:00:00:00:00:00 0000  0x1000d3b8
Aug  9 12:01:31> Couldn't get channel number: Transport endpoint is not connected
Aug  9 12:01:31> Doing disconnect
Aug  9 12:01:31> System Call Error

... ... ... ... ... ... ... ... ... ... ... ... ... ...
          (Пропустим 4 часа)

Aug  9 16:16:45> pppd 2.4.1 started by root, uid 0
Aug  9 16:16:45> Unexpected packet: Ether addr: 00:19:aa:25:db:18  (PPPOE Discovery)  PPPoE hdr: ver=0x1 type=0x1 code=0x07 sid=0x0000 length=0x002b (PADO)  PPPoE tag: type=0103 length=0004 (Host Uniq) data (bin):  b8 d3 00 10 PPPoE tag: type=0101 length= Aug  9 16:16:52> System Call Error
Aug  9 16:16:52> Failed to negotiate PPPoE connection: 25 
Aug  9 16:16:52> pppd 2.4.1 started by root, uid 0
Aug  9 16:17:08> System Call Error
Aug  9 16:17:08> Connecting PPPoE socket: 00:00:00:00:00:00 0000  0x1000d3b8
Aug  9 16:17:08> Couldn't get channel number: Transport endpoint is not connected
Aug  9 16:17:08> Doing disconnect
Aug  9 16:17:08> pppd 2.4.1 started by root, uid 0
Aug  9 16:17:08> Unexpected packet: Ether addr: 00:19:aa:25:db:18  (PPPOE Discovery)  PPPoE hdr: ver=0x1 type=0x1 code=0x07 sid=0x0000 length=0x002b (PADO)  PPPoE tag: type=0103 length=0004 (Host Uniq) data (bin):  b8 d3 00 10 PPPoE tag: type=0101 length= Aug  9 16:17:22> System Call Error
Aug  9 16:17:22> Connecting PPPoE socket: 00:00:00:00:00:00 0000  0x1000d3b8
Aug  9 16:17:22> Couldn't get channel number: Transport endpoint is not connected
Aug  9 16:17:22> Doing disconnect
Aug  9 16:17:23> pppd 2.4.1 started by root, uid 0
Aug  9 16:17:44> System Call Error
Aug  9 16:17:44> Connecting PPPoE socket: 00:00:00:00:00:00 0000  0x1000d3b8
Aug  9 16:17:44> Couldn't get channel number: Transport endpoint is not connected
Aug  9 16:17:44> Doing disconnect
Aug  9 16:17:45> pppd 2.4.1 started by root, uid 0
Aug  9 16:17:58> System Call Error
Aug  9 16:17:58> Connecting PPPoE socket: 00:00:00:00:00:00 0000  0x1000d3b8
Aug  9 16:17:58> Couldn't get channel number: Transport endpoint is not connected
Aug  9 16:17:58> Doing disconnect
Aug  9 16:17:58> pppd 2.4.1 started by root, uid 0
Aug  9 16:18:16> System Call Error
Aug  9 16:18:16> Connecting PPPoE socket: 00:00:00:00:00:00 0000  0x1000d3b8
Aug  9 16:18:16> Couldn't get channel number: Transport endpoint is not connected
Aug  9 16:18:16> Doing disconnect
Aug  9 16:18:16> pppd 2.4.1 started by root, uid 0
Aug  9 16:18:41> Connecting PPPoE socket: 00:19:aa:25:db:18 acaf nas1 0x1000d3b8
Aug  9 16:18:41> Connect: ppp0 {--} nas1
Aug  9 16:18:43> WAN IP address 88.200.XXX.XXX
Aug  9 16:18:43> WAN gateway 85.112.XXX.XXX
Aug  9 16:18:43> PPPoE Connect with IP Address 88.200.XXX.XXX 
Aug  9 16:18:43> PPPoE Connection Successfully Established 
Aug  9 16:18:43> PPPoE Connect with Gateway IP Address: 85.112.XXX.XXX

Что же это: линия или PPP сервер, не знающие повадок 500T или всё таки особенности 500T, не чувствующего линию :roll:

[/img]

Вернуться наверх

Davydov Denis

Заголовок сообщения:

Добавлено: Вт фев 13, 2007 11:09

Сотрудник D-LINK

Зарегистрирован: Пт апр 01, 2005 12:35
Сообщений: 8492
Откуда: Москва

В DSL-500T присутствует стандартный (отвечающий всем рекомендациям rfc2516) PPPoE клиент.
Судя по вашим логам, устройство инициализирует подключение, PADI пакеты уходят, но PPP сервер не всегда на них отвечает пакетами PADO.
Это легко можно отследить на стороне провайдера.

_________________
С уважением, Давыдов Денис.

Вернуться наверх

BTL

Заголовок сообщения:

Добавлено: Вт фев 13, 2007 23:14

Зарегистрирован: Вт ноя 21, 2006 18:44
Сообщений: 14
Откуда: Самара

Davydov Denis писал(а):

Получается PPP сервер не отвечает только 500-ым в связке только с данной линией. Повторюсь, на остальных проблем нет.
Кстати, вспомнил, что tcpdump на альтернативной прошивке выдаёт сообщение fragmentation error.
Провайдер советует менять модем на другого производителя, но меня это не особо устраивает, поскольку так сложилось, что мы используем всё оборудование исключительно D-Link (и проводное и безпроводное), что нас устраивало вполне и менять этого не хотели бы.

Вернуться наверх

Davydov Denis

Заголовок сообщения:

Добавлено: Ср фев 14, 2007 15:34

Сотрудник D-LINK

Зарегистрирован: Пт апр 01, 2005 12:35
Сообщений: 8492
Откуда: Москва

BTL писал(а):

Davydov Denis писал(а):

Попробуйте поэкспериментировать с параметром MTU в настройках WAN интерфейса. Например, уменьшите его до 1400 - 1300.

_________________
С уважением, Давыдов Денис.

Вернуться наверх

BTL

Заголовок сообщения:

Добавлено: Пн фев 19, 2007 01:28

Зарегистрирован: Вт ноя 21, 2006 18:44
Сообщений: 14
Откуда: Самара

Davydov Denis писал(а):

К сожалению, всё по прежнему. Что, наверное, не удивильно, поскольку минимальное значение MRU и MTU: 128, а размеры пакетов на стадии подключения не превышают 60 байт.

Но зато я выяснил следующее:
После отсылки броадкаст пакета Инициации PADI, доступные PPP серверы высылают Предложение PADO. Следующим шагом идёт Просьба PADR, в ответ приходит подтверждение Сеанса PADS с номером устанавливаемой сессии. Далее в рамках сессии идёт согласование шифрования, проверка паролей, выдача адресов и т.д.
Касательно меня (клиент pppd 2.4.1), стопор возникает в период первых 4 PADx пакетов. А именно, не всегда приходят PADO и PADS, а если приходят, то в интервале 2 мс после отправки запроса. Поскольку номер сессии не определён, в логе появляется запись:

Код:

Aug  9 12:48:59> System Call Error
Aug  9 12:48:59> Connecting PPPoE socket: 00:00:00:00:00:00 0000  0x1000d3b8
Aug  9 12:48:59> Couldn't get channel number: Transport endpoint is not connected
Aug  9 12:48:59> Doing disconnect

Вот что делает 500й (приведены только пакеты, относящиеся к устройству):

Код:

02:08.260001 PPPoE PADI [Host-Uniq 0xB8D30010]
02:08.510001 PPPoE PADO [Host-Uniq 0xB8D30010] [Service-Name]
02:08.510001 PPPoE PADR [Service-Name] [Host-Uniq 0xB8D30010]
02:17.120001 PPPoE PADT [Host-Uniq 0xB8D30010]
02:17.450001 PPPoE PADI [Host-Uniq 0xB8D30010]
02:23.000001 PPPoE PADT [Host-Uniq 0xB8D30010]
02:28.310001 PPPoE PADI [Host-Uniq 0xB8D30010]
02:28.320001 PPPoE PADO [Host-Uniq 0xB8D30010] [Service-Name]
02:28.330001 PPPoE PADR [Service-Name] [Host-Uniq 0xB8D30010]
02:34.540001 PPPoE PADT [Host-Uniq 0xB8D30010]
02:36.140001 PPPoE PADI [Host-Uniq 0xB8D30010]
02:44.320001 PPPoE PADT [Host-Uniq 0xB8D30010]
02:49.630001 PPPoE PADI [Host-Uniq 0xB8D30010]
02:49.640001 PPPoE PADO [Host-Uniq 0xB8D30010] [Service-Name]
02:49.640001 PPPoE PADR [Service-Name] [Host-Uniq 0xB8D30010]
02:58.020001 PPPoE PADT [Host-Uniq 0xB8D30010]
всё такое
20:24.530001 PPPoE PADI [Service-Name] [Host-Uniq 0xB8D30010]
20:34.530001 PPPoE PADI [Service-Name] [Host-Uniq 0xB8D30010]
20:34.550001 PPPoE PADO [Service-Name] [Host-Uniq 0xB8D30010]
20:34.550001 PPPoE PADR [Service-Name] [Host-Uniq 0xB8D30010]
20:51.660001 PPPoE PADR [Service-Name] [Host-Uniq 0xB8D30010]
20:51.680001 PPPoE PADS [Service-Name] [Host-Uniq 0xB8D30010]
20:52.000001 PPPoE PADI [Host-Uniq 0xB8D30010]
21:02.000001 PPPoE PADI [Service-Name] [Host-Uniq 0xB8D30010]
21:02.020001 PPPoE PADO [Service-Name] [Host-Uniq 0xB8D30010]
21:02.020001 PPPoE PADR [Service-Name] [Host-Uniq 0xB8D30010]
21:12.020001 PPPoE PADR [Service-Name] [Host-Uniq 0xB8D30010]
21:12.040001 PPPoE PADS [ses 0x5173] [Service-Name] [Host-Uniq 0xB8D30010]

Очень долго он решается на повторную отправку... Или закрывает сессию PADT.
А вот виндовый клиент, к примеру, не получив ответа через 5 сек. повторно отсылает последние данные и логинится с первой попытки.

Davydov Denis писал(а):

В DSL-500T присутствует стандартный (отвечающий всем рекомендациям rfc2516) PPPoE клиент.

А вот отрывок из RFC 2516:

Цитата:

8. Other Considerations

When a host does not receive a PADO packet within a specified amount of time, it SHOULD resend it's PADI packet and double the waiting period. This is repeated as many times as desired. If the Host is waiting to receive a PADS packet, a similar timeout mechanism SHOULD be used, with the Host re-sending the PADR. After a specified number of retries, the Host SHOULD then resend a PADI packet.

Кажется так:

8. Другие Соображения

Когда хост не получает пакет PADO в пределах определенного времени, он ДОЛЖЕН передать повторно пакет PADI и удвоить период ожидания. Это повторяется так много раз как захочет. Если хост ожидает получения пакета PADS, аналогичный механизм тайм-аута ДОЛЖЕН быть использован, с перепосылкой PADR. После определенного количества повторных попыток, хост ДОЛЖЕН затем передать повторно пакет PADI.

Провайдер, став монополистом в своём деле, либо не особо хочет решать проблемы своих клиентов, либо, как они отвечают: ничего не знаем, ставьте в бридж и работайте через ОС. Это для меня не приемлимо.

По сему возникают следующие вопросы:
1. По интерфейсу nas "влетают" чужие PADI, PADO пакеты, а иногда и сессии PPPoE вцелом. Так должно быть или это отклонение?
2. Я описывал, что все модемы подключаются хорошо, кроме D-Link'ов, но я пользуюсь именно им. Как можно в таком случае "нормально" устанавливать подключение?
3. Кажется столкнулся с этим не один я. И города у нас разные. http://forum.dlink.ru/viewtopic.php?t=36113

Вернуться наверх

Alexey Gakalo

Заголовок сообщения:

Добавлено: Пн фев 19, 2007 14:10

Сотрудник D-LINK

Зарегистрирован: Чт мар 17, 2005 11:14
Сообщений: 1314
Откуда: Воронеж

C какими прошивками вы наблюдали подобную проблему с DSL-500T? Назовите конкретные версии.

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

Вернуться наверх

BTL

Заголовок сообщения:

Добавлено: Пн фев 19, 2007 23:49

Зарегистрирован: Вт ноя 21, 2006 18:44
Сообщений: 14
Откуда: Самара

За всё время были опробованы 3 D-Link'а 500-х:
1. с родной прошивкой V1.00B02T02.RU.20041014;
2. с родной прошивкой V2.01B01T01.RU.20060522;
3. прошивки V1.00B02T02.RU.20041014 --> V2.00B01T01.EU.20050614 --> V2.00B01T01.EU.20050930 --> V2.01B01T01.RU.20060429 --> V2.01B01T01.RU.20060522 --> V2.01B01T01.RU.20060620 --> V3.02B01T01.RU.20060818 --> V1.00B02T02.RU.20051130.MC06.6b.ADSL1.

Ранее я приводил логи 3-го модема. В первом посте с прошивкой V3.02B01T01.RU.20060818, в остальных - V1.00B02T02.RU.20051130.MC06.6b.ADSL1.
Симптомы всегда одинаковые, с тем лишь отличием, что в первых прошивках модем периодически пытается установить соединение, а в последних, начиная с V2.01B01T01.RU.20060522 (или 20060620) однажды отослав несколько пакетов, модем ожидает Waiting for Response...

Вернуться наверх

Bigarov Ruslan

Заголовок сообщения:

Добавлено: Вт фев 20, 2007 10:41

Сотрудник D-LINK

Зарегистрирован: Пт янв 21, 2005 11:52
Сообщений: 11212
Откуда: D-Link, Moscow

1. Какая скорость у Вас по контракту?
2. Какая модуляция стоит в настройках?

_________________
С уважением,
Бигаров Руслан.

Вернуться наверх

Alexey Gakalo

Заголовок сообщения:

Добавлено: Вт фев 20, 2007 11:10

Сотрудник D-LINK

Зарегистрирован: Чт мар 17, 2005 11:14
Сообщений: 1314
Откуда: Воронеж

Цитата:

По сему возникают следующие вопросы:
1. По интерфейсу nas "влетают" чужие PADI, PADO пакеты, а иногда и сессии PPPoE вцелом. Так должно быть или это отклонение?
2. Я описывал, что все модемы подключаются хорошо, кроме D-Link'ов, но я пользуюсь именно им. Как можно в таком случае "нормально" устанавливать подключение?
3. Кажется столкнулся с этим не один я. И города у нас разные. http://forum.dlink.ru/viewtopic.php?t=36113

1. Да это нормально: PADI посылает на широковещательный адрес, поэтому он "cлышен" всем.
2.В данном случае "нормальность" целиком и полностью зависит от PPPoE сервера провайдера,а не от нас. Совершенно очевидно,что PPPoE сервер провайдера просто не справляется с нагрузкой, поскольку в отведенное время он не отсылает пакетов надлежащего формата ( по вашим логам тайм-аут между PADR и PADT достигает 5-10 секунд, что НЕНОРМАЛЬНО).
98-99% модемов подобного типа соединяется в этой ситуации совершенно нормально и без всяких проблем.
По RFC2516: заметьте Это повторяется так много раз как захочет . То есть модему решать, сколько раз он будет повторять запрос (2 или 100) и RFC нас в этом не ограничивает.
3.Не факт.В этом случае может быть совершенно другая проблема.

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

Вернуться наверх

BTL

Заголовок сообщения:

Добавлено: Вт фев 20, 2007 12:31

Зарегистрирован: Вт ноя 21, 2006 18:44
Сообщений: 14
Откуда: Самара

Bigarov Ruslan писал(а):

1. Какая скорость у Вас по контракту?
2. Какая модуляция стоит в настройках?

1. По контракту скорость без ограничений. Максимальная - 8 Mbps. В настоящий момент ограничили подключение на 7, а вообще пробоволи снижать до 4. Сама линия - чистая.
2. И в настройках модема, и на DSLAM'е стоит G.dmt.

Alexey Gakalo писал(а):

В данном случае "нормальность" целиком и полностью зависит от PPPoE сервера провайдера,а не от нас. Совершенно очевидно,что PPPoE сервер провайдера просто не справляется с нагрузкой, поскольку в отведенное время он не отсылает пакетов надлежащего формата ( по вашим логам тайм-аут между PADR и PADT достигает 5-10 секунд, что НЕНОРМАЛЬНО).
98-99% модемов подобного типа соединяется в этой ситуации совершенно нормально и без всяких проблем.
По RFC2516: заметьте Это повторяется так много раз как захочет . То есть модему решать, сколько раз он будет повторять запрос (2 или 100) и RFC нас в этом не ограничивает.

По поводу сервера. Их 3, и PADO пакеты приходят одновреммено от разных, стабильно 1-2. И работают они, как я думаю, нормально, поскольку и в соседнем доме и в остальных модем подключается.
Если дело всётаки в порту DSLAM'а, то ситуация тупиковая. Пров приходит, ставит свой ZyXel и посылает меня ... , подключается ведь он.
Не знаю насчёт RFC, но ГОСТ, например, это не рекомендации, а стандарт. Там чётко написано - отклонение от него преследуется по закону. А в RFC2516 указано - и PADI, и PADR пакеты модем ДОЛЖЕН передать повторно на том же этапе, а не начинать с самого начала с PADI как в моём случае. Я же описывал как подключается все модемы и винда, и DI-804HV тоже. IMHO, модем должен пытаться брать связь на любой линии, а не равняться по лучшей.

Вернуться наверх

Alexey Gakalo

Заголовок сообщения:

Добавлено: Вт фев 20, 2007 15:36

Сотрудник D-LINK

Зарегистрирован: Чт мар 17, 2005 11:14
Сообщений: 1314
Откуда: Воронеж

Мы проверим вашу ситуацию. По результатам отпишемся в форуме.

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

Вернуться наверх

xandr

Заголовок сообщения:

Добавлено: Ср фев 21, 2007 17:09

Зарегистрирован: Ср апр 05, 2006 08:38
Сообщений: 8
Откуда: N. Novgorod

Аналогичная ситуация. Уже несколько месяцев борюсь с этим - ничего не помогает. Бриджом работает, PPPoE - нет. В логах также как и здесь описано. Провайдер - Волгателеком. Сначала пытался с ними ругаться, но они говорят, что "рекомендация от Волгателеком - работать в режиме бриджа, т.к. 500T имеет проблемы с PPPoE".

Вернуться наверх

Виталий Кулак

Заголовок сообщения:

Добавлено: Ср фев 21, 2007 22:07

Зарегистрирован: Ср фев 21, 2007 22:03
Сообщений: 2

Все описанное и в моем случае. Судя по всему. это реальная проблема 500T! Если только за последний месяц на форуме 5-6 сообщений. D-linkoвцы! Фиксите баг!

Вернуться наверх

Страница 1 из 4

[ Сообщений: 50 ]

На страницу 1, 2, 3, 4 След.

Список форумов » ADSL и последняя миля

Часовой пояс: UTC + 3 часа

Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 143

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения