FreeBSD и 5614BXL/VR+

[erebus]

Уважаемый суппорт!
Понимаю, что скорее всего эта проблема не к вам, но раз вы заявляете работоспособность своих модемов под FreeBSD, то вам могут быть известны какие-то тонкости, которые пока я не знаю.
Модем IDC-5614BXL/VR+, прошивка 2.26, FreeBSD 5.4-RELEASE, pppd из поставки (v2.3.5) или из портов (v2.3.11) - без разницы.
User ppp работает нормально с дефолтными настройками (ну разве что номер телефона и логин вбить). Проблемы начинаются с kernel ppp. С настройками по умолчанию на прием соединение работает нормально, а на передачу сколь-нибудь больших объемов (например, письмо) либо вообще не работает (в основном на протоколе v34), либо работает очень медленно (v32 и v90), хотя это не должно быть связано с протоколом. Очень похоже на проблему 10.1 из PPP-FAQ (http://www.ibiblio.org/pub/Linux/docs/faqs/PPP-FAQ/PPP-FAQ), за исключением того, что у меня аппаратный контроль потока включен как в модеме, так и в настройках pppd. Если снижать mtu с 1500 до, например, 576, то передача начинает работать нормально, даже с приемлемой скоростью. Такая же ситуация если понизить скорость порта с 115200 до 38400. Скорость передачи хорошо смотреть на cvsup ports-supfile, на user ppp дерево портов обновляется за 10-15 минут, на kernel ppp от 40 минут до нескольких часов.
Очевидно, что проблема на стороне моего компьютера. Рабочее предположение: pppd некорректно обрабатывает аппаратный контроль потока и все-таки переполняет буфер модема (или какой-нибудь свой?), из-за чего соединения разрываются. Если это так, то естественно нужно связываться с разработчиками.
Хочется узнать ваше мнение по данному вопросу и совет, как проверить мою гипотезу.

[Technical Support]

Судя по симптомам, проблемы с управлением потоком - наиболее вероятная причина происходящего. Проверить данную теорию очень просто, надо лишь взглянуть на Unimodem Diagnostics (статистику, выдаваемую командой at#ud) после сеанса связи, в котором Вы пытались передавать большой объём данных.

Расшифровать Unimodem Diagnostics можно с помощью декодера диагностики #UD, который можно скачать с нашего сайта, см. на страничке "Программы сторонних производителей".

В статистике нужно проверить строчку:

TX/RX chars lost (data overrun): 0/0

Если с управлением потоком что-то не так, то счётчик потерянных при передаче байт данных будет ненулевым.
_________________
Inpro
Technical Support

[erebus]

Спасибо за совет. Действительно буфер модема переполнялся. Найден и виновник - это звонилка KPPP. Из-за глюка в её локализации pppd вызывается с параметром xonxoff независимо от всех настроек. Так что оказывается это не проблема FreeBSD или pppd. Проверил на SuSE 9.2 - такой же глюк. Буду связываться с разработчиком KPPP.

[Technical Support]

В принципе, можно жить и с XON/XOFF, если он правильно реализован в ПО. Посмотрите описание команды AT&Kn и выясните, какой из методов (&K4 или &K5) требуется при данной настройке ПО. Дальше останется лишь обеспечить выдачу нужной команды при инициализации модема
_________________
Inpro
Technical Support