1.8b Development

I've been using native IPv6 on 1.33 series and betas up to 1.8.0b478 but anything later will not provide me with a Wan IPv6 address from PPP.

Quite possibly a config error here but I can't see where. Perhaps the gateway entry is a clue.

In Interfaces
b478 shows correct IPv6 address and gateway ng0
later versions show no IPv6 address line and gateway ngwan0

IPv6 config in Interfaces->Wan is set to PPP in both cases

1.8.0b495 gives the same problem.

Since b479, MPD (= PPP client/server software) version 5 is used instead of version 4 (as the latter has been deprecated). Most likely that's the cause of the problem - now the question is just whether we simply need to adjust the configuration that m0n0wall generates for MPD to make it work again, or if it's a bug in MPD 5.

Would be great if you could send me some debug output (i.e. the output from /status.php just after a failed connection attempt).

(BTW, the changed gateway/interface name is normal and shouldn't be the cause of the problem)

I didn't actually download b479 so not tested but MPD could well be the problem.

No idea which bit of status.php would be useful so attached complete and anonymous version

Thanks for the reply

Strange - I just tested b495 against a MikroTik PPPoE server, and it worked fine, including DHCP-PD. From your status output, it looks like IPv6CP is not even negotiated, but can't say for sure as I don't see any MPD log lines.

Can you please try hitting the "Save" button on the WAN setup page (to make it restart MPD) and then look for MPD log lines in the system log?

Attached log after "Save" button on the WAN setup page, seem to be many MPD lines now, still no IPv6 on Wan.

Interesting excerpt from the log:

Feb 12 17:43:38 m0n0wall mpd: [B1] IFACE: Rename interface ng0 to ngwan0
Feb 12 17:43:38 m0n0wall mpd: [B1] IPV6CP: rec'd Configure Request #1 (Ack-Rcvd)
Feb 12 17:43:38 m0n0wall mpd: [B1] IPV6CP: SendConfigAck #1
Feb 12 17:43:38 m0n0wall mpd: [B1] IPV6CP: state change Ack-Rcvd --> Opened
Feb 12 17:43:38 m0n0wall mpd: [B1] IPV6CP: LayerUp
Feb 12 17:43:38 m0n0wall mpd: [B1]   020d:b9ff:fe17:2bbc -> 0203:97ff:fe16:8000
Feb 12 17:43:38 m0n0wall mpd: [B1] IFACE: Adding IPv6 address to ngwan0 failed: File exists
Feb 12 17:43:38 m0n0wall kernel: ifa_add_loopback_route: insertion failed

-> apparently it thinks that there is already an IPv6 address on ngwan0. Could be something to do with the renaming of ng0 to ngwan0 (which has become necessary with MPD 5 to avoid interface name ambiguity when also using PPTP VPN). In the logs of my tests, the renaming happens after IPV6CP is already up and the address has been assigned (and then it works). Maybe some kind of race condition/timing problem...

Here's a modified version for you to try that doesn't rename the interface, but still uses MPD 5:

http://m0n0.ch/temp/generic-pc-serial-1.8.0b496M.img

This won't work in conjunction with PPTP VPN, but it will allow us to find out whether it's just the renaming that causes the problem.

Second attempt to reply, not sure what happened to first.

Still no 6 on WAN and no MPD on the logs at all but I did not "Save" in WAN config this time, can repeat and "Save" if required.

OK - here's another idea. What is that 2001:xxx:xxxx::1/64 subnet that you have configured on your LAN interface? Could it be that your ISP is announcing that prefix on the PPP link, thus causing the conflict?

If you're not sure, try changing the LAN IPv6 address to something entirely different (won't work of course, but will show whether MPD still has troubles bringing up IPV6CP).

Thanks for your patience

OK, swapped the second and third sets around, still no 6 on WAN.

I've tried this on both b495 and b496M, logs for each attached. "Saved" WAN settings both times.

Could it be that your ISP is announcing that prefix on the PPP link, thus causing the conflict?

I will ask, they are usually very helpful.

No worries about the patience, will be good to get it working. Only recently registered here as I was hoping someone else might have come across it.

Sorry, only one log has appeared

OK, in that case it's not a conflict between LAN and WAN/PPP addresses (would have surprised me anyway), but more likely a case of MPD (and the kernel itself?) trying to add the link-local address to ngwan0 twice.

Well, looks like this is a bit more tricky. I'll try some more to reproduce it here as time permits; if nothing helps and other people can reproduce it too, we might have to switch back to MPD4.

Thanks for looking. No rush here as b478 is working well in the meantime.

Perhaps others have tried post b479 versions and failed but not taken it any further - as I did for a while - or simply not been concerned with or noticed IPv6 connectivity issues of course.

I have mailed support at my ISP and will post anything useful they have to say on the matter.

I have a response from support though well beyond my technical knowledge...

> 'Could it be that your ISP is announcing that prefix on the PPP
> link,
Yes we announce by dhcpv6 and ipcpv6.

> thus  causing the conflict?'
Only if your router is really silly and tries to do both, yes however I
doubt any sane router would get confused.

At the moment I have WAN IPv6 config set to PPP. Is it likely to make any difference if I set it to DHCP?

OK, I finally managed to reproduce the problem. It's related to the timing at which IPCP and IPV6CP come up: if IPCP comes up before IPV6CP, then the kernel will add a link-local (fe80:) address to ngwan0 automatically, even before MPD gets a chance to do that. Then when IPV6CP comes up, the address is already there, leading to the "File exists" error. Upon that error, MPD closes IPV6CP, so no IPv6 on ngwan0 anymore.

I've made a quick fix to MPD that simply makes it ignore "exists" errors when adding IPv6 link-local addresses. The "ifa_add_loopback_route: insertion failed" message will still appear in the logs, but is harmless. Can you please try b497 (should be available in about 15 minutes) and let us know if that works?

Yes, all seems to be OK, correct IPv6 address on WAN, log looks to be OK.

Many thanks