Core Update 157: pppd tries to fetch an IPv6 configuration despite it shouldn't, causing dial-up connections to be terminated by some ISPs

Hi all,

thank you for providing logs (“The logs, the logs. All the answers are in the logs.” - Wietse Venema). :slight_smile:

Apparently, the updated version of pppd tries to get an IPv6 configuration during the dial-up procedure, too. Some ISPs already assign IPv6 addresses to their customers, but since IPv6 is disabled in IPFire 2.x kernel, pppd fails to configure it:

The last line is interesting: It tells the ISP that it could not configure IPv6 properly. As an ISP, I would choose to ignore such events (maybe count them for statistical/network engineering purposes), but in case of BT, it looks like the ISP is shutting down the connection afterwards:

So, the root cause of this is pppd attempting to obtain an IPv6 configuration despite it shouldn’t - I will open up a bug later, and work on this.

EDIT: Done, please refer to bug #12651.

At least German DTAG behaves more fault-tolerant here - we have a lot of IPFire users sitting in their networks, and would have heard of if we broke all their setups. :slight_smile: Either way, some ISPs in the world seem to handle this more strict on purpose or by chance, so it is somewhat of a combined issue.

Since my ISP does not support IPv6, yet: Could I eventually rely on you folks to test solutions before we release them? That would be very helpful. :slight_smile:

(And to overcome the question: Yes, we know it’s 2021, and IPFire 2.x does not support IPv6 out of the box yet. Last year was 2020, where we didn’t either. Yes, we certainly will support IPv6 in the future, but for the moment, we simply lack resources to implement it in a secure manner.)

Thanks, and best regards,
Peter Müller

3 Likes