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 16:22 | Nová verze

Po pěti měsících od vydání Waylandu a Westonu 1.12.0 oznámil Bryce Harrington (Samsung) vydání Waylandu 1.13.0 a Westonu 2.0.0.

Ladislav Hagara | Komentářů: 0
24.2. 13:37 | Bezpečnostní upozornění

Společnost Cloudflare (Wikipedie) na svém blogu potvrdila bezpečnostní problém s její službou. V požadovaných odpovědích od reverzní proxy byla odesílána také data z neinicializované paměti. Útočník tak mohl získat cookies, autentizační tokeny, data posílaná přes HTTP POST a další citlivé informace. Jednalo se o chybu v parsování HTML. Zneužitelná byla od 22. září 2016 do 18. února 2017. Seznam webů, kterých se bezpečnostní problém potenciálně týká na GitHubu.

Ladislav Hagara | Komentářů: 1
24.2. 08:22 | Nová verze

Byla vydána první beta verze Ubuntu 17.04 s kódovým názvem Zesty Zapus. Ke stažení jsou obrazy Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu GNOME, Ubuntu Kylin, Ubuntu Studio a Xubuntu. Dle plánu by Ubuntu 17.04 mělo vyjít 13. dubna 2017.

Ladislav Hagara | Komentářů: 28
23.2. 17:53 | Bezpečnostní upozornění

Google na svém blogu věnovaném počítačové bezpečnost informuje o nalezení "reálného" způsobu generování kolizí hašovací funkce SHA-1. Podrobnosti a zdrojové kódy budou zveřejněny do 90 dnů. Již dnes lze ale na stránce SHAttered nalézt 2 pdf soubory, jejichž obsah se liší a SHA-1 otisk je stejný (infografika).

Ladislav Hagara | Komentářů: 33
23.2. 17:51 | Nová verze

Vyšla nová verzia open source software na správu a automatizáciu cloudových datacentier Danube Cloud 2.4. Danube Cloud je riešenie postavené na SmartOS, ZFS, KVM a zónach. Obsahuje vlastnosti ako integrovaný monitoring, DNS manažment, zálohy, a samozrejme rozsiahlu dokumentáciu.

dano | Komentářů: 8
23.2. 17:46 | Pozvánky

V Plzni se 3. až 5. března 2017 uskuteční AIMTEChackathon. Je to akce pro vývojáře, grafiky, webdesignéry i veřejnost. Akci provází zajímavé přednášky IT odborníků. Více o programu a možnosti přihlášení na stránkách akce.

cuba | Komentářů: 0
23.2. 01:00 | Nová verze

Známý šifrovaný komunikátor Signal od verze 3.30.0 již nevyžaduje Google Play Services. Autoři tak po letech vyslyšeli volání komunity, která dala vzniknout Google-free forku LibreSignal (dnes již neudržovaný). Oficiální binárky jsou stále distribuované pouze přes Google Play, ale lze použít neoficiální F-Droid repozitář fdroid.eutopia.cz s nezávislými buildy Signalu nebo oficiální binárku stáhnout z Google Play i bez Google účtu

… více »
xm | Komentářů: 8
22.2. 23:14 | Nová verze

Po třech týdnech od vydání první RC verze byla vydána první stabilní verze 17.01.0 linuxové distribuce pro routery a vestavěné systémy LEDE (Linux Embedded Development Environment), forku linuxové distribuce OpenWrt. Přehled novinek v poznámkách k vydání. Dotazy v diskusním fóru.

Ladislav Hagara | Komentářů: 8
22.2. 17:28 | Bezpečnostní upozornění

Byly zveřejněny informace o bezpečnostní chybě CVE-2017-6074 v Linuxu zneužitelné k lokální eskalaci práv. Jde o chybu v podpoře DCCP (Datagram Congestion Control Protocol). Do linuxového jádra se dostala v říjnu 2005. V upstreamu byla opravena 17. února (commit). Bezpečnostní chyba byla nalezena pomocí nástroje syzkaller [Hacker News].

Ladislav Hagara | Komentářů: 16
22.2. 15:00 | Zajímavý software

Společnost Valve vydala novou beta verzi SteamVR. Z novinek lze zdůraznit oficiální podporu Linuxu. Další informace o podpoře této platformy pro vývoj virtuální reality v Linuxu v diskusním fóru. Hlášení chyb na GitHubu.

Ladislav Hagara | Komentářů: 0
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (13%)
 (2%)
 (72%)
 (3%)
 (10%)
Celkem 709 hlasů
 Komentářů: 66, poslední 22.2. 18:57
    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: 469×

    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.