Topic: LCP: timeout sending Config-Requests

[guest22]

Ok, tried a different route/ISP (UMTS)

Here are the results as seen on the SME 7.4 box:

------ (private details removed)
Mar 22 19:43:26 pptpd[23638]: CTRL: Client xx.xx.xx.xx control connection started
Mar 22 19:43:27 pptpd[23638]: CTRL: Starting call (launching pppd, opening GRE)
Mar 22 19:43:27 pppd[23639]: Plugin radius.so loaded.
Mar 22 19:43:27 pppd[23639]: RADIUS plugin initialized.
Mar 22 19:43:27 pppd[23639]: pppd 2.4.4 started by root, uid 0
Mar 22 19:43:27 kernel: divert: not allocating divert_blk for non-ethernet device ppp0
Mar 22 19:43:27 pppd[23639]: Using interface ppp0
Mar 22 19:43:27 pppd[23639]: Connect: ppp0 <--> /dev/pts/1
Mar 22 19:43:57 pppd[23639]: LCP: timeout sending Config-Requests
Mar 22 19:44:03 pptpd[23638]: CTRL: Reaping child PPP[23639]
Mar 22 19:44:03 pppd[23639]: Modem hangup
Mar 22 19:44:03 pppd[23639]: Connection terminated.
Mar 22 19:44:03 kernel: divert: no divert_blk to free, ppp0 not ethernet
Mar 22 19:44:03 pppd[23639]: Exit.
Mar 22 19:44:03 pptpd[23638]: CTRL: Client xx.xx.xx.xx control connection finished
-----

Thanks,
guest

[electroman00]

Reason to VPN to it is to access the server-manager.

Sorry, didn't realize you were using SME default PPTP.

Was the PIX configured for PPTP??

Not sure if this is your Cisco PIX, you weren't specific.
Cisco Pix 500

hth

[electroman00]

What network card is in the SME.

Code: [Select]

Mar 22 19:43:27 kernel: divert: not allocating divert_blk for non-ethernet device ppp0
That looks like a nic driver issue or an SME bug.

[CharlieBrady]

I disabled LCP it in the properties of the XP network connection for the vpn

Really? Are you sure you didn't disable 'LCP extensions'? LCP is necessary:

http://www.ietf.org/rfc/rfc1548.txt

    Link Control Protocol

      In order to be sufficiently versatile to be portable to a wide
      variety of environments, PPP provides a Link Control Protocol
      (LCP).  The LCP is used to automatically agree upon the
      encapsulation format options, handle varying limits on sizes of
      packets, authenticate the identity of its peer on the link,
      determine when a link is functioning properly and when it is
      defunct, detect a looped-back link and other common
      misconfiguration errors, and terminate the link.

[guest22]

Was the PIX configured for PPTP??

Sorry, I don't know. But I can ask staff at ISP2 to change whatever I suggest.

Thanks,
guest

[guest22]

What network card is in the SME.

lspci:
02:00.1 PIC: Intel Corporation 6700/6702PXH I/OxAPIC Interrupt Controller A (rev 09)
03:02.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 6c)

lsmod:
e1000                 120273  0
3c59x                  41469  0

show config:
EthernetAssign=normal
EthernetDriver1=3c59x
EthernetDriver2=e1000


Thanks,
guest

[CharlieBrady]

What network card is in the SME.

Code: [Select]

Mar 22 19:43:27 kernel: divert: not allocating divert_blk for non-ethernet device ppp0
That looks like a nic driver issue or an SME bug.

Neither. It's harmless log noise from the diverter kernel module (an attempt was made to remove it in 2005, but wasn't followed through):

http://oss.sgi.com/archives/netdev/2005-01/msg00586.html

[David Harper]

When I did some Cisco training a few years back I was told that the PIX devices acted rather differently to standard routers in a variety of situations. So unfortunately there may be something PIX-specific else going on that is preventing the VPN connection from working.

[guest22]

According to:
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a0080094a5a.shtml#maintask1

section: PPTP with the Client Outside and the Server Inside

TCP port 1723 needs to added to the rules. Reading this, I vaguely remember this requirement from earlier discussion on the forums. I have requested ISP2 to perform the change.

Searching the forums on '1723' results in a massive amount of posts....

Will post the result.

Thanks,
guest

[Stefano]

as far as I can see, you have it already

access-list acl_outside line 21 extended permit tcp any host xx.xx.xx.xx eq pptp (hitcnt=17)

Ciao
Stefano

[electroman00]

Neither. It's harmless log noise from the diverter kernel module (an attempt was made to remove it in 2005, but wasn't followed through):

http://oss.sgi.com/archives/netdev/2005-01/msg00586.html

Yea I researched that and found it and was going to post it, then the couch got me.