abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 22:22 | Komunita

Společnost Purism představila kryptografický token Librem Key. Koupit jej lze za 59 dolarů. Token byl vyvinut ve spolupráci se společností Nitrokey a poskytuje jak OpenPGP čipovou kartu, tak zabezpečení bootování notebooků Librem a také dalších notebooků s open source firmwarem Heads.

Ladislav Hagara | Komentářů: 0
včera 20:33 | Nová verze

Společnost NVIDIA oficiálně vydala verzi 10.0 toolkitu CUDA (Wikipedie) umožňujícího vývoj aplikací běžících na jejich grafických kartách. Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
včera 20:00 | Upozornění

Příspěvek Jak přežít plánovanou údržbu DNS na blogu zaměstnanců CZ.NIC upozorňuje na historicky poprvé podepsání DNS root zóny novým klíčem dne 11. října 2018 v 18:00. Software, který nebude po tomto okamžiku obsahovat nový DNSSEC root klíč, nebude schopen resolvovat žádná data. Druhým důležitým datem je 1. února 2019, kdy významní výrobci DNS softwaru, také historicky poprvé, přestanou podporovat servery, které porušují DNS standard

… více »
Ladislav Hagara | Komentářů: 5
včera 15:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 156. brněnský sraz, který proběhne v pátek 21. září od 18:00 v restauraci Na Purkyňce na adrese Purkyňova 80.

Ladislav Hagara | Komentářů: 0
včera 13:22 | Nová verze

Alan Griffiths z Canonicalu oznámil vydání verze 1.0.0 display serveru Mir (GitHub, Wikipedie). Mir byl představen v březnu 2013 jako náhrada X serveru a alternativa k Waylandu. Dnes Mir běží nad Waylandem a cílen je na internet věcí (IoT).

Ladislav Hagara | Komentářů: 0
20.9. 22:00 | Nasazení Linuxu
Stabilní aktualizace Chrome OS 69 (resp. Chromium OS), konkrétně 69.0.3497.95, přináší mj. podporu linuxových aplikací. Implementována je pomocí virtualizace, a proto je tato funkce také omezena na zařízení s dostatkem paměti a podporou hardwarové akcelerace, tudíž nejsou podporovány chromebooky s 32bitovými architekturami ARM, či Intel Bay Trail (tzn. bez Intel VT-x).
Fluttershy, yay! | Komentářů: 5
20.9. 21:32 | Zajímavý projekt
Došlo k uvolnění linuxové distribuce CLIP OS, vyvíjené francouzským úřadem pro kybernetickou bezpečnost ANSSI, jako open source. Vznikla za účelem nasazení v úřadech, kde je potřeba omezit přístup k důvěrným datům. Je založená na Gentoo.
Fluttershy, yay! | Komentářů: 1
20.9. 16:00 | Komerce

Zjistěte více o bezpečné a flexibilní architektuře v cloudu! IBM Cloud poskytuje bezpečné úložiště pro Vaše obchodní data s možností škálovatelnosti a flexibilitou ukládání dat. Zároveň nabízí prostředky pro jejich analýzu, vizualizaci, reporting a podporu rozhodování.

… více »
Fluttershy, yay! | Komentářů: 12
20.9. 12:22 | Nová verze

V dubnu letošního roku Mozilla představila webový prohlížeč pro rozšířenou a virtuální realitu Firefox Reality (GitHub). V úterý oznámila vydání verze 1.0. Ukázka na YouTube. Firefox Reality je k dispozici pro Viveport, Oculus a Daydream.

Ladislav Hagara | Komentářů: 2
20.9. 12:00 | Komunita

V srpnu loňského roku společnost Oracle oznámila, že Java EE (Enterprise Edition) bude uvolněna jako open source. O měsíc později bylo rozhodnuto, že tato open source Java EE bude přejmenována a předána Eclipse Foundation. Nové jméno bylo oznámeno v únoru letošního roku. Z Java EE se stala Jakarta EE. Eclipse Foundation včera oznámila dosažení dalšího milníku. Zdrojové kódy aplikačního serveru GlassFish jsou již k dispozici v git repozitářích Eclipse Foundation (GitHub).

