Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Oprogramowanie / Software → WL500gp + OpenWRT + ADSL przez USB
Strony Poprzednia 1 2 3 4 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
Chyba nie rozwali, bo gdzieś widziałem właśnie taką konfigurację. Z tym, że skrypt, który odpala automatycznie ppp0 przewiduje tylko obsługę pppoe i trzeba by było go zmodyfikować dla pppoa.
Nie nie nie, skrypt napisz sam bo i tak musisz przed załadować moduły firmware i pewnie parę innych rzeczy.
Witaj Cezary,
Wreszcie mogę się zająć routerkiem.
Mam małe ograniczenia z testami. Mianowicie teraz jestem podpięty do netu przez inny router i kiedy przystępuję do testów muszę się rozłączyć z netem, wszystko przepięć, przetestować..... i jak nie działa wszystko spowrotem poprzepinać. Dlatego chciałem się trochę przygotować do uruchomienia połączenia z netem na WL500gp.
Teraz mam ustawione wszystko następująco:
- router z neo (ten obecny) 192.168.2.1 i dla innych kompów to jest brama
- WL500gp 192.168.2.3 (adr. statyczny) - włączony tylko LAN. WAN i WiFi mam wyłączone
- komp z którego konfiguruję WL500gp 192.168.2.6 (adr. statyczny)
Na czas próby WL500gp ustawię jako 192.168.2.1 (oczywiście wyłączając obecny router) - reszta zostanie.
Mam już napisany skrypt rozruchowy do speedtoucha.
Co mam zrobić, tak krok po kroku, żeby sprawnie ustawić połączenie z netem na WL500gp?
Jakich narzędzi używać do debagowania i co sprawdzać?
Jarek
restart wl-500gp. Uruchom skrypcik. Powinien podnieść ppp0 i zestawić połączenie. Jak nie to dopisujesz do skryptu wszystkie zmiany w systemie tak, żeby działało od samego resetu. Później tylko sprawdz czy z 2.6 działa Ci dns i czy możesz pingować coś po tamtej stronie.
Co do narzędzi - standard - route, ping traceroute nslookup.
Przestaw sobie syslog zebyś miał wszysko w logach. A jak będzie działało to wywal ze skryptów debug/kdebug i przestaw na -v1 w pppa3 żeby po logach nie śmieciło.
Ustaw wan_* na ppp0 zeby firewall się dobrze ustawił.
wan_device=eth0 # tu zmiana na: ppp0
wan_vport=4 # ????
wan_proto=none # ????
wan_dhcp_num= # ????
wan_ifnames=vlan1 # zmiana na: ppp0
wandevs=et0
wan_ifname=vlan1 # ????
wan_hostname=OpenWrt
wan_dhcp_start=
wan_dhcp_lease=lan_gateway=192.168.2.1 # zostaje
lan_ifnames=vlan0 eth2 # czy tu nie powinienem dopisać: ppp0
lan_proto=static # zostaje
lan_ipaddr=192.168.2.3 # zmiana na: 192.168.2.1
Sprawdź proszę, czy dobrze myślę. Tam gdzie są ???? nie jestem pewien.
wan_device=eth0 # tu zmiana na: ppp0
wan_ifname=vlan1 # tez na ppp0
lan_ipaddr=192.168.2.3 # zmiana na: 192.168.2.1
Tylko to zmień. wan_ifnames zostaw w spokoju.
Pierwsza próba taka sobie.....
1. Nie chce mi załadować ze skryptu modułu
# insmod ppp_synctty
I w konsekwencji nie odpala pppd. Dopiero (i tylko tak) ręczne załadowanie i odpalenie pppd nawiązuje połączenie.
2. ping odpowiada tylko z adresów 80.11.155.143 i 213.25.2.228. No i oczywiście 192.168.2.6 (laptop)
3. route pokazuje coś takiego:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
213.25.2.228 * 255.255.255.255 UH 0 0 0 ppp0
192.168.2.0 * 255.255.255.0 U 0 0 0 br0
.
. tutaj następuje długie oczekiwanie (kilkadziesiąt sekund)
.
default 192.168.2.1 0.0.0.0 UG 0 0 0 br0
4. nslookup nie odpowiada
5. Skrypt S90neostrada wygląda następująco
#!/bin/sh
#insmod atm # wsadziłem do: /etc/modules.d/90-pppoa
#insmod n_hdlc # wsadziłem do: /etc/modules.d/90-pppoa
#insmod ppp_synctty # również wsadzałem do 90-pppoa, ale też się nie odpalił
# tu dobrze by było sprawdzić czy jest już zamontowany. Nie wiem jak :(
mount -t usbdevfs usbdevfs /proc/bus/usb
# jak sprawdzić czy modem jest podłšczony do USB. Inaczej wywali się modem_run
/usr/local/modem_run -v 1 -m -f /usr/local/KQD6_3.012
# jak sprawdzić czy modem się zsynchronizował. Dobrze by było żeby pppd odpalać tylka przy zsynchronizowanym modemie.
insmod ppp_synctty # próbowałem też i tak, ale to samo. Nie odpala się.
sleep 1
pppd call neostrada-pppoa6. Zmiana
wan_device=eth0 # na: ppp0
wan_ifname=vlan1 # na: ppp0
nic nie daje. I tak, i tak, efekt jest ten sam.
Co o tym sądzisz?
# insmod ppp_synctty
/sbin/insmod ppp_synctty. Zobacz też, czy synctty nie zalezy od czegoś, bo być moze musisz najpierw załadować jakiś inny moduł, żeby włożyć synctty
2. ping odpowiada tylko z adresów 80.11.155.143 i 213.25.2.228. No i oczywiście 192.168.2.6 (laptop)
to dobrze 
3. route pokazuje coś takiego:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
213.25.2.228 * 255.255.255.255 UH 0 0 0 ppp0
192.168.2.0 * 255.255.255.0 U 0 0 0 br0
.
. tutaj następuje długie oczekiwanie (kilkadziesiąt sekund)
.
default 192.168.2.1 0.0.0.0 UG 0 0 0 br04. nslookup nie odpowiada
A to raczej oznacza, ze coś nie tak z dns'ami jest. jak masz ustawione resolv.conf dnsmasq?
zrobiłeś restart dnsmaq po podniesieniu ppp0?
# tu dobrze by było sprawdzić czy jest już zamontowany. Nie wiem jak
mount -t usbdevfs usbdevfs /proc/bus/usb
mount/grep i sprawdzić czy po mount dostaniesz usbdevfs
# jak sprawdzić czy modem jest podłšczony do USB. Inaczej wywali się modem_run
/usr/local/modem_run -v 1 -m -f /usr/local/KQD6_3.012
/usr/local/modem_run -v 1 -m -f /usr/local/KQD6_3.012 > /dev/null 2>&1 ?
# jak sprawdzić czy modem się zsynchronizował. Dobrze by było żeby pppd odpalać tylka przy zsynchronizowanym modemie.
Grep po logach w poszukawianiu tej informacji.
6. Zmiana
wan_device=eth0 # na: ppp0
wan_ifname=vlan1 # na: ppp0
nic nie daje. I tak, i tak, efekt jest ten sam.
Daje tyle, że _po restarcie_ masz skryp firewalla odpowiednio ustawiony na ppp0 a nie eth
3. route pokazuje coś takiego:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
213.25.2.228 * 255.255.255.255 UH 0 0 0 ppp0
192.168.2.0 * 255.255.255.0 U 0 0 0 br0
.
. tutaj następuje długie oczekiwanie (kilkadziesiąt sekund)
.
default 192.168.2.1 0.0.0.0 UG 0 0 0 br04. nslookup nie odpowiada
A to raczej oznacza, ze coś nie tak z dns'ami jest. jak masz ustawione resolv.conf dnsmasq?
zrobiłeś restart dnsmaq po podniesieniu ppp0?
W resolv.conf są wpisane 2 adresy DNS. Używane są teraz do ustawienia DNS dla LAN.
Po podniesieniu ppp0 nie robiłem restartu dnsmaq. Czy tak?
killall dnsmaq
dnsmasq -l /tmp/dhcp.leases -K -F lan,192.168.2.100,1 # (pokazuje w procesach, że tak jest odpalany) albo może odpalić SXXdnsmasq?
A może lepiej było by odpalić skrypt SXXneostrada przed SXXdnsmasq? Nie trze by było restartować dnsmasq.
Tak wygląda kolejność odpalanych procesów:
PID Uid VmSize Stat Command
1 root 356 S init
2 root SW [keventd]
3 root RWN [ksoftirqd_CPU0]
4 root SW [kswapd]
5 root SW [bdflush]
6 root SW [kupdated]
9 root SW [mtdblockd]
69 root SWN [jffs2_gcd_mtd4]
92 root 388 S /bin/sh /etc/init.d/rcS
93 root 344 S logger -s -p 6 -t
96 root 356 S init
98 root 336 S klogd
122 root 340 S /sbin/syslogd -C 16 -m 0
271 root SW [khubd]
381 root SW [usb-storage-0]
382 root SW [scsi_eh_0]
551 root 324 S wifi up
596 root 412 S /usr/sbin/nas -P /var/run/nas.lan.pid -l br0 -H 34954
603 root 392 S /usr/sbin/dropbear
611 root 380 S httpd -p 80 -h /www -r OpenWrt
787 nobody 404 S dnsmasq -l /tmp/dhcp.leases -K -F lan,192.168.2.100,1
793 root 272 S ntpclient -i 86400 -h pool.ntp.org
797 root 364 S /bin/sh /etc/init.d/S90neostrada start
799 root 52 S /usr/local/modem_run -v 1 -m -f /usr/local/KQD6_3.012
800 root 100 S /usr/local/modem_run -v 1 -m -f /usr/local/KQD6_3.012
801 root 100 S /usr/local/modem_run -v 1 -m -f /usr/local/KQD6_3.012
802 root 588 S /usr/sbin/dropbear
803 root 468 S -ash
806 root 328 R psDlaczego modem_run ma aż 3 procesy?
Tak przy okazji.
W jakiej kolejności odpalają się skrypty z /etc/modules.d i /etc/init.d ?
Dlaczego modem_run ma aż 3 procesy?
Tak przy okazji.
W jakiej kolejności odpalają się skrypty z /etc/modules.d i /etc/init.d ?
Wszystko zależy od tego co modem_ru robi i jak jest napisany. Może być 3, czemu nie.
Skrypty są uruchamiane jako /etc/init.d/S* czy wszystko co ma S na początku i w kolejnosci alfabetycznej (czyli w tym przypadku tak jak liczby lecą)
Moduły - tak samo.
Powinieneś zrobić skrypt przed dnsmasq lub,
restart dnsmasq (killall dnsmasq; /etc/init.d/S50dnsmasq start), lub
wpisać samodzielnie nameservery do /tmp/resolv.conf.auto
Najlepiej to pierwsze
Skrypty są uruchamiane jako /etc/init.d/S* czy wszystko co ma S na początku i w kolejnosci alfabetycznej (czyli w tym przypadku tak jak liczby lecą)
Moduły - tak samo.
Jak dobrze rozumiem, to moduły (/etc/modules.d) odpalają się przed skryptami (/etc/init.d). Czy tak?
EDIT:
Jeszcze jedno pytanie.
Jeśli wykonują się skrypty np. S40..... i S50......., to S50 czeka na zakończenie S40?
Jeśli tak, to co się stanie gdy S40 zawiśnie (np. zapętli się)?
Cezary napisał/a:Skrypty są uruchamiane jako /etc/init.d/S* czy wszystko co ma S na początku i w kolejnosci alfabetycznej (czyli w tym przypadku tak jak liczby lecą)
Moduły - tak samo.Jak dobrze rozumiem, to moduły (/etc/modules.d) odpalają się przed skryptami (/etc/init.d). Czy tak??
No akurat moduły laduje S10boot
Jeszcze jedno pytanie.
Jeśli wykonują się skrypty np. S40..... i S50......., to S50 czeka na zakończenie S40?
Jeśli tak, to co się stanie gdy S40 zawiśnie (np. zapętli się)?
Będzie całość wisiała aż S40 się skończy.
Mam już wszystko poustawiane.
Moduł ppp_synctty już się ładuje. Skrypt odpalał się wcześniej niż były ładowane 2 inne potrzebne moduły: slhc i ppp_generic
Nazwę skryptu zmieniłem na S51neostrada. Chciałem, żeby połączenie z netem zestawiało się przed uruchomieniem S52ez-ipupdate i S60dnsmasq. Powinne chyba już mieć dostęp do netu.
Teraz czekam tylko na test. Muszę poczekać do 10, bo pozbawię netu paru sąsiadów . Cóż trzeba się dzielić z bliźnimi
Zaraz po teście zdam relację co się udało osiągnąć
Pozdrawiam Jarek
No to czekamy
Widać wszystko co wartościowe rodzi się w bólach.....
Więc tak. Moduły ładują się prawidłowo. Firmware też. Jest synchro modemu.
Kiedy startuje pppd (dałem sllep 15 pomiędzy ładowaniem firmware i pppd) wywala jakiś błąd. Coś z LCP
Jan 1 00:00:59 (none) user.info : Info ADSL line is up (2496 kbit/s down | 320 kbit/s up)
# tu przerwa 15 sekund (dla pewności)
Jan 1 00:01:14 (none) kern.notice pppd[712]: pppd 2.4.3 started by root, uid 0
Jan 1 00:01:15 (none) kern.debug pppd[712]: using channel 1
Jan 1 00:01:15 (none) kern.info pppd[712]: Using interface ppp0
Jan 1 00:01:15 (none) kern.notice pppd[712]: Connect: ppp0 <--> /dev/pts/1
Jan 1 00:01:15 (none) kern.debug pppd[712]: rcvd [LCP EchoReq id=0x67 magic=0x581210e4]
Jan 1 00:01:15 (none) kern.debug pppd[712]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xa6ce3082> <pcomp> <accomp>]
Jan 1 00:01:15 (none) kern.debug pppd[712]: rcvd [LCP ConfReq id=0x68 <auth chap MD5> <magic 0x599f6116>]
Jan 1 00:01:15 (none) kern.debug pppd[712]: sent [LCP ConfAck id=0x68 <auth chap MD5> <magic 0x599f6116>]
Jan 1 00:01:15 (none) kern.debug pppd[712]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xa6ce3082> <pcomp> <accomp>]
Jan 1 00:01:15 (none) kern.debug pppd[712]: sent [LCP EchoReq id=0x0 magic=0xa6ce3082]
Jan 1 00:01:15 (none) kern.debug pppd[712]: rcvd [LCP TermReq id=0x69]
Jan 1 00:01:15 (none) kern.info pppd[712]: LCP terminated by peer
Jan 1 00:01:15 (none) kern.debug pppd[712]: sent [LCP TermAck id=0x69]
Jan 1 01:01:18 (none) kern.notice pppd[712]: Connection terminated.
Jan 1 01:01:18 (none) kern.notice pppd[712]: Modem hangupMuszę porównać z logami kiedy ładuje sie prawidłowo, może coś namierzę.
Skoro tak się działo to:
Zabiłem pppd, dnsmasq i zacząłem ładować z palca. pppd poszedł cacy, a po nim S60dnsmasq - tek OK.
Log wygląda tak:
Jan 1 01:05:00 (none) kern.notice pppd[1393]: pppd 2.4.3 started by root, uid 0
Jan 1 01:05:00 (none) kern.debug pppd[1393]: using channel 26
Jan 1 01:05:00 (none) kern.info pppd[1393]: Using interface ppp0
Jan 1 01:05:00 (none) kern.notice pppd[1393]: Connect: ppp0 <--> /dev/pts/1
Jan 1 01:05:01 (none) kern.debug pppd[1393]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3b58430> <pcomp> <accomp>]
Jan 1 01:05:05 (none) kern.debug pppd[1393]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3b58430> <pcomp> <accomp>]
Jan 1 01:05:05 (none) kern.debug pppd[1393]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x3b58430> <pcomp> <accomp>]
Jan 1 01:05:06 (none) kern.debug pppd[1393]: rcvd [LCP ConfReq id=0xeb <auth chap MD5> <magic 0x53586aa6>]
Jan 1 01:05:06 (none) kern.debug pppd[1393]: sent [LCP ConfAck id=0xeb <auth chap MD5> <magic 0x53586aa6>]
Jan 1 01:05:06 (none) kern.debug pppd[1393]: sent [LCP EchoReq id=0x0 magic=0x3b58430]
Jan 1 01:05:06 (none) kern.debug pppd[1393]: rcvd [CHAP Challenge id=0xd7 <59b09c574fa553a273d73117f9925c0fca7ead9dbd2cae25b70ea8fd452c>, name = "rze_ru1"]
Jan 1 01:05:06 (none) kern.debug pppd[1393]: sent [CHAP Response id=0xd7 <bc68525c39f9d8add22f584c748fbc85>, name = "XXXXXXX@neostrada.pl"]
Jan 1 01:05:06 (none) kern.debug pppd[1393]: rcvd [LCP EchoRep id=0x0 magic=0x53586aa6]
Jan 1 01:05:06 (none) kern.debug pppd[1393]: rcvd [CHAP Success id=0xd7 ""]
Jan 1 01:05:06 (none) kern.info pppd[1393]: CHAP authentication succeeded
Jan 1 01:05:06 (none) kern.notice pppd[1393]: CHAP authentication succeeded
Jan 1 01:05:06 (none) kern.debug pppd[1393]: sent [CCP ConfReq id=0x1 <mppe -H -M -S -L -D +C>]
Jan 1 01:05:06 (none) kern.debug pppd[1393]: sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
Jan 1 01:05:06 (none) kern.debug pppd[1393]: rcvd [LCP ProtRej id=0xec 80 fd 01 01 00 0a 12 06 00 00 00 01]
Jan 1 01:05:06 (none) kern.debug pppd[1393]: rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
Jan 1 01:05:06 (none) kern.debug pppd[1393]: sent [IPCP ConfReq id=0x2 <addr 0.0.0.0>]
Jan 1 01:05:06 (none) kern.debug pppd[1393]: rcvd [IPCP ConfNak id=0x2 <addr 83.11.151.34>]
Jan 1 01:05:06 (none) kern.debug pppd[1393]: sent [IPCP ConfReq id=0x3 <addr 83.11.151.34>]
Jan 1 01:05:06 (none) kern.debug pppd[1393]: rcvd [IPCP ConfAck id=0x3 <addr 83.11.151.34>]
Jan 1 01:05:06 (none) kern.debug pppd[1393]: rcvd [IPCP ConfReq id=0x95 <addr 213.25.2.228>]
Jan 1 01:05:06 (none) kern.debug pppd[1393]: sent [IPCP ConfAck id=0x95 <addr 213.25.2.228>]
Jan 1 01:05:06 (none) kern.err pppd[1393]: not replacing default route to br0 [192.168.2.1]
Jan 1 01:05:06 (none) kern.notice pppd[1393]: local IP address 83.11.151.34
Jan 1 01:05:06 (none) kern.notice pppd[1393]: remote IP address 213.25.2.228
Jan 1 01:05:06 (none) kern.debug pppd[1393]: Script /etc/ppp/ip-up started (pid 1409)
Jan 1 01:05:06 (none) kern.debug pppd[1393]: Script /etc/ppp/ip-up finished (pid 1409), status = 0x1
Jan 1 01:05:42 (none) kern.info dnsmasq[1495]: started, version 2.35 cachesize 150
Jan 1 01:05:42 (none) kern.info dnsmasq[1495]: compile time options: IPv6 GNU-getopt ISC-leasefile no-DBus no-I18N
Jan 1 01:05:42 (none) kern.info dnsmasq[1495]: DHCP, IP range 192.168.2.100 -- 192.168.2.249, lease time 12h
Jan 1 01:05:42 (none) kern.info dnsmasq[1495]: using local addresses only for domain lan
Jan 1 01:05:42 (none) kern.info dnsmasq[1495]: reading /tmp/resolv.conf.auto
Jan 1 01:05:42 (none) kern.info dnsmasq[1495]: using nameserver 217.98.63.164#53
Jan 1 01:05:42 (none) kern.info dnsmasq[1495]: using nameserver 194.204.152.34#53
Jan 1 01:05:42 (none) kern.info dnsmasq[1495]: using local addresses only for domain lan
Jan 1 01:05:42 (none) kern.info dnsmasq[1495]: read /etc/hosts - 1 addresses
Jan 1 01:05:42 (none) kern.info dnsmasq[1495]: read /etc/ethers - 0 addressesW tym logu nie podoba mi się:
Jan 1 01:05:06 (none) kern.err pppd[1393]: not replacing default route to br0 [192.168.2.1]
Jak go zmusić żeby zmienił zdanie?
i jeszcze
Jan 1 01:05:42 (none) kern.info dnsmasq[1495]: using local addresses only for domain lan
Jan 1 01:05:42 (none) kern.info dnsmasq[1495]: reading /tmp/resolv.conf.auto
Jan 1 01:05:42 (none) kern.info dnsmasq[1495]: using nameserver 217.98.63.164#53
Jan 1 01:05:42 (none) kern.info dnsmasq[1495]: using nameserver 194.204.152.34#53
Jan 1 01:05:42 (none) kern.info dnsmasq[1495]: using local addresses only for domain lan
mowa, że adres tylko dla LAN. Czy tak ma być?
Masz jakiś pomysł?
EDIT:
Zapomniałem.........
Pingi i route takie jak wczoraj. Czyli źle ustawione DNS, czy maże nie spięte ppp0 z br0?
Nie zmienia Ci domyślnej trasy bo już ja masz. Wywal ją przed odpaleniem ppp (route del default gw 192.168.2.1), wtedy powinien założyć trasę domyślna na ppp0.
Co do dnsmasq - tak powinno być. Za pierwszym razem zobacz że nie ma nic o autoryzacji - może Cię po prostu wywaliło z neo.
Witaj
Połączenie roszło. Pomogło (route del default gw 192.168.2.1) przed pppd. Pinguje różne ip. DNS też prawidłowo działa. Z kompa też wygląda, że jest wszystko OK. Właśnie piszę wiadoność na neo z WL500gp.
Został tylko problem pierwszego (automatycznego) odpalenia pppd. Znów jest ten sam problem z LPC
Jan 1 00:01:16 (none) kern.debug pppd[713]: Discarded non-LCP packet when LCP not open
Co ciekawe w pliku z logami od pppd nic na ten temat nie ma. Porównując z logami, które są po poprawnym załadowaniu pppd, wygląda jak by modem miał już coś wcześniej wysłane i wysłanie danych do niego zwraca jakieś błędy.
Jak by to sprawdzić?
Wszystko co jest googlach odnosi się do mppe i problemów z autoryzacją. Ale u Ciebie nie ma tunelu przez pptp 
Może brzydki hack: połącz się, odczekaj z 5 sekund, rozłącz i połącz ponownie. Lub jakaś magiczna opcja do pierwszego resetu modemu.
Porównując logi z błędnego (automatycznego) odpalenia pppd i paprawnego (ręcznego) wygląda na to, że w modemie są jakieś śmieci.
Automatyczne (błędne) ładowanie pppd:
Jan 1 00:01:15 (none) kern.notice pppd[717]: pppd 2.4.3 started by root, uid 0
Jan 1 00:01:15 (none) kern.debug pppd[717]: using channel 1
Jan 1 00:01:15 (none) kern.info pppd[717]: Using interface ppp0
Jan 1 00:01:15 (none) kern.notice pppd[717]: Connect: ppp0 <--> /dev/pts/1
Jan 1 00:01:15 (none) kern.debug pppd[717]: rcvd [LCP EchoReq id=0x14 magic=0x4792590d]
Jan 1 00:01:15 (none) kern.debug pppd[717]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xae5834a0> <pcomp> <accomp>]
Jan 1 00:01:16 (none) kern.debug pppd[717]: rcvd [LCP ConfReq id=0x15 <auth chap MD5> <magic 0x2557e3b3>]
Jan 1 00:01:16 (none) kern.debug pppd[717]: sent [LCP ConfAck id=0x15 <auth chap MD5> <magic 0x2557e3b3>]
Jan 1 00:01:16 (none) kern.debug pppd[717]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xae5834a0> <pcomp> <accomp>]
Jan 1 00:01:16 (none) kern.debug pppd[717]: sent [LCP EchoReq id=0x0 magic=0xae5834a0]
Jan 1 00:01:16 (none) kern.debug pppd[717]: rcvd [LCP TermReq id=0x16]
Jan 1 00:01:16 (none) kern.info pppd[717]: LCP terminated by peer
Jan 1 00:01:16 (none) kern.debug pppd[717]: sent [LCP TermAck id=0x16]I prawidłowe (ręczne) ładowanie pppd:
Jan 1 01:02:20 (none) kern.notice pppd[1013]: pppd 2.4.3 started by root, uid 0
Jan 1 01:02:20 (none) kern.debug pppd[1013]: using channel 7
Jan 1 01:02:20 (none) kern.info pppd[1013]: Using interface ppp0
Jan 1 01:02:20 (none) kern.notice pppd[1013]: Connect: ppp0 <--> /dev/pts/1
Jan 1 01:02:21 (none) kern.debug pppd[1013]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x25c393f2> <pcomp> <accomp>]
Jan 1 01:02:23 (none) kern.debug pppd[1013]: rcvd [LCP ConfReq id=0x70 <auth chap MD5> <magic 0x283ca3da>]
Jan 1 01:02:23 (none) kern.debug pppd[1013]: sent [LCP ConfAck id=0x70 <auth chap MD5> <magic 0x283ca3da>]
Jan 1 01:02:24 (none) kern.debug pppd[1013]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x25c393f2> <pcomp> <accomp>]
Jan 1 01:02:24 (none) kern.debug pppd[1013]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x25c393f2> <pcomp> <accomp>]
Jan 1 01:02:24 (none) kern.debug pppd[1013]: sent [LCP EchoReq id=0x0 magic=0x25c393f2]
Jan 1 01:02:24 (none) kern.debug pppd[1013]: rcvd [CHAP Challenge id=0xa9 <76bba1f1c76eccf907bde857d5b91dae6c2282e6c752319185cea699967a>, name = "rze_ru1"]sekwencja przesyłania danych z LCP rozpoczyna się w pierwszym (auto) od:
Jan 1 00:01:15 (none) kern.debug pppd[717]: rcvd [LCP EchoReq id=0x14 magic=0x4792590d]
jak widać '...rcvd [LCP EchoReq...' mówi że jest to odbierane Echo z modemu. Potem dopiero następuje wysyłanie danych do modemu i odbieranie.
W logu z rozruchu ręcznego (działającego) sekwencja z LCP rozpoczyna się od wysłania '...sent [LCP ConfReq..." danych i dopiero potem odebrania.
Podsumowując w logu błednym (auto) sekwencje LCP zaczynają się od odczytu danych (echo), a dopiero kolejne są podobne jak w logu prawidłowym (ręcznym).
Myślę że trzeba będzie zrobić, tak jak pisałeś, zastosować sztuczkę:
pppd call neostrada-pppoa
sleep 1
killall pppd
pppd call neostrada-pppoa
Chyba, że udało by się wyczyścić bufor modemu, albo zresetować. Ale jak?
Nie wiem czy jest możliwość programowego resetu modemu. Chyba że modem_run przed załadowaniem firmware co takiego umożliwia, ale raczej nie spodziewał bym się . Zobacz czy restart ppp Ci pomoże.
OK. Ale dopiero wieczorem, kiedy wrócę z pracy 
Pozdrawiam Jarek
Jeszcze jedno pytanie.
Czy w logu route nie powinien się znaleźć wpis dotyczący interface lo (Local Loopback) z IP 127.0.0.1 ? Coś w stylu
# the route to the loop back device
127.0.0.1 * 255.0.0.0 U 3584 0 483 lo
A co daje przełącznik -n w route?
co do lo - nie ma w openwrt takiej potrzeby. -n nie zamienia liczb w dns, czyli całość masz numerycznie.
Witaj Cezary
Cwilę mnie nie było. Mam ostatnio zatrzęsienie terminowej roboty......... Ale do rzeczy.
Sztuczka zadziałała i skrypcik automatycznie zestawia całe połącznie W tym miejscu GORĄCE PODZIĘKOWANIA za Twoją cierpliwość dla mojej osoby.
Chcę jeszcze podszlifować wszystkie ustawienia i zabieram się za HOWTO Coś dla potomności......
Pozdrawiam Jarek
PS. W razie pytań pozawracam Ci jeszcze trochę głowę.
Super. Ważne, że działa.
Strony Poprzednia 1 2 3 4 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
eko.one.pl → Oprogramowanie / Software → WL500gp + OpenWRT + ADSL przez USB
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc