ip-stories.com

  •  

    September 2010
    M T W T F S S
    « Aug    
     12345
    6789101112
    13141516171819
    20212223242526
    27282930  
  • Web Stat Counter

    • Search This Blog :

    • Add url
    • Add Me on FB

      Rahman Isnaini's Facebook profile
    • Hurricane Electric IPv6 Cert

      IPv6 Certification Badge for risnaini
    • comments

    • Visitors Referred From :

    • Geo Stats

    • Categories

    Archive for the 'GPRS' Category


    [GSM/Wireless] Share 3G Access via Wireless using Integrated 3G Router & Access Point

    Posted by admin on 14th December 2009

    Traveling to some areas that having no internet connection for an IT People is like salt less food :)
    Never hoping dedicated line or any wiring connection once you have arrived.

    Anyway, Internet Mobile through GSM [Either 3G/GPRS] is a good choice to have there.
    Virgin Broadband is one of them.

    An Easy Setup Process gives you a quick installation lead time.
    Here the steps [Please Insert your SIMCard]:

    1. Check Your Connection Status

    2. Enable Lan & Wireless Bridge


    3. Configure DHCP Servers


    4. Configure You GSM Connection [cellular]

    That’s All, you have to do.
    Anyway, I didn’t find any of WPA / WPE Wireless Security Features for Wireless Network Authentication.
    But for sure, Virgin Broadband it self can only covers in 10-20 meter radius.

    rgs
    a. rahman isnaini r.sutan

    Posted in GPRS, HSDPA, security, wireless | 2 Comments »

    [3G/HSDPA] INDOSAT 3G ? Scheduled to Online Now :)

    Posted by admin on 29th March 2009

    As the better speed news has been spread out since last years againts it’s competitors…
    INDOSAT 3G is now having more & more Data Users among top priority of ‘Voice users that will occupy’ the ‘idle’ even used data channel at a transceiver station.
    Used to handle and accomodate 4-5 Data Users in a BTS, is now 4 times increased rapidly.

    At the begining the speed was realy good.
    Lately last end of year months it was getting worse at the time of where Voice Channel is being used.
    The timing range a very bad connection are :

    a. 07:00 till 10:00 AM in the morning
    b. 06:00 till 11:00 PM in the evening

    During those times idle channel / slot for Data is extremely limited.
    All data connection might be extremely slowdown or even got disconnected.
    Of course that’s the rule Voice should have first place in channel management in Mobile Network System.

    So, if you still want to connect & have a bit better speed, please try to connect out of above two time ranges.
    05:00 - 07:00 is one of good time to online.
    Or you’ll be kicked out [i.e disconnected] or even denied to register by the system :) on no matter even you can get HSDPA on your Modem.
    What I’m suspecting is INDOSAT is running out of capacity for Data or over-data-subsribers in other word.

    a. rahman isnaini r.sutan
    BK-See

    Posted in GPRS, HSDPA, Mobile | No Comments »

    [Cisco] Clear Text Password Decryption - GetPass Utility

    Posted by a. Rahman Isnaini r. Sutan on 2nd August 2008

    Some of you might have been heard about this tool.
    It’s really useful.
    Not for spying others password purpose :) But decrypt your lost password.

    Getpass.Exe
    was created by Bosson.
    Here how it works :

    Take a look at below config for e.g :

    username adminv6 privilege 7 password 7 060F1F371A

    Put this “060F1F371A” in bosson getpass utility encrypted password.
    There you go, the decrypted password : ipv6 for adminv6

    a. rahman isnaini r.sutan

    Posted in GPRS | No Comments »

    [Mobile] INDOSAT HSDPA, Smooth Streaming & Issues

    Posted by a. Rahman Isnaini r. Sutan on 26th July 2008

    Staying at Home in the weekend almost to end of this July.
    Checking my Volume Usage Room (INDOSAT 3.5G Broadband).
    Only 15% volume filled from the total 1.5 GB monthly subscription.

    Before it’s getting reset to “zero” automatically by the system on the first of august
    I spent some hundreds MB for watching live streaming Indowebster.

    With 3 Bars of HSDPA signal strenght, I can have :
    - Smooth picture with 5 Inch Screen
    - At almost 3 Mbps from this HP520 BTS to MSC to GGSN to Local IndoWebster Web Server.

    Since it’s weekend..
    My thought goes to “more idle channels & capacity” in BTS and as well the BTS to BSC Backbone.
    BSC to MSC and GGSN as well.
    By this condition it gives you more room to be occupied.

    Sometimes for some occasions & situations, though I’m getting full bars of 3G or even 2 bars HSDPA,
    the connection keeps slow. Even browsing doesn’t seem to work out.
    Most page cannot be displayed.

    This usually happened at night of working days.
    And what I’ve done to make it good is trying to disconnect and reconnect again & again till pressing F5 key which gives me a prompt respond by transferring the data from the accessed website.
    For this condition I could say that BTS to End user Modem (Very good)..
    But the capacity at BTS/BSC/MSC might be oversubscribed or override by the voice channels.
    Therefor my “good” connection alocated only for several hundreds of kbps only along the pipe to GGSN.

    Other issue is, once the DataCard Modem Inserted.. it doesn’t automatically trying to search the network.
    It takes 5 minutes to start searching & registering to INDOSAT network.
    This also happened with ZTE bundled package default modem from INDOSAT.

    Second curiosity is why the signal strenght changes from HSDPA to 3G even GPRS without moving the Laptop even for a micro meter away ?
    It might be, I’m in the overlapping cell between the HSDPA supported BTS and GPRS/3G supported BTS :) How can stick only with HSDPA one ? :) No chance… or I should contact the Ericsson Engineer…

    a. rahman isnaini rangkayo sutan

    Posted in GPRS, HSDPA, Mobile | 1 Comment »

    INDOSAT 3G & GT Max Option 3.6 Mbps HSDPA DataCard

    Posted by a. Rahman Isnaini r. Sutan on 30th May 2008

    == Background ==

    Due to (As) 24 Hours Network Engineer, I should equip my self with any of instance & mobility internet connection. You know what can I do at 22:00 in the night while our support called & need assitance even immediate action, while Warnet Owner close their last door ?.
    This is a mandatory for service to be delivered as SLA defined.

    My choice goes to Indosat 3.5G Technology (Matrix Number), which a bit different with INDOSATM2 Broadband though coming from the same group.
    Mouth to mouth spread information, this 3.5G connection is pretty good in Speed.
    Better than tradisional 3G, GPRS too far behind the race.

    But truely I never want to have that ‘fast’ speed tested !. No Way.
    Why ? My subscription is Volume Base :)).
    Anyway, yes I did once before.
    Of course it’s not mine, my friend’s.
    International Speed Test, I got 1.7 Mbps using this 3.5 Broadband.

    == UPDATED JUNE 3, 2008 ==

    I got my DUMeter shows 1.2 Mbps for high traffic last night. (3G Speed Reality).

    ===================

    Well refer to above reasons, I took 1 Gbps Volume.
    I’m not sure If I can have remain couple Mbps of volume at the end of month or Over Volume :) What I’m gonna do is :

    - Using Webmail as much I can
    - Warn my ‘internet’ family not to open any web with more ‘content’ on it.
    - Lock internet connection by password key (good one :))

    == The set up ==

    1. Insert Globe Trotter DataCard
    2. Install Globe Trotter Driver (from CD) and Globe Trotter Connection Manager
    3. Insert SIMCard into DataCard
    4. Configure Connection Manager, just fill
    username : indosat
    password : indosat
    APN : indosat3g
    5. Wait for Network to be ready & registered to INDOSAT
    6. Once Ready, get Connect.
    7. Done.

    Read the rest of this entry »

    Posted in GPRS, HSDPA, Mobile | 18 Comments »

    Suggested to be IPv6 Enabled…

    Posted by a. Rahman Isnaini r. Sutan on 25th April 2008

    What I want to be IPv6 Enabled :

    Number #0.1 : ALL INTERNET EXCHANGE, TIERS, NAPS, PROVIDERS, TELCO OPERATORS & WARNETS [How can this be in this categories ? I mean Internet Cafe :)]
    Number #0.5 : BSD, UNIX, LINUX, CISCO, JUNIPER, MICROSOFT, APPLE [WEBsites & All Related Application Running On]

    Number #1 : Google.Com [Most popular & Fastest Search Engine, Earth Map, Mail]
    Number #2 : Yahoo.Com [Most Used Messenger, Mail]
    Number #3 : You Tube and other popular tubes [Most Video Streaming]
    Number #4 : CNN.COM BBC.COM and other NEWS WEBSITES [Most News]
    Number #5 : WORDPRESS.COM, BLOGSPOT, MULTIPLY, RAPIDSHARES [Most BLOGS]
    Number #6 : ALL SOFTWARES PROVIDERS
    Number #7 : ALL CONTENT & GAMES PROVIDERS [PORNS ? YES !] :) & I SHOULD BE AWAY FROM THIS.
    Number #8 : ALL BANKING SYSTEMS

    In INDONESIA :

    Number #0 : ALL NAPS, ISPs, INTERNET EXCHANGES, WARNETS, TELCO OPERATORS
    Number #1 : DETIK.COM [DONE with SIGIT ISNANTO]
    Number #2 : GAME CENTERS PROVIDERS [WHY DIDN'T THEY GO TO SCHOOL THIS LATE ?]
    Number #3 : ALL WEBSITES
    Number #4 : ALL BANKING SYSTEMS
    Number #499 : WWW.17TAHUN.COM ? :) [SORRY NOPE HOSTED HERE :))]

    WHY ?
    Because we are in the shortage of applications to get everybody even an internet dummy interested on the Big Issue of Running Out of IPv4 Address.
    And we are so close to the second, where every electronic boxes need IP for communicate.
    Yes, I Know NAT can do it for now, but it’s limited for some features.

    What I other thing know is still many of engines & boxes in some providers not IPv6 Supported yet.
    Replacement will equal to cost :) And Cost equals to How Revenue Calculated..
    And Gross Profit equals to COGS deducted from Revenue..
    And EBITDA derived from above..
    And ETDA Bocah… [This is BETAWI Languange, just passed to the bottom]…
    And Finally Net Profit Comes Up which might be 10% of Revenue :)) [kacian deh]…

    [I'm not actually sure, I'm a Network Engineer or Finance Expert by looking at above terms :)]

    So… What do you think Boss ?
    Forget Transition !!
    Forget That v6 Engines !! get Back to 4 cilinders ~!

    Matilah… awak…

    rgs
    a. rahman isnaini r.sutan
    NETSOFT NAP OPERATION
    Cyber Bld, 8th Floor
    Jakarta Selatan

    2404:170:253::10

    Posted in CDMA, CentOS, Cisco, Engine, FreeBSD, GPRS, IPv4, IPv6, Juniper, Linux, Slackware | 2 Comments »

    GPRS MTU Size Issues [Tunnel over Tunnel ?]

    Posted by a. Rahman Isnaini r. Sutan on 24th September 2007

    It’s been 4 days…
     
    Connected, Ping tidak ada masalah even the signal is pretty good !.
    Working with GPRS / 3G ISATnet Mobile.
     
    Sudah coba macam2 Aircard (Sierra, Novatel, Option Globe Trotter).
    Tidak satupun working.
     
    Telepon berdering2, chatting ber buzz2 dari partner di Tasik & Kep. RIAU.
    Seharian troubleshoot ke ISATnet.
    Akhirnya David memberikan solution dengan merubah registry khususnya TCP connection.
    Dan setelah di analyse memang benar ada perubahan MTU dari 1500 default menjadi 1440.
    Sehingga akhirnya berhasil
     
    Read the rest of this entry »

    Posted in GPRS | 3 Comments »

    GPRS VPDN L2TP Error "AUTH: Timeout"

    Posted by a. Rahman Isnaini r. Sutan on 7th September 2007

     
    Mau nyari harga laptop… tadi malam coba connect pakai GPRS…
    (Biar bisa nyicil, soale saat ini minjem… :)) buat config2 dan download2).
    Sebelumnya juga dipinjamin ma best prendku.. Hermansyah Smart Telecom.
     
    Menggunakan Sierra Wireless, dial APN Speednet.
    Bah, invalid APN ?
    Koq iso-isone invalid.
     
    Nunggu ke-esokan harinya… (karena malam2 dak boleh gedor2 warnet hanya untuk telnet, debug, analise ? loh kog nambah kerjaanne ?
    mana harus bayar lemburan tukang warnet + time billing explorernya)…
     
    Check punya check..
    Memang Auth Failed ketemu di LOG Router.
    Padahal Radius Reachable ? Team Radius (Batti) confirm OK ?
    Ya sudahlah, sementara set login ke Local Router ajah.
    Soale sesuk Sabtu & Minggu, jadi bisa standby neng Omah…
     
    Lognya spt dibawah :

    *Mar 8 13:50:12.186: Tnl 56283 L2TP: O StopCCN to ggsnlac tnlid 10
    *Mar 8 13:50:12.186: Tnl 56283 L2TP: Control channel retransmit delay set to 1 seconds
    *Mar 8 13:50:12.186: Tnl 56283 L2TP: Tunnel state change from no-sessions-left to shutting-down
    *Mar 8 13:50:13.186: Tnl 56283 L2TP: Control channel retransmit delay set to 1 seconds
    *Mar 8 13:50:13.830: L2TP: I SCCRQ from ggsnlac tnl 9
    *Mar 8 13:50:13.834: Tnl 42856 L2TP: Got a challenge in SCCRQ, ggsnlac
    *Mar 8 13:50:13.834: Tnl 42856 L2TP: New tunnel created for remote ggsnlac, address 202.152.240.154
    *Mar 8 13:50:13.834: Tnl 42856 L2TP: O SCCRP to ggsnlac tnlid 9
    *Mar 8 13:50:13.834: Tnl 42856 L2TP: Control channel retransmit delay set to 1 seconds
    *Mar 8 13:50:13.834: Tnl 42856 L2TP: Tunnel state change from idle to wait-ctl-reply
    *Mar 8 13:50:13.842: Tnl 42856 L2TP: I SCCCN from ggsnlac tnl 9
    *Mar 8 13:50:13.842: Tnl 42856 L2TP: Got a Challenge Response in SCCCN from ggsnlac
    *Mar 8 13:50:13.842: Tnl 42856 L2TP: Tunnel Authentication success
    *Mar 8 13:50:13.842: Tnl 42856 L2TP: Tunnel state change from wait-ctl-reply to established
    *Mar 8 13:50:13.842: Tnl 42856 L2TP: SM State established
    *Mar 8 13:50:13.842: Tnl 42856 L2TP: I ICRQ from ggsnlac tnl 9
    *Mar 8 13:50:13.842: Tnl/Sn 42856/58 L2TP: Session FS enabled
    *Mar 8 13:50:13.842: Tnl/Sn 42856/58 L2TP: Session state change from idle to wait-connect
    *Mar 8 13:50:13.842: Tnl/Sn 42856/58 L2TP: New session created
    *Mar 8 13:50:13.842: Tnl/Sn 42856/58 L2TP: O ICRP to ggsnlac 9/56836
    *Mar 8 13:50:13.842: Tnl 42856 L2TP: Control channel retransmit delay set to 1 seconds
    *Mar 8 13:50:13.850: Tnl/Sn 42856/58 L2TP: I ICCN from ggsnlac tnl 9, cl 56836
    *Mar 8 13:50:13.850: xl@speed.net.id Tnl/Sn 42856/58 L2TP: Session state change from wait-connect to wait-for-service-selection
    *Mar 8 13:50:13.854: ppp57 PPP: Authorization NOT required
    *Mar 8 13:50:13.854: ppp57 PPP: Sent PAP LOGIN Request
    *Mar 8 13:50:17.186: Tnl 56283 L2TP: Shutdown tunnel
    *Mar 8 13:50:17.186: Tnl 56283 L2TP: Tunnel state change from shutting-down to idle
    *Mar 8 13:50:23.854: ppp57 AUTH: Timeout 1

    ######################################################
    # ERROR Here ! #
    # AUTHENTICATION TIMED-OUT #
    # Please check : di Radius (authentication setting di Router ke Radius) #

    # #
    # #
    # aaa authentication ppp default group radius #
    # aaa authentication ppp vpdn group radius #
    # aaa authorization network vpdn none #
    # aaa authorization network ppp none #
    # aaa accounting network default start-stop group radius #
    # aaa accounting network vpdn start-stop group radius #
    # aaa accounting connection default start-stop group radius #
    # aaa accounting system default start-stop group radius #
    ######################################################

    *Mar 8 13:50:33.854: ppp57 PPP: Received LOGIN Response FAIL
    *Mar 8 13:50:33.854: ppp57 PAP: O AUTH-NAK id 0 len 26 msg is “Authentication failed”

    ####################

    # AUTH assumed FAILED #
    ####################

    * Mar 8 13:50:33.854: xl@speed.net.id Tnl/Sn 42856/58 L2TP: O SLI to ggsnlac 9/56836
    *Mar 8 13:50:33.854: xl@speed.net.id Tnl/Sn 42856/58 L2TP: Sending send ACCM 0xFFFFFFFF and receive ACCM 0xFFFFFFFF
    *Mar 8 13:50:33.854: Tnl 42856 L2TP: Control channel retransmit delay set to 1 seconds
    *Mar 8 13:50:33.862: xl@speed.net.id Tnl/Sn 42856/58 L2TP: I CDN from ggsnlac tnl 9, cl 56836
    *Mar 8 13:50:33.862: xl@speed.net.id Tnl/Sn 42856/58 L2TP: disconnect (AAA) IETF: 17/user-error Ascend: 55/PPP Auth Timeout
    *Mar 8 13:50:33.862: xl@speed.net.id Tnl/Sn 42856/58 L2TP: Destroying session
    *Mar 8 13:50:33.862: xl@speed.net.id Tnl/Sn 42856/58 L2TP: Session state change from wait-for-service-selection to idle
    *Mar 8 13:50:33.862: xl@speed.net.id Tnl/Sn 42856/58 L2TP: Accounting stop sent

    #############################################
    # SESSION TIDAK BISA ESTABLISH karena AUTH FAILED #
    #############################################

    *Mar 8 13:50:33.862: Tnl 42856 L2TP: Tunnel state change from established to no-sessions-left
    *Mar 8 13:50:33.862: Tnl 42856 L2TP: No more sessions in tunnel, shutdown (likely) in 10 seconds
    *Mar 8 13:50:33.862: VPDN failure cause: received Result 1, Error 0, existing Authentication failed
    *Mar 8 13:50:43.862: Tnl 42856 L2TP: O StopCCN to ggsnlac tnlid 9
    *Mar 8 13:50:43.862: Tnl 42856 L2TP: Control channel retransmit delay set to 1 seconds
    *Mar 8 13:50:43.862: Tnl 42856 L2TP: Tunnel state change from no-sessions-left to shutting-down
    *Mar 8 13:50:44.862: Tnl 42856 L2TP: Control channel retransmit delay set to 1 seconds
    *Mar 8 13:50:48.862: Tnl 42856 L2TP: Shutdown tunnel
    *Mar 8 13:50:48.862: Tnl 42856 L2TP: Tunnel state change from shutting-down to idle

    a. rahman isnaini rangkyo sutan

    Posted in GPRS | No Comments »

    Simple Log Analyze VPDN L2TP [User-GGSN/LAC-ISP/LNS]

    Posted by a. Rahman Isnaini r. Sutan on 7th September 2007

    Pada intinya,

    Saat user dial APN nya via Link Operator (GPRS/3G/HSDPA) ada dua process sampai user connected.


    A. TUNNEL ESTABLISHMENT antara GGSN - VPDN ISP Router

    *Mar 8 13:02:16.595: L2TP: I SCCRQ from ggsnlac tnl 10
    #GGSN kirim SCRRQ untuk initiate Tunnel (Tunnel 10)

    *Mar 8 13:02:16.595: Tnl 56283 L2TP: Got a challenge in SCCRQ, ggsnlac
    #Validasi SCCRQ di VPDN ISP ROuter

    *Mar 8 13:02:16.595: Tnl 56283 L2TP: New tunnel created for remote ggsnlac, address 202.152.240.154
    #VDPN ISP Router create Tunnel 10

    *Mar 8 13:02:16.595: Tnl 56283 L2TP: O SCCRP to ggsnlac tnlid 10
    #VPDN ISP Router Respon (Inform) ke GGSN Tunnel 10 sudah dicreate

    *Mar 8 13:02:16.595: Tnl 56283 L2TP: Control channel retransmit delay set to 1 seconds
    *Mar 8 13:02:16.595: Tnl 56283 L2TP: Tunnel state change from idle to wait-ctl-reply
    #Status Tunnel menjadi WAIT-CTL-REPLY

    *Mar 8 13:02:16.603: Tnl 56283 L2TP: I SCCCN from ggsnlac tnl 10
    #GGSN Respon menggunakan SCCCN ke VDPN ISP Router

    *Mar 8 13:02:16.603: Tnl 56283 L2TP: Got a Challenge Response in SCCCN from ggsnlac
    #Validasi SCCCN di VPDN ISP Router

    *Mar 8 13:02:16.603: Tnl 56283 L2TP: Tunnel Authentication success
    *Mar 8 13:02:16.603: Tnl 56283 L2TP: Tunnel state change from wait-ctl-reply to established
    #Tunnel sudah dicreate antara GGSN & VPDN ISP Router [SUCCESS]
    #Tunnel siap dipergunakan untuk Proses selanjutnya.

    B. SESSION ESTABLISHMENT dengan 3 WAYS EXCHANGE antara USER-GGSN-VPDN ROUTER - RADIUS [Jika ada]

    *Mar 8 13:02:16.603: Tnl 56283 L2TP: SM State established
    *Mar 8 13:02:16.603: Tnl 56283 L2TP: I ICRQ from ggsnlac tnl 10
    #GGSN kirim ICRQ ke VPDN ISP Router via Tunnel 10 untuk Request Session

    *Mar 8 13:02:16.603: Tnl/Sn 56283/56 L2TP: Session FS enabled
    *Mar 8 13:02:16.603: Tnl/Sn 56283/56 L2TP: Session state change from idle to wait-connect
    *Mar 8 13:02:16.603: Tnl/Sn 56283/56 L2TP: New session created
    #VPDN ISP Router create Session

    *Mar 8 13:02:16.603: Tnl/Sn 56283/56 L2TP: O ICRP to ggsnlac 10/55664
    #VPDN ISP Router respon ke GGSN menggunakan ICRP

    *Mar 8 13:02:16.603: Tnl 56283 L2TP: Control channel retransmit delay set to 1 seconds
    *Mar 8 13:02:16.615: Tnl/Sn 56283/56 L2TP: I ICCN from ggsnlac tnl 10, cl 55664
    #GGSN kirim ICCN ke VPDN ISP Router yang berisi informasi Negosiasi LCP GGSN - User

    *Mar 8 13:02:16.615: xl@speed.net.id Tnl/Sn 56283/56 L2TP: Session state change from wait-connect to wait-for-service-selection
    #Session User status berubah.

    *Mar 8 13:02:16.615: ppp55 PPP: Authorization NOT required
    *Mar 8 13:02:16.615: ppp55 PPP: Sent PAP LOGIN Request
    *Mar 8 13:02:16.615: ppp55 PPP: Received LOGIN Response PASS
    #Authentication PPP L2TP VPDN > Berhasil

    *Mar 8 13:02:16.619: Vi2.1 Tnl/Sn 56283/56 L2TP: Virtual interface created for xl@speed.net.id, bandwidth 100000 Kbps
    *Mar 8 13:02:16.619: Vi2.1 Tnl/Sn 56283/56 L2TP: VPDN session up
    #VPDN Session User sudah Up, IP sudah di assign & Virtual Interface sudah dicreate (Interface Vi2.1)

    *Mar 8 13:02:16.619: Vi2.1 Tnl/Sn 56283/56 L2TP: Session state change from wait-for-service-selection to established
    #User Session Established.

    *Mar 8 13:02:16.619: Vi2.1 PAP: O AUTH-ACK id 0 len 5
    *Mar 8 13:02:16.867: Tnl 4174 L2TP: Control channel retransmit delay set to 1 seconds
    *Mar 8 13:02:20.867: Tnl 4174 L2TP: Shutdown tunnel
    #Tunnel sudah bisa dishutdown, karena Session sudah UP.

    *Mar 8 13:02:20.867: Tnl 4174 L2TP: Tunnel state change from shutting-down to idle
    #Tunnel akan di Shutdown.

    a. rahman isnaini r. sutan
    2404:170:ee02::10
    talang betutu, River Side.

    Posted in GPRS | No Comments »

    GPRS VPDN L2TP [Connection Process Sequences] & Log Analyze

    Posted by a. Rahman Isnaini r. Sutan on 13th August 2007

    Hari yang melelahkan.. 13 July 2007.

    Brian dari Primanet hari ini submit log router AS5300 untuk compare GPRS nya yang masih Error. Setelah dicheck, setelah phase L2TP SCCRQ harusnya parse SCCN.. Namun sisi Primanet sudah stopCCN yang berati user sudah terminate / disconnect. Hal ini membuatku untuk menganalisa satu persatu setiap log yang berhasil.

    Log dari speednet router akan dicompare dengan Log yang failed.

    Status perangkat saat ini

    - GGSN XL [Huawei] sbg LAC - SPEEDNET [Cisco 7200] sebagai LNS

    – —– STEP BY STEPS GPRS LOG PROSES ——

    +++++++++++++++++++++++++

    + TUNNEL ESTABLISHMENT +
    +++++++++++++++++++++++++

    gprs-l2tp-auth-proses.gif

    The PPP/L2TP Connection Sequence

    This is the connection sequence of events:

    1. The remote user initiates a PPP connection. The LAC accepts the connection. A PPP link is established.
    2. LCP is negotiated between the remote user and LAC. The LAC issues a Challenge Handshake Authentication Protocol (CHAP) challenge in order to perform a partial authentication of the remote user. The reply is sent to the LNS during session establishment. The reply is sent as attribute-value pair (AVP) 33 proxy authentication response in the Incoming-Call-Connected (ICCN).
    3. The DNIS is used to determine whether the user is a virtual private dial-up network (VPDN) client.
    4. Because there is no existing tunnel for the dialed number (614629), creation of a new tunnel is necessary. RADIUS is queried and the tunnel information is downloaded to the LAC.
    5. The control connection is started. The tunnel is in an IDLE state:
    * The tunnel initiator (in this case, the LAC) sends a Start-Control-Connection-Request (SCCRQ) to the LNS. The SCCRQ contains an AVP 11 challenge, which indicates that the LAC wants to authenticate the tunnel with use of a CHAP-style authentication. The same secret is known to both tunnel endpoints. The tunnel is now in a WAIT-CTL-REPLY state.
    * The LNS can bring up the tunnel, so the LNS replies with a Start-Control-Connection-Reply (SCCRP). The SCCRP contains an AVP 11 challenge and an AVP 13 challenge response in reply to the SCCRQ. The tunnel is now in a WAIT-CTL-REPLY state.
    * The LAC responds with a Start-Control-Connection-Connected (SCCCN) message. The SCCCN contains an AVP 13 in reply to the SCCRP. The tunnel is now in an Established state.
    * The LNS sends a Zero-Length Body (ZLB) message to the LAC. The ZLB message is a sequenced acknowledgement. The tunnel is now in an Established state.
    6. The tunnel authentication is now complete and the tunnel is established. The session is now in an IDLE state.
    7. Now that the tunnel exists, a three-way exchange for session establishment within the tunnel is performed:
    * The LAC sends an Incoming-Call-Request (ICRQ) with the parameter information for the session. The session is now in a Wait Reply state.
    * The LNS sends an Incoming-Call-Reply (ICRP) that contains the session ID. The session is now in a Wait Connect state.
    * The LAC sends an ICCN and provides the LNS with additional information for the answered call. This information includes the LCP information from the negotiation that the LAC and remote user performed. The session is now in an Established state.
    * The LNS sends a ZLB message, which is a sequenced acknowledgement, to the LAC. The session is now in an Established state.
    8. After establishment of the session, a virtual access interface is created on the LNS. The LCP configuration information that was delivered in the ICCN is forced onto the virtual access interface PPP stack. This information includes the partial authentication information.
    9. The LNS generates an authentication challenge. The proxy authentication response AVP 33, which was delivered in the ICCN, is replayed.
    10. Normal authentication, authorization, and accounting (AAA) or PPP authentication and authorization takes place.
    11. A RADIUS Access-Request is sent for per-user authentication and authorization.
    12. A RADIUS Access-Accept is received.

    Note: RADIUS has been configured to allow the IP address that the remote user has offered in the incoming IPCP Configure-Request.
    13. A CHAP success message is sent to the remote user.
    14. PPP IPCP negotiation completes and is declared OPEN. A host route is installed to the remote interface. The remote user is now connected, and traffic flow can commence.

    +++++++++++++++++++++++++++++++++++++++++++++
    + Tunnel Establishment Persi Rahman Isnaini +
    +++++++++++++++++++++++++++++++++++++++++++++

    :: User Dial ke APN www.speed.net.id

    Aug 13 06:58:46.920: VPDN CEF From tunnel: Received 147 byte pak
    Aug 13 06:58:46.920: L2X: Punting to L2TP control message queue
    Aug 13 06:58:46.920: VPDN CEF From tunnel: Pak consumed
    Aug 13 06:58:46.920: L2X: Parse AVP 0, len 8, flag 0×8000 (M)
    Aug 13 06:58:46.920: L2X: Parse SCCRQ
    :: ROUTER-VPDN-ISP terima SCCRQ (State Control Connection Request) dari GGSN
    :: sebagai Tunnel Initiator.

    Aug 13 06:58:46.920: L2X: Parse AVP 2, len 8, flag 0×8000 (M)
    Aug 13 06:58:46.920: L2X: Protocol Ver 256
    Aug 13 06:58:46.920: L2X: Parse AVP 7, len 13, flag 0×8000 (M)
    Aug 13 06:58:46.920: L2X: Hostname ggsnlac
    :: –> GGSN-XL (LAC)

    Aug 13 06:58:46.920: L2X: Parse AVP 8, len 12, flag 0×0
    Aug 13 06:58:46.920: L2X: Vendor Name HuaWei

    :: –> GGSN VENDOR

    Aug 13 06:58:46.924: L2X: Parse AVP 3, len 10, flag 0×8000 (M)
    Aug 13 06:58:46.924: L2X: Framing Cap 0×3
    Aug 13 06:58:46.924: L2X: Parse AVP 9, len 8, flag 0×8000 (M)
    Aug 13 06:58:46.924: L2X: Assigned Tunnel ID 9
    :: –> ROUTER-VPDN-ISP Assign Tunnel 9

    Aug 13 06:58:46.924: L2X: Parse AVP 10, len 8, flag 0×8000 (M)
    Aug 13 06:58:46.924: L2X: Rx Window Size 64
    Aug 13 06:58:46.924: L2X: Parse AVP 11, len 22, flag 0×8000 (M)
    Aug 13 06:58:46.924: L2X: Chlng
    Aug 13 06:58:46.924: L2X: No missing AVPs in SCCRQ
    :: ROUTER-VPDN-ISP check SCCRQ yang berisi AVP 11

    Aug 13 06:58:46.924: L2X: I SCCRQ, flg TLS, ver 2, len 101, tnl 0, cl 0, ns 0, nr 0 contiguous pak, size 101
    Aug 13 06:58:46.924: L2TP: I SCCRQ from ggsnlac tnl 9
    Aug 13 06:58:46.924: Tnl 22396 L2TP: Got a challenge in SCCRQ, ggsnlac
    :: CHAP STYLE untuk L2TP Tunnel Authentication antara LAC (GGSN XL) dan LNS (ROUTER-VPDN-ISP)
    :: Secret Key “huaweiXL” di Exchange disini

    Aug 13 06:58:46.924: Tnl 22396 L2TP: New tunnel created for remote ggsnlac, address 202.152.240.154
    :: ROUTER-VPDN-ISP (LNS) sudah create Tunnel 9 untuk GGSN-XL (LAC) dan siap bring “UP” tunnel.

    Aug 13 06:58:46.924: Tnl 22396 L2TP: O SCCRP to ggsnlac tnlid 9
    Aug 13 06:58:46.924: Tnl 22396 L2TP: O SCCRP, flg TLS, ver 2, len 154, tnl 9, cl 0, ns 0, nr 1
    :: ROUTER-VPDN-ISP Reply SCCRQ GGSN-XL (LAC) dengan SCCRP (State Control Connection Reply) bahwa Tunnel sudah siap.

    Aug 13 06:58:46.924: Tnl 22396 L2TP: Control channel retransmit delay set to 1 seconds
    Aug 13 06:58:46.924: Tnl 22396 L2TP: Tunnel state change from idle to wait-ctl-reply
    :: STATUS Tunnel yang dicreate berubah dari “IDLE”ke “WAIT-CTL-REPLY”

    Aug 13 06:58:47.156: Tnl 22396 L2TP: Verify ns/nr, peer ns/nr 1/1, our ns/nr 1/1
    Aug 13 06:58:47.156: Tnl 22396 L2TP: Peer acknowledging through 1
    Aug 13 06:58:47.156: Tnl 22396 L2TP: Verify ns/nr, peer ns/nr 2/1, our ns/nr 1/2
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Process ctrl pkt peer ns/nr 1/1, our ns/nr 1/3, tunnel->peer_nr 1
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Clean resendQ, peer_nr 1, last_rx_nr 0
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Cleaned ns 0 from resendQ
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Currently 0 messages on the resend queue
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Parse AVP 0, len 8, flag 0×8000 (M)
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Parse SCCCN
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Parse AVP 13, len 22, flag 0×8000 (M)
    :: ROUTER-VPDN-ISP menerima SCCCN (State Control Connected) dari GGSN XL [LAC] yang berisi AVP 13 (Attribute Value Pair)
    :: sebagai respon dari SCCRP yang dikirimkan sebelumnya.

    Aug 13 06:58:47.160: Tnl 22396 L2TP: Chlng Resp
    Aug 13 06:58:47.160: Tnl 22396 L2TP: No missing AVPs in SCCCN
    Aug 13 06:58:47.160: Tnl 22396 L2TP: I SCCCN, flg TLS, ver 2, len 42, tnl 22396, cl 0, ns 1, nr 1 contiguous pak, size 42
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Sending ZLB ACK ns/nr 1/3
    :: ROUTER-VPDN-ISP check AVP 13 dalam SCCCN dari GGSN
    :: dan mengirim ZLB ACK (Zero Lenght Body) Acknowledgement ke GGSN-XL [LAC]
    :: Sebagai tanda Tunnel siap untuk establish.

    Aug 13 06:58:47.160: Tnl 22396 L2TP: O ZLB ctrl ack, flg TLS, ver 2, len 12, tnl 9, cl 0, ns 1, nr 3
    Aug 13 06:58:47.160: Tnl 22396 L2TP: I SCCCN from ggsnlac tnl 9
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Got a Challenge Response in SCCCN from ggsnlac
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Tunnel Authentication success
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Tunnel state change from wait-ctl-reply to established
    :: ROUTER-VPDN-ISP menerima ACK (acknowledgement) dari GGSN-XL [LAC]
    :: CHAP Style Tunnel authentication berhasil
    :: Tunnel Establish.

    ++++++++++++++++++++++++++++++++++++++++++++++
    + 3 WAY EXCHANGE untuk Session Establishment +
    ++++++++++++++++++++++++++++++++++++++++++++++

    Aug 13 06:58:47.160: Tnl 22396 L2TP: SM State established
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Process ctrl pkt peer ns/nr 2/1, our ns/nr 1/3, tunnel->peer_nr 1
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Parse AVP 0, len 8, flag 0×8000 (M)
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Parse ICRQ
    :: ROUTER-VPDN-ISP menerima ICRQ [Incoming Call Request] dari GGSN XL [LAC]

    Aug 13 06:58:47.160: Tnl 22396 L2TP: Parse AVP 14, len 8, flag 0×8000 (M)
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Assigned Call ID 53711
    :: CALLER ID

    Aug 13 06:58:47.160: Tnl 22396 L2TP: Parse AVP 15, len 10, flag 0×8000 (M)
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Serial Number 53711
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Parse AVP 18, len 10, flag 0×8000 (M)
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Bearer Type 3
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Parse AVP 21, len 10, flag 0×8000 (M)
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Called Number 8888
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Parse AVP 22, len 19, flag 0×8000 (M)
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Calling Number 6281808644365
    :: CALLING NUMBER [Nomer XL yang dial APN]

    Aug 13 06:58:47.160: Tnl 22396 L2TP: No missing AVPs in ICRQ
    :: ROUTER-VPDN-ISP check APV dalam ICRQ dari GGSN-XL [LAC]

    Aug 13 06:58:47.160: Tnl 22396 L2TP: I ICRQ, flg TLS, ver 2, len 77, tnl 22396, cl 0, ns 2, nr 1 contiguous pak, size 77
    Aug 13 06:58:47.160: Tnl 22396 L2TP: I ICRQ from ggsnlac tnl 9
    Aug 13 06:58:47.160: Tnl/Sn 22396/68 L2TP: Session FS enabled
    Aug 13 06:58:47.160: Tnl/Sn 22396/68 L2TP: Session state change from idle to wait-connect
    :: Session Tunnel status berubah dari IDLE ke Wait-Connect

    Aug 13 06:58:47.160: Tnl/Sn 22396/68 L2TP: New session created
    Aug 13 06:58:47.160: Tnl/Sn 22396/68 L2TP: O ICRP to ggsnlac 9/53711
    :: ROUTER-VPDN-ISP respon ICRQ GGSN-XL dengan mengirimkan ICRP [Incoming Call Reply] yang berisi session ID [53711]

    Aug 13 06:58:47.160: Tnl/Sn 22396/68 L2TP: O ICRP, flg TLS, ver 2, len 28, tnl 9, cl 53711, ns 1, nr 3
    Aug 13 06:58:47.160: Tnl 22396 L2TP: Control channel retransmit delay set to 1 seconds
    Aug 13 06:58:47.420: Tnl 22396 L2TP: Verify ns/nr, peer ns/nr 3/2, our ns/nr 2/3
    Aug 13 06:58:47.420: Tnl 22396 L2TP: Peer acknowledging through 2
    Aug 13 06:58:47.420: Tnl 22396 L2TP: Process ctrl pkt peer ns/nr 3/2, our ns/nr 2/4, tunnel->peer_nr 2
    Aug 13 06:58:47.420: Tnl 22396 L2TP: Clean resendQ, peer_nr 2, last_rx_nr 1
    Aug 13 06:58:47.420: Tnl 22396 L2TP: Cleaned ns 1 from resendQ
    Aug 13 06:58:47.424: Tnl 22396 L2TP: Currently 0 messages on the resend queue
    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Parse AVP 0, len 8, flag 0×8000 (M)
    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Parse ICCN
    :: GGSN-XL respon dengan mengirimkan ICCN [Incoming Call Connected]
    :: ke ROUTER-VPDN-ISP yang berisi informasi negosiasi LCP-LCP antara GGSN-XL dan USER.
    :: termasuk user mengirimkan username APN

    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Parse AVP 24, len 10, flag 0×8000 (M)
    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Connect Speed 0
    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Parse AVP 19, len 10, flag 0×8000 (M)
    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Framing Type 3
    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Parse AVP 26, len 10, flag 0×0
    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Initial LCPREQ
    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Parse AVP 27, len 14, flag 0×0
    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Last Sent LCPREQ
    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Parse AVP 28, len 10, flag 0×0
    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Last Rx LCPREQ
    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Parse AVP 36, len 38, flag 0×8000 (M)
    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Random Vector

    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Parse AVP 29, len 8, flag 0×0
    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Proxy Auth Type 3
    :: Proxy Authentication dalam Proses.

    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Parse AVP 30, len 38, flag 0×4000 (H)
    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Proxy Auth Name sid@speed.net.id
    :: Username Authentication

    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Parse AVP 32, len 8, flag 0×0
    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Proxy Auth ID 0
    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Parse AVP 33, len 22, flag 0×4000 (H)
    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Proxy Auth Resp
    :: ROUTER-VPDN-ISP [LNS] generate Authentication Challenge.
    :: Proxy Auth merespon melalui AVP 33

    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: Parse AVP 37, len 10, flag 0×0
    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: No missing AVPs in ICCN
    :: ROUTER-VPDN-ISP check AVPs Authentication.

    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: I ICCN, flg TLS, ver 2, len 198, tnl 22396, cl 68, ns 3, nr 2 contiguous pak, size 198
    Aug 13 06:58:47.424: Tnl 22396 L2TP: Sending ZLB ACK ns/nr 2/4
    :: ROUTER-VPDN-ISP mengirim ZLB ACK ke GGSN-XL [LAC]

    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: O ZLB ctrl ack, flg TLS, ver 2, len 12, tnl 9, cl 0, ns 2, nr 4
    Aug 13 06:58:47.424: Tnl/Sn 22396/68 L2TP: I ICCN from ggsnlac tnl 9, cl 53711
    :: GGSN XL mengirimkan ZLB control ack menggunakan ICCN ke ROUTER-VPDN-ISP
    :: bahwa Session [Virtual Interface] siap establish

    Aug 13 06:58:47.424: sid@speed.net.id Tnl/Sn 22396/68 L2TP: Session state change from wait-connect to wait-for-service-selection
    Aug 13 06:58:47.452: Vi3 Tnl/Sn 22396/68 L2TP: Virtual interface created for sid@speed.net.id, bandwidth 100000 Kbps
    Aug 13 06:58:47.452: Vi3 Tnl/Sn 22396/68 L2TP: VPDN session up
    Aug 13 06:58:47.452: Vi3 Tnl/Sn 22396/68 L2TP: Session state change from wait-for-service-selection to established
    :: ROUTER-VPDN-ISP create Virtual Interface untuk username : sid@speed.net.id dengan bw 100000 kbps
    :: Session established.

    Aug 13 06:58:47.456: %LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up
    :: Virtual Interface [Virtual-Access3] langsung UP di ROUTER-VPDN-ISP.
    :: USER HARUSNYA SUDAH DAPAT IP dan BISA AKSES INTERNET via GPRS

    Aug 13 06:58:47.456: Vi3 VPDN FS Network to tunnel: Punted 45 byte pak to l2x process queue
    Aug 13 06:58:47.456: Vi3 VPDN FS Network to tunnel: Punted 50 byte pak to l2x process queue
    Aug 13 06:58:47.456: Vi3 VPDN PROCESS Into tunnel: Sending 45 byte pak
    Aug 13 06:58:47.456: L2X: UDP socket write 45 bytes, 10.170.41.198(1701) to 202.152.240.154(1701)
    Aug 13 06:58:47.456: Vi3 VPDN PROCESS Into tunnel: Sending 50 byte pak
    Aug 13 06:58:47.456: L2X: UDP socket write 50 bytes, 10.170.41.198(1701) to 202.152.240.154(1701)
    Aug 13 06:58:47.740: VPDN CEF From tunnel: Received 76 byte pak
    Aug 13 06:58:47.740: Vi3 VPDN FS Tunnel to network: Sending 24 byte pak
    Aug 13 06:58:47.740: Vi3 VPDN CEF Tunnel to network: Fastswitching failed, punting pkt to process
    Aug 13 06:58:47.740: Vi3 VPDN CEF From tunnel: Punted 24 byte pak to ppp parse and iqueue
    Aug 13 06:58:47.740: VPDN CEF From tunnel: Received 64 byte pak
    Aug 13 06:58:47.740: Vi3 VPDN FS Tunnel to network: Sending 12 byte pak
    Aug 13 06:58:47.740: Vi3 VPDN CEF Tunnel to network: Fastswitching failed, punting pkt to process
    Aug 13 06:58:47.740: Vi3 VPDN CEF From tunnel: Punted 12 byte pak to ppp parse and iqueue
    Aug 13 06:58:47.740: Vi3 VPDN FS Network to tunnel: Punted 62 byte pak to l2x process queue
    Aug 13 06:58:47.740: Vi3 VPDN PROCESS Into tunnel: Sending 62 byte pak
    Aug 13 06:58:47.740: L2X: UDP socket write 62 bytes, 10.170.41.198(1701) to 202.152.240.154(1701)
    Aug 13 06:58:48.036: VPDN CEF From tunnel: Received 76 byte pak
    Aug 13 06:58:48.036: Vi3 VPDN FS Tunnel to network: Sending 24 byte pak
    Aug 13 06:58:48.036: Vi3 VPDN CEF Tunnel to network: Fastswitching failed, punting pkt to process
    Aug 13 06:58:48.036: Vi3 VPDN CEF From tunnel: Punted 24 byte pak to ppp parse and iqueue
    Aug 13 06:58:48.036: Vi3 VPDN FS Network to tunnel: Punted 62 byte pak to l2x process queue
    Aug 13 06:58:48.036: Vi3 VPDN PROCESS Into tunnel: Sending 62 byte pak
    Aug 13 06:58:48.036: L2X: UDP socket write 62 bytes, 10.170.41.198(1701) to 202.152.240.154(1701)
    Aug 13 06:58:48.036: Vi3 VPDN FS Network to tunnel: Punted 116 byte pak to l2x process queue
    Aug 13 06:58:48.036: Vi3 VPDN PROCESS Into tunnel: Sending 116 byte pak
    Aug 13 06:58:48.036: L2X: UDP socket write 116 bytes, 10.170.41.198(1701) to 202.152.240.154(1701)

    +++++++++++++++++++++
    + DISCONNECT PROSES +
    +++++++++++++++++++++

    gprs-l2tp-disconnect-proses.gif

    The PPP/L2TP Disconnect Sequence

    1.The remote user drops the ISDN link in order to drop the call to the LAC.
    2.The LAC PPP state machine terminates and the LCP state is Closed.
    3.In order to notify the LNS of the disconnection of the session, the LAC sends a Call-Disconnect-Notify (CDN) and destroys the session. The CDN contains an AVP 1 result code, which has “Loss of carrier” as the reason for the disconnect. The session is now in an IDLE state.
    4.The LNS sends a ZLB message, which is a sequenced acknowledgement, and destroys the session. The session is now in an IDLE state.
    5.The LNS takes down the local PPP interface. The virtual access interface changes state to Down:
    * IPCP is closed, LCP is closed, and the PPP state machine is declared Down.
    * The host route to the remote user is removed from the LNS routing table.
    * The tunnel state is now No-Sessions-Left on both the LAC and the LNS.
    6.Because this is the last session within the tunnel, the control connection can now be shut down. The default timers for tunnel shutdown are 10 seconds for the LNS and 15 seconds for the LAC.
    7.The LNS sends a Stop-Control-Connection-Notification (Stop-CCN) to the LAC in order to close down the control connection and tunnel. The Stop-CCN contains the reason for the tunnel shutdown, which is “Request to clear control connection”. The tunnel is now in an IDLE state.
    8.The LAC sends a ZLB message, which is a sequenced acknowledgement, to the LNS. The tunnel is now in an IDLE state.
    9. The tunnel is now shut down.

    Note: Either the LAC or LNS can initiate the session and control connection teardown. It is not necessary to clear the sessions within the tunnel before the tunnel can be shut down.

    ++++++++++++++++++++++++
    + Persi Rahman Isnaini +
    ++++++++++++++++++++++++

    :: User Disconnect
    :: LAC [GGSN XL] Terima Request dari User

    Aug 13 06:58:55.776: Vi3 Tnl/Sn 22396/68 L2TP: Parse AVP 0, len 8, flag 0×8000 (M)
    Aug 13 06:58:55.776: Vi3 Tnl/Sn 22396/68 L2TP: Parse CDN
    :: GGSN-XL [LAC] mengirimkan CDN [Call Disconnect Notify] ke ROUTER-VPDN-ISP dan destroy Session.
    :: CDN ini berisi AVP 1 dengan Result Code (1) : Loss of Carrier (link putus :))
    :: lihat dibawah :

    Aug 13 06:58:55.776: Vi3 Tnl/Sn 22396/68 L2TP: Parse AVP 1, len 10, flag 0×8000 (M)
    Aug 13 06:58:55.776: Vi3 Tnl/Sn 22396/68 L2TP: Result code(1): 1: Loss of carrier
    Aug 13 06:58:55.776: Error code(0): No error
    Aug 13 06:58:55.776: Vi3 Tnl/Sn 22396/68 L2TP: Parse AVP 14, len 8, flag 0×8000 (M)
    Aug 13 06:58:55.776: Vi3 Tnl/Sn 22396/68 L2TP: Assigned Call ID 53711
    Aug 13 06:58:55.776: Vi3 Tnl/Sn 22396/68 L2TP: No missing AVPs in CDN
    :: ROUTER-VPDN-ISP check AVP-AVP dari GGSN [LAC]

    Aug 13 06:58:55.776: Vi3 Tnl/Sn 22396/68 L2TP: I CDN, flg TLS, ver 2, len 38, tnl 22396, cl 68, ns 4, nr 2 contiguous pak, size 38
    Aug 13 06:58:55.776: Tnl 22396 L2TP: Sending ZLB ACK ns/nr 2/5
    :: ROUTER-VPDN-ISP mengirimkan ZLB [Zero Length Body] ke GGSN [LAC] untuk Acknowledge CDN.

    Aug 13 06:58:55.776: Vi3 Tnl/Sn 22396/68 L2TP: O ZLB ctrl ack, flg TLS, ver 2, len 12, tnl 9, cl 0, ns 2, nr 5
    Aug 13 06:58:55.780: Vi3 Tnl/Sn 22396/68 L2TP: I CDN from ggsnlac tnl 9, cl 53711
    :: Respon dari GGSN-XL [LAC] acknowledge Tunnel Session ID 53711 untuk di destroy

    Aug 13 06:58:55.780: Vi3 Tnl/Sn 22396/68 L2TP: disconnect (L2X) IETF: 2/lost-carrier Ascend: 61/VPDN Carrier Loss
    Aug 13 06:58:55.780: Vi3 Tnl/Sn 22396/68 L2TP: Destroying session
    :: ROUTER-VPDN-ISP destroy Tunnel Session

    Aug 13 06:58:55.780: Vi3 Tnl/Sn 22396/68 L2TP: Session state change from established to idle
    :: Tunnel Session berubah status dari Establish ke Idle.

    Aug 13 06:58:55.780: Vi3 Tnl/Sn 22396/68 L2TP: Accounting stop sent
    Aug 13 06:58:55.780: Vi3 Tnl/Sn 22396/68 L2TP: Unbinding session from idb
    Aug 13 06:58:55.780: Vi3 VPDN: Resetting interface
    Aug 13 06:58:55.780: Tnl 22396 L2TP: Tunnel state change from established to no-sessions-left
    Aug 13 06:58:55.780: Tnl 22396 L2TP: No more sessions in tunnel, shutdown (likely) in 10 seconds
    Aug 13 06:58:55.784: %LINK-3-UPDOWN: Interface Virtual-Access3, changed state to down
    :: ROUTER-VPDN-ISP stop accounting dan unbinding session.
    :: Tunnel Session berubah status ke no-sessions-left
    :: Interface Virtual-Access3 berubah status ke DOWN setelah 10 detik di ROUTER-VPDN-ISP [LNS]
    :: dan 15 detik di GGSN-XL [LAC] (default shutdown
    :: interface bila session dalam tunnel sudah tidak ada lagi)

    Aug 13 06:58:56.600: VPDN CEF From tunnel: Received 84 byte pak
    Aug 13 06:58:56.600: L2X: Punting to L2TP control message queue
    Aug 13 06:58:56.600: VPDN CEF From tunnel: Pak consumed
    Aug 13 06:58:56.600: Tnl 22396 L2TP: Verify ns/nr, peer ns/nr 4/2, our ns/nr 2/5
    Aug 13 06:58:56.604: Tnl 22396 L2TP: Process ctrl pkt peer ns/nr 4/2, our ns/nr 2/5, tunnel->peer_nr 2
    Aug 13 06:58:56.604: Tnl 22396 L2TP: Dropping old CM CDN, Ns 4, expected 5
    Aug 13 06:58:56.784: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to down
    Aug 13 06:58:57.648: VPDN CEF From tunnel: Received 84 byte pak
    Aug 13 06:58:57.648: L2X: Punting to L2TP control message queue
    Aug 13 06:58:57.648: VPDN CEF From tunnel: Pak consumed
    Aug 13 06:58:57.648: Tnl 22396 L2TP: Verify ns/nr, peer ns/nr 4/2, our ns/nr 2/5
    Aug 13 06:58:57.648: Tnl 22396 L2TP: Process ctrl pkt peer ns/nr 4/2, our ns/nr 2/5, tunnel->peer_nr 2
    Aug 13 06:58:57.648: Tnl 22396 L2TP: Dropping old CM CDN, Ns 4, expected 5
    Aug 13 06:58:58.664: VPDN CEF From tunnel: Received 84 byte pak
    Aug 13 06:58:58.664: L2X: Punting to L2TP control message queue
    Aug 13 06:58:58.664: VPDN CEF From tunnel: Pak consumed
    Aug 13 06:58:58.664: Tnl 22396 L2TP: Verify ns/nr, peer ns/nr 4/2, our ns/nr 2/5
    Aug 13 06:58:58.664: Tnl 22396 L2TP: Process ctrl pkt peer ns/nr 4/2, our ns/nr 2/5, tunnel->peer_nr 2
    Aug 13 06:58:58.664: Tnl 22396 L2TP: Dropping old CM CDN, Ns 4, expected 5 (sent zlb ack)
    Aug 13 06:58:58.664: Tnl 22396 L2TP: Sending ZLB ACK ns/nr 2/5
    Aug 13 06:58:58.664: Tnl 22396 L2TP: O ZLB ctrl ack, flg TLS, ver 2, len 12, tnl 9, cl 0, ns 2, nr 5
    Aug 13 06:59:05.780: Tnl 22396 L2TP: O StopCCN to ggsnlac tnlid 9
    :: ROUTER-VPDN-ISP mengirimkan StopCCN (Stop Control Connection Notification) ke GGSN-XL [LAC]
    :: untuk close down control connection dan tunnel.
    :: yang berisi juga reasons kenapa tunnel harus di shutdown.
    :: serta mengirimkan ZLB Ack juga ke GGSN-XL

    Aug 13 06:59:05.780: Tnl 22396 L2TP: O StopCCN, flg TLS, ver 2, len 38, tnl 9, cl 0, ns 2, nr 5
    Aug 13 06:59:05.780: Tnl 22396 L2TP: Control channel retransmit delay set to 1 seconds
    Aug 13 06:59:05.780: Tnl 22396 L2TP: Tunnel state change from no-sessions-left to shutting-down
    Aug 13 06:59:06.096: VPDN CEF From tunnel: Received 64 byte pak
    Aug 13 06:59:06.096: L2X: Punting to L2TP control message queue
    Aug 13 06:59:06.100: VPDN CEF From tunnel: Pak consumed
    Aug 13 06:59:06.100: Tnl 22396 L2TP: Verify ns/nr, peer ns/nr 5/3, our ns/nr 3/5
    Aug 13 06:59:06.100: Tnl 22396 L2TP: Peer acknowledging through 3
    Aug 13 06:59:06.100: Tnl 22396 L2TP: Dropped ZLB ACK
    :: GGSN-XL kirim Dropped ZLB ACK ke ROUTER-VPDN-ISP

    Aug 13 06:59:06.204: VPDN CEF From tunnel: Received 64 byte pak
    Aug 13 06:59:06.204: L2X: Punting to L2TP control message queue
    Aug 13 06:59:06.204: VPDN CEF From tunnel: Pak consumed
    Aug 13 06:59:06.204: Tnl 22396 L2TP: Verify ns/nr, peer ns/nr 5/3, our ns/nr 3/5
    Aug 13 06:59:06.204: Tnl 22396 L2TP: Dropped ZLB ACK
    Aug 13 06:59:06.780: Tnl 22396 L2TP: Clean resendQ, peer_nr 3, last_rx_nr 2
    Aug 13 06:59:06.780: Tnl 22396 L2TP: Cleaned ns 2 from resendQ
    Aug 13 06:59:06.780: Tnl 22396 L2TP: Currently 0 messages on the resend queue
    Aug 13 06:59:06.780: Tnl 22396 L2TP: Control channel retransmit delay set to 1 seconds
    Aug 13 06:59:10.780: Tnl 22396 L2TP: Shutdown tunnel
    :: TUNNEL SHUTDOWN.

    Aug 13 06:59:10.780: Tnl 22396 L2TP: Tunnel state change from shutting-down to idle

    Posted in GPRS | No Comments »