Keresés

talaltam egy hasonlo problemat ha neki tudtok segiteni az nekem is jo, ig nekem nem kell kivagdalni a maszazsbol...

http://mlf.linux.rulez.org/Archivum/linux-199909/msg00012.html

valaki letudna nekem irni hogy ha analog modemmemel aka rok hivast fogadnoi
akkor mi mindent kell bealitani pontrol pontra mert en mar elvesztettem a
fonalat a faqkban egyellore addig jutot a modem, hogy az autentikacio lemegy majd nem tud TCPIPt felepiteni
amugy a pntrol pontra leiras szerintem masnak is jol jonne ( ha lehet a kor a folyamattal egyutt, ki kit hiv milyen esemeny eseten...)

es mia helyzet ha isdn...
a z isdn dial on demandba megy kifele...
i4l hiSAX winbond kartya ippp0 pingeti a tavoli halozatot ( csak az elso ket csomag tunik el a sulyesztoben)..

befele ...
kernel: isdn_net: dial ignored
kernel :isdn_tty dial ignored

mit hagytam ki ? sejti valaki ( egyszer mar ment a csak nem tudom mitol, mintha nem hivodna meg az ippp??? )

atyakukac,

kössz a törődést, de ez a problema régen megoldódott. Ha default router (ISDN) kikapcs, akkor tud ppp default lenni és minden OK. Nem érdekes, hogy analog vagy ISDN, csak egyszerre a kettő nem lehet, miután 1 account van.
Mégeccer kössz! :-))

ugyanazzal a acountal megy a ruter ISDN mint az aanalóg. merth a igen akkor necsodálkozz a Ma$ vagy itt vagy ott fogadja a hivaast (tudtommall)

Szerintem a "/etc/hosts" file-ból a pingvines sort törölni kéne,mert amikor a default route-tot keresi, a saját gépedet találja annak. ami teljesen korrekt, leven, hogy a gepnek nincs allando IP cime, hanem a WAN interfesz feleledesekor kapja azt meg. Amig nem el a ppp addig a default route a localhostra mutat. Abban tok igazad van, hogy foloslesges, csupancsak szepeszeti celokat szolgal. Arra jo, hogyha offline vagy es mondjuk fut rajtad az apacs, akkor beirhatod, hogy http://pingvin/ es nem kell a http://localhost/ format hasznalnod, de hasonloan hasznalhatod X display leironak a pingvin:0-t.

Mukodik!!!Zseni vagy!
Nagyon koszonom a segitseged.Es koszonom mindenkinek
kik tanacsaikkal a helyes utat megmutattak.

/etc.resolv.conf:

search .

maneserver 145.236.224.248 

nameserver 145.236.224.249

/etch/hosts:

127.0.0.1	localhost

0.0.0.0		pingvin

/etc/hosts.allow:

ALL: LOCAL

/etc/hosts.deny:

ALL: ALL

/etc/hostname:

pingvin                                                                                                      

nandi,

nincs beállítva default router még a ppp előtt? Ha van akkor azt lődd le mielőtt tárcsázni kezdel.
(/sbin/route del default)

Szolgáltatói névszerver (145.236.224.248 és 145.236.224.249) be van állítva?

Üdv:
dj

