Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

Wi-CAT LLC
Навигация Форума
Вы должны войти, чтобы создавать сообщения и темы.

(решено) PPPoE не подключается с первого раза (PAP authentication failed)

Собственно заметил такую вещь именно на Wive. Другой роутер или текущий на альтернативной прошивке такой проблемы не имеет, подключается с полпинка.

Соединение с провом PPPoE, обязательно указывать имя службы, но такое ощущение, что роутер перебирает все доступные AC, естественно получает в большинстве случаев отлуп.

Логи приложу позже (когда с работы приду, так что ногами не пинать).

Ещё заметил, что это поведение почему-то связанно с первым байтом мак-адреса, если он не нулевой, то сто процентов после перезагрузки не соединяется с первой попытки.

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

PS. Попытка включить дебаг на странице настройки VPN не приводит к увеличению информативности логов.

PSS. Вот лог после перезагрузки роутера. Логин и пароль заведомо верные.

Aug 14 18:19:18 2nd_stage: Copy web pages to tmpfs.
Aug 14 18:19:19 2nd_stage: Start WEB Managment Server.
Aug 14 18:19:20 vpnhelper-pppoe: ==================START-PPPOE-CLIENT=======================
Aug 14 18:19:20 vpnhelper-pppoe: PPPOE connect over eth2.2 to  rp_pppoe_service ESILNET
Aug 14 18:19:20 pppd[3120]: Plugin /lib/rp-pppoe.so loaded.
Aug 14 18:19:20 pppd[3120]: RP-PPPoE plugin version 3.12 compiled against pppd 2.4.7
Aug 14 18:19:20 pppd[3120]: pppd 2.4.7 started by daemon, uid 0
Aug 14 18:19:20 pppd[3120]: PPP session is 144 (0x90)
Aug 14 18:19:20 pppd[3120]: Connected to 90:e2:ba:01:eb:c0 via interface eth2.2
Aug 14 18:19:20 pppd[3120]: Using interface ppp0
Aug 14 18:19:20 pppd[3120]: Connect: ppp0 <--> eth2.2
Aug 14 18:19:23 kernel: br0: port 1(eth2.1) entered forwarding state
Aug 14 18:19:23 pppd[3120]: PAP authentication failed
Aug 14 18:19:23 pppd[3120]: Connection terminated.
Aug 14 18:19:23 pppd[3120]: Sent PADT
Aug 14 18:19:23 udhcpd[2809]: sending OFFER of 192.168.4.251
Aug 14 18:19:24 kernel: br0: port 2(ra0) entered forwarding state
Aug 14 18:19:25 udhcpd[2809]: sending OFFER of 192.168.4.60
Aug 14 18:19:25 udhcpd[2809]: sending OFFER of 192.168.4.53
Aug 14 18:19:25 udhcpd[2809]: sending ACK to 192.168.4.251
Aug 14 18:19:25 udhcpd[2809]: sending ACK to 192.168.4.53
Aug 14 18:19:25 udhcpd[2809]: sending ACK to 192.168.4.60
Aug 14 18:19:28 pppd[3120]: PPP session is 758 (0x2f6)
Aug 14 18:19:28 pppd[3120]: Connected to 90:e2:ba:01:ec:3c via interface eth2.2
Aug 14 18:19:28 pppd[3120]: Using interface ppp0
Aug 14 18:19:28 pppd[3120]: Connect: ppp0 <--> eth2.2
Aug 14 18:19:31 pppd[3120]: PAP authentication failed
Aug 14 18:19:31 pppd[3120]: Connection terminated.
Aug 14 18:19:31 pppd[3120]: Sent PADT
Aug 14 18:19:36 pppd[3120]: PPP session is 552 (0x228)
Aug 14 18:19:36 pppd[3120]: Connected to 90:e2:ba:3e:35:f0 via interface eth2.2
Aug 14 18:19:36 pppd[3120]: Using interface ppp0
Aug 14 18:19:36 pppd[3120]: Connect: ppp0 <--> eth2.2
Aug 14 18:19:39 pppd[3120]: PAP authentication failed
Aug 14 18:19:39 pppd[3120]: Connection terminated.
Aug 14 18:19:39 pppd[3120]: Sent PADT
Aug 14 18:19:44 pppd[3120]: PPP session is 759 (0x2f7)
Aug 14 18:19:44 pppd[3120]: Connected to 90:e2:ba:01:ec:3c via interface eth2.2
Aug 14 18:19:44 pppd[3120]: Using interface ppp0
Aug 14 18:19:44 pppd[3120]: Connect: ppp0 <--> eth2.2
Aug 14 18:19:47 pppd[3120]: PAP authentication failed
Aug 14 18:19:47 pppd[3120]: Connection terminated.
Aug 14 18:19:47 pppd[3120]: Sent PADT
Aug 14 18:19:52 pppd[3120]: PPP session is 127 (0x7f)
Aug 14 18:19:52 pppd[3120]: Connected to 90:e2:ba:01:eb:c0 via interface eth2.2
Aug 14 18:19:52 pppd[3120]: Using interface ppp0
Aug 14 18:19:52 pppd[3120]: Connect: ppp0 <--> eth2.2
Aug 14 18:19:55 pppd[3120]: PAP authentication failed
Aug 14 18:19:55 pppd[3120]: Connection terminated.
Aug 14 18:19:55 pppd[3120]: Sent PADT
Aug 14 18:20:00 pppd[3120]: PPP session is 132 (0x84)
Aug 14 18:20:00 pppd[3120]: Connected to 90:e2:ba:01:eb:c0 via interface eth2.2
Aug 14 18:20:00 pppd[3120]: Using interface ppp0
Aug 14 18:20:00 pppd[3120]: Connect: ppp0 <--> eth2.2
Aug 14 18:20:03 pppd[3120]: PAP authentication succeeded
Aug 14 18:20:03 pppd[3120]: peer from calling number 90:E2:BA:01:EB:C0 authorized
Aug 14 18:20:03 pppd[3120]: local  IP address 176.108.XXX.XXX
Aug 14 18:20:03 pppd[3120]: remote IP address 172.16.XXX.XXX
Aug 14 18:20:03 pppd[3120]: primary   DNS address 176.108.XXX.XXX
Aug 14 18:20:03 pppd[3120]: secondary DNS address 176.108.XXX.XXX
Aug 14 18:20:03 pppd: Store old default route to file. default via 10.4.0.254 dev eth2.2  
Aug 14 18:20:03 pppd: Remove vpnDGW
Aug 14 18:20:03 pppd: Replace default route to ppp0
Aug 14 18:20:03 pppd: Flush route cache
Aug 14 18:20:03 pppd: Restart dns server, dyndns, ntp sync and rebuild shaper and iptables rules
Aug 14 18:20:04 services: Restart needed services and scripts. Mode pppd
Aug 14 18:20:04 QoS: Stopping SHAPER
Aug 14 18:20:04 QoS: Set default rules.
Aug 14 18:20:04 Codel: QoS Add codel for all interfaces.
Aug 14 18:20:05 iptables: Add netfiler rules
Aug 14 18:20:05 iptables: Allow established/related in input
Aug 14 18:20:05 iptables: Drop invalid state connections
Aug 14 18:20:05 iptables: Service limit set
Aug 14 18:20:05 iptables: DHCP server allow
Aug 14 18:20:05 iptables: Dnsproxy allow to connect
Aug 14 18:20:05 iptables: allow local port range 32768:61000 from LAN, need for some local service
Aug 14 18:20:05 iptables: UPNP allow to connect
Aug 14 18:20:05 iptables: Remote managment web limit
Aug 14 18:20:05 iptables: Remote managment ssh limit
Aug 14 18:20:05 iptables: Remote managment telnet limit
Aug 14 18:20:05 iptables: Allow rate limited ping from all interfaces.
Aug 14 18:20:05 iptables: Set forward rules
Aug 14 18:20:05 iptables: Allow forward from LAN to any
Aug 14 18:20:05 iptables: Add SNAT from 192.168.4.1/255.255.255.0 to 10.32.5.11 at eth2.2.
Aug 14 18:20:05 iptables: Call to add VPN netfilter rules.
Aug 14 18:20:05 iptables: Add base upnp rules
Aug 14 18:20:05 iptables: Allow established/related in forward
Aug 14 18:20:05 resolv: Generate resolv DNS1: 10.4.0.1 DNS2: 
Aug 14 18:20:05 resolv: Install ipv4 DNS servers to local resolv.
Aug 14 18:20:05 resolv: Add ISP DNS from vpn servers for local resolv
Aug 14 18:20:05 dnsserver: Generate /etc/hosts file.
Aug 14 18:20:05 dnsserver: Send HUP to dnsmasq.
Aug 14 18:20:05 dnsmasq[995]: read /etc/hosts - 47 addresses
Aug 14 18:20:05 dnsmasq[995]: using nameserver 10.4.0.1#53
Aug 14 18:20:05 dnsmasq[995]: using nameserver 176.108.XXX.XXX#53
Aug 14 18:20:06 ntp: Stopping NTPD
Aug 14 18:20:06 ntp: Starting NTPD
Aug 14 18:20:06 upnpd: Starting UPNP at 176.108.XXX.XXX
Aug 14 18:20:06 miniupnpd[3685]: version 2.1 started
Aug 14 18:20:06 miniupnpd[3685]: HTTP listening on port 8666
Aug 14 18:20:06 miniupnpd[3685]: no HTTP IPv6 address, disabling IPv6
Aug 14 18:20:06 miniupnpd[3685]: Listening for NAT-PMP/PCP traffic on port 5351
Aug 14 18:20:06 miniupnpd[3685]: PCPSendUnsolicitedAnnounce() IPv6 sendto(): Bad file descriptor
Aug 14 18:20:07 pppd: Enable forwarding for ppp0 interface
Aug 14 18:20:07 pppd: Run scripts from /etc/ppp/ip-up.d

 

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

Таким образом проблема возникает только при перезагрузке роутера (Save & Reboot).

Спасение утопающих.....

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

--- /opt/Wive-MT/user/nginx/extra-modules/nginx-http-wive/asp_mod_utils.c	2019-08-14 21:30:25.466899671 +0600
+++ /opt/Wive-MT/user/nginx/extra-modules/nginx-http-wive/asp_mod_utils.c1	2019-08-14 20:43:10.410058629 +0600
@@ -678,6 +678,10 @@
     /* only by save and reboot logic must save rwfs */
     doSystem("fs save");
 
+    /* close ppp session */
+    if (nvram_get(RT2860_NVRAM, "vpnEnabled") == "on")
+	doSystem("service vpnhelper stop");
+
     /* Reboot */
     wp->on_response_ok = DO_REBOOT;
 }

Теперь вроде всё работает как дОлжно.

Утопающий. =) Надо проверить где при перезде на ngix потеряли стоп ppp сессии.

Т.е. причина не неверный выбор AC а в том что выбирает таки верно, просто сессия на стороне браса всё ещё висит. И происходит это только если ребутить роутер или дёргать из розетки или reboot с консоли.

Ошибкой это как таковой не является и проблем при обычной эксплуатации не вызывает от слова никаких. Ибо подразумевается схема "настроил и забыл".

Освобожусь посмотрю где потерялось ибо точно было.

Глянул бегло. Потерялось оно после того как потребовалось разрешить обновление прошивки с WAN при VPN на доступе.

Стоп жил в unload_all.sh и выполнялся перед любым ребутом по любому поводу. Но тогда понятно что будет чехарда со счётчиками обновления через VPN. Т.к. сначала зальётся прошивка в tmpfs, затем погаситься в т.ч. vpn и лишь потом будет попытка показать обратный отсчёт.

Так что да, похоже единственный вариант добавить как у вас выше при save and reboot а при обновлении не трогать это дело. Т.к. если начали уже писать на флэш то что-то с него исполнить будет уже не реально, а если сделать раньше обрыв сессии то при обновлении с WAN счётчика юзверь не увидит.

Ладно почешу репу на днях как лучше сделать.

Скорее всего следует обрывать сессию в unload_all всегда если включен VPN при этом доступ в рожу с WAN запрещён. Это даст обработку 99% кейзов тем более что рожу в WAN выставлять это бяда по определению.

 

В общем внёс необходимые правки в гит, но проверить в ближайшее время не смогу (занят однако). Потому просьба проверить и отписаться.

 

Спасибо что не бросаете утопающих! ;)

Вечером пересоберу с правками, залью, проверю и отпишусь.

Проверил всё что смог.

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

Тему можно закрывать.

Цитата: RoxsAndy от 15/08/2019, 17:58

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

Да вот прям.

Если доступ к роже из WAN не открыт то должен завешить и сессию и даже WAN погасить перед началом записи на флэш.

eval `nvram_buf_get 2860 RemoteManagement`

if [ "$1" = "REBOOT" ] || [ "$RemoteManagement" != "2" ]; then
# stop vpn and wan for correct terminate
# pppoe session and DHCP address release
stop_serv="$stop_serv vpnhelper wan"
fi

При save and reboot просто вызывается с флгаом REBOOT, а при обновлении будет вызвано без флага и будет зависить открыт доступ в WEB с WAN. Вдруг обновляют с WAN тогда лучше сессию не рвать.

Так что при обновлении тоже должно быть всё ок за исключением случая включенного с WAN доступа к WEBUI (что вообще-то крайне бы не рекомендовал бы делать ни на каком железе, ни на каком ПО).

P.S. В HQ у нас логика несколько иная но ограничения те же. Можно попробовать подумать и определять откуда юзверь льёт обновление по факту (ngix в общем-то знает откуда льётся). Или вот по хорошему вообще с WAN обновление софта из образа запретить нафиг. Только автоматикой. Подумаем. Тема вынтересная.

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

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

Теперь вместо счётчика лицезреем вот такой скрин:

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..

Обновляете то с LAN или с WAN ?

Обновляю локально с LAN, проверил трижды - счётчик пропал.

Тттак щас сделаем иначе похоже понял в чём прикол в т.ч со счётчиком. Придётся делать хитрее.

 

 

Так. В гит. Пробумс.

Такс, с апдейтами вы ПРАВЫ - нет больше тайм-аута после апдейта. Это я словил его после апдейта со своей сборки. Посыпаю голову пеплом.... :(

Ну щас текущую проверьте что бы уже зафиксироваться и не трогать больше да и всё. Хорошо что нет, как бы ошибиться там не где было.

Вот только флуш контрака при six/wan stop не учёл потому счётчика и нет т.к. клеент от WEBа дисконнетит раньше чем счётчик отрисовать.

Сейчас нормально должно быть всё.

 

Пересобираю....

Так ещё очепяточка, блин воттороплюсь, надо убегать. Так что ресинк на всякий.

Без последней правки - счётчика нет.

Позже соберу с последними изменениями. Тоже надо идти срочно.

Сегодня-завтра проверю окончательную версию.

Вспомнил, в vpnhelper stop тоже контрак же флушиться. Ок. Сделал прямое прибивание сервисов VPN и release в сторону сервера.

Приверил с последними правками - счётчик при апдейте на месте,  сессия завершилась правильно, тайм-аут от прова не пойман. Вроде всё хорошо.... Но, блин, такое количество кода ради этого счётчика...

Не проще было бы где-нибудь в модуле nginx firmware.c  (к примеру, в mtd_write_firmware) вставить пару вызовов типа vpnhelper stop и.т.д, для релиза dhcp и прерывания сессии ppp?

Как-то всё запутанно становится...

PS. Кстати, просматривая код nginx, наткнулся в нескольких местах на упоминание goahead. Особенно ляписто выглядит в принтах ошибок. Надо бы поправить для полной красоты картины. :)

Ну вот и хорошо.

Кода как раз меньше получается и он переиспользуется в зависимости от кейзов что упрощает отладку.

А в HQ вообще сущности все разделили и нгикс больше напрямую не учавствует ни в прошивке фирмвари ни в чём-то ещё.  Чётко выделили что и чем занимается.

Что касается "проще вставить пару тройку" я боюсь а глаза станут ууууузкими.... =) Так что я воздержусь от проще в пользу лучше. Учитывая что натыкать и помнить куда и зачем натыкал эт ещё та радость. Так что не проще как ни крути.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: