headers
Libor Pechacek | 1 Feb 2010 13:59
Picon

[PATCH] Make `nosendip' behavior more insistent

Hi,

Recently I was testing scenario where the remote end refuses to provide its IP
address.  I found out there is a pppd option for this purpose, however it works
reliably only in case the local pppd uses `noremoteip'.  If you don't specify
`noremoteip' on the local end, the remote end will reveal its IP address
despite it has been disabled with `nosendip'.

This patch makes pppd never send the local IP address when `nosendip' is
specified.

Libor Pechacek

--- a/pppd/ipcp.c
+++ b/pppd/ipcp.c
 <at>  <at>  -1004,6 +1004,7  <at>  <at>  ipcp_nakci(f, p, len, treat_as_reject)
     int treat_as_reject;
 {
     ipcp_options *go = &ipcp_gotoptions[f->unit];
+    ipcp_options *wo = &ipcp_wantoptions[f->unit];
     u_char cimaxslotindex, cicflag;
     u_char citype, cilen, *next;
     u_short cishort;
 <at>  <at>  -1193,7 +1194,7  <at>  <at>  ipcp_nakci(f, p, len, treat_as_reject)
 	    ciaddr1 = htonl(l);
 	    if (ciaddr1 && go->accept_local)
 		try.ouraddr = ciaddr1;
-	    if (try.ouraddr != 0)
+	    if (wo->neg_addr && try.ouraddr != 0)
 		try.neg_addr = 1;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iordan Neshev | 4 Feb 2010 14:37

Why DNS1 is rejected twice?

Hello,

we had a problem with link establishment when connecting to a private 
GPRS VPN.
The peer rejected our request with "ipcp_rejci: received bad Reject!"
Later it turned out that the link fails because we insist on negotiating 
DNS,
but the private VPN does not have one (we were not aware of that).

There was something strange in the peer's response: it rejected DNS1 *twice*

Our packet is:
[0x7E 0xFF 0x03 0x80 0x21 0x01 0x01 0x00 0x16 0x03 0x06 0x00 0x00 0x00 0x00
 0x81 0x06 0x00 0x00 0x00 0x00 0x83 0x06 0x00 0x00 0x00 0x00 0x6E 0xDB 0x7E]

This is IPCP  Config request,
ask for IP       0x03 0x06 0x00 0x00 0x00 0x00,    // 0.0.0.0
ask for DNS1 0x81 0x06 0x00 0x00 0x00 0x00,    // 0.0.0.0
and for DNS2 0x83 0x06 0x00 0x00 0x00 0x00.    // 0.0.0.0

This is the peer's response:
 [0x7E 0x80 0x21 0x04 0x01 0x00 0x10 0x81 0x06 0x00 0x00 0x00 0x00 0x81 
0x06 0x00 0x00 0x00 0x00 0xF4 0x79 0x7E ]  

Our device reported:
pppInput[0]: IPCP len=16
fsm_input(IPCP): code 4,id 1, len 16
fsm_rconfnakrej(IPCP): Rcvd id 1 state=6 (LS_REQSENT)
ipcp_rejci: received bad Reject!
(Continue reading)

Permalink | Reply | 2 comments |
headers
James Carlson | 8 Feb 2010 19:32

Re: Why DNS1 is rejected twice?

Iordan Neshev wrote:
> This is the peer's response:
> [0x7E 0x80 0x21 0x04 0x01 0x00 0x10 0x81 0x06 0x00 0x00 0x00 0x00 0x81
> 0x06 0x00 0x00 0x00 0x00 0xF4 0x79 0x7E ] 
> Our device reported:
> pppInput[0]: IPCP len=16
> fsm_input(IPCP): code 4,id 1, len 16
> fsm_rconfnakrej(IPCP): Rcvd id 1 state=6 (LS_REQSENT)
> ipcp_rejci: received bad Reject!

Yep; that violates the RFC.  It's a garbage message.

> The qustion is: Does somebody know why the peer rejected twice DNS1?

Only the designer of that peer system knows for sure.  It looks like a
bug in that system.

> The GSM operator did not reply this question, that's why I'm asking here.
> Also, does pppd behave properly in this case?

I believe that it does.  It shouldn't tolerate obvious protocol
violations from the peer, because it's not generally possible to "guess"
what the peer might have meant for arbitrary nonsense.

It should be possible, though, to create an option to allow pppd to
ignore any unrequested (or duplicated) options in Reject messages.
Whether doing so, and thus continuing to make a connection with an
obviously malfunctioning peer, is a good idea is perhaps subject to some
debate.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Iordan Neshev | 9 Feb 2010 09:54

Re: Why DNS1 is rejected twice?

Thank you very much, James!
I was worried that the bug is in our device.
We can not switch to another operator but we can now live with that 
because DNS is not really
needed in this special VPN. We solved the problem by removing 
usepeerdns=1 in our code.

Greetings,
Iordan

James Carlson wrote:
> Iordan Neshev wrote:
>   
>> This is the peer's response:
>> [0x7E 0x80 0x21 0x04 0x01 0x00 0x10 0x81 0x06 0x00 0x00 0x00 0x00 0x81
>> 0x06 0x00 0x00 0x00 0x00 0xF4 0x79 0x7E ] 
>> Our device reported:
>> pppInput[0]: IPCP len=16
>> fsm_input(IPCP): code 4,id 1, len 16
>> fsm_rconfnakrej(IPCP): Rcvd id 1 state=6 (LS_REQSENT)
>> ipcp_rejci: received bad Reject!
>>     
>
> Yep; that violates the RFC.  It's a garbage message.
>
>   
>> The qustion is: Does somebody know why the peer rejected twice DNS1?
>>     
>
> Only the designer of that peer system knows for sure.  It looks like a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hashmat Khan | 11 Feb 2010 09:10
Picon

Control pppd behaviour


Hello,

I understand that pppd uses parameters from different files such as those
located in /etc/ppp directory to control its behaviours on failures etc.

I wanted to know if its possible to say for example implement a different
retry algorithm(user defined). Is this possible without modifying code ?

thank you
Hashmat
--

-- 
View this message in context: http://old.nabble.com/Control-pppd-behaviour-tp27543592p27543592.html
Sent from the linux-ppp mailing list archive at Nabble.com.

--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 24 comments |
headers
walter harms | 11 Feb 2010 10:03
Picon
Favicon

Re: Control pppd behaviour


Hashmat Khan schrieb:
> Hello,
> 
> I understand that pppd uses parameters from different files such as those
> located in /etc/ppp directory to control its behaviours on failures etc.
> 
> I wanted to know if its possible to say for example implement a different
> retry algorithm(user defined). Is this possible without modifying code ?
> 

What do you try "to retry" ? when one provider is down you can easy switch to others.
like this (not working) example:

#!/bin/sh
for PROV in prov1 prov2 prov2
do
	pppd call $PROV
	if [ everythink_works ]
		exit 0
done

exit 1

re,
 wh

--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 23 comments |
headers
walter harms | 11 Feb 2010 10:06
Picon
Favicon

wrong return code in pppd 2.4.5

I found this bug in ppp 2.4.5 (Source:ftp://ftp.samba.org/pub/ppp/ppp-2.4.5.tar.gz).

After idle the pppd should return with 12 (idle timeout) but does return with 16 (hang up).
(see log below)

Is this a known problem ? Is there a patch available ?

re,
 wh

/var/log/messages:

....
Feb 10 11:02:51 mws3-94700737 daemon.notice pppd[1716]: Terminating connection due to lack of activity.
Feb 10 11:02:51 mws3-94700737 daemon.info pppd[1716]: Connect time 1.4 minutes.
Feb 10 11:02:51 mws3-94700737 daemon.info pppd[1716]: Sent 3090 bytes, received 3869 bytes.
Feb 10 11:02:51 mws3-94700737 daemon.debug pppd[1716]: Script /etc/ppp/ip-down started (pid 1751)
Feb 10 11:02:51 mws3-94700737 daemon.debug pppd[1716]: sent [LCP TermReq id=0x2 "Link inactive"]
Feb 10 11:02:51 mws3-94700737 daemon.debug pppd[1716]: Script /etc/ppp/ip-down finished (pid 1751),
status = 0x0
Feb 10 11:02:54 mws3-94700737 daemon.debug pppd[1716]: sent [LCP TermReq id=0x3 "Link inactive"]
Feb 10 11:02:57 mws3-94700737 daemon.notice pppd[1716]: Connection terminated.
Feb 10 11:02:58 mws3-94700737 daemon.notice pppd[1716]: Modem hangup
Feb 10 11:02:58 mws3-94700737 daemon.info pppd[1716]: Exit.
Feb 10 11:02:58 mws3-94700737 user.notice root: pppd terminated with: 16

--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ashmath Khan | 11 Feb 2010 12:53
Picon

Re: Control pppd behaviour

I am not looking for multiple options with which pppd needs to try.
Let me give an example, normally if auth fails...it will retry after
'a' seconds for 'n' number of times.
What I would need is say it should try after 'a' seconds for first
retry, after '2a' seconds for second try after first retry fails and
so on..etc. Basically I want to change the retry mechanism. Is there a
way to change without changing the code ?

thanks.

On Thu, Feb 11, 2010 at 2:33 PM, walter harms <wharms <at> bfs.de> wrote:
>
>
> Hashmat Khan schrieb:
>> Hello,
>>
>> I understand that pppd uses parameters from different files such as those
>> located in /etc/ppp directory to control its behaviours on failures etc.
>>
>> I wanted to know if its possible to say for example implement a different
>> retry algorithm(user defined). Is this possible without modifying code ?
>>
>
>
> What do you try "to retry" ? when one provider is down you can easy switch to others.
> like this (not working) example:
>
> #!/bin/sh
> for PROV in prov1 prov2 prov2
> do
(Continue reading)

Permalink | Reply | 22 comments |
headers
James Carlson | 11 Feb 2010 14:18

Re: Control pppd behaviour

Ashmath Khan wrote:
> I am not looking for multiple options with which pppd needs to try.
> Let me give an example, normally if auth fails...it will retry after
> 'a' seconds for 'n' number of times.
> What I would need is say it should try after 'a' seconds for first
> retry, after '2a' seconds for second try after first retry fails and
> so on..etc. Basically I want to change the retry mechanism. Is there a
> way to change without changing the code ?

It's still unclear what you're after.

Are you asking about the details of how the protocol itself works?  In
other words, are you asking about how you can modify the algorithm that
decides when to send PPP negotiation packets?

If so, then you'll need to change the source code and recompile.  There
are documented parameters that allow you to change the maximum number of
retries and the interval between retries, but none that change the
algorithm used to determine when retries occur.  The algorithm is simple
and fixed: when the timer expires and there are retries left, the TO+
event is delivered, and that causes the timer to be restarted and a new
message to be generated.

Perhaps the real question here is: "what are you trying to do?"  If you
could explain what higher-level problem you're trying to solve, it might
be possible for someone to give you a better answer.

Are you trying to work around a problem?  If so, what problem, with what
symptoms and debug log messages?  Are you trying to interoperate with a
peer that has bugs?  Are you trying to experiment with PPP itself?
(Continue reading)

Permalink | Reply | 21 comments |

Gmane