Linux PPP protocol development
 help / color / mirror / Atom feed
* How to fix continuous ConfReq's on celluar internet connection
@ 2008-08-10 23:06 Marshall Crocker
  2008-08-10 23:11 ` James Cameron
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: Marshall Crocker @ 2008-08-10 23:06 UTC (permalink / raw)
  To: linux-ppp

Hi all,

For over a year now I've been having problems with ConfReq's resetting 
my ppp connection to my cellular EvDO internet provider.  I can connect 
with no problems but usually the connection will only stay up for a few 
minutes (sometimes a few seconds) before I receive a ConfReq.  I think 
the ConfReq is sent because I'm in a fringe area of service and my 
connection is switching between EvDO (3G broadband speeds) and 1xRTT 
(144 Kbps 2.5G).  It may also be that I'm between two towers and the 
connection is bouncing between the two thereby requiring my host to 
reconfigure.

The biggest problem with this behavior is that the ppp0 interface is 
brought down after the ConfReq is received.  Any TCP connections that 
were in progress get closed.  In Windows, the connection is reconfigured 
but either the interface isn't completely brought down or a "no route to 
host" isn't sent  for each open connection and the packets just get 
dropped during the reconfigure and then retransmitted once the 
connection comes back up so actions such as browsing  web pages only get 
stalled briefly.

So my questions are

1) Has anyone else seen this behavior or is it specific to my internet 
provider?

2) Is there some pppd option that I'm missing that could solve this problem?

3) Should I block these ConfReq's once the connection is established 
using iptables or some other method?  I assume not since the tower may 
drop my connection if my host doesn't respond.

4) Maybe I could hack pppd to not bring the connection down during 
reconfiguration/reauthenication if the connection details are the same 
(i.e. same local and ptp ip addresses, same dns, etc. )?

I know there is a firmware update to my EvDO card (a Kyocera KPC650) 
which will allow you to "lock" in a tower and technology (EvDO or 1xRTT) 
but I don't think it will work in linux unless the KPC650 command and 
control protocol has been decoded.  It may be possible to do the "lock" 
from the windows client and then the card stays locked but I don't know.

Any help is greatly appreciated as I have been stuck using XP and ICS 
instead of putting my EvDO card in my soekris router.

Below is a snip from the pppd debug log.  I can also provide the windows 
ppp log if that would help.

Thanks,
Marshall

local  IP address X.X.X.X
 remote IP address X.X.X.X
 primary   DNS address X.X.X.X
 secondary DNS address X.X.X.X
 Script /etc/ppp/ip-up started (pid 15676)
 Script /etc/ppp/ip-up finished (pid 15676), status = 0x1
 rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0xdd5ce74b>]
 Connect time 0.3 minutes.
 Sent 1115 bytes, received 778 bytes.
 Script /etc/ppp/ip-down started (pid 15685)
 sent [LCP ConfReq id=0x8e <asyncmap 0x0> <magic 0x6a4b56c2> <pcomp> 
<accomp>]
 sent [LCP ConfAck id=0x1 <asyncmap 0x0> <auth pap> <magic 0xdd5ce74b>]
 rcvd [LCP ConfAck id=0x8e <asyncmap 0x0> <magic 0x6a4b56c2> <pcomp> 
<accomp>]
 sent [LCP EchoReq id=0x0 magic=0x6a4b56c2]
 sent [PAP AuthReq id=0xb2 user="XXXXX@cs3g.com" password=<hidden>]
 Script /etc/ppp/ip-down finished (pid 15685), status = 0x0
 rcvd [LCP EchoRep id=0x0 magic=0xdd5ce74b]
 rcvd [PAP AuthAck id=0xb2 ""]
 PAP authentication succeeded
 sent [IPCP ConfReq id=0x57 <compress VJ 0f 01> <addr X.X.X.X> <ms-dns1 
0.0.0.0> <ms-dns3 0.0.0.0>]
 rcvd [IPCP ConfReq id=0x1 <addr X.X.X.X>]
 sent [IPCP ConfAck id=0x1 <addr X.X.X.X>]
 rcvd [IPCP ConfRej id=0x57 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x58 <addr X.X.X.X> <ms-dns1 0.0.0.0> <ms-dns3 
0.0.0.0>]
 rcvd [IPCP ConfNak id=0x58 <ms-dns1 X.X.X.X> <ms-dns3 X.X.X.X>]
 sent [IPCP ConfReq id=0x59 <addr X.X.X.X> <ms-dns1 X.X.X.X> <ms-dns3 
X.X.X.X>]
 rcvd [IPCP ConfAck id=0x59 <addr X.X.X.X> <ms-dns1 X.X.X.X> <ms-dns3 
X.X.X.X>]
 Cannot determine ethernet address for proxy ARP
 local  IP address X.X.X.X
 remote IP address X.X.X.X
 primary   DNS address X.X.X.X
 secondary DNS address X.X.X.X
 Script /etc/ppp/ip-up started (pid 15691)
 Script /etc/ppp/ip-up finished (pid 15691), status = 0x1

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: How to fix continuous ConfReq's on celluar internet connection
  2008-08-10 23:06 How to fix continuous ConfReq's on celluar internet connection Marshall Crocker
@ 2008-08-10 23:11 ` James Cameron
  2008-08-10 23:21 ` James Cameron
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: James Cameron @ 2008-08-10 23:11 UTC (permalink / raw)
  To: linux-ppp

Have you tried the demand option?  This keeps the network interface
present over a reconfiguration.

-- 
James Cameron                         http://quozl.netrek.org/
HP Open Source, Volunteer             http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: How to fix continuous ConfReq's on celluar internet connection
  2008-08-10 23:06 How to fix continuous ConfReq's on celluar internet connection Marshall Crocker
  2008-08-10 23:11 ` James Cameron
@ 2008-08-10 23:21 ` James Cameron
  2008-08-10 23:28 ` Marshall Crocker
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: James Cameron @ 2008-08-10 23:21 UTC (permalink / raw)
  To: linux-ppp

Oh, and something else that springs to mind ... when I had this problem
that you report with 1x RTT modems, an analysis of the packet stream
with pppdump and tcpdump resulted in a correlation between certain
packets and a reconfiguration event.

I could force it to occur by emitting packets to the modem with IP
addresses that were incorrect.  The provider's back-end NAT equipment
was closing the session when it saw such invalid packets.

The host was multi-homed, and when the 1x RTT link came up the default
route was swung onto the link.  Existing connections began to emit
packets to the modem link with a source IP corresponding to the previous
default route.  It was these packets which caused the reconfiguration.

In the end what solved the problem for me was filtering the packets
before they reached the modem ... by adding the following to an ip-up
script:

        iptables --insert OUTPUT 1 --source 192.168.0.0/255.255.0.0 \
            --destination 0.0.0.0/0.0.0.0 --jump DROP \
            --out-interface ${PPP_IFACE}

        iptables --insert OUTPUT 1 --source 10.0.0.0/255.255.0.0 \
            --destination 0.0.0.0/0.0.0.0 --jump DROP \
            --out-interface ${PPP_IFACE}

        iptables --insert OUTPUT 1 --protocol GRE --jump DROP \
            --out-interface ${PPP_IFACE}

In my case, 10.0/16 was a local LAN, and 192.168/16 was the satellite
service.

It looks like I've said all this before:

http://osdir.com/ml/linux.ppp/2007-10/msg00011.html

-- 
James Cameron                         http://quozl.netrek.org/
HP Open Source, Volunteer             http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: How to fix continuous ConfReq's on celluar internet connection
  2008-08-10 23:06 How to fix continuous ConfReq's on celluar internet connection Marshall Crocker
  2008-08-10 23:11 ` James Cameron
  2008-08-10 23:21 ` James Cameron
@ 2008-08-10 23:28 ` Marshall Crocker
  2008-08-11  0:04 ` Marshall Crocker
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: Marshall Crocker @ 2008-08-10 23:28 UTC (permalink / raw)
  To: linux-ppp

James Cameron wrote:
> Have you tried the demand option?  This keeps the network interface
> present over a reconfiguration.
Doh...after sending my original email I decided to add idle and demand
options to my peers file so the connection wouldn't be up all the time
(been meaning to that for a while anyway).  I read the man pages to see
what arguments they needed and saw that demand keeps the network
interface in between connections.  That appears to be working although
the ConfReq's are still coming and the connection is averaging about 0.2
minutes up.

I had no idea that the demand option would keep the ppp interface.  I
feel silly for putting up with this for over a year and the whole time a
simple pppd option would work around it.

Marshall


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: How to fix continuous ConfReq's on celluar internet connection
  2008-08-10 23:06 How to fix continuous ConfReq's on celluar internet connection Marshall Crocker
                   ` (2 preceding siblings ...)
  2008-08-10 23:28 ` Marshall Crocker
@ 2008-08-11  0:04 ` Marshall Crocker
  2008-08-11  0:06 ` Bill Unruh
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: Marshall Crocker @ 2008-08-11  0:04 UTC (permalink / raw)
  To: linux-ppp

>
> The host was multi-homed, and when the 1x RTT link came up the default
> route was swung onto the link.  Existing connections began to emit
> packets to the modem link with a source IP corresponding to the previous
> default route.  It was these packets which caused the reconfiguration.
>   
I'm not doing any sort of multihoming so there is no default route until 
the ppp connection comes up. No invalid packets should be making it to 
the ISP but I'll do a capture and see what comes up...

> It looks like I've said all this before:
>
> http://osdir.com/ml/linux.ppp/2007-10/msg00011.html
>   
Sorry....I did a search on the Nabble archive for ConfReq but that 
thread wasn't returned or at least I didn't see it. 

Thanks for your help.

Marshall


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: How to fix continuous ConfReq's on celluar internet connection
  2008-08-10 23:06 How to fix continuous ConfReq's on celluar internet connection Marshall Crocker
                   ` (3 preceding siblings ...)
  2008-08-11  0:04 ` Marshall Crocker
@ 2008-08-11  0:06 ` Bill Unruh
  2008-08-11  5:03 ` Marshall Crocker
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: Bill Unruh @ 2008-08-11  0:06 UTC (permalink / raw)
  To: linux-ppp

On Sun, 10 Aug 2008, Marshall Crocker wrote:

> Hi all,
>
> For over a year now I've been having problems with ConfReq's resetting my ppp 
> connection to my cellular EvDO internet provider.  I can connect with no 
> problems but usually the connection will only stay up for a few minutes 
> (sometimes a few seconds) before I receive a ConfReq.  I think the ConfReq is 
> sent because I'm in a fringe area of service and my connection is switching 
> between EvDO (3G broadband speeds) and 1xRTT (144 Kbps 2.5G).  It may also be 
> that I'm between two towers and the connection is bouncing between the two 
> thereby requiring my host to reconfigure.
>
> The biggest problem with this behavior is that the ppp0 interface is brought 
> down after the ConfReq is received.  Any TCP connections that were in 
> progress get closed.  In Windows, the connection is reconfigured but either 
> the interface isn't completely brought down or a "no route to host" isn't 
> sent  for each open connection and the packets just get dropped during the 
> reconfigure and then retransmitted once the connection comes back up so 
> actions such as browsing  web pages only get stalled briefly.
>
> So my questions are
>
> 1) Has anyone else seen this behavior or is it specific to my internet 
> provider?
>
> 2) Is there some pppd option that I'm missing that could solve this problem?
>
> 3) Should I block these ConfReq's once the connection is established using 
> iptables or some other method?  I assume not since the tower may drop my 
> connection if my host doesn't respond.
>
> 4) Maybe I could hack pppd to not bring the connection down during 
> reconfiguration/reauthenication if the connection details are the same (i.e. 
> same local and ptp ip addresses, same dns, etc. )?
>
> I know there is a firmware update to my EvDO card (a Kyocera KPC650) which 
> will allow you to "lock" in a tower and technology (EvDO or 1xRTT) but I 
> don't think it will work in linux unless the KPC650 command and control 
> protocol has been decoded.  It may be possible to do the "lock" from the 
> windows client and then the card stays locked but I don't know.
>
> Any help is greatly appreciated as I have been stuck using XP and ICS instead 
> of putting my EvDO card in my soekris router.
>
> Below is a snip from the pppd debug log.  I can also provide the windows ppp 
> log if that would help.

Don't remove the timing information from the log ( or perpahs you are not
giving the syslog output
Put
local2.*;daemon.*     /var/log/ppplog
into /etc/syslog.conf
and then do 
killall -1 syslogd

(do not forget the -1)
)

You could also try disabling echo req. Perhaps that it triggering the far
end to dump the connection.




>
> Thanks,
> Marshall
>
> local  IP address X.X.X.X
> remote IP address X.X.X.X
> primary   DNS address X.X.X.X
> secondary DNS address X.X.X.X
> Script /etc/ppp/ip-up started (pid 15676)
> Script /etc/ppp/ip-up finished (pid 15676), status = 0x1
> rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0xdd5ce74b>]
> Connect time 0.3 minutes.
> Sent 1115 bytes, received 778 bytes.
> Script /etc/ppp/ip-down started (pid 15685)
> sent [LCP ConfReq id=0x8e <asyncmap 0x0> <magic 0x6a4b56c2> <pcomp> 
> <accomp>]
> sent [LCP ConfAck id=0x1 <asyncmap 0x0> <auth pap> <magic 0xdd5ce74b>]
> rcvd [LCP ConfAck id=0x8e <asyncmap 0x0> <magic 0x6a4b56c2> <pcomp> 
> <accomp>]
> sent [LCP EchoReq id=0x0 magic=0x6a4b56c2]
> sent [PAP AuthReq id=0xb2 user="XXXXX@cs3g.com" password=<hidden>]
> Script /etc/ppp/ip-down finished (pid 15685), status = 0x0
> rcvd [LCP EchoRep id=0x0 magic=0xdd5ce74b]
> rcvd [PAP AuthAck id=0xb2 ""]
> PAP authentication succeeded
> sent [IPCP ConfReq id=0x57 <compress VJ 0f 01> <addr X.X.X.X> <ms-dns1 
> 0.0.0.0> <ms-dns3 0.0.0.0>]
> rcvd [IPCP ConfReq id=0x1 <addr X.X.X.X>]
> sent [IPCP ConfAck id=0x1 <addr X.X.X.X>]
> rcvd [IPCP ConfRej id=0x57 <compress VJ 0f 01>]
> sent [IPCP ConfReq id=0x58 <addr X.X.X.X> <ms-dns1 0.0.0.0> <ms-dns3 
> 0.0.0.0>]
> rcvd [IPCP ConfNak id=0x58 <ms-dns1 X.X.X.X> <ms-dns3 X.X.X.X>]
> sent [IPCP ConfReq id=0x59 <addr X.X.X.X> <ms-dns1 X.X.X.X> <ms-dns3 
> X.X.X.X>]
> rcvd [IPCP ConfAck id=0x59 <addr X.X.X.X> <ms-dns1 X.X.X.X> <ms-dns3 
> X.X.X.X>]
> Cannot determine ethernet address for proxy ARP
> local  IP address X.X.X.X
> remote IP address X.X.X.X
> primary   DNS address X.X.X.X
> secondary DNS address X.X.X.X
> Script /etc/ppp/ip-up started (pid 15691)
> Script /etc/ppp/ip-up finished (pid 15691), status = 0x1
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

-- 
William G. Unruh   |  Canadian Institute for|     Tel: +1(604)822-3273
Physics&Astronomy  |     Advanced Research  |     Fax: +1(604)822-5324
UBC, Vancouver,BC  |   Program in Cosmology |     unruh@physics.ubc.ca
Canada V6T 1Z1     |      and Gravity       |  www.theory.physics.ubc.ca/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: How to fix continuous ConfReq's on celluar internet connection
  2008-08-10 23:06 How to fix continuous ConfReq's on celluar internet connection Marshall Crocker
                   ` (4 preceding siblings ...)
  2008-08-11  0:06 ` Bill Unruh
@ 2008-08-11  5:03 ` Marshall Crocker
  2008-08-11  5:09 ` James Cameron
  2008-08-11  5:36 ` Marshall Crocker
  7 siblings, 0 replies; 9+ messages in thread
From: Marshall Crocker @ 2008-08-11  5:03 UTC (permalink / raw)
  To: linux-ppp


>> The host was multi-homed, and when the 1x RTT link came up the default
>> route was swung onto the link.  Existing connections began to emit
>> packets to the modem link with a source IP corresponding to the previous
>> default route.  It was these packets which caused the reconfiguration.
>>   
> I'm not doing any sort of multihoming so there is no default route 
> until the ppp connection comes up. No invalid packets should be making 
> it to the ISP but I'll do a capture and see what comes up...

What comes up are packets from a host in my local network getting sent 
out over ppp!  Every time a packet with the source from my internal 
network gets sent over ppp, the connection reconfigures. You were 
exactly right!  What I'm seeing is packets being sent out over ppp such as

192.168.0.10 -> google.com

Which means that my iptables NAT script isn't doing its job. I've never 
claimed to be an iptables expert which is why I've always used 
MonMotha's iptables firewall.  I guess its time to learn....


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: How to fix continuous ConfReq's on celluar internet connection
  2008-08-10 23:06 How to fix continuous ConfReq's on celluar internet connection Marshall Crocker
                   ` (5 preceding siblings ...)
  2008-08-11  5:03 ` Marshall Crocker
@ 2008-08-11  5:09 ` James Cameron
  2008-08-11  5:36 ` Marshall Crocker
  7 siblings, 0 replies; 9+ messages in thread
From: James Cameron @ 2008-08-11  5:09 UTC (permalink / raw)
  To: linux-ppp

On Mon, Aug 11, 2008 at 12:03:58AM -0500, Marshall Crocker wrote:
> What comes up are packets from a host in my local network getting sent  
> out over ppp!  Every time a packet with the source from my internal  
> network gets sent over ppp, the connection reconfigures. You were  
> exactly right!

Fantastic.  It suggests the mobile telephone networks probably use the
same software in their NAT implementations ... hey, it might even be a
feature.

> I guess its time to learn....

Yes, just block the packets that aren't from the source IP that pppd
assigns to the link.

-- 
James Cameron                         http://quozl.netrek.org/
HP Open Source, Volunteer             http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: How to fix continuous ConfReq's on celluar internet connection
  2008-08-10 23:06 How to fix continuous ConfReq's on celluar internet connection Marshall Crocker
                   ` (6 preceding siblings ...)
  2008-08-11  5:09 ` James Cameron
@ 2008-08-11  5:36 ` Marshall Crocker
  7 siblings, 0 replies; 9+ messages in thread
From: Marshall Crocker @ 2008-08-11  5:36 UTC (permalink / raw)
  To: linux-ppp


> Yes, just block the packets that aren't from the source IP that pppd
> assigns to the link.

I tired adding the rule to drop packets with a source of 192.168.0.X 
destined for ppp0 but that didn't appear to work. Most likely due to 
some of the other chains created by MonMontha's script.  I'm curious as 
to why packets with a source from my internal LAN are getting sent out 
over ppp in the first place.  The FORWARD chain looks like:

Chain FORWARD (policy DROP)
target     prot opt source               destination        
INETIN     all  --  anywhere             anywhere           
INETOUT    all  --  anywhere             anywhere           
ACCEPT     all  --  192.168.0.0/24       anywhere 

Is it possible the INETOUT chain gets executed first and sometimes 
bypasses the accept for 192.168.0.0/24?   I'm sure I'll figure it out 
sooner or later but if anyone knows iptables better than me, I'll glady 
accept any suggestions :).

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2008-08-11  5:36 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-10 23:06 How to fix continuous ConfReq's on celluar internet connection Marshall Crocker
2008-08-10 23:11 ` James Cameron
2008-08-10 23:21 ` James Cameron
2008-08-10 23:28 ` Marshall Crocker
2008-08-11  0:04 ` Marshall Crocker
2008-08-11  0:06 ` Bill Unruh
2008-08-11  5:03 ` Marshall Crocker
2008-08-11  5:09 ` James Cameron
2008-08-11  5:36 ` Marshall Crocker

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox