Orange France are playing silly bu***** again.

[marjohn56]

Seems Orange France are messing with the authentication and it dynamically changes. There is a solution as a fix for wrt and others has been posted. What it means though is that we would have to add a checkbox for Orange France users to fire off the calculation on their password. If we do this, then where should we add this checkbox?

What it means is that the user would just enter their username/password string, no messing with adding a load of hex chars - then opnsense would create the login credentials and put them in the dhclient and dhcp6c configurations automagically. Not complex, just a question of where to put the GUI stuff.

@fichtner - your instructions on this?

[nivek1612]

Yes on a reboot or WAN refresh (NOT ON RENEW) a md5 hash of RANDOMCHAR+PASSWORD+RANDOMSTRING is now appended to a fixed string and the userid and sent at the authentication string option-90 for dhcp and option-11 for dhcp6. So from "fixed string+userid" we now have "fixed string + userid + MD5 hash"

As Marjohn says its very simple code. My thoughts where to add these options to the dhcp and dhcpv6 sections on WAN config.

[marjohn56]

Thinking on this, at present the user enters the full string, including all of the padding. If we just have a text input box called 'Orange France ID', if that has anything in it then it will generate the correct string and send that as the authentication. If empty then nothing extra happens. Stick it in system->Settings->Administration?

[nivek1612]

That is nice and clean compared to the idea I emailed you :-) Although we need to send two parameters userid and password. so maybe they have to fill in userid='xxxxxxx';password='yyyyyy' we can then pull that into the wan.config generation process

[nivek1612]

here is the idea I shared with Martin

In the dhcp and dhcpv6 sections of WAN maybe check box called MD5HASH ??? which then presents something like this Service name or ISP field or whatever will allow us to add any other ISP that start to go this way later maybe as i believe this is a RFC 3118 standard

[marjohn56]

Although my way is simple, if as you say it could become more prevalent that different ISP's add this, then we would maybe have to use different algorithms for each ISP, therefore a separate section in the WAN configuration page with a drop down selector might be a better option as we could then add specific ISPs

[fichtner]

I would add this to WAN settings, maybe only DHCP(v4) and then use it for DHCPv6 as well if set. Later we could add a select box for additional providers should the need arise?

[fichtner]

TBH, this is an annoying stunt that Orange FR is pulling and will not go down well if they continue making more weird modifications in the future.

[nivek1612]

thinking a bit more how about this

[nivek1612]

@fichtner yes a few users have already indicated if they make it harder to connect they will leave

[nivek1612]

@fichtner Is it possible we could have this before 19.1. I suspect Orange are not enforcing the md5 hash yet based on feedback of users who are keeping it the same between reboots/wan reconfigures but I suspect it will happen very soon once all the livebox have been flashed meaning reboots will need manual intervention without the script

[fichtner]

It would be ironic if they manage to lock out their own routers with older firmware at some point.

Would add what you suggest to advanced and use the service name to match which magic to use for the username?

[nivek1612]

Would add what you suggest to advanced and use the service name to match which magic to use for the username

I like that :-)

[nivek1612]

@marjohn56 when can I test :-)

[fichtner]

@marjohn56 knows better but I don't know how busy he is so I'm willing to help now, probably have a few silly questions via mail though?

[nivek1612]

whatever works best for you guys let me know.

[fichtner]

@nivek1612 sent you a mail, let's see if we can crack this now

[nivek1612]

email conversation underway :-)

[marjohn56]

OK, I had started to add it to the WAN interfaces as RFC3118 Option, this class only appears if both dhcp6c and dhcp is selected, obviously we can drop the && v6. However, I suspect @fichtner has almost finished it by now and I had to mow the lawn and vacuum the garden too. :)

[fichtner]

@marjohn56 no by all means go ahead, I'm still trying to wrap my head around it.

[marjohn56]

Well my idea was to follow Kev's original idea, using the drop down list to select the ISP or none for normal operation. If an ISP is selected, then we use that when the interface is saved to generate the new authentication strings and store those in the config too. I am pretty busy as I have got some real work stuff to do this afternoon too, pain in the ass but I have no choice otherwise deadlines will be missed. I'll try and get it finished over the next couple of days.

[Franck78]

And indeed, around 10-22 december 2018, the things changed, again ! Seen after applying 18.7.9 patch, no more ipv6

[nivek1612]

18.7.9 introduced full DUID support for DUID types such as LL LLT UUID. Looks liek it may not always get across

Make sure you have one specified
Interfaces > Settings> DHCP Unique Identifier

I captured the DUID from the livebox. DHCP6c request client identification option so that I match the livebox exactly. DUID is in LL format and is 00: 03: 00: 01: AddressMacEth1.

[Franck78]

Nivek, as-tu un email public que tu peux partager ici, je trouve pas de 'Messagrie Privée' sur github. Ou on se retrouve sur lafibreinfo (ou je te lis generalement).

AddressMacEth1.

Eth1 from what device ??? The livebox, the appliance used for opnSense ??? Or the Eth dedicated for the GPON ? What is the logic here ??

AddressMac. Is 6 bytes. The "Insert a new LL DUID" adds 4 random bytes after the 00:03:00:01

00:03:00:01:23:B6:B6:1C

Isn't that better ? 00:03:00:01: 4_rigths_bytes_of(AddressMacEth1)

[nivek1612]

Just wireshark trace the one from the livebox dhcp6c request

[marjohn56]

Can you give me the wiretrace from the livebox. There is an error in the code generating the LL duid type, it may work for some ISPs that are not picky, but at present it does appear not to conform to rfc3315.

[nivek1612]

Sent via mail

[marjohn56]

PR Issued. See #3073

[Franck78]

"Just wireshark trace the one from the livebox dhcp6c request" Cannot do that until jan, 2

Manually entering this 00:03:00:01:52:54:00:36:40:7F (actual opnsense) or 00:03:00:01:A4:3E:51:78:xx:xx (mac on livebox sticker)

in the DUID field and disabling/enabling Wan interface does not bring back IPV6 for now.

[nivek1612]

try to reboot router disabling/enabling WAN did not work for me. Thats another issue we need to investigate

[Franck78]

A little late but here is the DHCPv6 Sollicit message from Livebox

The main difference between what opnSense send and livebox send is the IA-PD option. Go figure !

Nivek, the script on lafibreinfo also outputs a different value for option 6 (request 11,17,23,24)

When do you 'integrate it' in opnSense GUI !?

After picking bytes opt11 from the livebox capture, DHCPv6 is working again.

Frame 16: 282 bytes on wire (2256 bits), 282 bytes captured (2256 bits) on interface 0
Ethernet II, Src: AnovFran_78:96:d6 (a4:3e:51:78:96:d6), Dst: IPv6mcast_01:00:02 (33:33:00:01:00:02)
802.1Q Virtual LAN, PRI: 6, DEI: 0, ID: 832
Internet Protocol Version 6, Src: fe80::a63e:51ff:fe78:96d6, Dst: ff02::1:2
User Datagram Protocol, Src Port: 546, Dst Port: 547
DHCPv6
    Message type: Solicit (1)
    Transaction ID: 0x129726
    Vendor-specific Information
        Option: Vendor-specific Information (17)
        Length: 22
        Value: 000005580006000e495056365f524551554553544544    ="IPV6_REQUESTED" ???????
        Enterprise ID: Orange (1368)
        option
    Client Identifier
        Option: Client Identifier (1)
        Length: 10
        Value: 00030001a43e517896d6
        DUID: 00030001a43e517896d6
        DUID Type: link-layer address (3)
        Hardware type: Ethernet (1)
        Link-layer address: a4:3e:51:78:96:d6
    Option Request
        Option: Option Request (6)
        Length: 8
        Value: 000b001100170018
        Requested Option code: Authentication (11)
        Requested Option code: Vendor-specific Information (17)
        Requested Option code: DNS recursive name server (23)
        Requested Option code: Domain Search List (24)
    Elapsed time
        Option: Elapsed time (8)
        Length: 2
        Value: 0000
        Elapsed time: 0ms
    Authentication
        Option: Authentication (11)
        Length: 70
        Value: 00000000000000000000001a0900000558010341010d6674692f...
        Protocol: 0
        Algorithm: 0
        RDM: 0
        Replay Detection: 0000000000000000
        Authentication Information: 1a0900000558010341010d6674692f...
    User Class
    Vendor Class
        Option: Vendor Class (16)
        Length: 11
        Value: 0000040e0005736167656d
        Enterprise ID: SAGEMCOM SAS (1038)
        vendor-class-data: sagem
    Identity Association for Prefix Delegation
        Option: Identity Association for Prefix Delegation (25)
        Length: 12
        Value: 517896d600000e1000001518
        IAID: 517896d6
        T1: 3600
        T2: 5400 

[marjohn56]

@Franck78 Kev is at his Chateaux this weekend so he'll be taking a look at several things. :)

[nivek1612]

I'm here and just upgraded to 19.1.1

Cant break anything yet

As for implementing the auto generation of the auth stings via an algorithm at this point it is pointless as Orange are not requiring a change between refresh or reboot YET.

Once they do we will have to move quickly.

It is also clear that the scripts that generate a random string for the authentication options actually don't always work as Orange seems to be doing the SALT and HASH differently. For now copy the auth strings from the livebox. I did that approx 5 months ago and the dame strings are still working

[Franck78]

It is working again yes. My problem is understing why it is working.... No log anywhere about the 2a01:0000:XXXX:ae00:5054:ff:fe93:7702 public IP assigned to LAN_Nic No log anywhere for my local devices receiving also an IPV6 public No DHCPv6 leases

But the most annoying thing, is when in dashboard the "DHCPv6 Server" service goes red, there is absolutly ZERO log about why it cannot restart. And starting to trace from Firefox to Lighttpd to some 'system.inc' file is just impossible ;-)

Anyway IPv6 is more or less useless now, so not a big deal. Just not helping learning it ;)

[marjohn56]

The log info for dhcpd6 can be found in the normal dhcpd logs, log info for dhcp6 can also be found there and/or in system logs.

[marjohn56]

Is this using the dhcp6c I sent you or one that came with 19.1* ?

[marjohn56]

This is the issue we were looking at in early January, The memory gets corrupted and causes dhcp6c to write rubbish to the config, hence me asking @Franck78 if this is the version from 19.1 or 19.2. Kev has been unable to replicate the issue since the update and I cannot replicate it on my system either. I'll not be able to look any deeper into this for several weeks due to work load.

[Franck78]

root@opnSense:~ # md5 which dhcp6c MD5 (/usr/local/sbin/dhcp6c) = 5c42d94f2e95574e6ae9310e4399bf98

[Franck78]

same thing repeated. Note the delay before the coredump, it looks like dhcp6c never receive this Received REPLY for REQUEST and go coredump (bug or code corrupted)? / codes for SIGBUS /

define BUS_ADRALN 1 / Invalid address alignment. /

define BUS_ADRERR 2 / Nonexistent physical address. /

define BUS_OBJERR 3 / Object-specific hardware error. /

