Temat: Problem z dostępem do WAN po zerwaniu połączenia

Witam,
mam zainstalowanego:

[OpenWrt Barrier Breaker (r44952)                             |
Build time: 2015-03-28 08:47 CET

jest to wersja z LuCi.
Dostęp do WAN mam poprzez modem TP-Link TD8816 który działa w trybie bridge. Do niego podłączony jest TP-Link TL-WR1043ND, a dostęp do WAN skonfigurowany jest przez PPPOE.
Za każdym razem gdy modem ADSL zrywa i nawiązuje nowe połączenie (dostaje inny IP) to WR1043ND przestaje mieć dostęp do WAN.
Podejrzewam iż jest tutaj jakiś problem z routingiem.
ifconfig pokazuje na interfejsie pppoe-wan nowy adres ip poprawnie:

pppoe-wan Link encap:Point-to-Point Protocol
          inet addr:83.5.124.99  P-t-P:83.1.4.238  Mask:255.255.255.255

a wynik polecenia route jest następujący:

root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         83.1.4.238      0.0.0.0         UG    0      0        0 pppoe-wan
10.10.1.0       *               255.255.255.0   U     0      0        0 br-lan
83.1.4.238      *               255.255.255.255 UH    0      0        0 pppoe-wan

dostępu do WAN jednak BRAK i przy próbie pinga dostaję komunikat 'bad host'. Nie działa ping ani po IP ani po nazwie.

Aby przywrócić połączenie WAN pomaga tylko restart routera albo /etc/init.d/network restart.

Jedyna różnica jaką wtedy zaobserwowałem to to, że Gateway w poleceniu route jest pokazywany nie jako IP ale jako nazwa.

root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         kat-bng2.neo.tp 0.0.0.0         UG    0      0        0 pppoe-wan
10.10.1.0       *               255.255.255.0   U     0      0        0 br-lan
83.1.4.238      *               255.255.255.255 UH    0      0        0 pppoe-wan

Podejrzewam więc iż jest problem z jakimś skryptem który nie uaktualnia tabeli routingu poprawnie po zerwaniu połączenia - może jest to w jakiś sposób do skonfigurowania?
Przy poprzednim Open-WRT (bodjaże BackFire) tego problemu nie było.

2

Odp: Problem z dostępem do WAN po zerwaniu połączenia

Dnsy w takim razie nie działają. Sprawdź sam restart dnsmasq.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

3

Odp: Problem z dostępem do WAN po zerwaniu połączenia

Niestety restart dnsmasq nie rozwiązuje problemu.
W tej chwili jestem w stanie zasymulować problem poprzez zabicie demona pppd.

kill -s SIGHUP `pidof pppd`

nslookup dla domyślnej bramy przed zabiciem pppd:

nslookup 83.1.4.238
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

Name:      83.1.4.238
Address 1: 83.1.4.238 kat-bng2.neo.tpnet.pl

po zabiciu:

root@OpenWrt:~# nslookup 83.1.4.238
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

Name:      83.1.4.238
Address 1: 83.1.4.238

4

Odp: Problem z dostępem do WAN po zerwaniu połączenia

mam to samo tylko z tplinkiem 4300 sad

5 (edytowany przez pyra73 2015-05-12 14:38:11)

Odp: Problem z dostępem do WAN po zerwaniu połączenia

Witam, miałem dokładnie to samo na neostradzie + 1043nd v2. Polecam własną kompilację i działa bez problemu. Podejrzewam jakiś błąd w kompilacji Cezarego, bo to nie jest odosobniony przypadek.

6

Odp: Problem z dostępem do WAN po zerwaniu połączenia

Mi jakoś działa. A nikt nie był w stanie jeszcze zdiagnozować problemu.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

7

Odp: Problem z dostępem do WAN po zerwaniu połączenia

Witam, bez urazy dla mnie jesteś guru. Ja zrobiłem sobie własny obraz, ale koledzy z forum twierdzili, że po restarcie firewalla połączenie wracało, więc podejrzewam problem właśnie w nim

8

Odp: Problem z dostępem do WAN po zerwaniu połączenia

Nie mogę poprawić czegoś jak u mnie działa. Zdiagnozujcie z czym jest problem (bo akurat w firewallu nie było grzebane nic, w dnsmasq też).

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

9 (edytowany przez phoenix 2015-05-13 09:58:20)

Odp: Problem z dostępem do WAN po zerwaniu połączenia

Jak zmusić dnsmasq do wrzucania czegoś do logów?

Chyba pytanie o dnsmasq już nieaktualne, tak jak napisał kolega pyra73 po restarcie firewalla wszystko wraca do normy. Czyli najpierw robie kill'a pppd -> i przestaje działać -> następnie restart firewalla -> i zaczyna działać.

10

Odp: Problem z dostępem do WAN po zerwaniu połączenia

logqueries/log-facilit/log-dhcp, manual od dnsmasq zobacz.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

11

Odp: Problem z dostępem do WAN po zerwaniu połączenia

Wiec zrób sprawdzenie czym się to różni.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

12

Odp: Problem z dostępem do WAN po zerwaniu połączenia

Cezary, zerknij wyżej - właśnie zrobiłem edit swojego poprzedniego posta - chyba jest problem z firewallem.

13

Odp: Problem z dostępem do WAN po zerwaniu połączenia

Nadal nic ciekawego nie napisałeś. Restart i działa, ale nie sprawdziłeś dlaczego.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

14

Odp: Problem z dostępem do WAN po zerwaniu połączenia

Sprawdziłem sobie reguły firewala czyli:

iptables -L -n

i zarówno gdy działa jak i gdy nie działa są takie same.

15

Odp: Problem z dostępem do WAN po zerwaniu połączenia

Sam widzisz że taka wypowiedź nie wnosi nic do rozwiązania problemu. Szukaj ponownie.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

16

Odp: Problem z dostępem do WAN po zerwaniu połączenia

Wnosi o tyle, że widać co zostało sprawdzone. Natomiast szczerze powiedziawszy już za bardzo nie wiem gdzie i czego mam szukać.

17

Odp: Problem z dostępem do WAN po zerwaniu połączenia

Sprawdź logach czy po ponownym podniesieniu interfejsu kiedy nie internetu, netifd zgłasza przeładowanie firewalla.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

18

Odp: Problem z dostępem do WAN po zerwaniu połączenia

Witam

Zmagam się z tym samym problemem...
Mam Netgar WRND 3700 v2 z najnowszym BB, internet z UPC 60mbit, mam modem Cisco EPC3212 a mimo to raz dziennie modem odmawia ruterowi przyznania Wan i trzeba restartować router bo sieć nie ma dostępu do internetu...

Oto moje spostrzeżenia :

Wg mnie winne jest Transmission a dokładnie - upload, po ściągnięciu plików seedujemy i gdy zapomniałem trochę o swoich torentach zobaczyłem że ratio mam ponad 30 smile co powiedzmy przy 40 Gb danych x 30 daje niezłą wysyłkę.. i to np w dwa dni..
Ponieważ zamroziłem Transmission przez kolejnych kilka ostatnich dni - wszystko pięknie śmiga, bez zawiech..
Teraz testuje ustawienie w Transmission ratio max 2.0, a jak to nie pomoże to może limit UL na niewiem może na 1 Mb/s ...

Nie wiem czy to rozwiązanie problemu ale jako miłośnik teorii spiskowych myślę że to świadoma polityka UPC aby walczyć z streamami filmów i innymi usługami swoich abonentów bo akurat ten kawałek usługi jest wrażliwy - w sytuacji kiedy każdy wysyła obraz w hd gadając przez skype to UL ledwo wyrabia - to takie moje spostrzeżenia

pozdrawiam

19

Odp: Problem z dostępem do WAN po zerwaniu połączenia

U mnie jest identycznie. Poniżej moje logi ale nic w nich pewnie nie ma ciekawego. Udało się komuś z Was to ogarnąć? Wkurzające to trochę już.

Fri May 29 10:21:23 2015 daemon.info pppd[1648]: LCP terminated by peer
Fri May 29 10:21:23 2015 daemon.info pppd[1648]: Connect time 1440.1 minutes.
Fri May 29 10:21:23 2015 daemon.info pppd[1648]: Sent 193029921 bytes, received 3272211681 bytes.
Fri May 29 10:21:23 2015 daemon.notice netifd: Network device 'pppoe-wan' link is down
Fri May 29 10:21:23 2015 daemon.notice netifd: Network alias 'pppoe-wan' link is down
Fri May 29 10:21:23 2015 daemon.notice netifd: Interface 'wan6' has link connectivity loss
Fri May 29 10:21:23 2015 daemon.notice netifd: Interface 'wan' has lost the connection
Fri May 29 10:21:23 2015 user.notice mwan3: ifdown interface wan (unknown)
Fri May 29 10:21:24 2015 daemon.notice netifd: Interface 'wan6' is now down
Fri May 29 10:21:24 2015 daemon.notice netifd: Interface 'wan6' is disabled
Fri May 29 10:21:26 2015 daemon.info hostapd: wlan1: STA 00:13:e8:98:26:7d WPA: group key handshake completed (RSN)
Fri May 29 10:21:26 2015 daemon.notice pppd[1648]: Connection terminated.
Fri May 29 10:21:26 2015 daemon.info hostapd: wlan0: STA 98:0c:82:82:16:64 WPA: group key handshake completed (RSN)
Fri May 29 10:21:26 2015 daemon.notice pppd[1648]: Modem hangup
Fri May 29 10:21:28 2015 daemon.warn dnsmasq[1945]: no servers found in /tmp/resolv.conf.auto, will retry
Fri May 29 10:21:56 2015 daemon.info pppd[1648]: PPP session is 12384
Fri May 29 10:21:56 2015 daemon.warn pppd[1648]: Connected to f0:1c:2d:7e:a6:4a via interface eth0.2
Fri May 29 10:21:56 2015 daemon.info pppd[1648]: Using interface pppoe-wan
Fri May 29 10:21:56 2015 daemon.notice pppd[1648]: Connect: pppoe-wan <--> eth0.2
Fri May 29 10:21:56 2015 daemon.info pppd[1648]: CHAP authentication succeeded
Fri May 29 10:21:56 2015 daemon.notice pppd[1648]: CHAP authentication succeeded
Fri May 29 10:21:56 2015 daemon.notice pppd[1648]: peer from calling number F0:1C:2D:7E:A6:4A authorized
Fri May 29 10:21:57 2015 daemon.notice netifd: Network device 'pppoe-wan' link is up
Fri May 29 10:21:57 2015 daemon.notice pppd[1648]: local  IP address 83.11.9.97
Fri May 29 10:21:57 2015 daemon.notice pppd[1648]: remote IP address 83.1.4.248
Fri May 29 10:21:57 2015 daemon.notice pppd[1648]: primary   DNS address 194.204.152.34
Fri May 29 10:21:57 2015 daemon.notice pppd[1648]: secondary DNS address 194.204.159.1
Fri May 29 10:21:57 2015 daemon.notice netifd: Interface 'wan6' is enabled
Fri May 29 10:21:57 2015 daemon.notice netifd: Network alias 'pppoe-wan' link is up
Fri May 29 10:21:57 2015 daemon.notice netifd: Interface 'wan6' has link connectivity
Fri May 29 10:21:57 2015 daemon.notice netifd: Interface 'wan6' is setting up now
Fri May 29 10:21:57 2015 daemon.notice netifd: Interface 'wan' is now up
Fri May 29 10:21:57 2015 user.notice firewall: Reloading firewall due to ifup of wan (pppoe-wan)
Fri May 29 10:21:58 2015 user.notice ddns-scripts-myddns: Running IP check ...
Fri May 29 10:21:59 2015 daemon.info dnsmasq[1945]: reading /tmp/resolv.conf.auto
Fri May 29 10:21:59 2015 daemon.info dnsmasq[1945]: using local addresses only for domain lan
Fri May 29 10:21:59 2015 daemon.info dnsmasq[1945]: using nameserver 194.204.152.34#53
Fri May 29 10:21:59 2015 daemon.info dnsmasq[1945]: using nameserver 194.204.159.1#53
Fri May 29 10:21:59 2015 user.notice ddns-scripts-myddns: update failed, retrying in 60 seconds
Fri May 29 10:21:59 2015 daemon.err miniupnpd[20467]: could not open lease file: /var/upnp.leases
Fri May 29 10:21:59 2015 daemon.err miniupnpd[20467]: Why did you run me anyway?
Fri May 29 10:22:59 2015 user.notice ddns-scripts-myddns: Running IP check ...
Fri May 29 10:22:59 2015 user.notice ddns-scripts-myddns: update failed, retrying in 60 seconds
Fri May 29 10:23:59 2015 user.notice ddns-scripts-myddns: Running IP check ...
Fri May 29 10:24:00 2015 user.notice ddns-scripts-myddns: update failed, retrying in 60 seconds
Fri May 29 10:25:00 2015 user.notice ddns-scripts-myddns: Running IP check ...
Fri May 29 10:25:00 2015 user.notice ddns-scripts-myddns: update failed, retrying in 60 seconds
Fri May 29 10:25:45 2015 daemon.info dnsmasq-dhcp[1945]: DHCPINFORM(br-lan) 192.168.1.143 00:13:e8:98:26:7d
Fri May 29 10:25:45 2015 daemon.info dnsmasq-dhcp[1945]: DHCPACK(br-lan) 192.168.1.143 00:13:e8:98:26:7d tomek-Komputer
Fri May 29 10:26:00 2015 user.notice ddns-scripts-myddns: Running IP check ...
Fri May 29 10:26:01 2015 user.notice ddns-scripts-myddns: update failed, retrying in 60 seconds




root@OpenWrt:~# netifd
netifd_ubus_init(1180): connected as 314bf432
Failed to publish object 'network': Invalid argument
Failed to publish object 'network.device': Invalid argument
Failed to publish object 'network.wireless': Invalid argument
Failed to publish object 'network.interface': Invalid argument
proto_shell_add_handler(805): Add handler for script ./3g.sh: 3g
proto_shell_add_handler(805): Add handler for script ./dhcp.sh: dhcp
proto_shell_add_handler(805): Add handler for script ./dhcpv6.sh: dhcpv6
proto_shell_add_handler(805): Add handler for script ./directip.sh: directip
proto_shell_add_handler(805): Add handler for script ./l2tp.sh: l2tp
proto_shell_add_handler(805): Add handler for script ./ncm.sh: ncm
proto_shell_add_handler(805): Add handler for script ./ppp.sh: ppp
proto_shell_add_handler(805): Add handler for script ./ppp.sh: pppoe
proto_shell_add_handler(805): Add handler for script ./ppp.sh: pptp
proto_shell_add_handler(805): Add handler for script ./qmi.sh: qmi

20

Odp: Problem z dostępem do WAN po zerwaniu połączenia

U mnie też występuje taki objaw.
Router TL-WR842ND + modem huawei-e3131.
Pomaga zrestartowanie firewalla:

/etc/init.d/firewall restart

21

Odp: Problem z dostępem do WAN po zerwaniu połączenia

Ja problem rozwiązałem instalując BB z ze strony openwrt.
Oznacza to, że w obrazach Cezarego jest coś nie tak, chociaż nie udało się ustalić co.
Swoją walkę prowadziłem w tym temacie:
http://eko.one.pl/forum/viewtopic.php?id=10997

22

Odp: Problem z dostępem do WAN po zerwaniu połączenia

Mały pomysł - odinstalujcie pakiet całkowicie pakiety  mwan3/luci-app-mwan3 i zobaczcie czy będzie chodzić.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

23

Odp: Problem z dostępem do WAN po zerwaniu połączenia

Bingo.
Po odinstalowaniu mwan3 wan jest dostępny chwilę po nawiązaniu nowego połączenia.

24

Odp: Problem z dostępem do WAN po zerwaniu połączenia

To teraz zgłoście to autorowi na forum openwrt.org.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

25

Odp: Problem z dostępem do WAN po zerwaniu połączenia

Cezary, widzę, że w swojej dystrybucji BB usunąłeś mwan3/luci-app-mwan3 dnia 2015-04-02
Jednak dystrybucja LuCi tych zmian nie zawiera, co więcej ostatnie wydanie jest z 2015-03-28
Myślałem, że LuCi to twoje BB z GUI a tymczasem okazuje się że nie?