Re: [v6ops] DHCPv6 PD client on cellular on Android

sthaug@nethelp.no Tue, 18 July 2017 09:19 UTC

Return-Path: <sthaug@nethelp.no>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42162131DCB for <v6ops@ietfa.amsl.com>; Tue, 18 Jul 2017 02:19:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uY8K2KUcd_OS for <v6ops@ietfa.amsl.com>; Tue, 18 Jul 2017 02:19:52 -0700 (PDT)
Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F423131DC7 for <v6ops@ietf.org>; Tue, 18 Jul 2017 02:19:48 -0700 (PDT)
Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 1AD3DE6065; Tue, 18 Jul 2017 11:19:47 +0200 (CEST)
Date: Tue, 18 Jul 2017 11:19:47 +0200
Message-Id: <20170718.111947.74661387.sthaug@nethelp.no>
To: Francis.Dupont@fdupont.fr
Cc: mellon@fugue.com, v6ops@ietf.org
From: sthaug@nethelp.no
In-Reply-To: <201707180835.v6I8ZD1v036694@givry.fdupont.fr>
References: <CAPt1N1=wz91yXS0doYXKZ1Mj_0HPobYapiB2BZJwiHTQ7AYckA@mail.gmail.com> <201707180835.v6I8ZD1v036694@givry.fdupont.fr>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/oTrTu2b8b1FJNV2r9uw8L5NnydE>
Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jul 2017 09:19:55 -0000

> >  Understood.   The issue here is that the ISC client is using bpf (or lpf)
> >  to send packets rather than using the Linux stack.   Try compiling it with
> >  #define USE_SOCKETS and see if the behavior changes.
> 
> => in fact it uses BPF/LPF/... for DHCPv4 but as you can't disable
> DHCPv4 yet you should recompile with the socket only option.
>  This can break direct DHCPv4 on some systems but it doesn't matter as
> you want only DHCPv6. Note if (when?) this will become a common case
> you can ask for a feature request so it will be handled directly
> at the configuration phase.

The problem, at least on some systems, is being able to receive DHCP
*broadcast* packets (e.g. the first Discover packet in a DHCPv4
transaction).

I run ISC DHCP on FreeBSD, compiled without BPF, and with all DHCP
traffic via relay agents. No problems.

Steinar Haug, AS2116