archive mirror
 help / color / mirror / Atom feed
From: Benjamin Cama <>
Subject: Re: Configuring pppd to accept link-local IPv6 interface id from remote peer
Date: Tue, 16 Feb 2021 10:04:47 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Nicholas,

[Cc'ing the list if I may, as it may be useful]

Le mardi 16 février 2021 à 00:56 +0000, Nicholas Humfrey a écrit :
>  > It is a very small change that is basically activated on the “client”-
>  > side with:
>  >
>  >   ipv6 ::,
>  >
>  > thus sending a zero identifier for our side.
> I just tried applying your patch to Git master (5191399) and 
> successfully compiled it.

Thanks for testing!

> However when running this on my 'client':
> ./pppd/pppd file ~/ppp-options ipv6 ::, ipv6cp-accept-local /dev/ttyAMA0 
> 115200
> Then it seemed to fail to negotiate the link-local address. Here is the 
> output:

It seems it keeps sending ConfReq for the zero identifier… strange.
Here is the output with the patched version from last june when I wrote
it, latest git at the time (some time after 2.4.8), which works:

   using channel 19
   Using interface ppp0
   Connect: ppp0 <--> /dev/pts/18
   rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xfc846b9d> <pcomp> <accomp>]
   sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x29314916> <pcomp> <accomp>]
   sent [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xfc846b9d> <pcomp> <accomp>]
   rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x29314916> <pcomp> <accomp>]
   sent [LCP EchoReq id=0x0 magic=0x29314916]
   sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
   sent [IPV6CP ConfReq id=0x1 <addr fe80::0000:0000:0000:0000>]
   rcvd [LCP EchoReq id=0x0 magic=0xfc846b9d]
   sent [LCP EchoRep id=0x0 magic=0x29314916]
   rcvd [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
   sent [CCP ConfAck id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
   rcvd [IPV6CP ConfReq id=0x1 <addr fe80::0000:0000:0000:0001>]
   sent [IPV6CP ConfAck id=0x1 <addr fe80::0000:0000:0000:0001>]
   rcvd [LCP EchoRep id=0x0 magic=0xfc846b9d]
   rcvd [CCP ConfAck id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
   Deflate (15) compression enabled
   rcvd [IPV6CP ConfNak id=0x1 <addr fe80::0000:0000:0000:0002>]
   sent [IPV6CP ConfReq id=0x2 <addr fe80::0000:0000:0000:0002>]
   rcvd [IPV6CP ConfAck id=0x2 <addr fe80::0000:0000:0000:0002>]
   local  LL address fe80::0000:0000:0000:0002
   remote LL address fe80::0000:0000:0000:0001
   Script /etc/ppp/ipv6-up started (pid 11628)
   Script /etc/ppp/ipv6-up finished (pid 11628), status = 0x0
   ^CTerminating on signal 2
   Script /etc/ppp/ipv6-down started (pid 11655)
   sent [LCP TermReq id=0x2 "User request"]
   Script /etc/ppp/ipv6-down finished (pid 11655), status = 0x0
   Child process sudo /home/benoar/Dev/ppp/pppd/pppd notty noauth noip +ipv6 ipv6 ::1,::2 (pid 11617) terminated with signal 2
   Modem hangup
   Connection terminated.
   Connect time 0.1 minutes.
   Sent 120 bytes, received 120 bytes.

   It correctly gets nacked when sending zero iid, and then acks the given
   identifier. BTW, I use a quick “self-test” for development testing:

   sudo ./pppd/pppd pty "sudo $(pwd)/pppd/pppd notty noauth noip +ipv6 ipv6 ::1,::2" noauth nodetach noip +ipv6 ipv6 ::, debug

   But with latest git and my patch, I indeed get the same trace as you.

   > In my hack, rather than changing the definition of what a valid 
> Interface Identifier is, I instead looked for the calls to eui64_magic() 
> and commented them out.

The VALIDID macro was sparsely used and fitted my use-case well, so I
went with that.

> Looking at the git master branch, it looks like Pali Rohár is actively 
> working in this space:

Well, I'll give a look to find what's wrong.

Thanks for your feedback!

  parent reply	other threads:[~2021-02-16 10:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-14  1:03 Configuring pppd to accept link-local IPv6 interface id from remote peer Nicholas Humfrey
2021-02-14  1:57 ` Michael Richardson
2021-02-14 13:42 ` Nicholas Humfrey
2021-02-14 16:23 ` James Carlson
2021-02-14 17:07 ` Kurt Van Dijck
2021-02-14 17:50 ` James Carlson
2021-02-14 21:24 ` Benjamin Cama
2021-02-14 22:46 ` James Carlson
2021-02-14 23:15 ` Benjamin Cama
2021-02-16  0:10 ` Nicholas Humfrey
2021-02-16 10:04 ` Benjamin Cama [this message]
2021-02-18  0:18 ` Nicholas Humfrey
2021-02-20  1:13 ` Nicholas Humfrey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).