How to fix continuous ConfReq's on celluar internet connection

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="[email protected]" 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

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/

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/

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

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...

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

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.

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 |     [email protected]
Canada V6T 1Z1     |      and Gravity       |  www.theory.physics.ubc.ca/

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....

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

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/

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 :).