Kitöltöttem a két fájlt az útmutatásodnak megfelelően.A kapcsolat így már nem szakad meg,
viszont sem a netscape sem a ping nem látja a hálózatot.Mit kell még beállítani?
A log fájlom:
Mar 1 01:16:39 pingvin kernel: CSLIP: code copyright 1989 Regents of the University of California
Mar 1 01:16:40 pingvin kernel: PPP: version 2.2.0 (dynamic channel allocation)
Mar 1 01:16:40 pingvin kernel: PPP Dynamic channel allocation code copyright 1995 Caldera, Inc.
Mar 1 01:16:40 pingvin kernel: PPP line discipline registered.
Mar 1 01:16:40 pingvin kernel: registered device ppp0
Mar 1 01:16:43 pingvin pppd[250]: pppd 2.2.0 started by root, uid 0
Mar 1 01:16:43 pingvin pppd[250]: Using interface ppp0
Mar 1 01:16:43 pingvin pppd[250]: Connect: ppp0 < /dev/modem
Mar 1 01:16:43 pingvin pppd[250]: sent [LCP ConfReq id=0x1
]
Mar 1 01:16:43 pingvin pppd[250]: rcvd [LCP ConfReq id=0x2e
]
Mar 1 01:16:43 pingvin pppd[250]: sent [LCP ConfAck id=0x2e
]
Mar 1 01:16:43 pingvin pppd[250]: rcvd [LCP ConfAck id=0x1
]
Mar 1 01:16:43 pingvin pppd[250]: sent [PAP AuthReq id=0x1 user="nandor" password="jelszo"]
Mar 1 01:16:44 pingvin pppd[250]: rcvd [PAP AuthAck id=0x1msg=""]
Mar 1 01:16:44 pingvin pppd[250]: Remote message:
Mar 1 01:16:44 pingvin pppd[250]: sent [IPCP ConfReq id=0x1 ]
Mar 1 01:16:44 pingvin pppd[250]: sent [IPXCP ConfReq id=0x1 ]
Mar 1 01:16:44 pingvin pppd[250]: rcvd [LCP ProtRej id=0x2f 80 2b 01 01 00 18 01 06 00 00 00 00 02 08 00 00 0d 34 2b 09 04
04 00 02 06 02]
Mar 1 01:16:44 pingvin pppd[250]: rcvd [IPCP ConfReq id=0x87 ]
Mar 1 01:16:44 pingvin pppd[250]: sent [IPCP ConfAck id=0x87 ]
Mar 1 01:16:46 pingvin pppd[250]: rcvd [IPCP ConfReq id=0x88 ]
Mar 1 01:16:46 pingvin pppd[250]: sent [IPCP ConfAck id=0x88 ]
Mar 1 01:16:47 pingvin pppd[250]: sent [IPCP ConfReq id=0x1 ]
Mar 1 01:16:47 pingvin pppd[250]: rcvd [IPCP ConfNak id=0x1 ]
Mar 1 01:16:47 pingvin pppd[250]: sent [IPCP ConfReq id=0x2 ]
Mar 1 01:16:48 pingvin pppd[250]: rcvd [IPCP ConfAck id=0x2 ]
Mar 1 01:16:48 pingvin pppd[250]: local IP address 145.236.208.159
Mar 1 01:16:48 pingvin pppd[250]: remote IP address 145.236.208.1
Mar 1 01:21:22 pingvin pppd[250]: Terminating on signal 15.
Mar 1 01:21:22 pingvin pppd[250]: sent [LCP TermReq id=0x2]
Mar 1 01:21:22 pingvin pppd[250]: rcvd [LCP TermAck id=0x2]
Mar 1 01:21:22 pingvin pppd[250]: Connection terminated.
Mar 1 01:21:22 pingvin pppd[250]: Exit.
Mar 1 01:22:39 pingvin kernel: PPP: ppp line discipline successfully unregistered

Naszal a pap/chap secret file igy nézzen ki:

[client(account)]    [server(acoount)]    [secret]  [server IP] 

nandoraccount        matavnet             jelszo     *

matavnet             nandoraccount        jelszo     *

A masodik sor akkor kell, ha calback-kal megy, ha ott van, nemsok vizet zavar. Az IP-t vagy beirod vagy don't care "*"

nandi,

vigyázz, hogy a jelszóban ne legyenek "érdekes" karakterek, pl. @&!# ezeket nem kedveli elküldeni a kppp no és a többi ppp-t használó progi se.

Üdv:
dj

Kezd alakulni, már csak hibás jelszó üzenetet kapok.Lehet hogy hülyeséget írtam a fájlokba?
chap secret file:
user nandoraccount
remotename matavnet
pap secret file:
######client server secret 145.236.224.243
nandoraccount matavnet jelszo

Feb 25 00:06:04 pingvin pppd[226]: Connect: ppp0 < /dev/modem
Feb 25 00:06:04 pingvin pppd[226]: sent [LCP ConfReq id=0x1
]
Feb 25 00:06:06 pingvin pppd[226]: rcvd [LCP ConfReq id=0x73
]
Feb 25 00:06:06 pingvin pppd[226]: sent [LCP ConfAck id=0x73
]
Feb 25 00:06:07 pingvin pppd[226]: sent [LCP ConfReq id=0x1
]
Feb 25 00:06:07 pingvin pppd[226]: rcvd [LCP ConfReq id=0x74
]
Feb 25 00:06:07 pingvin pppd[226]: sent [LCP ConfAck id=0x74
]
Feb 25 00:06:07 pingvin pppd[226]: rcvd [LCP ConfAck id=0x1
]
Feb 25 00:06:07 pingvin pppd[226]: sent [PAP AuthReq id=0x1 user="nandor" password="jelszo"]
Feb 25 00:06:07 pingvin pppd[226]: rcvd [PAP AuthNak id=0x1msg="Password validation failure"]
Feb 25 00:06:07 pingvin pppd[226]: Remote message: Password validation failure
Feb 25 00:06:07 pingvin pppd[226]: PAP authentication failed
Feb 25 00:06:07 pingvin pppd[226]: rcvd [LCP TermReq id=0x75]
Feb 25 00:06:07 pingvin pppd[226]: LCP terminated at peer's request
Feb 25 00:06:07 pingvin pppd[226]: sent [LCP TermAck id=0x75]
Feb 25 00:06:08 pingvin pppd[226]: Modem hangup
Feb 25 00:06:08 pingvin pppd[226]: Connection terminated.
Feb 25 00:06:08 pingvin pppd[226]: Exit.

Kezd alakulni, már csak hibás jelszó üzenetet kapok.Lehet hogy hülyeséget írtam a fájlokba?
chap secret file:
user nandoraccount
remotename matavnet
pap secret file:
######client server secret 145.236.224.243
nandoraccount matavnet jelszo

Feb 25 00:06:04 pingvin pppd[226]: Connect: ppp0 < /dev/modem
Feb 25 00:06:04 pingvin pppd[226]: sent [LCP ConfReq id=0x1
]
Feb 25 00:06:06 pingvin pppd[226]: rcvd [LCP ConfReq id=0x73
]
Feb 25 00:06:06 pingvin pppd[226]: sent [LCP ConfAck id=0x73
]
Feb 25 00:06:07 pingvin pppd[226]: sent [LCP ConfReq id=0x1
]
Feb 25 00:06:07 pingvin pppd[226]: rcvd [LCP ConfReq id=0x74
]
Feb 25 00:06:07 pingvin pppd[226]: sent [LCP ConfAck id=0x74
]
Feb 25 00:06:07 pingvin pppd[226]: rcvd [LCP ConfAck id=0x1
]
Feb 25 00:06:07 pingvin pppd[226]: sent [PAP AuthReq id=0x1 user="nandor" password="aC1n8iA"]
Feb 25 00:06:07 pingvin pppd[226]: rcvd [PAP AuthNak id=0x1msg="Password validation failure"]
Feb 25 00:06:07 pingvin pppd[226]: Remote message: Password validation failure
Feb 25 00:06:07 pingvin pppd[226]: PAP authentication failed
Feb 25 00:06:07 pingvin pppd[226]: rcvd [LCP TermReq id=0x75]
Feb 25 00:06:07 pingvin pppd[226]: LCP terminated at peer's request
Feb 25 00:06:07 pingvin pppd[226]: sent [LCP TermAck id=0x75]
Feb 25 00:06:08 pingvin pppd[226]: Modem hangup
Feb 25 00:06:08 pingvin pppd[226]: Connection terminated.
Feb 25 00:06:08 pingvin pppd[226]: Exit.

Sziasztok!

Én is a Kpp-t gyötröm, de sikertelenül A
chipben februári számában lévő script példát is kipróbáltam valamint az általatok leírtakat.A következőt tapasztaltam.Csak a terminál ablakos bejelentkezésnél nem írta, hogy meghalt a démon.Ott viszont nem történt semmi mind addig, mig elnem kezdetem gépelni a logint majd entert nyomva átugorta a jelszót és acess denied.Matávnetről van szó, a felhasználó név előti soremelés sem vált be, akkor meg a felhasználó név elé írta be a jelszót és
szintén kizárt, a chipes példánál meg timout-ot
írt, mielőtt el kezdtem volna gépelni, mivel ez a script sem csinált semmit perceken át míg el nem kezdtem gépelni.Fogalmam sincs mi a teendő.Segítsetek!
Ja és itt van a logfájlom:

