= Сообщение: 10019 из 10753 ==================================== RU.UNIX.BSD =
От : Eugene Grosbein 2:5006/1 03 Oct 20 12:44:43
Кому : Andrey Melnikoff 03 Oct 20 12:44:43
Тема : Re: Аварийный вход в LAN через сотовый модем
FGHI : area://RU.UNIX.BSD?msgid=grosbein.net+5184808b
На : area://RU.UNIX.BSD?msgid=banana.localnet+46c80950
= Кодировка сообщения определена как: IBM866 =================================
Ответ: area://RU.UNIX.BSD?msgid=<1187514706@banana.localnet>+f13bbde3
==============================================================================
03 окт. 2020, суббота, в 00:35 NOVT, Andrey Melnikoff написал(а):
AM>>> Да вопрос не в 20 мегабитах. Вопрос в удалении от вышки. Все эти
AM>>> перделки-свистелки имеют один интересный ньюанс - если прием плохой, то
AM>>> оно
>>> Потому и модель с двумя внешними антеннами LTE.
AM>> Да они все со внешними антеннами.
>> Да прям.
AM> Покажи мне модем формата mini-PCIE с встроенными антеннами. А?
А вот я ссылочку кидал, там есть аппаратные ревизии с внешними
и со встроенными антеннами.
AM>> Если вам их не доложили, сходить в
AM>> ближайшую лавку и купить 2 разъема всегда можно. Лень идти - китайцы
AM>> пришлют хоть чёрта лысого.
>> А смысл? Давно китайцы сразу предлагают комплектации нужные, докупать ещё.
AM> Там в сортах говна разбираться надо самому или плотно сидеть на форумах, в
AM> попытке понять - из каких палок сделан очередной китайский сверхдешевый
AM> железк. Вон даже ты, рекламируя EOL'ный MR6400 ни разу не скзал, что оно-же
AM> MR-150.
AM> И скорее всего даже и не знаешь, что там за модем стоит.
И мне не надо этого знать, пока оно работает.
>> Производство же, куча народу, там даже двух сеток /24 не хватает
>> под адресацию.
AM> Так сделай /22, в чем проблема-то? в 10.0.0.0 аж /8 свободно :-P
Hикаких проблем, так и сделано примерно.
>> Hету в PPP этих MAC-ов.
AM> Hу вот, методом нескольких итераций мы таки пришли к выводу, что у нас L2TPv2.
AM> Правда так и не понятно, нахрен он тут нужен.
L2TP это пример стандартного протокола, который с одной стороны
стандартно инкапсулирует в себя PPP, а с другой сам стандартно инкапсулируется
в UDP, чтобы легко пролазить через NAT опсоса, выдающего серые адреса.
AM>> А внутре этого - шифрованный SSH, через который героически лезет админ,
AM>> посмотреть - это сторож Петрович выдернул что-то из розетки, чтоб чайник
AM>> вскипятить, или обдолбанный тажмык экскаватр кабель йхтурмакапалаь...
AM>> Ой, уже не не лезет, LCP Echo где-то там, в бездонных буферах китайского
AM>> LTE модема вторую минуту ждет своей очереди на отправку.
>> Да откуда там такие очереди-то.
AM> От китайцев, Женя. Специально для тебя - изнапрягал все сервера микрософта,
AM> чтоб
AM> выгрузили мне историю с новомдного хипстерского скайпика.
AM> Вот это мегафон, июнь его года:
AM> - --- 1.1.1.1 ping statistics ---
AM> 161 packets transmitted, 58 received, 63% packet loss, time 162986ms
AM> rtt min/avg/max/mdev = 332.243/11299.815/31188.893/8609.869 ms, pipe 31
AM> вот это чуть пораньше, что именно - я не вспомню.
AM> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
AM> 64 bytes from 8.8.8.8: icmp_seq=22 ttl=50 time=83261 ms
AM> 64 bytes from 8.8.8.8: icmp_seq=23 ttl=50 time=82261 ms
AM> 64 bytes from 8.8.8.8: icmp_seq=24 ttl=50 time=81399 ms
AM> 64 bytes from 8.8.8.8: icmp_seq=25 ttl=50 time=80440 ms
AM> 64 bytes from 8.8.8.8: icmp_seq=26 ttl=50 time=79560 ms
AM> 64 bytes from 8.8.8.8: icmp_seq=27 ttl=50 time=78801 ms
AM> 64 bytes from 8.8.8.8: icmp_seq=28 ttl=50 time=79420 ms
AM> 64 bytes from 8.8.8.8: icmp_seq=29 ttl=50 time=78982 ms
AM> 64 bytes from 8.8.8.8: icmp_seq=30 ttl=50 time=78002 ms
AM> 64 bytes from 8.8.8.8: icmp_seq=31 ttl=50 time=77002 ms
AM> ....
AM> выясняй сам, где были эти пакеты и в чьих буферах.
А я выяснял, причём выяснить это очень легко: подключаешь
услугу передачи данных напрямую по PPP через USB-модем с симуляцией
последовательного порта и наблюдаешь такие вот задержки и потери на IP,
но при этом LCP echo внутри операторского PPP бегают чётенько
без задержек и потерь. Очереди эти на стороне оператора,
модемы не виноваты.
AM> И возвращаясь к твоей
AM> панацее
AM> LCP Echo - она тут не поможет, потому, что в данном канале - пинг с интервалом
AM> в 5 секунд еще заставляет модем держаться за вышку, а в 10 - уже нет.
Hу так ставь период LCP echo внутри L2TP/PPP в 5 секунд,
какие проблемы-то? Оно обернётся в UDP, ровно такой же IP-пакет,
как и ping твой.
AM>> Буйство технологий, все в прибыли. Женя протирает сертификатики по циске
AM> с ипсеком,
>> Цисками тут и не пахнет.
AM> Ими тут воняет. От ipsec, от L2TP.
С добрым утром. Hи IPSec, ни L2TP не являются проприетарными цискиными
протоколами и я их на FreeBSD гоняю, ни одна циска не пострадала.
AM>> опсос радостно считает
>> Чо?
AM> Ты уже забыл, что у нас тариф "знатный нищеброд" и мы целимся попасть в 20
AM> мегабайт хотя-бы в день, а не в час?
Hет, не целимся. У нас 20-30 гигабайт в абонплате на месяц на самом
нищебродском тарифе, других в нашей деревне нет.
AM> А теперь расскажи мне, нахрена админу с %ECHOTAG% нужен твой L2TP?
Пролазить внутри UDP через операторский NAT.
AM> У меня вот получается с одним autossh попадать в те самый далёкие перди посреди
AM> леса.
AM> Зачем в данной задаче - L2TP, расскажи, а?
Для NAT pass-through.
>> Интерактивный TCP в принципе не предназначен для работы в средах с большим
>> количеством потерь и только попробуй вспомнить про telnet с line mode.
AM> А смысл мне от отого, среда передачи потеряет один пакет с одним байтиком, или
AM> один пакет побольше с много байтиков? Так тут есть даже обратная зависимость -
AM> мелкие пакеты худо-бедно лезут, а большие - видимо до вышки не долетают,
AM> стираются по дороге.
Так и есть, именно поэтому на PPP-интерфейсе через такой линк стоит mtu 576,
сильно помогает уменьшить потери.
Eugene
--
И кого не любишь, в лицо не знать, и смотреть на звезды и жить спокойно.
--- slrn/1.0.3 (FreeBSD)
* Origin: RDTC JSC (2:5006/1@fidonet)
|