Ladislav Hagara | Komentářů: 0
Na optické médium (CD, DVD, BD aj.) jsem naposledy vypaloval(a) data před méně než
 (13%)
 (14%)
 (21%)
 (23%)
 (25%)
 (4%)
 (1%)
Celkem 385 hlasů
 Komentářů: 33, poslední 16.9. 11:55
Rozcestník

Dotaz: pptp - LCP timeout

14.5.2005 00:34 Martin Beránek | skóre: 33 | blog: mousehouse | Brno
pptp - LCP timeout
Přečteno: 484×

takze uz asi 8 hodin se snazim rozjet pptp klienta oproti univerzitnimu serveru (mel by bezet na windows). jsem za routerem, tak sem se projistotu skousel pripojit z windows a pripojeni funguje:

$ pon muni debug dump logfd 2 nodetach
pppd options in effect:
debug           # (from command line)
nodetach        # (from command line)
logfd 2         # (from command line)
dump            # (from command line)
noauth          # (from /etc/ppp/options.pptp)
name xberane1   # (from /etc/ppp/peers/muni)
remotename PPTP # (from /etc/ppp/peers/muni)
                # (from /etc/ppp/options.pptp)
pty pptp pptp.ics.muni.cz --nolaunchpppd  # (from /etc/ppp/peers/muni)
ipparam muni    # (from /etc/ppp/peers/muni)
nobsdcomp       # (from /etc/ppp/options.pptp)
nodeflate       # (from /etc/ppp/options.pptp)
using channel 2
Using interface ppp0
Connect: ppp0 <--> /dev/pts/6
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xf8cac249> <pcomp> <accomp>]
... tohle se opakuje 10x ...
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xf8cac249> <pcomp> <accomp>]
LCP: timeout sending Config-Requests
Connection terminated.
Waiting for 1 child processes...
  script pptp pptp.ics.muni.cz --nolaunchpppd, pid 9695
Script pptp pptp.ics.muni.cz --nolaunchpppd finished (pid 9695), status = 0x0

skousel jsem hledat chyby podle navodu a dostal jsem se az k bodu 4 (Check GRE Works). tcpdump mi pise tohle:

00:18:56.035180 IP mousehouse > pptp.ics.muni.cz: call 33152 seq 5 gre-ppp-payload
00:18:56.049259 IP pptp.ics.muni.cz > 0.0.0.0: call 0 seq 10 ack 5 gre-ppp-payload
00:18:56.083630 IP pptp.ics.muni.cz > 0.0.0.0: call 0 seq 11 gre-ppp-payload
00:18:58.084663 IP pptp.ics.muni.cz > 0.0.0.0: call 0 seq 12 gre-ppp-payload

z tohohle usuzuji ze gre jde (nejsem zrovna odbornik na site a tcp dump jsem puzival podle navodu...)

mppe jsem take zkousel (jak je uvedeno na strankach) a v jadre je urcite a u toho

mousehouse bery # strings `which pppd`|grep -i mppe|wc --lines
28

vite prosim nekdo co s tim... diky

PS: konfigurace

$ cat /etc/ppp/options.pptp
lock
noauth
nobsdcomp
nodeflate

$ cat /etc/ppp/chap-secrets
username        PPTP            heslo      *
PPTP            username        heslo      *

$ cat /etc/ppp/peers/muni
pty "pptp pptp.ics.muni.cz --nolaunchpppd"
name username
remotename PPTP
# tady jsem zkousel vsechno mozne - vypnout, zapnout mschap-v2, ...
require-mschap  
file /etc/ppp/options.pptp
ipparam muni

PS2: pouzivam Gentoo (pppd version 2.4.2, pptp-linux version 1.5.0)

never use rm after eight

Odpovědi

Vašek Lorenc avatar 14.5.2005 01:11 Vašek Lorenc | skóre: 27
Rozbalit Rozbalit vše Re: pptp - LCP timeout
Vytrvalá snaha, to se musí nechat :-)

Občas bývá problém v tom, že si nerozumí jádro a pptp daemon, ale to asi nebude tenhle problém. Možná by se dalo nastavit lcp-echo-interval na nulu, ověřit, že pppd opravdu bere parametr mschap a nevyžaduje jej zapsaný v jiném tvaru (např. mppe), což se v některém patchi dá potkat také...

V případě nejhorším (a to myslím vážně) zkusit _nešifrované!_ spojení na pptpne.ics.muni.cz. Tím ze hry vyloučíte MPPE a budete moci případně pokračovat v trasování jinde.

Pokud Vás to potěší, tak to z linuxu jede..
...včetně majestátného loosa
14.5.2005 08:23 Martin Beránek | skóre: 33 | blog: mousehouse | Brno
Rozbalit Rozbalit vše Re: pptp - LCP timeout
tak sem skusl zakomentovat vsechno s mppe, ale vysledek je naprosto stejny... skusim se hodit cele tcpdump a reknete mi prosim nekdo, jestli je to v poradku, nebo je nekde na ceste problem...

jak jsem psal, tady je navod kde hledat chyby... je tam mimo jine vyzkouset traceroute $SERVER. tohle neprojde, ale telnet $SERVER:$PORT se pripoji... zkousel jsem traceroute odjinud (i z pocitacu s verejnou IP (na fakulte) ) a znich traceroute take neprojde
$ traceroute pptp.ics.muni.cz
traceroute to pptpne.ics.muni.cz (147.251.19.248), 30 hops max, 40 byte packets
 1  * * *
 2  * * *
 ...
tak co, funguje komunikace nebo ne... (ja se opravdu ve vystupu tcpdump zrovna moc nevyznam...)