Feb 23 22:20:24 pingvin squid[133]: Starting Squid Cache version 1.NOVM.21 for i686-pc-linux-gnu...
Feb 23 22:20:26 pingvin squid[133]: Ready to serve requests.
Feb 23 22:23:32 pingvin kernel: CSLIP: code copyright 1989 Regents of the University of California
Feb 23 22:23:32 pingvin syslog: Exit.
Feb 23 22:23:33 pingvin kernel: PPP: version 2.2.0 (dynamic channel allocation)
Feb 23 22:23:33 pingvin kernel: PPP Dynamic channel allocation code copyright 1995 Caldera, Inc.
Feb 23 22:23:33 pingvin kernel: PPP line discipline registered.
Feb 23 22:24:31 pingvin kernel: PPP: ppp line discipline successfully unregistered
Feb 23 22:44:10 pingvin syslog: Exit.

És ezt ismétli több oldalon át.

Kistel kössz!

Előbb utóbb utánanéztem volna :-))

Üdv:
dj

TaXiN: a SLIP általában nem kell, de pl. a diald-hez igen. Ha azt nem használod, akkor felejtsd el a SLIP-et is, nem kell neked.

(dj: A 10.* tényleg intranetes cím. Csak.)

cancel:
CONFIG_DUMMY
This is essentially a bit-bucket device (i.e. traffic you send to this device is consigned into oblivion) with a configurable IP address. It is most commonly used in order to make your currently inactive SLIP address seem like a real address for local programs. If you use SLIP or PPP, you might want to enable it.
(oblivion = feledés)

CONFIG_INET
These are the protocols used on the Internet and on most local Ethernets. The safest is to say Y here (which will enlarge your kernel by about 35 kB), since some programs (e.g. the X window system) use TCP/IP even if your machine is not connected to any other computer. You will get the so-called loopback device which allows you to ping yourself (great fun, that!).

Bővebb információk a kernel configban :-)

Üdv,
Kistel

Sziasztok!

A rendes intranet címet azért kell beállítani, hogy még véletlenül se jusson ki a belső cím az internetre (nem tom, hogy a 10 kezdetű az fenntartott-e vagy sem). Ha fenntartott intranet címet (pl. 192.168.1.0) adsz a hálódnak akkor biztosan nem kavarodsz össze senkivel, azért találták ki.
Mint a mellékelt ábra is mutatja a dummy nem kellett, de ha maradt volna is és megvonta volna tőle default kimenetet akkor az eredmény ugyan ez lett volna. De ez már a múlt :-))

Üdv:
dj

cancel: Örök hálám üldözni fog a linux bugyraiban is.

Kikapcsoltam a dummy0-t és láss csodát.

Tényleg nagyon köszönöm a segítséget, már teljesen reménytelen voltam.

TaXiN: azért adtam az eth0-nak a 10.0.0.1 címet, mert nálunk a cégnél, hála az MS Backoffice-nak ez terjedt el. Na ezt akarom lecserélni (mármint az MS cuccost) egy linux szerverre, csak előbb otthon kísérletezem egy kicsit. Mégsem élesben kéne.

Köszi mindent, Traxy.

OFF: Szia cancel !

[Csak ugy beallitani egy IP cimet, pedig nem tudom mennyivel
jobb mint mondjuk a 10.0.0.1, "igazi" IP cimmel]

???????

10.0.0.0-10.255.255.255
192.168.0.0-192.168.255.255

is intranet cim. Tkp mindegy, de kis halozatokhoz a 192.168.x.x - et _illik_ valasztani.

[itt kikapcsolni az eth0-t a legegyszerubb.]

Nagyon igaz.

ON:

[ppp]# /sbin/route -n

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

192.168.0.2 0.0.0.0 255.255.255.255 UH 1 0 2 sl0

192.168.1.0 192.168.2.1 255.255.255.0 UG 0 0 24 eth1

Ez a 2. belso halo. Mivel a ppp-nek kell lennie a default-nak. Azaz a 0.0.0.0-nak.
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 1 eth1

127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 7 lo

0.0.0.0 0.0.0.0 0.0.0.0 UG 0 0 58 sl0

Melyik SuSE ? Nem mintha szamitana. Az epitsunk szervert-ben van egy osszefoglalo. Tudom nem itt, hanem a kezdoben kellene megkerdeznem, de mi a szosz az a dummy (tudom - valami ami nem valodi, csak makett - lasd gyalog galopp) - man pppd -ben nincs rola, illetve bele kell ferditeni a kernelbe egy net eszkoz ppp-hez, es slip-hez. Kell ez ? Vagy csak valami maradvany mint a minix file rendszer - van, de inkabb ne hasznaljuk ?

Hello dj!

en ugy sok ertelmet a dummynak nem latom, nalam jol elvan egy linuxos gep ethernet kartyaval, ppp-vel dummy nelkul.

Csak ugy beallitani egy IP cimet, pedig nem tudom mennyivel jobb mint mondjuk a 10.0.0.1, "igazi" IP cimmel meg nagyobb az esely, hogy osszekavarodjon valakivel.
(Jo hat nem tul nagy persze, de azert annak az IP cimnek megis megvan a jogos tulajdonosa.)
Meg kulonben is jobb az egyszerubb feladatot megoldani elobb es utana bonyolitani, marpedig itt kikapcsolni az eth0-t a legegyszerubb.

---

ping

Traxy!
A pingelesrol most az jutott eszembe, hogy elvileg a
tavoli IP cimre elmentek a csomagok a routing tabla alapjan,
(mellesleg ugy tunt, hogy ez az egyetlen kulso cim amit a gep el tudodd erni), viszont igen valoszinu, hogy az csak egy buta kis terminalserver, aki nem "erti" a ping uzeneteket, ezert nem valaszolt.

Vagyis ha a ping nem jon ossze nem biztos, hogy halozati problema van, lehet, hogy csak a tulso gep nem valaszol.

cancel

Hello fiúk!

Bocsika 1. nekifutásra elég lenne beállítani egy rendes intranet címet (pl. 192.168.1.11) és törölni a route tábla default sorát: route del default
Aztán mehet a csatlakozás. Ugyanis ha már van default kimenet akkor a pppd nem tudja létrehozni a sajátját. (Több heti küzdelem volt nálam is eleinte) Hogy minek a dummy azt nemtom, de ha kell hát kell :-)) (Ha mégsem akkor érdemes lelőni)

Üdv:
dj

Hello Traxy!

Eloszor is az egyertelmu kovetkeztetesek:

• az ifconfig kimeneteben nincs 'ppp0' interface, a
  route-nal mar viszont van. Ez azt jelenti, hogy tul hamar adtad ki az ifconfig parancsot addigra meg nem sikerult a 'ppp0'
  interfacet a ppp daemonnak bakapcsolnia, de kesobb sikerult.
  

  Igy most nem tudjuk, hogy mi ennek az interfacenek az IP cime, es mi a szemkozti gep IP cime, bar ezen utobbi talan kiderul a route -n bol.
  

  IP cime ugyanis nem szamitogepnek, hanem halozati Interfacenek van. Igy egy olyan gep, melyben ethernet,
  es ppp (es termeszetesen loopback azaz kamu) interface is van 3 kulonbozo IP cimmel rendelkezik.
  (Vannak picit bonyolultabb esetek is)
  

• Aztan jol osszekuszalodott a route parancsok kimenete, eredetileg szepen tabulalt volt.
  

• A dummy0 interface az nem tudom, hogy honnan kerult oda, sok szukseg nincs ra es meg jol megkavarja a routing tablat is.
  

  (talan ifconfig paranccsal ki lehetne kapcsolni, hogy legalabb vizualisan ne zavarjon ifconfig dummy0 down, vagy valami ilyesmi.)
  

---

Aztan a kicsit bonyolultabb osszefuggesek:
Az ethernet kartya IP cime 10.0.0.1
Ez a cim egy olyan cimtartomanybol van amit arra talaltak ki, hogy ha valaki soha nem fog rakapcsolodni a nagy Internetre akkor otthoni halozatan ezt a tartomanyt hasznalja.

Namarmost rakapcsolodni az IN-re csak olyan cimmel illik
amit valaki kiosztott nekunk, legbol kapott IP cimmel nagy kavarodas lehetseges. ppp kapcsolodaskor a szolgaltato oszt ki a sajat tartomanyabol egy IP cimet amit a kapcsolat erejeig hasznalhatunk.

