Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Мистический UDP пакет
|
|||
|---|---|---|---|
|
#18+
Пишу свою пересылалку файлов по UDP. Пересылаю по проводному инету с провайдера А на провайдера Б. Случайно получилось что один пакет стабильно рубится. После изучения и урезания получил магические 16 байт, причем первые 8 без разницы какие, главное что их 8. Код: plaintext 1. 2. 3. 4. 5. Похоже правда что провайдеры действительно балуются фильтрацией UDP. В данном случае проверяется значение вторых 8-ми байт. Изменяешь любой из них и все доходит. В принципе неважно кто рубит (А, Б или В которых их соединяет), неважно зачем (борьба с вирусами или софтом), важно что рубят и как с этим бороться. Как подозреваю фильтры примитивные типа в таком-то месте такая-то последовательность байт, т.к. скорости передачи гигантские и на серьезные проверки ресурсов просто не хватит. Пока созрел только один план: не слать повторно тоже самое. Берем 4 маски, при отправке XOR с одной из них (случайно выбранной), с указанием номера маски в первом байте, т.е. занимаем 2 бита в первом байте и имеем 4 варианта абсолютно разного представления одного и того же пакета. Причем пакет изначально не содержит пустот в виде кучи нулей (данные будут пожаты архиватором). Поможет? PS Если кто подозревает что у меня с руками проблема, для тех полный вариант тестаЕсть ПК1 для него шлюз роутер к провайдеру А, есть ПК2 для него шлюз роутер к провайдеру Б. ПК2 слушает свой порт 45678. На роутере Б проброшен порт 45678 на ПК2. На ПК1 открывается случайный порт и отправляется пакет на внешний IP Б порт 45678. Другие пакеты проходят, этот - нет. ПК1 и ПК2 в локалке, по локалке этот пакет доходит на IP ПК2:45678. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2014, 14:04 |
|
||
|
Мистический UDP пакет
|
|||
|---|---|---|---|
|
#18+
Сделал по своему плану, теперь одно и тоже сообщение в 4-х видах, в данном случае естественно помогло. Т.к. UDP то изначальная установка на потери и повторы, только повторы будут разные. Прикинул изначальную вероятность такого попадания (1 / 2^64) * количество 8-байтовых фильтров, величина очень близкая к нулю, но я попал и хорошо что попал во время отладочных тестов. Подзабыл теорию вероятностей, не знаю как прикинуть на сколько увеличилась вероятность прохождения пакета через фильтры если я могу послать его в четырех разных видах? В четыре раза или в четвертой степени? И просто интересно что означает {00, 00, 00, 00, 00, 0x38, 00, 00}, это код на асме или просто статичный кусок заголовка? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2014, 18:51 |
|
||
|
Мистический UDP пакет
|
|||
|---|---|---|---|
|
#18+
Dima T, Попробуйте сниффером выяснить: а) покидают ли физически пакеты хост-источник б) доходят ли физически пакеты до хоста-получателя В качестве версии с потолка - это может быть даже багом оборудования, читал про подобное - тынц ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2014, 19:00 |
|
||
|
Мистический UDP пакет
|
|||
|---|---|---|---|
|
#18+
miksoftDima T, Попробуйте сниффером выяснить: а) покидают ли физически пакеты хост-источник б) доходят ли физически пакеты до хоста-получателя В качестве версии с потолка - это может быть даже багом оборудования, читал про подобное - тынц Не, провайдер однозначно. Выше писал подробное описание тестаЕсть ПК1 для него шлюз роутер к провайдеру А, есть ПК2 для него шлюз роутер к провайдеру Б. ПК2 слушает свой порт 45678. На роутере Б проброшен порт 45678 на ПК2. На ПК1 открывается случайный порт и отправляется пакет на внешний IP Б порт 45678. Другие пакеты проходят, этот - нет. ПК1 и ПК2 в локалке, по локалке этот пакет доходит на IP ПК2:45678. Еще подробнее (IP условные) ПК1 192.168.0.10 шлюз 192.168.0.1 ПК2 192.168.0.20 шлюз 192.168.0.2 роутер А внутренний 192.168.0.1 внешний 87.226.122.53 роутер Б внутренний 192.168.0.2 внешний 217.11.80.157 на роутере Б правило с порта 217.11.80.157:45678 перенаправлять на 192.168.0.20:45678 с ПК1 запускаю отправку на 217.11.80.157:45678 - этот пакет не доходит (другие доходят) с ПК1 запускаю отправку на 192.168.0.20:45678 - этот пакет доходит Все тесты на одних и тех же EXE. Не вижу бага оборудования или бага в своем коде (тем долее после добавки шифрования он заработал при тех же условиях). Кроме того изначально обнаружил когда тестил с третьего провайдера (GPRS через телефон) на 87.226.122.53:45678. Терял стабильно один и тот же пакет на ответе. В итоге эти 16 байт выковыряны из того пакета. PS провайдер А реально параноики неадекватные (были прецеденты), могли и фильтрацию запустить. Они у меня как резервный канал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2014, 19:36 |
|
||
|
Мистический UDP пакет
|
|||
|---|---|---|---|
|
#18+
Dima TНе вижу бага оборудованияА он может быть и не у вас, а у какого-либо провайдера в цепочке. Если интерес еще остался, то можно попробовать отправлять этот магический пакет с разными TTL и посмотреть до какого промежуточного хоста он доходит, а до какого уже нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2014, 20:44 |
|
||
|
Мистический UDP пакет
|
|||
|---|---|---|---|
|
#18+
miksoftDima TНе вижу бага оборудованияА он может быть и не у вас, а у какого-либо провайдера в цепочке. Баг оборудования или фильтр на провайдере - это не важно, важно что это есть. По большому счету важна природа глюка, а она такова что не вписывается в концепцию "доставка UDP пакета не гарантируется", тут получилось что "доставка конкретного UDP пакета невозможна" хоть сколько раз его повторяй. Вероятность повторения такого глюка сложно предсказывать, сглючило на пересылке одного конкретного файла (слал .pdb который компилятором создается), но файлов по инету я немного погонял 10-20, а на запрет нарвался. Может случайно "повезло", а может много таких "багов". miksoftЕсли интерес еще остался, то можно попробовать отправлять этот магический пакет с разными TTL и посмотреть до какого промежуточного хоста он доходит, а до какого уже нет. Смысла нет искать конкретное место. В итоге работать будет там, где у меня не будет ни времени, ни возможности детально разбираться. В идеале должно само работать без вмешательств даже при наличии подобных явлений. Не хотел делать лишнего шифрования того что не надо, но приходится. Если кому интересно вот мой шифратор/дешифратор Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2014, 10:35 |
|
||
|
Мистический UDP пакет
|
|||
|---|---|---|---|
|
#18+
Dima TmiksoftЕсли интерес еще остался, то можно попробовать отправлять этот магический пакет с разными TTL и посмотреть до какого промежуточного хоста он доходит, а до какого уже нет. Смысла нет искать конкретное место. это, тем не менее, интересно ибо может всплыть в самых неожиданных ситуациях. не проходит в пакете с определённым смещением или в любом месте? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2014, 14:41 |
|
||
|
Мистический UDP пакет
|
|||
|---|---|---|---|
|
#18+
Изопропилэто, тем не менее, интересно ибо может всплыть в самых неожиданных ситуациях. Гиморно это. Согласен что интересно, но как-то надо разумно ограничивать свои творческие изыскания, а то я вместо написания собственного простенького протокола передачи файла стану спецом по низкоуровневому устройству интернета )) Изопропилне проходит в пакете с определённым смещением или в любом месте? Мой вывод: сглючевает по значению вторых 8ми байт Код: plaintext 1. первые 8 другие были, менял по одному на ! потом из far скопировал, кстати 0x забыл дописать. Но если из восьми первых один убрать - проходит. (добавить в первые не пробовал). После тоже было много, убирал с конца пока проходить не начал, в итоге остались эти 16 байт. При изменении одного из вторых 8-ми - начинает проходить (правда не все менял, выборочно по одному 2-3 раза). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2014, 15:05 |
|
||
|
Мистический UDP пакет
|
|||
|---|---|---|---|
|
#18+
Dima T Код: plaintext 1. если не по смещению 8 - проходит или нет ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2014, 23:46 |
|
||
|
Мистический UDP пакет
|
|||
|---|---|---|---|
|
#18+
Это пров режет протокол торрента µTP (запросы на коннект пиру имеют такую сигнатуру). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 02:43 |
|
||
|
Мистический UDP пакет
|
|||
|---|---|---|---|
|
#18+
ИзопропилDima T Код: plaintext 1. если не по смещению 8 - проходит или нет ? Код отправки Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. лог отправкиsend 16 {21,21,21,21,21,21,21,21,00,00,00,00,00,38,00,00,} send 16 {21,21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,} send 16 {21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,} send 16 {21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,} send 16 {21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,} send 16 {21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,21,} send 16 {21,21,00,00,00,00,00,38,00,00,21,21,21,21,21,21,} send 16 {21,00,00,00,00,00,38,00,00,21,21,21,21,21,21,21,} send 16 {00,00,00,00,00,38,00,00,21,21,21,21,21,21,21,21,} прием через инетrecv 16 {21,21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,} recv 16 {21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,} recv 16 {21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,} recv 16 {21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,} recv 16 {21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,21,} recv 16 {21,21,00,00,00,00,00,38,00,00,21,21,21,21,21,21,} recv 16 {21,00,00,00,00,00,38,00,00,21,21,21,21,21,21,21,} recv 16 {00,00,00,00,00,38,00,00,21,21,21,21,21,21,21,21,} прием по локалке recv 16 {21,21,21,21,21,21,21,21,00,00,00,00,00,38,00,00,} recv 16 {21,21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,} recv 16 {21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,} recv 16 {21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,} recv 16 {21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,} recv 16 {21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,21,} recv 16 {21,21,00,00,00,00,00,38,00,00,21,21,21,21,21,21,} recv 16 {21,00,00,00,00,00,38,00,00,21,21,21,21,21,21,21,} recv 16 {00,00,00,00,00,38,00,00,21,21,21,21,21,21,21,21,} Если интересно - напиши интересующие варианты - затестю, отпишусь. Anatoly MoskovskyЭто пров режет протокол торрента µTP (запросы на коннект пиру имеют такую сигнатуру). Интересная версия, вполне правдоподобная, даже не по причине борьбы за лицензионность контента, а просто защита от перегруза каналов где домашним пользователям обещаны десятки мегабит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 07:16 |
|
||
|
Мистический UDP пакет
|
|||
|---|---|---|---|
|
#18+
тест пакетами по 18 отправкаsend 18 {21,21,21,21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,} send 18 {21,21,21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,} send 18 {21,21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,} send 18 {21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,} send 18 {21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,21,} send 18 {21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,21,21,} прием с инетаrecv 18 {21,21,21,21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,} recv 18 {21,21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,} recv 18 {21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,} recv 18 {21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,21,} recv 18 {21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,21,21,} по локалке все доходит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 07:33 |
|
||
|
Мистический UDP пакет
|
|||
|---|---|---|---|
|
#18+
Dima TAnatoly MoskovskyЭто пров режет протокол торрента µTP (запросы на коннект к пиру имеют такую сигнатуру). Интересная версия, вполне правдоподобная, даже не по причине борьбы за лицензионность контента, а просто защита от перегруза каналов где домашним пользователям обещаны десятки мегабит. Что значит правдоподобная. Так оно и есть на самом деле :) Некоторые провадеры с дешевым конечным оборудованием включают фильтрацию µTP для защиты раутеров от перегрузки мелкими пакетами, которые любит µTP. Потому что одно дело 100Мбпс при пакете 1500 и другое дело при пакете 60 байтов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 10:16 |
|
||
|
|

start [/forum/topic.php?fid=57&msg=38602685&tid=2019572]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
37ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 295ms |
| total: | 423ms |

| 0 / 0 |