ale jak jsem psal, pripojeni z windows mi funguje... tak tady je ten tcpdump:
mousehouse bery # tcpdump -i eth0 -s 0 tcp port 1723 or proto 47
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:15:06.175114 IP mousehouse.57362 > pptpne.ics.muni.cz.1723: S 2819512896:2819512896(0) win 5840 <mss 1460,sackOK,timestamp 2696334 0,nop,wscale 2>
08:15:06.193815 IP pptpne.ics.muni.cz.1723 > mousehouse.57362: S 499842501:499842501(0) ack 2819512897 win 5792 <mss 1460,sackOK,timestamp 857924995 2696334,nop,wscale 2>
08:15:06.193883 IP mousehouse.57362 > pptpne.ics.muni.cz.1723: . ack 1 win 1460 <nop,nop,timestamp 2696353 857924995>
08:15:06.194244 IP mousehouse.57362 > pptpne.ics.muni.cz.1723: P 1:157(156) ack 1 win 1460 <nop,nop,timestamp 2696353 857924995>: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(AS) BEARER_CAP(DA) MAX_CHAN(65535) FIRM_REV(1) HOSTNAME(local) VENDOR(cananian)
08:15:06.210606 IP pptpne.ics.muni.cz.1723 > mousehouse.57362: . ack 157 win 1448 <nop,nop,timestamp 857925012 2696353>
08:15:06.211957 IP pptpne.ics.muni.cz.1723 > mousehouse.57362: P 1:157(156) ack 157 win 1448 <nop,nop,timestamp 857925013 2696353>: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP() BEARER_CAP() MAX_CHAN(1) FIRM_REV(1) HOSTNAME(local) VENDOR(linux)
08:15:06.212001 IP mousehouse.57362 > pptpne.ics.muni.cz.1723: . ack 157 win 1460 <nop,nop,timestamp 2696371 857925013>
08:15:07.196530 IP mousehouse.57362 > pptpne.ics.muni.cz.1723: P 157:325(168) ack 157 win 1460 <nop,nop,timestamp 2697356 857925013>: pptp CTRL_MSGTYPE=OCRQ CALL_ID(0) CALL_SER_NUM(0) MIN_BPS(2400) MAX_BPS(10000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(3) PROC_DELAY(0) PHONE_NO_LEN(0) PHONE_NO() SUB_ADDR()
08:15:07.214002 IP pptpne.ics.muni.cz.1723 > mousehouse.57362: P 157:189(32) ack 325 win 1448 <nop,nop,timestamp 857926016 2697356>: pptp CTRL_MSGTYPE=OCRP CALL_ID(3200) PEER_CALL_ID(0) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(10000000) RECV_WIN(3) PROC_DELAY(0) PHY_CHAN_ID(0)
08:15:07.214053 IP mousehouse.57362 > pptpne.ics.muni.cz.1723: . ack 189 win 1460 <nop,nop,timestamp 2697373 857926016>
08:15:07.214998 IP mousehouse > pptpne.ics.muni.cz: call 3200 seq 1 gre-ppp-payload
08:15:07.225100 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 0 gre-ppp-payload
08:15:07.238893 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 1 ack 1 gre-ppp-payload
08:15:09.225807 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 2 gre-ppp-payload
08:15:10.176270 IP mousehouse > pptpne.ics.muni.cz: call 3200 seq 2 gre-ppp-payload
08:15:10.191487 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 3 ack 2 gre-ppp-payload
08:15:11.226568 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 4 gre-ppp-payload
08:15:13.176823 IP mousehouse > pptpne.ics.muni.cz: call 3200 seq 3 gre-ppp-payload
08:15:13.191012 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 5 ack 3 gre-ppp-payload
08:15:13.227475 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 6 gre-ppp-payload
08:15:15.229227 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 7 gre-ppp-payload
08:15:16.177366 IP mousehouse > pptpne.ics.muni.cz: call 3200 seq 4 gre-ppp-payload
08:15:16.193149 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 8 ack 4 gre-ppp-payload
08:15:17.229485 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 9 gre-ppp-payload
08:15:19.177899 IP mousehouse > pptpne.ics.muni.cz: call 3200 seq 5 gre-ppp-payload
08:15:19.192868 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 10 ack 5 gre-ppp-payload
08:15:19.230346 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 11 gre-ppp-payload
08:15:21.231680 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 12 gre-ppp-payload
08:15:22.178451 IP mousehouse > pptpne.ics.muni.cz: call 3200 seq 6 gre-ppp-payload
08:15:22.193298 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 13 ack 6 gre-ppp-payload
08:15:23.232845 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 14 gre-ppp-payload
08:15:25.179416 IP mousehouse > pptpne.ics.muni.cz: call 3200 seq 7 gre-ppp-payload
08:15:25.195094 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 15 ack 7 gre-ppp-payload
08:15:25.233264 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 16 gre-ppp-payload
08:15:27.234591 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 17 gre-ppp-payload
08:15:28.179804 IP mousehouse > pptpne.ics.muni.cz: call 3200 seq 8 gre-ppp-payload
08:15:28.195310 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 18 ack 8 gre-ppp-payload
08:15:29.235265 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 19 gre-ppp-payload
08:15:31.180084 IP mousehouse > pptpne.ics.muni.cz: call 3200 seq 9 gre-ppp-payload
08:15:31.196607 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 20 ack 9 gre-ppp-payload
08:15:31.236197 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 21 gre-ppp-payload
08:15:33.237464 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 22 gre-ppp-payload
08:15:34.180652 IP mousehouse > pptpne.ics.muni.cz: call 3200 seq 10 gre-ppp-payload
08:15:34.194029 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 23 ack 10 gre-ppp-payload
08:15:35.238333 IP pptpne.ics.muni.cz > 0.0.0.0: call 0 seq 24 gre-ppp-payload
08:15:37.215688 IP mousehouse.57362 > pptpne.ics.muni.cz.1723: P 325:341(16) ack 189 win 1460 <nop,nop,timestamp 2727379 857926016>: pptp CTRL_MSGTYPE=CCRQ CALL_ID(0)
08:15:37.229623 IP pptpne.ics.muni.cz.1723 > mousehouse.57362: P 189:337(148) ack 341 win 1448 <nop,nop,timestamp 857956031 2727379>: pptp CTRL_MSGTYPE=CDN CALL_ID(3200) RESULT_CODE(4) ERR_CODE(0) CAUSE_CODE(0) CALL_STATS()
08:15:37.229692 IP mousehouse.57362 > pptpne.ics.muni.cz.1723: . ack 337 win 1460 <nop,nop,timestamp 2727393 857956031>
08:15:37.237860 IP mousehouse.57362 > pptpne.ics.muni.cz.1723: P 341:357(16) ack 337 win 1460 <nop,nop,timestamp 2727401 857956031>: pptp CTRL_MSGTYPE=CCRQ CALL_ID(0)
08:15:37.250750 IP pptpne.ics.muni.cz.1723 > mousehouse.57362: P 337:485(148) ack 357 win 1448 <nop,nop,timestamp 857956053 2727401>: pptp CTRL_MSGTYPE=CDN CALL_ID(65535) RESULT_CODE(4) ERR_CODE(0) CAUSE_CODE(0) CALL_STATS()
08:15:37.250801 IP mousehouse.57362 > pptpne.ics.muni.cz.1723: P 357:373(16) ack 485 win 1460 <nop,nop,timestamp 2727414 857956053>: pptp CTRL_MSGTYPE=StopCCRQ REASON(3)
08:15:37.263814 IP pptpne.ics.muni.cz.1723 > mousehouse.57362: P 485:501(16) ack 373 win 1448 <nop,nop,timestamp 857956065 2727414>: pptp CTRL_MSGTYPE=StopCCRP RESULT_CODE(1) ERR_CODE(0)
08:15:37.264075 IP pptpne.ics.muni.cz.1723 > mousehouse.57362: F 501:501(0) ack 373 win 1448 <nop,nop,timestamp 857956065 2727414>
08:15:37.303861 IP mousehouse.57362 > pptpne.ics.muni.cz.1723: . ack 502 win 1460 <nop,nop,timestamp 2727468 857956065>
08:15:39.252653 IP mousehouse.57362 > pptpne.ics.muni.cz.1723: R 373:373(0) ack 502 win 1460 <nop,nop,timestamp 2729417 857956065>

55 packets captured
55 packets received by filter
0 packets dropped by kernel

never use rm after eight
Vašek Lorenc avatar 14.5.2005 08:57 Vašek Lorenc | skóre: 27
Rozbalit Rozbalit vše Re: pptp - LCP timeout
A nemáte na Linuxu zapnutý nějaký firewall zahazující GRE protokol? Takhle po ránu mžourám do monitoru dost neostře, ale skoro bych měl pocit, že odpovědi na z pptp serveru na GRE requesty se někde cestou k Vám ztratí.. A jestli to pod Windows jede, tak by bylo možné, že to zahodí až Linux.

Co pravidla v iptables?
...včetně majestátného loosa
14.5.2005 09:18 Martin Beránek | skóre: 33 | blog: mousehouse | Brno
Rozbalit Rozbalit vše Re: pptp - LCP timeout
jelikoz jsem za routrem (kterej ma i fw) tak sem iptables nijak nenastavoval - nemam snad ani nainstalovane. na site nejsem zrovna odbornik - tak maximalne se nekam pripojit :-) (a obcas ani to nejde..)

