* 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