Lehetseges egyebkent egy ppp kapcsolaton keresztul egesz alhalozatot IN-re kotni, de most egyelore koncentraljunk arra, hogy 1 gep mukodjon.

Nezzuk a route parancsok kimenetet.
Innen latszik, hogy nem DNS problema van, hanem routing.

A route (es route -n) kimenetenek egyes sorai:

• Az 10.0.0.1 cimre (azaz sajat magunknak)
  gateway nelkul, azaz kozvetlenul kuldunk a dummy0-on keresztul.
  

• A 145.236.208.1 cimre (gondolom ez a ppp kapcsolat tul fele)
  direktbe kuldunk a ppp-n keresztul, azt a bejegyzest minden bizonnyal a ppp daemon kovette el.
  

• Az osszes 10.0.0 kezdeture az eth-n keresztul,
  loopbackre a loopbacken keresztul kuldunk.
  
• Az utolso sor a legerdekesebb, vagyis minden egyeb cimre
  a dummy0 interface-en keresztul kuldunk, sajat magunkon keresztul. (Mennyivel jobb lenne a ppp0!)
  

Ez igy jol ossze van kavarodva.

Javaslatom. (Tegyuk fel, hogy egyelore nem akarod az egesz halozatot rakotni.)

ppp kapcsolodas elott kapcsold ki a dummy0 es eth0 interfaceeket, valami
ifconfig dummy0 down, es
ifconfig eth0 down
parancsokkal. (bovebben man ifconfig, vagy NET-3-Howto)

Ettol valoszinu visszaall a routing tabla valami alapallapotba amit aztan a ppp daemon rendesen le tud kezelni.

---

Ha megsem: akkor miutan kikapcsoltad az interfaceeket,
probalj megint kapcsolodni, es masold be megint a fenti parancsok kimenetet (/etc/resolv.conf mar nem kell),
ha az ifconfigban nincs ppp0 akkor futtasd megint.

---

Az a kppp-s dolog erdekes. En ugyan nem kppp-t hasznalok, de hasonlo dolgokat csinal, de meg annyitra nem foglalkoztam vele, hogy kitapasztaljam, pontosan hogysmint.

---

Ja es javaslom a NET-3-Howto olvasgatasat, talan meg magyarul is megtalalhato valamilyen gyujtemenyben.

cancel

Hát ez baromira összeesett...

Na megvan minden. A következőt kaptam:

ifconfig
dummy0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.255.255.255
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0

eth0 Link encap:Ethernet HWaddr 00:E0:29:1B:D2:E0
inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:9 Base address:0x6c00

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:24 errors:0 dropped:0 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0

route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.1 0.0.0.0 255.255.255.255 UH 1 0 0 dummy0
145.236.208.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 dummy0

cat /etc/resolv.conf
nameserver 145.236.224.248
nameserver 145.236.224.249
nameserver 145.236.224.248 #kppp temp entry
nameserver 145.236.224.249 #kppp temp entry

route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
home.cooltech.h * 255.255.255.255 UH 1 0 0 dummy0
145.236.208.1 * 255.255.255.255 UH 0 0 0 ppp0
10.0.0.0 * 255.255.255.0 U 0 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo
default home.cooltech.h 0.0.0.0 UG 0 0 0 dummy0

Ez utóbbi program futása meglehetősen sok ideig tartott mire befejeződött.

Alaposabban megfigyeltem, hogy mit csinál pingelés közben. Saját kapott IP címemet meg tudom pingelni rendben. A remote gépet megpingelve adat megy-jön a modemen, ezt látom a ledeken és az ablakban is, az adatcsomag számláló pörög, viszont nem jelenik meg semmi, amit a ping értelmezett volna. Bármi mást pingelve (matáv DNS szerver vagy www.matav.hu stb.) semmilyen adatmozgás nincsen.

Még egy kérdés. Mi a fene lehet az, hogy a kppp csak minden második elindulásra hajlandó tenni a dolgát, egyébként meg egy olyan hobaüzenetet ad, hogy "Sorry. Kppp's helper process just died. Since a further execution would be pointless, kppp will shut down right now". Újraindítás és müxik. ???

Remélem a fenti szövegből (nem spóroltam a hellyel) sikerül következtetni valamire.

