(fwd) IDC-2814B[X]L[+] AT&D3S13=3 Штрих к портрету.

Andrey Gerzhov (kittle@freeland.alex-ua.com)
Mon, 28 Jun 1999 11:30:56 +0300 (EEST)

-- forwarded message --
Path: freeland.alex-ua.com!routki.ki.yurteh.net!carrier.kiev.ua!news.lucky.net!not-for-mail
From: olwi@icyb.kiev.ua
Newsgroups: ukr.nodes
Subject: IDC-2814B[X]L[+] AT&D3S13=3 Штрих к портрету.
Date: 25 Jun 1999 05:58:26 GMT
Organization: Unknown
Lines: 137
Message-ID: <930290306.508622@jet.ncc.icyb.kiev.ua>
NNTP-Posting-Host: jet.ncc.icyb.kiev.ua
Mime-Version: 1.0
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
X-Trace: news.lucky.net 930290306 13363 193.193.216.139 (25 Jun 1999 05:58:26 GMT)
X-Complaints-To: usenet@news.lucky.net
NNTP-Posting-Date: 25 Jun 1999 05:58:26 GMT
User-Agent: tin/pre-1.4-19990517 ("Psychonaut") (UNIX) (FreeBSD/2.2.8-STABLE (i386))
Cache-Post-Path: jet.ncc.icyb.kiev.ua!olwi@citadel.ncc.icyb.kiev.ua
X-Cache: MPS 2.1.2
Xref: freeland.alex-ua.com ukr.nodes:6050

Всем привет.

Один наш абонент, неравнодушный к модемам IDC, на днях провел при моем
активном участии небольшое расследование, показавшее, что документация
к IDC-2814B[X]L[+] содержит ряд неточностей. Благодаря этим неточностям,
например, модемы в нашем пуле были настроены не лучшим образом.
Расследование завершилось статьей в SU.INPRO, которая, я полагаю,
может быть полезна также многим обитателям nodes.
(Статью я самую малость сократил, но на сути это не отразилось)

--
Olwi

[ This is a (modified) repost of the following article: ] [ From: "Yuri V. Bondarenko" <yura@cdre.kiev.ua> ] [ Subject: IDC-2814B[X]L[+] AT&D3S13=3 Штрих к портрету. ] [ Newsgroups: fido7.su.inpro ] [ Message-ID: <2.07b2.KE48.FDSVRO@cdre.kiev.ua> ]

Добрый вечер, господа читатели и писатели этой эхи. В этот вечер я очень хотел бы вас всех чем-нибудь обрадовать, но увы - радовать пока нечем. :-(

Как начиналось то, о чём я хочу рассказать...

Примерно полгода назад, после того, как включил озвучивание пересогласований скорости и перетренировок в своём IDC-2814BXL+ я заметил, что провайдерский модем (такой же) при разрыве связи не посылает моему модему кадра DISC (LAPM) или LD (MNP). Эти кадры сигнализируют удалённому модему, что пора класть трубочку и сеанс связи завершён. Из-за отсутствия такой индикации разрыва соединения, локальный IDC ещё какое-то время пытался соединяться с короткими гудками и сбрасывал всю накопленную статистику, что меня радовать не могло.

В модемах 3COM (U.S. Robotics) и ZyXEL, где есть пункт статистики Disconnect Reason, такая причина разрыва соединения называется соответственно:

USR: DISC received или LD received; ZyXEL: Remote hang up.

Итак, после чтения одной из статей Майкка Телиса в эхе, где он пояснял вопрошающему, как настроить модем чтобы тот немедленно производил разрыв связи, я из некоего намёка в тексте пиcьма понял, что если наш модем настроен на выполнение немедленного аппаратного сброса по перепаду DTR (S13.1=1), напарник, скорее всего, не будет получать от нашего модема кадров DISC/LD или GSTN cleardown (для соединений без коррекции ошибок).

Тогда я связался с провайдером и попросил выставить аппаратный сброс через 2 секунды, а не сразу (S13.0=1). Сотрудник провайдера добрососвестно выполнил требуемую команду и, разумеется, получил S13=3, после чего обратил моё внимание на то, что задержки на 2 секунды не наблюдается, как если бы в S13 по прежнему была записана двойка. Ж8-[ ~ ]

Большинство из читателей этой эхи знают мою склонность к паранойе, поэтому не удивятся, если я скажу, что сразу навострил уши и стал усиленно принюхиваться к очередному багу. :-)))