Mar 3 22:10:44 | kernel: pid 71388 (dhcp6c), uid 0: exited on signal 10 (core dumped)
-- | --
Mar 3 22:09:00 | kernel: cannot forward src fe80:2::64c4:53be:1aed:33e7, dst  2a01::5054:ff:fe93:7702, nxt 58, rcvif em1, outif  em0_vlan832
Mar 3 22:08:09 | kernel: arp: 22:54:00:0b:ae:b5 is using my IP address 10.0.0.200 on em1!
Mar 3 22:08:08 | opnsense: /usr/local/etc/rc.linkup: Warning! services_radvd_configure(auto) found no suitable IPv6 address on em1
Mar 3 22:08:06 | kernel: arp: 22:54:00:0b:ae:b5 is using my IP address 10.0.0.200 on em1!
Mar 3 22:08:06 | dhcp6c[71388]: freeing op data at 0x62ccc625080
Mar 3 22:08:06 | dhcp6c[71388]: freeing op data at 0x62ccc667270
Mar 3 22:08:06 | dhcp6c[71388]: freeing op data at 0x62ccc6263c0
Mar 3 22:08:06 | dhcp6c[71388]: freeing op data at 0x62ccc660060
Mar 3 22:08:06 | dhcp6c[71388]: Sending Request
Mar 3 22:08:06 | dhcp6c[71388]: freeing op data at 0x62ccc625070
Mar 3 22:08:06 | dhcp6c[71388]: freeing op data at 0x62ccc6673c0
Mar 3 22:08:06 | dhcp6c[71388]: freeing op data at 0x62ccc626230
Mar 3 22:08:06 | dhcp6c[71388]: freeing op data at 0x62ccc660060
Mar 3 22:08:06 | dhcp6c[71388]: Sending Solicit

Not funny thing is that the trigger (ifconfig down/up) does not always 'corrupt' dhcp6c. Here it perfectly restarted...

Mar 4 02:52:47 | dhcp6c: dhcp6c REQUEST on em0_vlan832 - running newipv6
-- | --
Mar 4 02:52:47 | dhcp6c[71398]: add an address 2a01::5054:ff:fe93:7702/64 on em1
Mar 4 02:52:47 | dhcp6c[71398]: Received REPLY for REQUEST
Mar 4 02:52:47 | dhcp6c[71398]: freeing op data at 0x4602ac25070
Mar 4 02:52:47 | dhcp6c[71398]: freeing op data at 0x4602ac6d330
Mar 4 02:52:47 | dhcp6c[71398]: freeing op data at 0x4602ac26370
Mar 4 02:52:47 | dhcp6c[71398]: freeing op data at 0x4602ac66030
Mar 4 02:52:47 | dhcp6c[71398]: Sending Request
Mar 4 02:52:47 | dhcp6c[71398]: freeing op data at 0x4602ac25030
Mar 4 02:52:47 | dhcp6c[71398]: freeing op data at 0x4602ac6d2d0
Mar 4 02:52:47 | dhcp6c[71398]: freeing op data at 0x4602ac26190
Mar 4 02:52:47 | dhcp6c[71398]: freeing op data at 0x4602ac66030
Mar 4 02:52:47 | dhcp6c[71398]: Sending Solicit

[nivek1612]

@Franck78 let me have your email address I will send you an alternative dhcp6c that @marjohn56 built. Its test only and not intended for production use but if it stops your problem it will give us some further insight into the issue.

[Franck78]

@Nivek,

'fbourdonnec' at 'chez' dot 'com'

[nivek1612]

sent

[Franck78]

The linecounter used while parsing the config file is not reset to 1. It just keeps incrementing. The data are perfectfly red. Fix this before a try a new dhcp6c please.

in cftoken.l

int
cfparse(const char *conf)
{
        lineno = 1;                            <========= ADD THIS
        free(configfilename);
        configfilename = strdup(conf);

        if ((yyin = fopen(configfilename, "r")) == NULL) {
                d_printf(LOG_ERR, FNAME, "cfparse: fopen(%s): %s",
                        configfilename, strerror(errno));
                if (errno == ENOENT)
                        return (0);
                return (-1);
        }

        if (yyparse() || yyerrorcount) {
                if (yyerrorcount) {
                        yyerror("fatal parse failure: exiting (%d errors)",
                                yyerrorcount);
                } else
                        yyerror("fatal parse failure: exiting");
                return (-1);
        }

        return (cf_post_config());
}

[marjohn56]

Nice catch,,, I'll recompile and send it to you shortly.

[Franck78]

nice catch but it is only a line counter.

I don't like this kind of code : BUFSIZ is coming out of nowhere and if it happens that sizeof(struct dhcp6) is greater, then screwed....