Előre is köszi, Traxy.

calcel:
köszönöm a segítséget, be fogom másolni a kimenetet ma este. IP címmel próbáltam a pingelést. Egészen pontosan én a kppp-t használom a kapcsolódáshoz és miutás belépett a hálózatba, a details ablak megadja, hogy mi az én IP címem és mi a remote gép IP címe. Magamat meg tudom ping-elni, de a remote masinát már nem. Próbáltam címet is pingelni, mint www.matav.hu stb, de semmim sem jött be. Ma este kipróbálom amit írtál.
Még egyszer köszi.
Üdv, Traxy.

Ja igen, es persze ha tovabbra sem mukszik akkor masold ide be a megadott parancsok kimenetet, talan mas is tanulhat belole.

cancel

Csatlakozasi problemak eseten a kovetkezoket erdemes tenni, ha valaki segitseget ker:

Gondolkodas nelkul terminalbol rootkent kiadni az alabbi parancsokat, az alabbi sorrendben, es a kimenetuket megmutatni a "szakertonek":

ifconfig
route -n
cat /etc/resolv.conf
route

Az ifconfigban benne kell lennie annak az interface-nek amivel a csatlakozasnak kellene tortennie, altalaban ppp0.

A route -n kiirja a routing tablat IP cimekkel, vagyis akkor is
mukszik ha esetleg a nevfeloldassal lenne problema.
(Most a routing tablat nincs kedvem reszletezni, de sokminden kiderul belole, pl. hogy melyik kartyara teszi ki a csomagot.)

az /etc/resolv.conf-ban erdemes megnezni, hogy a NameServerek helyesen vannak-e benne, illetve a domain bejegyzes is helyes-e, pl.

domain matav.hu
nameserver a.b.c.d
(vagy valami hasonlo)

A route a routing tablat irja ki, de nem IP cimekkel, hanem nevekkel. Ha pl. minden mukszik, de a DNS nem stimmel akkor ez altalaban az elso sor kiirasa utan "lehal".

Ha route -n OK, de route nem -> 99% DNS azaz nev feloldasi problema, erdemes a resolv.conf-ot megegyszer jol atnezni, nem lett-e valami elutve.
--
pingelni nevvel, vagy IP cimmel probaltal?
Ha nevvel akkor probalj IP cimmel, pl.
ping 204.152.190.63
Ha ez megy -> DNS.

Sziasztok!
Egy olyan kérdéssel fordulok hozzátok, hogy SuSe linux alól feljelentkezek a Matávnet-hez (nagy nehezen sikerült belépni), de ott senkit nem látok. Ping-elni csak saját magamat tudom, már a remote gépet sem! Biztosan nálam van a hiba, a gépemben van egy hálózati kártya is. Az a gyanúm, hogy arra teszi ki a csomagot, nem a telefonra. Az igazság az, hogy suta vagyok hozzá hogy ilyen mélységben beleássak a dologba, s a FAQ sem említett ilyen jellegű problémát. Ha tudtok tanácsot adni nagyon megköszönném. Fontos lenne.

Köszi, Traxy.

Yes! Megcsináltam!
Már nincs is ppp csatlakozási problémám, először Linux alól a Neten!
(a nyáron is elolvashattam volna a SuSE gyári doksiját....)
SzG

Szia,

kde alatt van kppp, konzol alatt ált. van vwdial (vagy wvdial?), pppconfig. És egy rahedli további dolog amivel csatlakozni lehet. Ha nem szereted a scriptet akkor használj Xwin alatt valami PPP connectet (pl. kppp). Konzol alatt, ha pppconfig-al megcsinálsz 1 csatlakozást (név=ISP_nev) azt pon ISP_nev és poff parancsokkal kezelheted. Ha a mostani scriptet használod akkor, ha lehal, mielőtt újra indítod írd be: killall pppd utána indítsd újra a scriptet.

Ha betárcsázott és eltelt kb. 1 perc akkor írd be: route -n akkor láthatod, hogy van-e 0.0.0.0 kezdetű sor és a gateway oszlopban az IP címet amit az ISP adott.
Másik, pingelj meg (ping IP_cím) egy létező címet az interneten. Ha van válasz akkor jól van beállítva a kapcsolat kifelé.

Üdv:
dj