Dale
-
Posts
104 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by Dale
-
-
Заметил, в #tools.settings, что когда отключаешь USB устройство из черного разъема USB 2.0, становится активным пункт выбора режима работы синего порта USB 3.0 вот тут:
Версия прошивки 2.09.A.6.0-0. У кого-нибудь еще было такое?
-
Только сейчас заметил то, на что, похоже, никто не обратил внимание в теме Периодически отваливается L2TP/IPSec соединение - при использовании L2TP/IPSec соединения отваливается только L2TP без пересогласования IPSec. Поэтому скромно спрошу у уважаемых администраторов, программистов и @Le ecureuil персонально
- не появилось ли у Вас новых идей, почему такое может быть? Полный селфтест, как обычно, в следующем сообщении.
Spoiler[I] Apr 12 21:06:20 pppd[8227]: Hangup (SIGHUP) [I] Apr 12 21:06:20 pppd[8227]: Connect time 706.7 minutes. [I] Apr 12 21:06:20 pppd[8227]: Sent 811304760 bytes, received 1213458849 bytes. [I] Apr 12 21:06:20 ipsec: 07[KNL] interface ppp1 deactivated [I] Apr 12 21:06:20 ipsec: 09[KNL] 10.10.1.2 disappeared from ppp1 [I] Apr 12 21:06:20 ndm: Network::InterfaceFlusher: flushed L2TP0 conntrack and route cache. [I] Apr 12 21:06:20 ndm: Dns::Manager: name server 209.222.18.218, domain (default) deleted. [I] Apr 12 21:06:20 ndm: Dns::Manager: name server 209.222.18.222, domain (default) deleted. [I] Apr 12 21:06:20 upnp: shutting down MiniUPnPd [I] Apr 12 21:06:20 ndm: Core::Server: client disconnected. [I] Apr 12 21:06:22 ndm: Core::Server: started Session /var/run/ndm.core.socket. [I] Apr 12 21:06:22 upnp: HTTP listening on port 43220 [I] Apr 12 21:06:22 upnp: Listening for NAT-PMP/PCP traffic on port 5351 [I] Apr 12 21:06:26 pppd[8227]: Connection terminated. [I] Apr 12 21:06:26 pppd[8227]: Modem hangup [I] Apr 12 21:06:26 pppd[8227]: Exit. [I] Apr 12 21:06:26 ndm: kernel: Fast VPN ctrl: release for src 178.162.199.39 [E] Apr 12 21:06:26 ndm: Service: "L2TP0": unexpectedly stopped. [I] Apr 12 21:06:26 ipsec: 10[KNL] interface ppp1 activated [I] Apr 12 21:06:26 ndm: Network::Interface::Base: "L2TP0": interface is up. [I] Apr 12 21:06:29 pppd[19059]: Plugin pppol2tp.so loaded. [I] Apr 12 21:06:29 pppd[19059]: pppd 2.4.4-4 started by root, uid 0 [I] Apr 12 21:06:29 ndm: Network::Interface::L2TP: "L2TP0": added host route to 178.162.199.39 via 93.100.188.1. [I] Apr 12 21:06:29 pppd[19061]: l2tp_control v2.02 [I] Apr 12 21:06:29 pppd[19061]: l2tp: remote host: 178.162.199.39 [I] Apr 12 21:06:29 pppd[19061]: l2tp: bind: 93.100.my.ip [I] Apr 12 21:06:30 ndm: kernel: Fast VPN ctrl: setup for src 178.162.199.39 [I] Apr 12 21:06:30 pppd[19059]: Using interface ppp1 [I] Apr 12 21:06:30 pppd[19059]: Connect: ppp1 <--> l2tp[0] [I] Apr 12 21:06:30 pppd[19059]: CHAP authentication succeeded [I] Apr 12 21:06:30 ipsec: 16[KNL] 10.10.1.2 appeared on ppp1 [I] Apr 12 21:06:30 ipsec: 05[KNL] 10.10.1.2 disappeared from ppp1 [I] Apr 12 21:06:30 ipsec: 07[KNL] 10.10.1.2 appeared on ppp1 [I] Apr 12 21:06:30 pppd[19059]: local IP address 10.10.1.2 [I] Apr 12 21:06:30 pppd[19059]: remote IP address 10.10.1.1 [I] Apr 12 21:06:30 pppd[19059]: primary DNS address 8.8.8.8 [I] Apr 12 21:06:30 pppd[19059]: secondary DNS address 8.8.4.4 [I] Apr 12 21:06:30 ndm: Network::Interface::Base: "L2TP0": interface is up. [I] Apr 12 21:06:30 ndm: Network::Interface::Base: "L2TP0": interface is up. [I] Apr 12 21:06:30 ndm: Network::Interface::PPP: interface "L2TP0" is global, priority 1000. [I] Apr 12 21:06:30 ndm: Network::Interface::PPP: "L2TP0": adding default route via L2TP0. [I] Apr 12 21:06:30 ndm: Network::Interface::PPP: adding nameserver 8.8.8.8. [I] Apr 12 21:06:30 ndm: Dns::Manager: name server 8.8.8.8 added, domain (default). [I] Apr 12 21:06:30 ndm: Network::Interface::PPP: adding nameserver 8.8.4.4. [I] Apr 12 21:06:30 ndm: Dns::Manager: name server 8.8.4.4 added, domain (default). [I] Apr 12 21:06:30 ndm: Network::Interface::IP: "L2TP0": IP address is 10.10.1.2/32. [I] Apr 12 21:06:30 ndm: Dns::Manager: name server 209.222.18.218 added, domain (default). [I] Apr 12 21:06:30 ndm: Dns::Manager: name server 209.222.18.222 added, domain (default). [I] Apr 12 21:06:30 ndm: kernel: IPv4 conntrack wan: flushed 5 entries with address 93.100.my.ip [I] Apr 12 21:06:30 ndm: Network::InterfaceFlusher: flushed GigabitEthernet1 conntrack and route cache. [I] Apr 12 21:06:30 upnp: shutting down MiniUPnPd [I] Apr 12 21:06:30 ndm: Core::Server: client disconnected. [I] Apr 12 21:06:32 ndm: Core::Server: started Session /var/run/ndm.core.socket. [I] Apr 12 21:06:32 upnp: HTTP listening on port 35300 [I] Apr 12 21:06:32 upnp: Listening for NAT-PMP/PCP traffic on port 5351
PS Более того, VPN провайдер, похоже, не считает это событие разрывом соединения, потому что, например, сохраняется port-forwarding, запрошенный в начале соединения.
-
4 minutes ago, r13 said:
Это в клиентском режиме?
В серверном режиме в обзоре на хоботе порядка 50 МБит/c PPTP c MPPE Ультра 2 выдает.
В клиентском. Серверный точно не померить, но видно, что нагрузка больше. Но топикстартер говорил, кажется именно о клиентском соединении? Кстати, вопрос, почему шифрование клиентского PPTP соединения явно ускоряется аппаратно, а серверного - нет, может @Le ecureuil знает что-нибудь по этому поводу?
-
-
3 hours ago, r13 said:
Это без аппаратного ускорения. С ускорителем на топовых кинетиках ipsec более 300 мегабит выдает, а mppe описынные вами 40.
Неправда Ваша, у меня на Ultra II при соединении по PPTP со 128битным шифрованием MPPE выдает порядка 80-90 МБит/c при загрузке процессора около 30%.
-
12 minutes ago, Goblin said:
@Dale, печаль. вот если не надо ипв6, а те модули нужны. чего делать? появляется выбор. или сносить всё или пусть ипв6 висит мертвым грузом.
А я не утверждаю, что все эти модули имеют зависимость, просто они мне первые пришли в голову. Возможно, что на самом деле список гораздо короче, просто я их удалил одним махом, а после этого уже снова стал проверять на возможность удаления IPv6.
-
11 minutes ago, Mamay said:
Сам не пробовал. А если так в cli
no ipv6 address auto
no ipv6 prefix auto
no ipv6 name-servers auto
no ipv6cp?4 minutes ago, Goblin said:не должно вроде. и кстати на установку я его не ставил. само как-то установилось.
из последнего что делал установил Entware-3x
Удалил у себя модули Kernel modules for Netfilter, Kernel modules for Traffic Control support, Extension package Xtables-addons for Netfilter, Packet capture. После этого смог удалить IPv6, похоже действительно какие-то зависимости появились при очередном обновлении.
-
20 minutes ago, AndreBA said:
Может с каким то компонентам завязан, вот и не дает удалить.
В том-то все и дело, что до 2.09.A.5.0-2 он был удален. Набор компонентов достаточно стандартный и не менялся, ничего из них вроде не должно требовать IPv6
-
Подтверждаю, на Ultra II такая же ситуация, прошивка 2.09.A.6.0-0.
-
1
-
-
21 minutes ago, Sfut said:
Скорее всего да, но есть одно но. У @fOx Ultra 2, а с ней есть вопросы по поводу ошибок на портах. Подробнее здесь https://forum.keenetic.net/topic/2234-ultra-ii-низкая-скорость-записи-на-hdd/. Причем и там и здесь rxerrors. Так что имеет смысл посмотреть на ошибки по остальным портам.
Я бы не стал обобщать на все Ultra II вот так вот, скопом. Вот у меня Ultra II и нет вопросов по поводу большого количества rxerrors на портах. Например, за двое суток на ISP интерфейсе:
Spoiler~ # ifconfig eth3
eth3 Link encap:Ethernet HWaddr 58:8B:F3:6B:EF:05
inet addr:93.xxx.xxx.xxx Bcast:93.xxx.xxx.xxx Mask:255.255.254.0
inet6 addr: fe80::5a8b:f3ff:fe6b:ef05/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6487270 errors:3 dropped:37022 overruns:0 frame:0
TX packets:2732614 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2058909428 (1.9 GiB) TX bytes:2094933970 (1.9 GiB)
Interrupt:11Прошивка последняя, 2.09.A.5.0-2, но и на других не наблюдал. Так что согласен с KorDen - скорее всего виноват кабель.
-
1 hour ago, TheBB said:
на какой странице? пертыкал все, какие есть, ошибку не выдаёт.
Сразу при заходе в WebUI появляется, после загрузки стартовой страницы. Потом можно по всем страничкам пробежаться - ошибки больше нет, пока браузер не закроешь и не откроешь снова. Проверил на Firefox и Google Chrome - без разницы.
-
После обновления на 2.09.A.5.0-2 в логе при обращении к Web интерфейсу роутера появляются ошибки такого вида:
SpoilerApr 01 17:56:55 ultra-ii nginx (conn: *6) open() "/usr/share/htdocs/zyxel.ico" failed (2: No such file or directory), client: 192.168.1.33Поправьте пожалуйста.
-
1
-
-
9 hours ago, ndm said:
Откатываем сборку на 2.09.A.4, не ставьте A.5. Там с Wi-Fi что-то неладно.
После этого индикатор FN, настроеннный по дефолту, т.е. на индикацию наличия обновления, ведет себя странно - мигает, хотя в Updates пусто. Перезагрузка не помогает, через некоторое время начинает мигать опять. Версия прошивки 2.09.A.4.0-1. Поправьте пожалуйста.
-
Это не баг, Le ecureuil уже писал по этому поводу тут. Другое дело, что значение, на которое меняется MTU, отсюда не узнать, т.к. во всех vanilla-like версиях, к которым относится и прошивка наших роутеров, в выводе этого сообщения используется неправильная переменная, я про это уже писал.
-
2
-
-
Заметил, что список разрешений на доступ в интернет для подключенных устройств в #home.hosts выглядит неправильно. Вместо Permitted пишется Forbidden. Доступ у устройств к интернету, конечно, есть. Прошивка v2.09(AAUX.6)A3.
-
5 hours ago, Le ecureuil said:
Код 1-в-1 с vanilla, как и должно быть. А что тут странного?
Понятно, неудивительно, что этот баг плавает с 2005 года и периодически выныривает
Смотрите, в данном куске кода сравниваются значения osize и isize+MPPE_OVHD+2. В случае, если первое меньше второго, то пакет дропается и выводится то самое отладочное сообщение, что osize (практически это MTU) слишком мало и оно должно быть не меньше чем osize+MPPE_OVHD+2, хотя по логике вещей должно выводиться сообщение, что osize должно быть не меньше чем isize+MPPE_OVHD+2. В первом случае сообщение бесполезно и является неинформативным, более того, в интернете полно пользователей и советчиков, которые увидев это сообщение увеличивают MTU на 4 и удивляются, почему сообщение продолжает возникать вновь, но со значениями, увеличенными на 4. Во втором случае сообщение весьма информативно и пользователь может из него сделать выводы в виде изменения начального значения MTU на основании реальных данных. А вы говорите, про новые алгоритмы, которые не реализовывают якобы из-за каких-то высших соображений, а такой банальный баг копипастят уже более 10 лет. 
PS Кстати, можете считать это сообщение багрепортом.
-
14 hours ago, Le ecureuil said:
Технически это не баг в mppe, это особенность работы в режиме, когда MTU роута меняется.
А я не про то, что такое сообщение выводилось, хотя оно, конечно, раздражало, а про то, что оно выводилось неправильно. Как Вы там говорили, "Talk's cheap, show us the code!"? Их есть у меня:
Spoilerdrivers/net/ppp/ppp_mppe.c: /* Make sure we have enough room to generate an encrypted packet. */ if (osize < isize + MPPE_OVHD + 2) { /* Drop the packet if we should encrypt it, but can't. */ printk(KERN_DEBUG "mppe_compress[%d]: osize too small! " "(have: %d need: %d)\n", state->unit, osize, osize + MPPE_OVHD + 2); return -1; }
https://github.com/torvalds/linux/blob/master/drivers/net/ppp/ppp_mppe.c#L384 https://github.com/ndmsystems/linux-3.4/blob/master/drivers/net/ppp/ppp_mppe.c#L383 И т.д.
Ничего странного не замечаете?
-
4 hours ago, Le ecureuil said:
Даже в linux-next этот код не изменен, значит на то есть причины.
Это не показатель. Например, баг в модуле PPTP "mppe_compress[0]: osize too small! (have: 1404 need: 1408)" существует как минимум с 2005 года, а периодически он прорывается до сих пор (у вас это тоже было, кстати, совсем недавно
).
-
4 hours ago, Le ecureuil said:
"Talk's cheap, show us the code!"
https://github.com/ndmsystems/linux-3.4/blob/master/net/netfilter/xt_TCPMSS.c#L132Понятно. А как же RFC4821? Там как раз описывается вариант PMTUD с увеличением MSS.
-
1 hour ago, Le ecureuil said:
В этой статье не учитывается размер L2TP и NAT-T Encap заголовков, потому там есть неточности. Однако суть верна, будет использоваться самое оптимальное значение из возможных.
Я эту статью привел просто в качестве примера того, что не всегда увеличение MSS приводит к увеличению скорости инкапсулированного соединения (интересно было бы посчитать с учетом всех заголовков, а какой MSS действительно будет оптимальным), а уж про увеличение MTU при активном PMTUD я и не говорю даже. Кстати, после изучения цисковского описания PMTUD у меня сложилось впечатление, что он может только уменьшать MSS при попытке TCP соединения, а увеличение как-то не предусмотрено. Я что-то недопонял или тут алгоритм более гибкий?
-
4 hours ago, Sfut said:
Может быть это проблемы конкретного провайдера и не стоит уменьшать размер MTU по дефолту? У меня провайдер на PPPoE аргументируя такими же проблемами уменьшил MTU до 1200 и планирует уменьшить еще до 1000. Хотя у других провайдеров в городе прекрасно работает на 1492.
Я это понимаю так: тут дело не в размере MTU, допустимом у конкретного VPN провайдера, а в том, что при соединении с некоторыми сайтами алгоритм автоматического регулирования MSS по каким-то причинам работает криво (например, админы запретили ICMP пакеты на каком-то промежуточном узле и не приходит ответ fragmentation needed), если изначально установлено слишком большое значение MTU. И именно поэтому я предлагаю изменить дефолтное значение MTU при создании соединения L2TP/IPSec, чтобы алгоритм автоматического изменения MSS работал более корректно.
PS Кстати, по поводу MSS на L2TP/IPSec соединении. Прочитал тут один занятный документ, называется "IPSec Bandwidth Overhead Using AES". Там расчитывается полный overhead для разных MSS и показывается, что максимизация MSS вовсе не ускоряет скорость инкапсулированного соединения, а оптимальное значение равно 1328.
-
9 hours ago, Le ecureuil said:
Попробуйте выполнить
> interface L2TP0 ip mtu 1300Создал заново соединение, установил MTU для него по Вашей рекомендации и подключился. Подтверждаю, проблема исчезла. Может, стоит изменить дефолтные настройки при создании L2TP/IPSec соединения?
-
Обратил внимание, что для моего L2TP/IPSec соединения (конфиг ниже прилагаю) очень странно работает tcp adjust-mss pmtu с некоторыми сайтами, например forum.keenetic.net, сервисы google (например, получение почты через мобильный клиент, hangouts через web-интерфейс и пр.) - для пользователя это выглядит как очень медленное, с таймаутами, соединение. Но если проявить настойчивость, то после нескольких таймаутов соединение с сайтом устанавливается и все начинает работать как положено, до отключения L2TP/IPSec соединения. При соединении через PPTP такого не наблюдается. Как можно исправить эту проблему понятно, поставить в ip tcp adjust-mss значение поменьше, но хотелось бы, чтобы заработало и tcp adjust-mss pmtu. Версия прошивки v2.09(AAUX.5)A3
Spoilerinterface L2TP0 description "Private Internet Access" peer 178.162.211.216 no ipv6cp lcp echo 30 3 ipcp default-route ipcp name-servers ipcp dns-routes no ccp security-level public authentication identity *** authentication password ns3 *** ip dhcp client dns-routes ip dhcp client name-servers ip mtu 1400 ip global 1000 ip tcp adjust-mss pmtu ipsec preshared-key ns3 *** connect up -
Тоже подтверждаю, сталкивался с этой проблемой, изменения, сделанные в #broadband.ppp не всегда записываются, сохраняются 100% только после system configuration save. От чего зависит - не понял.
UPD: Вот сейчас только что удалил созданное L2TP/IPSec соединение, в вебморде нотификация о сохранении изменений прошла, а в логах сообщения о сохранении нет, В startup-config оно так же присутствует.
- не появилось ли у Вас новых идей, почему такое может быть? Полный селфтест, как обычно, в следующем сообщении.
В WebUI возможно перепутаны местами порты USB
in 2.09
Posted · Edited by Dale
В синем порте стоял модем USB 2.0, в черном - флешка USB 2.0. В связи с покупкой USB 3.0 жесткого диска отключил transmission, opkg, отключил флешку в #dashboard.status - USB devices, модем пока не трогал и не отключал. После этого в какой-то момент заметил, что пункт выбора режима работы синего порта, в который еще остался воткнут модем, активен. Возможно, что порты не перепутаны, а это баг из той же серии, что описан в Ошибка: При перезагрузке модема возникает перемонтирование флешки