Впрочем, давайте почитаем, что написано в описании S13, взятом из официальной документации на IDC-2814B[X]L[+]:

S13 │ 0-255 │ 00, hex │ Используется раздельно по битам

─────┬─────────┬──────────────────────────────────────────────────────── Бит │Значение │Описание ─────┼─────────┼──────────────────────────────────────────────────────── 0 │0 * │Модем не будет ждать перед аппаратным сбросом в режиме │ │обмена данными │1 │Модем будет ждать 2 с перед аппаратным сбросом в режиме │ │обмена данными 1 │0 * │Модем не будет сбрасываться при переходе сигнала DTR из │ │1 в 0 │1 │Модем будет выполнять аппаратный сброс при переходе │ │сигнала DTR из 1 в 0

Позволю себе процитировать, как отозвался Майк Телис по поводу этого отрывка инструкции:

MT> The manual is wrong. Frankly, I read it twice and still can't understand it.

Итак, как вы уже поняли, в описании этих битов регистра есть фатальная неточность. Попытаюсь это исправить. Смотрите, как на самом деле нужно читать описание этих битов:

S13 -- опции сброса (регистр используется побитно)

S13.0 - если установлен, по переходу сигнала DTR из состояния вкл. в состояние выкл., модем будет выполнять апааратный сброс немедленно, если соединения не установлено, или через 2 секунды, если он находится в режиме обмена данными (2 секундная пауза необходима для выполнения GSTN cleardown)

S13.1 - если установлен, по переходу сигнала DTR из состояния вкл. в состояние выкл., модем будет выполнять аппаратный сброс немедленно, независимо от наличия текущего соединения (этот бит имеет приоритет над S13.0). В этом режиме модем будет разрывать соединение немедленно без посылки DISC/LD или GSTN cleardown напарнику.

Ладно, с помощью Майка Телиса мы с сотрудником провайдера эту проблему выяснили. Было выставлено не S13=3, а S13=1 и всё должно было заработать... да не тут-то было. Сброс всё равно производился немедленно, да ещё вдобавок по прежнему без посылки DISC/LD или GSTN cleardown удалённому модему.

По моей просьбе сотрудник провайдера, ведающий модемным пулом, сравнил эффект от разрыва связи при помощи Drop DTR и при помощи ~~~~+++~~~~ath|

Оказалось, что при отработке ath DISC/LD посылается всегда и напарник тут же и сам кладёт трубку, а в случае Drop DTR происходит разрыв без оповещения. :-(

Давайте разберёмся, где же грабли? Я проверил у себя на модеме как работает S13=1. Оказалось, что у меня с посылкой DISC/LD/GSTN cleardown при выполнении Drop DTR проблемы не наблюдается. Логика подсказывает, что есть ещё какая-то установка у провайдерских модемов, влияющая на оповещение напарника перед выполнением аппаратного сброса.

Так вот, такая установка действительно есть. Это AT&D3. Смотрим в инструкцию:

&Dn │ Обработка сигнала DTR ("терминал готов") │ Команда &D определяет реакцию модема на переход On/Off │ сигнала DTR: │ 3 - модем разрывает соединение и выполняет сброс, как при │ включении питания

Вы не поверите, но здесь тоже имеется неточность. :-)) Понимать описание этой команды следует так, что она выполняет аппаратный сброс модема немедленно. При этом, нет никакой разницы, чем занимается модем. Эта команда *никогда* не выполняет оповещение напарника о разрыве соединения по инициативе нашего модема и несовместима с любыми установками битов 0 и 1 регистра S13 в том плане, что они будут игнорироваться.

Теперь можно подвести небольшой итог: если вы хотите, чтобы ваш модем выполнял аппаратный сброс по перепаду DTR и при этом корректно оповещал напарника о разрыве соединения, вам нужно установить &D2S13.0=1S13.1=0.

---
Юра.
-- end of forwarded message --

-- 
С тем, что не помешает никогда,
                                               Kittle