no ale pokud to ve windows jede (za stejnym routerem) tak by to melo jet i v linuxu, ne?

btw, jak muzu zjistit jestli nekde neco zahazuju?
never use rm after eight
14.5.2005 09:21 Martin Beránek | skóre: 33 | blog: mousehouse | Brno
Rozbalit Rozbalit vše Re: pptp - LCP timeout
jinak router mam tenhle - firmware posledni
never use rm after eight
14.5.2005 19:55 Martin Beránek | skóre: 33 | blog: mousehouse | Brno
Rozbalit Rozbalit vše Re: pptp - LCP timeout
takze uz je vyreseno

stacilo do /etc/ppp/options.pptp pridat:
lcp-echo-interval 30
lcp-echo-failure 4
jak jednoduche, ach jo...
never use rm after eight
17.5.2005 08:37 Martin Beránek | skóre: 33 | blog: mousehouse | Brno
Rozbalit Rozbalit vše Re: pptp - LCP timeout
ach jo, tak to vyresene neni, po restartu stroje uz to zase nefunguje... delat to to same co predtim... opravdu s tim nema nekdo nejake zkusenosti? (omlouvam se za "topnuti" - je to naposled)
never use rm after eight
17.5.2005 09:19 Martin Beránek | skóre: 33 | blog: mousehouse | Brno
Rozbalit Rozbalit vše Re: pptp - LCP timeout
zrejme to bude tim, ze mi neco zahazuje pakety (ale co? - na windows to jede, iptables nemam...)
never use rm after eight

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.