на самом деле если по простому то для борьбы с замираниями радиосигнала

Точно! Блин, как я мог об этом забыть... Разнесенный прием, типа!... Ну дааа...

2 Lorenz

дубль два.

"В трубе хранится UAK(User Authentication Key) длиной 128 бит.
Он генерится случайным образом базой и передается трубке в процессе "привязки"(когда телефон лежит на базе).
База посылает трубке псевдослучайное число RAND (64 бита) и еще одоно число RS (64 бита).
На основании значений K(генерится из UAK) и RS алгоритмом A11 вычисляется число KS(Session
Authentication Key, 128 бит). Затем, из KS и RAND алгоритм A12 вычисляет RES(ответ, 32 бита),
который отсылается базе, и DCK(динамический ключ шифрования, 64 бита).
База сравнивает значение RES с ожидаемым(вычисленным на базе) значением и, в случае совпадения
этих значений, устанавливает соединение.
***********
Вопросы
1. целесообразно комплекс перехвата сделать в виде 10 баз (по кол-ву если не ошибаюсь частотных каналов в диапазоне 1880-1900). Каждую базу настроить на фиксированную частоту. Оцените трудность ПРОБЛЕМЫ1.
2. трубке при лежании на базе передается инфа о частоте, на кот след производить аутентификацию и 128 бит код UAK
3. далее ответ трубы -f(uak), Бесполезно иметь дело с перехватом на этапе аутентификации.
4. при установлении связи-далее следует некий пакет со служебной инфой-ПРОБЛЕМА2-можем ли мы его распознать?
5. при установлении связи нет ухода сеанса на другую частоту , нежели была частота при аутентификации? ПРОБЛЕМА3 так как весь перехват должен происходить на одной из баз мониторингового набора , иначе будет сложно
6. Решение-однозначно игнорировать процедуру аутентификации. в каждой базе базе можно ли "закоротить" блок отвечающий за аутентификацию и сразу перехватывать служ инфу и декодировать на этом основании трафик ПРОБЛЕМА4
7. какова модификация мониторинговых баз для адекватного чтения служебной инфы ПРОБЛЕМА5
8. мониторинговая база может работать только на прием или она должна двусторонне обмениваться с трубой какой-то управляющей инфой ПРОБЛЕМА6

Надо повышать детализацию . ответ лучше сходу не давать:)

9. проблемка в случа недальнобойного декта- побочной актуальности-мы не сможем идентифицировать перехватываемый телефон

целесообразно комплекс перехвата сделать в виде 10 баз

Да чего уж тут мелочиться... Лучше на каждый таймслот по базе!

"Да чего уж тут мелочиться... Лучше на каждый таймслот по базе!"

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

И вообще, можно попросить без подколов, знаете как лучше-предлагайте по существу. я c этой целью свои, возможно неверные , предположения и выдвигаю

3. далее ответ трубы -f(uak), Бесполезно иметь дело с перехватом на этапе аутентификации.

Почему же бесполезно? Можно перехватывать RS!

4. при установлении связи-далее следует некий пакет со служебной инфой-ПРОБЛЕМА2-можем ли мы его распознать?

Конечно можем! Все форматы всех пакетов соответствуют стандарту...

5. при установлении связи нет ухода сеанса на другую частоту , нежели была частота при аутентификации?

Стандарт предусматривает и переходы по частоте и хэндоверы...

ПРОБЛЕМА3 так как весь перехват должен происходить на одной из баз мониторингового набора , иначе будет сложно

Вот это действитель ПРОБЛЕМА... заставить исследуемый тандем сидеть на одной частоте! :))))) Имеет смысл ожидать вызова на одной частоте, а потом "вести" его...

6. Решение-однозначно игнорировать процедуру аутентификации. в каждой базе базе можно ли "закоротить" блок отвечающий за аутентификацию и сразу перехватывать служ инфу и декодировать на этом основании трафик ПРОБЛЕМА4

И в чем же здесь, собственно, проблема ?

7. какова модификация мониторинговых баз для адекватного чтения служебной инфы ПРОБЛЕМА5

Вопрос поставлен некорректно... ("Как бесплатно звонить по межгороду?")...
Все зависит от используемого оборудования...

8. мониторинговая база может работать только на прием или она должна двусторонне обмениваться с трубой какой-то управляющей инфой ПРОБЛЕМА6

Только на прием... Причем, принимать все 24 таймслота на частотном канале...

Вот только идея с базами тупиковая по определению! - дорого и немобильно...
Хотя...
Нужно смотреть сервис-мануалы...

Serg

Кстати, если интересно, могу дать ссылки на рекомендации DECT. Там обо всем написано... и форматы кадров и все процедуры...

Интересно.
Отпишу позже.
ваф-за мной

Serg

Пиши тогда в почту...

Lorenz, подскажи, пожалуйста, откуда информация, что в DECT
может использоваться 16QAM и 64QAM, в протокле я что-то не видел.

Vanya

См. рекомендацию ETSI EN 300 175-3 "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI); Part 3: Medium Access Control (MAC) layer"

Lorenz, м.б. у меня релиз староват (V 1.6.1 2002-01), но я ничего
не нашел. Только GFSK, pi/2 DBPSK, pi/4 DQPSK и pi/8 D8PSK.
Может быть и мне повезет увидеть ссылки на новые рекомендации ? :-)

Vanya

м.б. у меня релиз староват (V 1.6.1 2002-01),

Похоже, что староват... :)
Самый последний релиз - V1.7.1 (2003-07).
Ссылка - http://pda.etsi.org/pda/home.asp?wki_id=IioCUvEyJq opsxxtSdWgt (требуется регистрация) :)

Lorenz, спасибо. Да... Системы развиваются семимильными шагами.
Там, оказывается, и поля новые появились.
Хотя, по жизни кроме GFSK я ничего пока в этом стандарте не видел.

Наслушавшись сортирников заинтересовался DECT-ом :)

В общем пока хорошего решения не вижу, даже если шифрование не используется (а кто-нибудь знает точно, используется оно или нет? если да - то можно сразу успокоиться).

Была идея, использовать обычную трубу. Встреченные на этом пути проблемы:

1) Мне не удалось найти подробной информации ни по одной микросхеме DECT контроллера (Смотрел NXP: PCD509x2, National Semiconductor: SC14428, Infineon:PMB7722). Соответственно влезть в код невозможно. Да и контроллеры поставляются чаще всего уже прошитые под трубу или базу (тут могу ошибаться). Соответственно нужно самостоятельно разгребать таймслоты и декодировать ADPCM. А это сложно и скорее всего не мобильно.

2) Моя труба (General Electric, он же Thomson Telecom 21816) состоит из трех микросхем: DECT Power Amplifier, DECT Transceiver - PMB7610 (Infineon) и неизветного бескорпусного чипа DECT контроллера (залит какой-то черно фигней). Найти информацию на PMB7610 я тоже не смог. Соответсвенно, нужно либо искать документацию на PMB7610, либо трубу с трансивером NXP:UAA3545 (что видимо будет проблематично, т.к. этот чип вроде снят с производства, но зато есть документация). Ну или делать свой приемник на 1.9ГГц с демодулятором GFSK.

3) Скорее всего, мощность передатчика обычной базы DECT заметно меньше мощности передатчика базы сортирника. Соответственно ловить сигнал на удачу будет проблематично.

Это были мысли в слух. Скорее всего я не буду копать дальше DECT (сложно, да и зачем?). Но от какой-либо информации по теме не откажусь.

Да. Вот еще вопрос. Две домашние базы DECT стоящие рядом будут всегда работать на разных частотах. Чтобы заставить их работать на одной частоте - нужна внешняя синхронизация. А значит в пределах радиовидимости может нормально работать не более 10 баз. Правильно ли я понимаю? Если все так, то если вдруг все мои соседи поставят себе по 3 базы (что вполне возможно - будут покупать трубы, ну за одно и базы, чтобы их заряжать), то мне свободной частоты не останется :(

У меня трубка подключается к базе бесконтактно - на трубе соотв. меню где надо набрать код базы (по умолчанию 0000), на базе держать int пока светодиод не замигает, так-что утечка кодов в эфир происходит. Кстати база и трубка разных фирм.
По поводу загадить все частоты - баз надо больше 10и т.к. на одной частоте могут работать несколько телефонов в разные моменты времени.

Телефоны-то с базами синхронизируются, а вопрос в том, как базы синхронизируются (?) между собой. База-то постоянно излучает (в смысле человеческих времен).

Телефоны-то с базами синхронизируются, а вопрос в том, как базы синхронизируются (?) между собой. База-то постоянно излучает (в смысле человеческих времен).
По памяти 2х летней давности: базы между собой никак не синхронизируются. DECT на то он и DECT, что когда его рассчитывали исходили из того что на площади 1 (то ли 5) кв.км. могут одновременно вестисть до 10000 переговоров друг другу не мешая. При этом есть жесткое требование к времени занятию частоты, не более стольки-то миллисекунд. Потом переход на другую. Весь прикол - получение алгоритма генерации этой последовательности частот.

Телефоны-то с базами синхронизируются, а вопрос в том, как базы синхронизируются (?) между собой. База-то постоянно излучает (в смысле человеческих времен).
Думаю, что синхронизируются, иначе зачем тайм-слоты делать.

Вопрос возник после чтения стандарта DECT (читал, по правде сказать по диагонали, может чего и не заметил).

База всегда занимает 1 таймслот на 1 частоте (чтобы телефон ее видел). Теоретически, 2 базы могут работать на 1 частоте, заняв разные таймслоты (частот всего 10, таймслотов 12). Но! При этом какая-то база должна подстраиваться под другую! Алгоритма выбора главной базы я не нашел! Подстраиваться друг под друга думаю не получитья (таймслоты "поплывут"). Да и в стандарте прописана возможность синхронизации через спец. интерфейс или через GPS.

Ясно, что при развертывании более или менее большой сети DECT, с использованием профессионального оборудования, несколько баз будет работать на одной частоте, но возможен ли такой трюк с бытовым оборудованием?

На счет 10000 одновременных переговоров на площади 1 кв. км. - по моему не может быть такого. Всего каналов 10*12=120. Покрытие одной базы - радиус 300м. Ну и как раскидать базы?

На счет 10000 одновременных переговоров на площади 1 кв. км. - по моему не может быть такого.
Вот тут пишут еще круче: http://einstein.informatik.uni-oldenburg.de/rechnernetze/seite24.htm .
10000 эрлангов на кв.км на этаж. Т.е. если у телефона 20% загрузка и если средняя этажность района 10, то вообще получается 500'000 "телефонных линий" на кв.км.

Дааа. Домножили на этажность вы лихо. Только вот правильным это будет лишь в случае радионепрозрачных межэтажных перегородок.

Да и в 10000 я не верю. Там посчитано исходя из расстояния между базами 25 метров и еще из непонятно каких соображений.

В общем, пока, для бытового оборудования, правило не более 9 баз в радиусе 100м от каждой мне кажется оправданным.

Эта тема не раз подымалась – смотрите в сети. (Страна разработчик – Индия)
Видел PCMCI плату и ПО делающую такую работу.
Основная выполняемая задача – мониторинг DECT оборудования.
В базовый набор ПО входят модули позволяющие:
Внедрять между базой и трубкой ложный репитер.
Проводить стресс тестирование оборудования. К примеру загрузка выбранных каналов (и наверное и тайм слотов) ложными соединениями.
И что самое интересное – проводить удаленное администрирование базовой станции.
Так что получается, что и DECT можно «иметь».
Только дорого это все…
Существует оборудование такого типа и для других систем связи.
«Маркони» – например.

Видел PCMCI плату и ПО делающую такую работу.


А интересно,получится ли, если поступить так:

Открываем свою базу своей трубкой (типа, разговор идёт по каналу), затем в своей трубке вывод RSSI вч блока принудительно удерживая в высоком уровне(чтоб трубка думала, что сигнал в канале по-прежнему есть), выдёргиваем питание у базы. Предполагаю, что в этом случае трубка будет продолжать работать в режиме "разговора" и если на этом канале и этом слоте какая-нибудь база заработает, то будет слышна в т рубке.Можно даже для верности придавить к земле управляющие линии data и clk синтезатора, чтоб не соскочил с канала.И "хирургическим путём" отключить передачу, чтоб этот канал могли занимать другие базы/трубк,которых собираемся мониторить.

Есть только вот какие сомнения. Вроде бы, во время разговора трубка успевает гулять по соседним каналам для проверки их состояния, и если проц почувствует что-то "нештатное", не прекратит ли он декодировать нужный канал.

Что скажете? какие будут предположения?

Сертифицированные бытовые телефоны DECT готовы для скрытного прослушивания.

У меня например в домашней базе SIEMENS, в списке прописанных трубок, находится несуществующая трубка, которую невозможно удалить. Все трубки можно удалить, а эту невозможно, прописана в базе намертво.

Triazalon Ну и что? Уже прослушали кого? Это как понимать Сертифицированные бытовые телефоны DECT готовы для скрытного прослушивания.? Как паранойю? :)

Вроде бы, во время разговора трубка успевает гулять по соседним каналам для проверки их состояния, и если проц почувствует что-то "нештатное", не прекратит ли он декодировать нужный канал.

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

Это как понимать

Это условия получения сертификата - доступность для прослушивания спецслужбами. В противном случае телефон не получит сертификата соответствия.

Triazalon ну и что? Америку открыли? Это нормальный ход педалей, в любой стране. :) Ещё спцслужбы имеют наглость за ваим проследить, если им очень нужно будет. :) Проблема-то в чём? Уже прослушали кого? Или так?