необходим дроп пакетов при пропадании канала

[buryanov 5]

Всем привет

 

Имеется бук и arduino устройство, которым управляет бук по udp через ethernet броадкастом (скажем 192.168.0.255/24). Эксплуатация временная, как правило на 1-2 дня всё это нужно. Монтируется зачастую воздушкой вдоль силовых линий(380). Иногда происходят обрывы линий или перегорания(выгорел от попадания источника огня кусок провода), стала применятся другая схема: добавляется 2 маршрутизатора(mikrotik) и кидается или вторая линия или по wifi.

 

Теперь проблема:

Бук посылает команды с привязкой ко времени, как правило 40-50pps(значение колеблется 1-100pps), последовательность пакетов КРИТИЧНА и время прихода.

Роутеры пробовал настраивать по 2-м вариантам (1 порт на бук, 2-3 связь между роутерами): либо всё в бридж и по stp рубится петля, либо по ospf "мониторинг" каналов. НО!!! при этих настройках есть проблема: при попадании канала 1 между роутерами, пакеты которые должны били уйти, зависают в буфере гдето, во вторй канал идут уже другие пакеты, но те которые зависли в буфере, потом доходят, что не есть хорошо(проверялось дампом трафика). Мне нужно, чтобы сохранялась последовательность пакетов, а пакеты, которые не доставились сразу, дропались, мне лучше чтоб пакет не пришел вообще, чем пришел не в свою очередь. В программе управления нет контроля доставки пакетов. Принимающее устройство получает команды и сразу их выполняет.

[adeep 212]

Протокол UDP не имеет механизмов контроля очередности и доставки. Вам надо или сменить протокол или реализовать поверх UDP свой контроль порядка команд, что делается незначительной корректировкой кода софта.

[greyshadow 22]

Всем привет

 

Имеется бук и arduino устройство, которым управляет бук по udp через ethernet броадкастом (скажем 192.168.0.255/24). Эксплуатация временная, как правило на 1-2 дня всё это нужно. Монтируется зачастую воздушкой вдоль силовых линий(380). Иногда происходят обрывы линий или перегорания(выгорел от попадания источника огня кусок провода), стала применятся другая схема: добавляется 2 маршрутизатора(mikrotik) и кидается или вторая линия или по wifi.

 

Теперь проблема:

Бук посылает команды с привязкой ко времени, как правило 40-50pps(значение колеблется 1-100pps), последовательность пакетов КРИТИЧНА и время прихода.

Роутеры пробовал настраивать по 2-м вариантам (1 порт на бук, 2-3 связь между роутерами): либо всё в бридж и по stp рубится петля, либо по ospf "мониторинг" каналов. НО!!! при этих настройках есть проблема: при попадании канала 1 между роутерами, пакеты которые должны били уйти, зависают в буфере гдето, во вторй канал идут уже другие пакеты, но те которые зависли в буфере, потом доходят, что не есть хорошо(проверялось дампом трафика). Мне нужно, чтобы сохранялась последовательность пакетов, а пакеты, которые не доставились сразу, дропались, мне лучше чтоб пакет не пришел вообще, чем пришел не в свою очередь. В программе управления нет контроля доставки пакетов. Принимающее устройство получает команды и сразу их выполняет.

В рамках ip НЕ РЕАЛИЗУЕМО впринципе.

[adeep 212]

 

В рамках ip НЕ РЕАЛИЗУЕМО впринципе.

 

Зачем так категорично?

В рамках UDP да, не реализуемо без расширение протокола на высшем уровне.

В рамках tcp/ip  все реализуемо.

Відредаговано 2013-07-03 12:45:38 adeep

[buryanov 5]

Софт закрытый, протокол управления открыт и реализован только поверх udp. На arduino используется opensource. Количество слушающих устройств может быть неограниченным, поэтому идёт всё бродкастом, внутри пакета есть привязка к адресу, который никак не связан с Ethernet адресом

[adeep 212]

Софт закрытый, протокол управления открыт и реализован только поверх udp. На arduino используется opensource. Количество слушающих устройств может быть неограниченным, поэтому идёт всё бродкастом, внутри пакета есть привязка к адресу, который никак не связан с Ethernet адресом

Вариант перед железкой поставить минироутер. на него поднять tcp-туннель (например с помощью openvpn), а с него уже на железку.

[buryanov 5]

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

 

Пришел пакет с командами на устройство:

1 - двигатель 5 поставить в положение 127 скажем,

3 - двигатель 5 поставить в положение 120

4 - двигатель 5 поставить в положение 115

а потом приходит 2 -  двигатель 5 поставить в положение 125,

5 - двигатель 5 поставить в положение 110

сейчас получается так

[adeep 212]

Главная мысль: вам надо сделать выстраивание пакетов в цепочку. Если вариант с tcp туннелем не подходит, можно нарисовать свою обертку поверх udp. Например на выходе с ноута добавлять к каждому пакету порядковый номер и отсылать на последнюю железку перед назначением. На ней смотреть на порядковые номера и отбрасывать лишние пакеты.

Теоретически задача на пару часов написания и отладки кода.

[greyshadow 22]

 

 

В рамках ip НЕ РЕАЛИЗУЕМО впринципе.

 

Зачем так категорично?

В рамках UDP да, не реализуемо без расширение протокола на высшем уровне.

В рамках tcp/ip  все реализуемо.

 

При чем тут tcp/ip?? маршрутизаторы о tcp вообще говоря не вкурсе, они именно ip пакеты обрабатывают и буферизируют, и в рамках IP НЕ РЕАЛИЗУЕМО! если не верите - обратитесь к теории, каждый IP пакет - он сам по себе и очередности никакой внутри именно IP заголовка не предусмотрено.

[Гайджин 574]

