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

[Ted Lemon <[e-mail]>]

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.

On Mon, Jul 17, 2017 at 6:26 PM, Alexandre Petrescu <
[e-mail]> wrote:

> Well, this is to note that we too (Fred mentioned it too earlier) made
> the ISC DHCPv6 dhclient work on Android, including DHCPv6 Solicit that
> requests Prefix Delegation.
>
> (but we still dont have a response to DHCP Solicit on cellular link).
>
> Alex
>
> Le 06/07/2017 à 18:32, Alexandre Petrescu a écrit :
>
>> Mark, noted, will try.
>>
>> Just a note...
>>
>> Le 06/07/2017 à 03:16, Mark Andrews a écrit :
>>
>>>
>>> In message <[e-mail]>,
>>> Alexandre Petrescu writes:
>>>
>>>> Hello,
>>>>
>>>> We discussed extensively about the potential use of DHCPv6
>>>> Prefix Delegation on cellular links.
>>>>
>>>> The chicken issue is the lack of DHCPv6 PD software on typical
>>>> User Equipment.  For example, there is no DHCPv6-PD app on
>>>> Android.  The egg issue is the lack of operator support of
>>>> DHCPv6-PD towards the User Terminal.  For example, there is no
>>>> cellular operator answering to DHCPv6-PD requests issued by the
>>>> User Terminal.
>>>>
>>>> To address the chicken issue, we started with an ISC DHCP open
>>>> software client, which does implement Prefix Delegation.  It can
>>>> be (cross)compiled on various platforms; then type "./dhclient -6
>>>> -P"; this sends an DHCPv6 Solicit Identity Associtaion for Prefix
>>>> Delegation message on the interface.
>>>>
>>>> However, whereas this software runs ok on interfaces such as
>>>> Ethernet, USBnet and WiFi interfaces, it breaks if run on the
>>>> cellular interface of some IoT cellular platform.  The error can
>>>> be corrected by the quick-and-dirty solution below.
>>>>
>>>
>>> The hack would be better as
>>>
>>> #ifdef ARPHRD_XXXX case ARPHRD_XXXX: hw->hlen = 7; hw->hbuf[0] =
>>> HTYPE_ETHER; memcpy(&hw->hbuf[1], sa->sa_data, 6); break; #endif
>>> default: log_fatal("Unsupported device type %ld for \"%s\"", (long
>>> int)sa->sa_family, name); break;
>>>
>>> with ARPHRD_XXXX being replaced by the correct macro for 503 from
>>> <net/if_arp.h>.  Something like that is at least portable.
>>>
>>
>> But it means when I go to other platform will have to modify again
>> the ISC client source code?
>>
>> In cellular terminals there are so many non-IEEE different kinds of
>> links.
>>
>> Other clients work out of the box on this - I agree with you, strange
>> - "rmnet0" interface.
>>
>> Alex
>>
>>
>>> As for the rest of it I have no idea about the presented hardware
>>> address of this type so I don't know it the rest of it make sense.
>>>
>>> Alex
>>>>
>>>> ------------------------------------------------------------
>>>> ------------
>>>>
>>>>
>>>> The error says "//UNSUPPORTED DEVICE TYPE 503 FOR RMNET0."
>
>> dhcp-4.3.5 ./common/lpf.c line number: 551
>>>>
>>>> //default: //      log_fatal("Unsupported device type %ld for
>>>> \"%s\"", //                (long int)sa->sa_family, name); default:
>>>> hw->hlen = 7; hw->hbuf[0] = HTYPE_ETHER; memcpy(&hw->hbuf[1], sa->sa_data,
>>>> 6); break;
>>>>
>>>> (two programmers worked this out).
>>>>
>>>> Alex
>>>>
>>>> _______________________________________________ v6ops mailing
>>>> list [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>
>> _______________________________________________ v6ops mailing list
>> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>