Hmmm przeczytałem, postąpiłem zgodnie z opisem w sekcji "WAN by PPPoE", czyli edytowałem plik /etc/config/network, następnie podniosłem interfejs o nazwie "modem", dodałem regułę firewalla i teraz pod dodanym adresem odpala mi się interfejs ale nie Modemu a Routera sad.

Witam,
moja konfiguracja jest następująca

ISP --- ADSL Modem (192.168.1.1) ---- Router (10.10.1.1) --- LAN

Modem ADSL podłączony z jednej strony do internetu a z drugiej poprzez port LAN do portu WAN Routera.
Modem jest ustawiony w trybie Bridge Mode.

Interfejs WAN routera ustawiony jako PPPoE.

Przy tej konfiguracji chciałbym mieć dostęp do GUI modemu ADSL.

Z tego co trochę pogrzebałem to polecane są dwie metody.
Statyczny routing lub utworzenie nowego interfejsu WAN z adresem IP w tej samej sieci co modem ADSL.
Niestety nie udało mi się z tego wyklikać działającego rozwiązania.

Cezary napisał/a:

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

Ja również potwierdzam, że odinstalowanie wspomnianych pakietów rozwiązuje problem.

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

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.

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

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ć.

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

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.

Fajnie, działa. Przy okazji potwierdził się bug w mojej wersji OpenWRT. Nie działa przekierowanie zapytań przychodzących z wan dla adresów w lan'ie które nie są przydzielane na stałe poprzez ethers.

Witam,
mam komputer z kartą bezprzewodową który łączy się po WiFi z Routerem z OpenWRT. Komputer dostaje adres IP przez DHCP z routera. Czy można jakaś sprawdzić jego adres MAC w OpenWRT?

12

(6 odpowiedzi, napisanych Oprogramowanie / Software)

Cezary napisał/a:

Albo raczej jednak jesteś za jakimś transparentnym proxy. 443 też masz zamknięte?

Z tego co się dowiedziałem to proxy na 100% nie ma. 443 zamknięty. Ale https na www działa.

Dlatego na wstępie zapytałem czy jest jakies oprogramowanie na openwrt za pomocą którego mógłbym zrobić VPN przez HTTP bo najprawdopodobniej OpenVPN nie da tutaj rady.

13

(6 odpowiedzi, napisanych Oprogramowanie / Software)

Cezary napisał/a:

Dlaczego przestawienie opevpn na port 80 Ci nie działa?

smile Dobre pytanie - ale tego to ja nie wiem