> void
> client6_send(struct dhcp6_event *ev)
> {
>         struct dhcp6_if *ifp;
>         char buf[BUFSIZ];
>         struct sockaddr_in6 dst;
>         struct dhcp6 *dh6;
>         struct dhcp6_optinfo optinfo;
>         ssize_t optlen, len;
>         struct dhcp6_eventdata *evd;
>         struct rawoption *rawop;
> 
>         ifp = ev->ifp;
> 
>         dh6 = (struct dhcp6 *)buf;
>         memset(dh6, 0, sizeof(*dh6));

[marjohn56]

Well dhcp6c is really old now, dates back a long way. Apart from the few additions here and there over the years it’s as is, it’s never been cleaned up and polished.

[marjohn56]

As it happens it appears bufsiz is a constant macro defined in stdio.h, it’s usually 512 bytes, so I doubt whether that’s an issue. The coredump issue is related to the freeing of memory when using RAW options.

[Franck78]

I can make your specific version of dhcp6c crashes the same way as the regular one. Can you do something like that ? : https://stackoverflow.com/questions/2281739/automatically-adding-enter-exit-function-logs-to-a-project This thing really need to run under a debugger ! Reordering sections in the /var/etc/dhcp6c_opt1.conf changes the type of bug response, but with the first launch being always successful. Something missing after reload of the configfile

Mar/04/2019 21:56:38: restarting
Mar/04/2019 21:56:38: Bypassing address release because of -n flag
.....
Mar/04/2019 21:56:38: /var/etc/dhcp6c_opt1.conf 23: Raw option 16 length 11 stored at 0x1911786f0f0 with data at 0x1911781f040
Mar/04/2019 21:56:38: /var/etc/dhcp6c_opt1.conf:1668505393 invalid interface configuration
^C to get out of inifinite loop

or

Mar/04/2019 22:21:53: /var/etc/dhcp6c_opt1.conf 24: Raw option 16 length 11 stored at 0x2703546f210 with data at 0x2703541f020
Mar/04/2019 22:21:53: /var/etc/dhcp6c_opt1.conf:976303674 unsupported option type: 859257397
Bus error (core dumped)

or

Mar/04/2019 21:54:27: Received REPLY for REQUEST
Mar/04/2019 21:54:27: add an address 2a01:::5054:ff:fe93:7702/64 on em1
OK
Mar/04/2019 21:54:34: restarting
Mar/04/2019 21:54:34: Bypassing address release because of -n flag
Mar/04/2019 21:54:34: failed to remove an address on em1: Can't assign requested address
....
Mar/04/2019 21:54:34: /var/etc/dhcp6c_opt1.conf 6: Raw option 16 length 11 stored at 0x1b40d86f0f0 with data at 0x1b40d81f040
Mar/04/2019 21:54:34: /var/etc/dhcp6c_opt1.conf:12 invalid interface configuration
Mar/04/2019 21:54:34: failed to reload configuration file
Mar/04/2019 21:54:34: Sending Solicit
Mar/04/2019 21:54:34:     freeing op data at 0x1b40d86e060
Mar/04/2019 21:54:34:     freeing op data at 0x1b40d828230
Mar/04/2019 21:54:34:     freeing op data at 0x1b40d86f3c0
Mar/04/2019 21:54:34:     freeing op data at 0x1b40d81f070
Mar/04/2019 21:54:34: Sending Request
Mar/04/2019 21:54:34:     freeing op data at 0x1b40d86e060
Mar/04/2019 21:54:34:     freeing op data at 0x1b40d8283c0
Mar/04/2019 21:54:34:     freeing op data at 0x1b40d86f270
Mar/04/2019 21:54:34:     freeing op data at 0x1b40d81f080
Bus error (core dumped)
root@opnSense:~ # vi /var/etc/dhcp6c_opt1.conf

[marjohn56]

Do you want this compiled against the Opnsense Github source, i.e. the distribution version with no other changes?

[Franck78]

yes, because it's the source I have. What are your changes ?

[marjohn56]

@Franck78 - I've just hammered my test unit ( RAW Options set ) for about 30 minutes taking the igb0 interface up and down and I cannot make dhcp6c crash. The version in my test unit is the one I sent you some weeks back.