From: Benjamin Cama <benoar@dolka.fr>
To: linux-ppp@vger.kernel.org
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: <072169f215e68427ba9b65caac3c3effef3b971c.camel@dolka.fr> (raw)
In-Reply-To: <d529e496-ac5f-9498-0e3d-1fa1ec2c4750@aelius.com>
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:
> https://gist.github.com/njh/437713988b108880a8fe23ed10168c0c
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:
>
> https://github.com/paulusmack/ppp/commits/master
Well, I'll give a look to find what's wrong.
Thanks for your feedback!
Regards,
--
benjamin
next prev 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=072169f215e68427ba9b65caac3c3effef3b971c.camel@dolka.fr \
--to=benoar@dolka.fr \
--cc=linux-ppp@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).