Thu Feb 07 15:37:02 2013 Attempting to establish TCP connection with x.x.x.x:80
Thu Feb 07 15:37:23 2013 TCP: connect to x.x.x.x:80 failed, will try again in 5 seconds: Connection timed out (WSAETIMEDOUT)[

Ping dochodzi bez problemu, a VPN nie działa. Wczoraj sprawdzałem z innej lokalizacji i na 80 działało, a w miejscu gdzie jestem teraz - nie działa. Może jest jakaś detekcja pakietów po protokole?

14

(6 odpowiedzi, napisanych Oprogramowanie / Software)

Witam wszystkich ponownie,
do tej pory korzystałem z OpenVPN i jakoś sobie radziłem nawet gdy na drodze stało proxy.
Natomiast teraz sieć z której próbuje się połączyć z moim VPN'em ma poblokowane prawie wszystko!
Jest oczywiście otwarty port 80 i przez przeglądarkę mogę spokojnie sobie do was pisać smile. Wpadłem więc na pomysł aby puścić VPN przez port 80 ale niestety nie działa. Dodam iż nie ma w sieci żadnego proxy.
Jestem otwarty na wszystkie sugestie ale jedyne co przychodzi mi teraz to głowy to VPN przez HTTP - czy ktoś prówał już coś takiego na OpenWRT?

15

(13 odpowiedzi, napisanych Oprogramowanie / Software)

rpc napisał/a:

możesz spróbować mniejsze mtu
np. 4500

Zostawię na 1500 bo i tak ograniczeniem była moc procesora w NAS'ie i zmiana MTU niewiele mi wtedy pomogła.

16

(13 odpowiedzi, napisanych Oprogramowanie / Software)

rpc napisał/a:

a się zapytam
jakie mtu masz ustawione na windows na tym komputerze
bo na tym PC masz jumbo frame
zrób dla testu
ifconfig eth0 mtu 1500

i daj znać czy jest lepiej

Nie jest lepiej. Jest idealnie!. Ehhhh testowałem KIEDYŚ na NASie i na PC JumboFrame (żeby przyśpieszyć transfer). Później na NAS'ie wyłączyłem. Ale nie pamiętam żeby spowodowało to jakieś problemy. Widać teraz po zmianie oprogramowania na routerze już Routerowi nie pasowało, że rozmiar ramki jest inny na NAS'ie, a inny na PC.

WIELKIE DZIĘKI !!!.

Mała poprawka. Na NAS'ie nadal mam JumboFrame włączone. ifconfig pokazuje jednak nie 9000 a 9004 jako rozmiar ramki.

Co zrobiłem to zmieniłem na PC i NAS rozmiar ramki na 9000 i nie było połączenia.
9000 na NAS i 1500 na PC - jest połączenie.
Czyżby OpenWRT miał problem z JumboFrame?

17

(13 odpowiedzi, napisanych Oprogramowanie / Software)

Cezary napisał/a:

a czasami nie masz ipv6 domyślnie na tym gentoo?

Przecież wireshark pokazywał zapytania i odpowiedzi od i do 10.10.1.20 a to IPv4.

ifconfig daje takie rezultaty:

EdGeeV ~ # ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:1b:fc:4a:17:69  
          inet addr:10.10.1.20  Bcast:10.10.1.255  Mask:255.255.255.0
          inet6 addr: fe80::21b:fcff:fe4a:1769/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
          RX packets:5997 errors:0 dropped:4 overruns:0 frame:0
          TX packets:6356 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3578270 (3.4 MiB)  TX bytes:929819 (908.0 KiB)
          Interrupt:17 

18

(13 odpowiedzi, napisanych Oprogramowanie / Software)

Kolejne odkrycie. Na problematycznym PC uruchomiłem windowsa. O dziwo z windowsa potrafię otworzyć stronę www z NAS'a. Po przełączni do linuxa (Gentoo) problem nadal istnieje. Wygląda więc jak problem w samym Gentoo. Tylko gdzie? I dlaczego z ssh nie ma problemu, a po porcie 80 nie chce działać? Czy jest możliwe aby źle skonfigurowane jądro dawało takie objawy? Sam już nie wiem - takiego dziwnego przypadku jeszcze nie miałem.
Żadnego firewalla na Gentoo nie mam. IPtables jako pakiet nie jest zainstalowane nawet.

19

(13 odpowiedzi, napisanych Oprogramowanie / Software)

rpc napisał/a:

Narysuj schemat sieci jak to wszystko się z czym łączy. Nie musi być ładnie byle zrozumiale

masz retransmisje

TCP Previous segment lost
TCP Dup ACK 6#1

Jak masz to podłączone?. PC2 bezpośrednio do routera ? Zmień kabel/zmień port to na początek
Może coś z kartą sieciową w PC2 ?

Tak to wygląda:

http://i88.photobucket.com/albums/k168/phoenixqaz/siec.jpg

20

(13 odpowiedzi, napisanych Oprogramowanie / Software)

Cezary napisał/a:

lan/wifi jeżeli nie rozdzieliłeś specjalnie jest jednością. Wiec jak coś działa na wifi musi i na lan; na firewallu nie masz nawet jak tego zrobić bo posługujesz się oznaczeniem bridge, nie poszczególnych interfejsów.

Tylko niestety nie posunęło mnie to ani trochę do przodu jeśli chodzi o rozwiązanie problemu, a szczerze powiedziawszy skończyły mi się pomysł gdzie szukać problemu.

21

(13 odpowiedzi, napisanych Oprogramowanie / Software)

Witam,
mam router z OpenWRT i podłączonego do niego m.in:
Dysk Sieciowy (linux)
PC1 (windows) (po WiFi)
PC2 (linux) (ethernet)

Gdy w przeglądarce na PC1 wywołuję dysk sieciowy, nie mam żadnego problemu. Otwiera się interfejs www z dysku sieciowego. Nie jestem natomiast w stanie zrobić tego z PC2. Bez problemu z PC2 mogę zalogować się po SSH do dysku sieciowego, ale w żaden sposób nie chcę mi się załadować interfejs www (standardowo na porcie 80).

Uruchomiłem wireshark'a na PC2 i tak to wygląda przy próbie otwarcia interfejsu www.

No.     Time        Source                Destination           Protocol Info
      1 0.000000    10.10.1.20            10.10.1.10            TCP      35557 > http [SYN] Seq=0 Win=17920 Len=0 MSS=8960 SACK_PERM=1 TSV=45795987 TSER=0 WS=7
      2 0.002939    IcpElect_8b:dc:20     Broadcast             ARP      Who has 10.10.1.20?  Tell 10.10.1.10
      3 0.002946    AsustekC_4a:17:69     IcpElect_8b:dc:20     ARP      10.10.1.20 is at 00:1b:fc:4a:17:69
      4 0.003158    10.10.1.10            10.10.1.20            TCP      http > 35557 [SYN, ACK] Seq=0 Ack=1 Win=17904 Len=0 MSS=8964 SACK_PERM=1 TSV=260029452 TSER=45795987 WS=2
      5 0.003177    10.10.1.20            10.10.1.10            TCP      35557 > http [ACK] Seq=1 Ack=1 Win=17920 Len=0 TSV=45795990 TSER=260029452
      6 0.003275    10.10.1.20            10.10.1.10            HTTP     GET / HTTP/1.1 
      7 0.003511    10.10.1.10            10.10.1.20            TCP      http > 35557 [ACK] Seq=1 Ack=400 Win=17904 Len=0 TSV=260029453 TSER=45795990
      8 2.013568    10.10.1.10            10.10.1.20            TCP      [TCP Previous segment lost] http > 35557 [FIN, ACK] Seq=4124 Ack=400 Win=17904 Len=0 TSV=260029654 TSER=45795990
      9 2.013603    10.10.1.20            10.10.1.10            TCP      [TCP Dup ACK 6#1] 35557 > http [ACK] Seq=400 Ack=1 Win=17920 Len=0 TSV=45798000 TSER=260029453 SLE=4124 SRE=4125
     10 4.909275    10.10.1.20            10.10.1.10            TCP      41341 > http [FIN, ACK] Seq=1 Ack=1 Win=140 Len=0 TSV=45800896 TSER=260005171 SLE=4124 SRE=4125
     11 4.909521    10.10.1.10            10.10.1.20            TCP      http > 41341 [RST] Seq=1 Win=0 Len=0

Podejrzewam, że może firewall na routerze coś blokuje?
Moja konfiguracja firewalla na OpenWRT wygląda następująco:

config 'defaults'
        option 'syn_flood' '1'
        option 'input' 'ACCEPT'
        option 'output' 'ACCEPT'
        option 'forward' 'REJECT'

config 'zone'
        option 'name' 'lan'
        option 'input' 'ACCEPT'
        option 'output' 'ACCEPT'
        option 'forward' 'REJECT'

config 'zone'
        option 'name' 'wan'
        option 'input' 'REJECT'
        option 'output' 'ACCEPT'
        option 'forward' 'REJECT'
        option 'masq' '1'
        option 'mtu_fix' '1'

config 'forwarding'
        option 'src' 'lan'
        option 'dest' 'wan'

config 'rule'
        option 'src' 'wan'
        option 'proto' 'udp'
        option 'dest_port' '68'
        option 'target' 'ACCEPT'
        option 'family' 'ipv4'

config 'rule'
        option 'src' 'wan'
        option 'proto' 'icmp'
        option 'icmp_type' 'echo-request'
        option 'target' 'ACCEPT'

config 'include'
        option 'path' '/etc/firewall.user'

config 'rule'
        option 'name' 'openvpn'
        option 'src' 'wan'
        option 'target' 'ACCEPT'
        option 'proto' 'tcp'
        option 'dest_port' '443'

config 'rule'
        option 'name' 'ssh'
        option 'src' 'wan'
        option 'target' 'ACCEPT'
        option 'proto' 'tcp'
        option 'dest_port' '22'

Nmap na dysku sieciowym pokazuje:

PORT      STATE SERVICE
22/tcp    open  ssh
80/tcp    open  http
111/tcp   open  rpcbind
139/tcp   open  netbios-ssn
443/tcp   open  https
445/tcp   open  microsoft-ds
981/tcp   open  unknown
1000/tcp  open  cadlock
2049/tcp  open  nfs
4000/tcp  open  remoteanything
4001/tcp  open  unknown
8080/tcp  open  http-proxy
9001/tcp  open  tor-orport
9090/tcp  open  zeus-admin
9099/tcp  open  unknown
15000/tcp open  hydap
16000/tcp open  unknown
32769/tcp open  unknown

Nmap na PC2

PORT    STATE SERVICE
22/tcp  open  ssh
111/tcp open  rpcbind

Nmap na routerze

PORT    STATE SERVICE
21/tcp  open  ftp
22/tcp  open  ssh
53/tcp  open  domain
443/tcp open  https
rpc napisał/a:

sprawdzasz smile rozumiem
jest ten sam numer pid przed i po użyciu w/w
czyli dokładnie to co chcesz

Mar 26 17:08:56 pppd[640]: Hangup (SIGHUP)
Mar 26 17:08:56 pppd[640]: Connect time 1225.5 minutes.
Mar 26 17:08:56 pppd[640]: Sent 14624778 bytes, received 165287122 bytes.
Mar 26 17:08:56 pppd[640]: Connection terminated.
Mar 26 17:09:26 pppd[640]: PPP session is 2519
Mar 26 17:09:26 pppd[640]: Using interface pppoe-wan
Mar 26 17:09:26 pppd[640]: Connect: pppoe-wan <--> eth0.2
Mar 26 17:09:27 pppd[640]: PAP authentication succeeded
Mar 26 17:09:27 pppd[640]: peer from calling number 00:90:1A:A3:77:1D authorized
Mar 26 17:09:27 pppd[640]: local  IP address xx.xx.xx.xx
Mar 26 17:09:27 pppd[640]: remote IP address 195.114.190.155
Mar 26 17:09:27 pppd[640]: primary   DNS address 62.233.233.233

Wygląda tak jak powinno. Wielkie dzięki!. Oczywiście Tobie i wszystkim innym zaangażowanym w wątek.

rpc napisał/a:

jak wywalisz demona pppd w powietrze to co nawiąże ci połączenie ?

no, a
kill -s SIGHUP `pidof pppd`
nie kończy procesu?
Myślałem, że po zabiciu pppd będzie automatyczny restart.

(nie jestem u siebie więc na razie nie miałem możliwości potestowania)

rpc napisał/a:

w sumie to można smile

kill -s SIGHUP `pidof pppd`

wywołaj i ciesz się restartem pppd i połączenia. Z tego co widzę reszta działa jak należy

O właśnie. Wczoraj byłem na tropie tego tylko zastanawiam się czy SIGHUP czy może lepiej SIGKILL. Z tego co widzę w dokumentacji SIGHUP powoduje zawieszenie procesu 'Hangup' i jego zakończenie jak przy zerwaniu łączności z terminalem. Czy rozwiązaniem jeszcze prostszym nie byłoby killall pppd?

Cezary napisał/a:

A przeszkadza to Ci w czymś?

Jeżeli nie trzeba muchy zabić armatą bo pod ręką jest bardziej stosowne narzędzie to je wykorzystam. Jeżeli jest jakaś metoda by nie wyłączać interfejsu, a jedynie poinformować grzecznie demona ppp aby zwolnił i nawiązał połączenie ponownie - to jest to prostsza i bardziej elegancka metoda.

No i jeszcze jedno pytanie - jak odnowić wtedy automatycznie ddns?