Если линии связи проводной эзернет, то не проще ресайлент линк меду двумя свичами? -т.е. то что у Вас не получается на уровне л3 с высокой степенью вероятности получится на уровне л2.

[madf 279]

 

 

В рамках ip НЕ РЕАЛИЗУЕМО впринципе.

Зачем так категорично?

В рамках UDP да, не реализуемо без расширение протокола на высшем уровне.

В рамках tcp/ip  все реализуемо.

 

При чем тут tcp/ip?? маршрутизаторы о tcp вообще говоря не вкурсе, они именно ip пакеты обрабатывают и буферизируют, и в рамках IP НЕ РЕАЛИЗУЕМО! если не верите - обратитесь к теории, каждый IP пакет - он сам по себе и очередности никакой внутри именно IP заголовка не предусмотрено.

 

Это реализуемо конечным оборудованием или ПО с использованием протоколов более высокого уровня. Маршрутизаторы тут вообще не при чем. Иначе интернет не работал бы. Совсем. А то фрагментация, ведь...

[greyshadow 22]

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

 

Пришел пакет с командами на устройство:

1 - двигатель 5 поставить в положение 127 скажем,

3 - двигатель 5 поставить в положение 120

4 - двигатель 5 поставить в положение 115

а потом приходит 2 -  двигатель 5 поставить в положение 125,

5 - двигатель 5 поставить в положение 110

сейчас получается так

Как можно дропнуть то, что не доставилось??

Для маршрутизатора логика невыполнима - он получается должен UDP до 7-ого уровня развернуть и помнить историю по всем таким пакетам, причем как маршрутеру учитывать вариант прохождения пакета 1 одним путем, а пакета 2 другим???

Это даже теоретически реализуемо только на железке, от которой единственный путь к вашему контроллеру, соответственно каждую железяку(исполнителя команд) надо включить в другую железяку, которая будет разворачивать UDP, вытаскивать ID команды, и если ID меньше чем полученый ранее - дропать... теоретически конечно выполнимо если трафик не шифрованый.

[madf 279]

 

 

 

В рамках ip НЕ РЕАЛИЗУЕМО впринципе.

Зачем так категорично?

В рамках UDP да, не реализуемо без расширение протокола на высшем уровне.

В рамках tcp/ip  все реализуемо.

 

При чем тут tcp/ip?? маршрутизаторы о tcp вообще говоря не вкурсе, они именно ip пакеты обрабатывают и буферизируют, и в рамках IP НЕ РЕАЛИЗУЕМО! если не верите - обратитесь к теории, каждый IP пакет - он сам по себе и очередности никакой внутри именно IP заголовка не предусмотрено.

 

Это реализуемо конечным оборудованием или ПО с использованием протоколов более высокого уровня. Маршрутизаторы тут вообще не при чем. Иначе интернет не работал бы. Совсем. А то фрагментация, ведь...

 

А, пардон. Как-то не учел что речь идет об IP. Да, согласен, на этом уровне не реализуемо. Но вон там выше подсказывали решение с VPN.

[buryanov 5]

Всем привет

Большая часть обсуждения сводится к тому, как доставить пакеты, а мне наоборот не надо их доставлять. У меня есть жесткая привязка пакетов к timeline. у меня есть закрытый софт, который по udp/ip отправляет бродкаст. если у меня стоит бук к которому по витой паре подключён девайс. Всё работает, когда я отключаю кабель и потом спустя какое то время его включаю, то пакеты которые были отправлены в этот момент никуда не доходят. Это мне и нужно. НО!!! Если кабель рвётся, повреждается, перегорает, буда с мухамедом что через левое плечо на него посмотрели, во время мероприятия, то восстановление его работоспособности - скорее невероятно в течении нескольких часов, не говоря уже о 5 - 10 секундах. Для этого и была взята схема с кабелем + wifi в резерв. Для её построения используются микротики в качестве маршрутизаторов. Если на микротике активный канал отключить, то часть трафика, не потеряется, а потом вдогонку прибежит. вот в чём проблема.

[adeep 212]

Всем привет

Большая часть обсуждения сводится к тому, как доставить пакеты, а мне наоборот не надо их доставлять. У меня есть жесткая привязка пакетов к timeline. у меня есть закрытый софт, который по udp/ip отправляет бродкаст. если у меня стоит бук к которому по витой паре подключён девайс. Всё работает, когда я отключаю кабель и потом спустя какое то время его включаю, то пакеты которые были отправлены в этот момент никуда не доходят. Это мне и нужно. НО!!! Если кабель рвётся, повреждается, перегорает, буда с мухамедом что через левое плечо на него посмотрели, во время мероприятия, то восстановление его работоспособности - скорее невероятно в течении нескольких часов, не говоря уже о 5 - 10 секундах. Для этого и была взята схема с кабелем + wifi в резерв. Для её построения используются микротики в качестве маршрутизаторов. Если на микротике активный канал отключить, то часть трафика, не потеряется, а потом вдогонку прибежит. вот в чём проблема.

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

[madf 279]

А лучше обратиться к производителям железки или ПО к ней чтобы они пофиксили проблему.

[greyshadow 22]

Судя по описанию - управление производственным процессом, судя по доп. замечаниям - территория тоже довольно обширная.

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

 

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

 

Короче прав madf - долбать производителя.

А если вы такую атаку продемонстрируете заказчику да еще и в полевых условиях - так он сам его (производителя) задолбет до потери сознания....

[buryanov 5]

Протокол ArtNet, описание по ссылке, применяется в шоубизе. В спецификации протокола нет никаких счётчиков и их добавление поломает обратную совместимость. Устройств работающих по этому протоколу масса, передатчиком может выступать как софт, так и железка, слушать тоже может что угодно. Поэтому производителя долбать не получится.

[madf 279]

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