IPv6 - One last throw.

[Rachel]

Here we go again. One more time.

Once again, IPv6 worked for a couple of weeks, maybe, then spontaneously stopped working again. Symptoms this time, as before: LAN all works (clients get IPv6 addresses assigned as you'd expect, so the router's DHCPv6 is up), but no IPv6 traffic gets routed outwards to the internets. I do seem able to get inward connections though, at least as far as the router's IPv6 address.

Checked: No new firmware available. I'm on the latest. (BiPAC 7800N firmware 1.06g)
Checked: Multiple restarts and resets aren't making it work again this time.

One more time to explain what I think the problem is. I believe I'm not getting router advertisements or whatever configuration I'm supposed to be getting from upstream.

It's always been the case that I've only got IPv6 at all by not only enabling IPv6 in the config (as everyone says is all that's necessary) but also by putting in "2a02:390:feed:XXXX::1/64" into my static LAN IPv6 address configuration (in "Interface Address / Prefix Length"). Only when I do that, does the WAN interface get a stateless IPv6 address in the same prefix, and other machines in my LAN get their status IPv6 addresses too.

Theory: The WAN IP address is actually being set up by the router's own DHCPv6, having been set up with the static LAN IPv6 address. Repeat: If I don't put that value into my static IPv6 address, but otherwise IPv6 is all enabled the way it's supposed to work, nothing gets an IPv6 address, no IPv6 happens.

Now, sometimes when I put in that LAN IPv6 address, I also get full routing upstream and IPv6 all seems to work. (And then I go quiet for a while, until it spontaneously fails again, even though I know something's not right but can't get any attention on that, especially when it "works".) Other times I don't. Since late Wednesday night, for instance, after a short connection outage, I don't. It's basically exactly as if my router doesn't know where its upstream router is. Because that's supposed to be all getting configured automatically, and it's not happening. My guess is that when it works, some part of the IPv6 stack is making some kind of informed guess as to where the router should be, given it's not being told (eg: using the remote LL address or sticking an idnet prefix on the front of that), and sometimes the guess is correct and sometimes it isn't. This may be due to changes at idnet; a change, for instance, that might have happened during my outage late wednesday night.

Anyway, as usual after such an occurrence I also try taking out that LAN IPv6 address again and seeing if autoconfig has started working for me, as a result of any such idnet changes that might have occurred. But no.

Here is a syslog from the router from trying to connect with IPv6 all set up to autoconfig, no LAN IPv6 address defined - basically the configuration that's supposed to "just work":

  Jun 29 07:24:04  daemon  pppd[1684]: PPPoE: Terminating on signal 15.
  Jun 29 07:24:04  daemon  pppd[1684]: Clear IP addresses.  Connection DOWN.
  Jun 29 07:24:04  daemon  pppd[1684]: Clear IP addresses.
  Jun 29 07:24:04  daemon  pppd[1684]: Couldn't increase MTU to 1500.
  Jun 29 07:24:04  daemon  pppd[1684]: Connection terminated.
  Jun 29 07:24:04  daemon  pppd[1684]: Connect time 14.2 minutes.
  Jun 29 07:24:04  daemon  pppd[1684]: Sent 237698 bytes, received 297214 bytes.
  Jun 29 07:24:04  user  kernel: dev_shutdown, dec ppp device refcnt, dev->refcnt=6
  Jun 29 07:24:05  user  kernel: unregister_netdevice: waiting for ppp_0_0_38_1 to become free. Usage count = -1
  Jun 29 07:24:05  user  kernel: dev->name = ppp_0_0_38_1, dev->refcnt=-1
  Jun 29 07:24:05  user  kernel: after reset to 0, dev->refcnt=0
  Jun 29 07:24:08  daemon  pppd[1684]: Exit.
  Jun 29 07:24:08  user  syslog: begin: interface: ppp_0_0_38_1 go to down
  Jun 29 07:24:08  user  syslog: end: interface: ppp_0_0_38_1 go to down
  Jun 29 07:24:12  daemon  pppd[31610]: PPPoATM setdevname_pppoatm
  Jun 29 07:24:12  daemon  pppd[31610]: PPPoATM setdevname_pppoatm - SUCCESS
  Jun 29 07:24:12  daemon  pppd[31610]: pppd 2.4.1 started by admin, uid 0
  Jun 29 07:24:12  daemon  pppd[31610]: PPP: Start to connect ...
  Jun 29 07:24:12  daemon  pppd[31610]: Using interface ppp0_0_38_1
  Jun 29 07:24:12  daemon  pppd[31610]: Connect: ppp_0_0_38_1 <-->
  Jun 29 07:24:12  daemon  pppd[31610]: Couldn't increase MTU to 1500.
  Jun 29 07:24:12  daemon  pppd[31610]: PPP LCP UP.
  Jun 29 07:24:15  user  syslog: ping -c 1 8.8.8.8 &
  Jun 29 07:24:18  daemon  pppd[31610]: local  LL address fe80::e592:7456:6f1e:e8c6
  Jun 29 07:24:18  daemon  pppd[31610]: remote LL address fe80::0212:7fff:feae:411b
  Jun 29 07:24:18  daemon  pppd[31610]: local  IP address 93.89.130.22
  Jun 29 07:24:18  daemon  pppd[31610]: remote IP address 212.69.63.98
  Jun 29 07:24:18  daemon  pppd[31610]: primary   DNS address 212.69.40.3
  Jun 29 07:24:18  daemon  pppd[31610]: secondary DNS address 212.69.36.3
  Jun 29 07:24:18  user  syslog: wan6Autod start..
  Jun 29 07:24:18  daemon  dnsmasq[91]: using nameserver 212.69.36.3#53
  Jun 29 07:24:18  daemon  dnsmasq[91]: using nameserver 212.69.40.3#53
  Jun 29 07:24:18  daemon  pppd[31610]: Received valid IP address from server.  Connection UP.
  Jun 29 07:24:19  user  syslog: begin: interface: ppp_0_0_38_1 go to up
  Jun 29 07:24:19  daemon  UPNPD[1889]: received signal 15, good-bye
  Jun 29 07:24:21  user  syslog: Hop limit                : 64
  Jun 29 07:24:21  user  syslog: Stateful address conf.    : No
  Jun 29 07:24:21  user  syslog: Stateful other conf.      : No
  Jun 29 07:24:21  user  syslog: Router preference        : medium
  Jun 29 07:24:21  user  syslog: Router lifetime           : 1800 seconds
  Jun 29 07:24:21  user  syslog: Reachable time           : 0 milliseconds
  Jun 29 07:24:21  user  syslog: Retransmit time          : 0 milliseconds
  Jun 29 07:24:21  user  syslog: Prefix                   : 2a02:390:feed:XXXX::/64
  Jun 29 07:24:21  user  syslog: Valid time               : 2592000 seconds
  Jun 29 07:24:21  user  syslog: Pref. time               : 604800 seconds
  Jun 29 07:24:21  user  syslog: dhcp6c restart..
  Jun 29 07:24:21  daemon  UPNPD[31829]: HTTP listening on port 2800
  Jun 29 07:24:23  user  syslog: end: interface: ppp_0_0_38_1 go to up


Note near the bottom:

  Jun 29 07:24:21  user  syslog: Prefix                   : 2a02:390:feed:XXXX::/64

(XXXX marks the identifying bit, not that I'm sure why I bother to hide it, it doesn't work!)

This isn't now configured anywhere in the router, so I must be receiving this. I am getting a prefix. But there's nothing else being logged: Nothing about an upstream router (beyond the "Remote LL address" higher up), nothing about IPv6 getting set up.

BTW I'm not just giving up too soon, on the thought that IPv6 config happens after some kind of delay. Nearly an hour later (after writing the rest of this post) the only extra traffic in the syslog is:

  Jun 29 07:31:22  syslog  -- MARK --
  Jun 29 07:34:29  user  syslog: web: logout (timeout)
  Jun 29 07:34:29  user  syslog: web: ::ffff:192.168.1.101 login
  Jun 29 07:50:16  user  syslog: web: logout (timeout)
  Jun 29 07:50:17  user  syslog: web: ::ffff:192.168.1.101 login
  Jun 29 07:56:41  user  syslog: ethctl eth0 vport query 2>/var/vcfgerr
  Jun 29 07:56:41  user  syslog: rm /var/vcfgerr
  Jun 29 07:56:41  user  syslog: ethctl eth1 vport query 2>/var/vcfgerr
  Jun 29 07:56:41  user  syslog: rm /var/vcfgerr
  Jun 29 08:12:24  user  syslog: web: logout (timeout)
  Jun 29 08:12:26  user  syslog: web: ::ffff:192.168.1.101 login
  Jun 29 08:18:35  user  syslog: web: logout (timeout)
  Jun 29 08:18:37  user  syslog: web: ::ffff:192.168.1.101 login


(Which is mostly just my web admin session timing out between visits to check stuff and get more screenshots...)

Here is my config:




Now, can someone with a BiPAC 7800N for whom this is all working as advertised do the same thing please? That is:

Go to "Status->System Log"
Hit "Clear"
Go to "Status"
Hit "Disconnect"
(wait for disconnection)
Hit "Connect"
(wait for connection)

Now, first, what do you see in Status? I see this:



And syslog as above. And no IPv6 is working.

What do you see? Is there more stuff in syslog? Like it getting an upstream IPv6 router address, and configuring its own IPv6 addresses?

BTW, this also tallies with when I tried a while back to apply the Linux (Gentoo) IPv6 tutorial available here: I'd failed to apply the knowledge to an ubuntu install, so actually installed gentoo to try it direct. The logs clearly indicated that I wasn't receiving any kind of router advertisements from upstream. I tried explaining this to idnet support but all I get from there is "you are enabled for ipv6", "if you enable it it just works" and "have you tried a firmware upgrade?" and not much indication that anyone's paying any more attention than to repeat the standard things.

Addendum: Here is what I posted to support last time, and just got a "If IPv6 is switched on at the router it just works" response clearly indicating it wasn't read properly:

I think IPv6 needs to be enabled for me at the router. Please do so. I think specifically advertisements and prefix delegation and routing aren't working for me, or at least aren't working properly. Some idnetters forum posts indicate we have to specifically ask for it to be turned on, so this is me asking. (Others seemed to indicate that's not necessary any more, but as it's not working for me, I suspect it is.)

For a while I had some success using a Billion 7800N router (reported to "just work" on the idnetters forum) - It didn't "just work" for me, but it seemed to work for a while if I manually supplied a LAN IP address: 2a02:390:feed:6d2e::1. Then it would pick up a WAN IP address and work. It didn't seem quite right (as everything out there suggested I didn't need to enter the LAN IP address) but it was working so I was content.

Then last Monday it spontaneously (from my point of view as I'd changed nothing) stopped working; specifically, the setup all seemed to happen but there was no routing.

I've tried various things since then, including fully manual configuration, using linux, using OSX, using an airport base station (with manual config) and nothing worked. Finally I thought I'd try this guide by an idnetter forum user:

http://www.idnetters.co.uk/forums/index.php/topic,25909.0.html

I'd avoided it before because it takes a long time to set up gentoo, especially on the old PowerPC Mac Mini that's the only spare machine available, and then because he says this works for FTTC and I'm on ADSL - but I'm using a Vigor Draytek 120 ADSL modem which works by being a PPPoA to PPPoE bridge.

So I used it and got online (using it now) - ipv4 working fine. The problem comes when I try to use dhcpv6 to get my IPV6 delegation. According to the instructions on that post, I installed dibbler and tried it with just 'pd' for prefix delegation. This is the most verbose log I could get:

firefly dibbler # dibbler-client run
| Dibbler - a portable DHCPv6, version 0.8.2 (CLIENT, Linux port)
| Authors : Tomasz Mrugalski<thomson(at)klub.com.pl>,Marek Senderski<msend(at)o2.pl>
| Licence : GNU GPL v2 only. Developed at Gdansk University of Technology.
| Homepage: http://klub.com.pl/dhcpv6/
2012.05.05 15:04:46 Client Notice    My pid (8185) is stored in /var/lib/dibbler/client.pid
2012.05.05 15:04:46 Client Notice    Detected iface ppp0/203, MAC=.
2012.05.05 15:04:46 Client Notice    Detected iface eth1/5, MAC=00:25:4b:fd:3a:81.
2012.05.05 15:04:46 Client Notice    Detected iface sit0/4, MAC=00:00:00:00.
2012.05.05 15:04:46 Client Notice    Detected iface firewire0/3, MAC=00:0d:93:ff:fe:63:d1:c4.
2012.05.05 15:04:46 Client Notice    Detected iface eth0/2, MAC=00:0d:93:63:d1:c4.
2012.05.05 15:04:46 Client Notice    Detected iface lo/1, MAC=00:00:00:00:00:00.
2012.05.05 15:04:46 Client Notice    Parsing /etc/dibbler/client.conf config file...
2012.05.05 15:04:46 Client Debug     Prefix delegation option found.
2012.05.05 15:04:46 Client Debug     Parsing /etc/dibbler/client.conf done, result=0
2012.05.05 15:04:46 Client Debug     1 interface(s) specified in /etc/dibbler/client.conf
2012.05.05 15:04:46 Client Info      Interface ppp0/203 configuation has been loaded.
2012.05.05 15:04:46 Client Debug     DUID's value = 00:01:00:01:17:37:da:8a:00:25:4b:fd:3a:81 was loaded from client-duid file.
2012.05.05 15:04:46 Client Info      My DUID is 00:01:00:01:17:37:da:8a:00:25:4b:fd:3a:81.
2012.05.05 15:04:46 Client Info      Loading old address database (client-AddrMgr.xml), using built-in routines.
2012.05.05 15:04:46 Client Info      DB timestamp:1336226633, now()=1336226686, db is 53 second(s) old.
2012.05.05 15:04:46 Client Debug     Client 00:01:00:01:17:37:da:8a:00:25:4b:fd:3a:81 loaded from disk successfuly (0/0/0 ia/pd/ta).
2012.05.05 15:04:46 Client Debug     Bind reuse enabled (multiple instances allowed).
2012.05.05 15:04:46 Client Notice    Creating control ( socket on the lo/1 interface.
2012.05.05 15:04:46 Client Notice    Creating socket (addr=fe80::1) on ppp0/203 interface.
2012.05.05 15:04:46 Client Debug     Initialising link-state detection for interfaces: ppp0/203
2012.05.05 15:04:46 Client Notice    CONFIRM support compiled in.
2012.05.05 15:04:46 Client Info      Creating SOLICIT message with 0 IA(s), no TA and 1 PD(s) on ppp0/203 interface.
2012.05.05 15:04:46 Client Debug     Sending SOLICIT(opts:1 25 8 ) on ppp0/203 to multicast.
2012.05.05 15:04:46 Client Debug     Sleeping for 1 second(s).
2012.05.05 15:04:47 Client Info      Processing msg (SOLICIT,transID=0xefb9c1,opts: 1 25 8)
2012.05.05 15:04:47 Client Debug     Sending SOLICIT(opts:1 25 8 ) on ppp0/203 to multicast.
2012.05.05 15:04:47 Client Debug     Sleeping for 2 second(s).
2012.05.05 15:04:49 Client Info      Processing msg (SOLICIT,transID=0xefb9c1,opts: 1 25 8)
2012.05.05 15:04:49 Client Debug     Sending SOLICIT(opts:1 25 8 ) on ppp0/203 to multicast.
2012.05.05 15:04:49 Client Debug     Sleeping for 4 second(s).
2012.05.05 15:04:53 Client Info      Processing msg (SOLICIT,transID=0xefb9c1,opts: 1 25 8)
2012.05.05 15:04:53 Client Debug     Sending SOLICIT(opts:1 25 8 ) on ppp0/203 to multicast.
2012.05.05 15:04:53 Client Debug     Sleeping for 8 second(s).
^C2012.05.05 15:04:54 Client Critical  Signal received. Shutting down.
2012.05.05 15:04:54 Client Debug     Failed to read sockets (select() returned -1), error=Interrupted system call
2012.05.05 15:04:54 Client Notice    Shutting down entire client.
2012.05.05 15:04:54 Client Notice    Creating RELEASE for 0 IA(s), 1 PD(s),  (no TA) on the ppp0/203 interface.
2012.05.05 15:04:54 Client Error     Unable to send RELEASE. Unable to find DUID.
2012.05.05 15:04:54 Client Debug     Sleeping for 1 second(s).
2012.05.05 15:04:55 Client Notice    Bye bye.

Basically it seems that we're sending the SOLICIT message and getting nothing back.

I then also enabled the IA_NA option to try to get an address that way. That's actually the default in the prefix delegation example. I get this:

firefly dibbler # dibbler-client run
| Dibbler - a portable DHCPv6, version 0.8.2 (CLIENT, Linux port)
| Authors : Tomasz Mrugalski<thomson(at)klub.com.pl>,Marek Senderski<msend(at)o2.pl>
| Licence : GNU GPL v2 only. Developed at Gdansk University of Technology.
| Homepage: http://klub.com.pl/dhcpv6/
2012.05.05 15:05:06 Client Notice    My pid (8188) is stored in /var/lib/dibbler/client.pid
2012.05.05 15:05:06 Client Notice    Detected iface ppp0/203, MAC=.
2012.05.05 15:05:06 Client Notice    Detected iface eth1/5, MAC=00:25:4b:fd:3a:81.
2012.05.05 15:05:06 Client Notice    Detected iface sit0/4, MAC=00:00:00:00.
2012.05.05 15:05:06 Client Notice    Detected iface firewire0/3, MAC=00:0d:93:ff:fe:63:d1:c4.
2012.05.05 15:05:06 Client Notice    Detected iface eth0/2, MAC=00:0d:93:63:d1:c4.
2012.05.05 15:05:06 Client Notice    Detected iface lo/1, MAC=00:00:00:00:00:00.
2012.05.05 15:05:06 Client Notice    Parsing /etc/dibbler/client.conf config file...
2012.05.05 15:05:06 Client Debug     Prefix delegation option found.
2012.05.05 15:05:06 Client Debug     Parsing /etc/dibbler/client.conf done, result=0
2012.05.05 15:05:06 Client Debug     1 interface(s) specified in /etc/dibbler/client.conf
2012.05.05 15:05:06 Client Info      Interface ppp0/203 configuation has been loaded.
2012.05.05 15:05:06 Client Debug     DUID's value = 00:01:00:01:17:37:da:8a:00:25:4b:fd:3a:81 was loaded from client-duid file.
2012.05.05 15:05:06 Client Info      My DUID is 00:01:00:01:17:37:da:8a:00:25:4b:fd:3a:81.
2012.05.05 15:05:06 Client Info      Loading old address database (client-AddrMgr.xml), using built-in routines.
2012.05.05 15:05:06 Client Info      DB timestamp:1336226694, now()=1336226706, db is 12 second(s) old.
2012.05.05 15:05:06 Client Debug     Client 00:01:00:01:17:37:da:8a:00:25:4b:fd:3a:81 loaded from disk successfuly (0/0/0 ia/pd/ta).
2012.05.05 15:05:06 Client Debug     Bind reuse enabled (multiple instances allowed).
2012.05.05 15:05:06 Client Notice    Creating control ( socket on the lo/1 interface.
2012.05.05 15:05:06 Client Notice    Creating socket (addr=fe80::1) on ppp0/203 interface.
2012.05.05 15:05:06 Client Debug     Initialising link-state detection for interfaces: ppp0/203
2012.05.05 15:05:06 Client Notice    CONFIRM support compiled in.
2012.05.05 15:05:06 Client Info      Creating SOLICIT message with 1 IA(s), no TA and 1 PD(s) on ppp0/203 interface.
2012.05.05 15:05:06 Client Debug     Sending SOLICIT(opts:1 3 25 8 ) on ppp0/203 to multicast.
2012.05.05 15:05:06 Client Debug     Sleeping for 1 second(s).
2012.05.05 15:05:06 Client Debug     Received 55 bytes on interface ppp0/203 (socket=6, addr=fe80::212:7fff:feae:411b.).
2012.05.05 15:05:06 Client Info      Received ADVERTISE on ppp0/203,TransID=0x6104e, 3 opts: 2 1 13
2012.05.05 15:05:06 Client Notice    IA_NA option requested, but not present in this message. Ignored.
2012.05.05 15:05:06 Client Notice    PD option requested, but not returned in this message. Ignored.
2012.05.05 15:05:06 Client Info      Server message was rejected.
2012.05.05 15:05:06 Client Debug     Not executing external script (Notify script disabled).
2012.05.05 15:05:06 Client Debug     Sleeping for 1 second(s).
2012.05.05 15:05:07 Client Info      Processing msg (SOLICIT,transID=0x6104e,opts: 1 3 25 8)
2012.05.05 15:05:07 Client Debug     Sending SOLICIT(opts:1 3 25 8 ) on ppp0/203 to multicast.
2012.05.05 15:05:07 Client Debug     Sleeping for 2 second(s).
2012.05.05 15:05:07 Client Debug     Received 55 bytes on interface ppp0/203 (socket=6, addr=fe80::212:7fff:feae:411b.).
2012.05.05 15:05:07 Client Info      Received ADVERTISE on ppp0/203,TransID=0x6104e, 3 opts: 2 1 13
2012.05.05 15:05:07 Client Notice    IA_NA option requested, but not present in this message. Ignored.
2012.05.05 15:05:07 Client Notice    PD option requested, but not returned in this message. Ignored.
2012.05.05 15:05:07 Client Info      Server message was rejected.
2012.05.05 15:05:07 Client Debug     Not executing external script (Notify script disabled).
2012.05.05 15:05:07 Client Debug     Sleeping for 2 second(s).
2012.05.05 15:05:09 Client Info      Processing msg (SOLICIT,transID=0x6104e,opts: 1 3 25 8)
2012.05.05 15:05:09 Client Debug     Sending SOLICIT(opts:1 3 25 8 ) on ppp0/203 to multicast.
2012.05.05 15:05:09 Client Debug     Sleeping for 4 second(s).
2012.05.05 15:05:09 Client Debug     Received 55 bytes on interface ppp0/203 (socket=6, addr=fe80::212:7fff:feae:411b.).
2012.05.05 15:05:09 Client Info      Received ADVERTISE on ppp0/203,TransID=0x6104e, 3 opts: 2 1 13
2012.05.05 15:05:09 Client Notice    IA_NA option requested, but not present in this message. Ignored.
2012.05.05 15:05:09 Client Notice    PD option requested, but not returned in this message. Ignored.
2012.05.05 15:05:09 Client Info      Server message was rejected.
2012.05.05 15:05:09 Client Debug     Not executing external script (Notify script disabled).
2012.05.05 15:05:09 Client Debug     Sleeping for 4 second(s).
2012.05.05 15:05:13 Client Info      Processing msg (SOLICIT,transID=0x6104e,opts: 1 3 25 8)
2012.05.05 15:05:13 Client Debug     Sending SOLICIT(opts:1 3 25 8 ) on ppp0/203 to multicast.
2012.05.05 15:05:13 Client Debug     Sleeping for 8 second(s).
2012.05.05 15:05:13 Client Debug     Received 55 bytes on interface ppp0/203 (socket=6, addr=fe80::212:7fff:feae:411b.).
2012.05.05 15:05:13 Client Info      Received ADVERTISE on ppp0/203,TransID=0x6104e, 3 opts: 2 1 13
2012.05.05 15:05:13 Client Notice    IA_NA option requested, but not present in this message. Ignored.
2012.05.05 15:05:13 Client Notice    PD option requested, but not returned in this message. Ignored.
2012.05.05 15:05:13 Client Info      Server message was rejected.
2012.05.05 15:05:13 Client Debug     Not executing external script (Notify script disabled).
2012.05.05 15:05:13 Client Debug     Sleeping for 8 second(s).
^C2012.05.05 15:05:14 Client Critical  Signal received. Shutting down.
2012.05.05 15:05:14 Client Debug     Failed to read sockets (select() returned -1), error=Interrupted system call
2012.05.05 15:05:14 Client Notice    Shutting down entire client.
2012.05.05 15:05:14 Client Notice    Creating RELEASE for 0 IA(s), 1 PD(s),  (no TA) on the ppp0/203 interface.
2012.05.05 15:05:14 Client Error     Unable to send RELEASE. Unable to find DUID.
2012.05.05 15:05:14 Client Debug     Sleeping for 1 second(s).
2012.05.05 15:05:15 Client Notice    Bye bye.

Now it looks like I am actually getting a response:

2012.05.05 15:05:07 Client Debug     Received 55 bytes on interface ppp0/203 (socket=6, addr=fe80::212:7fff:feae:411b.).
2012.05.05 15:05:07 Client Info      Received ADVERTISE on ppp0/203,TransID=0x6104e, 3 opts: 2 1 13

and I recognise that address: it's the link-local address of the upstream router at your end that I could see with my partial success using other systems. So I do seem to be reaching that server, and getting a reply from it.

But there's no IA_NA or PD returned in that reply.

(BTW I tried waiting longer for a reply - many minutes - without any difference. The log pasted here is of a shorter attempt only for brevity.)

I suspect I've *never* received these advertisements, on the Billion, on anything, but with a bit of a nudge (supplying the LAN IP address which allowed other stuff to configure itself) I at least got routing and it worked. So if anything it looks now as if something was *fixed* on the router so it doesn't route for users it's not configured to deliver prefix delegation to. At least, it was intermittently fixed; as sometimes I could get routing through a manual configuration, but later, without having changed it here, it wasn't working any more. Finally it seemed to settle on no-routing.

So in summary, I think it just needs you to 'switch my ipv6 on'.

This is the last throw of the dice for me. I chose this ISP for IPv6 support, but it doesn't work and I'm not getting the support.

[Glenn]

Rachel, have you called support to see if they can help?

[Rachel]

Rachel, have you called support to see if they can help?

As reported in the post above, i've had little joy from emailing support (there are logs to show so phoning seems far less efficient than emailing); hence posting here to see if another idnetter with a billion 7800n (i know they're here) for whom it's all working as it's supposed to can compare what they see in *their* logs so i can *prove* something's not enabled for me the way it is for them, as i've been suspecting and reporting to support for months.

[Rachel]

Rachel, have you called support to see if they can help?

part of the problem of course is that it sometimes starts working again, as randomly as when it stops. And when it does, I just have to go "oh, it's working again" and wander off.

But it's *never* worked without that LAN IPv6 address setting, which I'm *sure* is wrong. So I really think that needs to be fixed.

[Bill]

I can't help with an explanation, but here's what my log says for a disconnect/reconnect using FTTC:

Jun 29 10:09:06  user  syslog: web: logout (timeout)
  Jun 29 10:09:13  user  syslog: web: ::ffff:192.168.1.66 login
  Jun 29 10:10:48  daemon  pppd[18560]: PPPoE: Terminating on signal 15.
  Jun 29 10:10:48  daemon  pppd[18560]: Clear IP addresses.  Connection DOWN.
  Jun 29 10:10:48  daemon  pppd[18560]: Clear IP addresses.
  Jun 29 10:10:48  daemon  pppd[18560]: Couldn't increase MTU to 1500.
  Jun 29 10:10:48  daemon  pppd[18560]: Couldn't increase MRU to 1500
  Jun 29 10:10:48  daemon  pppd[18560]: Connection terminated.
  Jun 29 10:10:48  daemon  pppd[18560]: Connect time 23007.4 minutes.
  Jun 29 10:10:48  daemon  pppd[18560]: Sent 2755582392 bytes, received 16289257184 bytes.
  Jun 29 10:10:48  user  kernel: dev_shutdown, dec ppp device refcnt, dev->refcnt=8
  Jun 29 10:10:48  daemon  dhcp6c[21349]: client6_send: transmit failed: Network is unreachable
  Jun 29 10:10:48  daemon  pppd[18560]: Doing disconnect
  Jun 29 10:10:48  user  kernel: unregister_netdevice: waiting for ppp_ewan_1 to become free. Usage count = -1
  Jun 29 10:10:48  user  kernel: dev->name = ppp_ewan_1, dev->refcnt=-1
  Jun 29 10:10:48  user  kernel: after reset to 0, dev->refcnt=0
  Jun 29 10:10:51  daemon  pppd[18560]: Exit.
  Jun 29 10:10:52  user  syslog: begin: interface: ppp_ewan_1 go to down
  Jun 29 10:10:52  user  syslog: end: interface: ppp_ewan_1 go to down
  Jun 29 10:10:59  daemon  pppd[23722]: pppd 2.4.1 started by admin, uid 0
  Jun 29 10:10:59  daemon  pppd[23722]: PPP: Start to connect ...
  Jun 29 10:10:59  daemon  pppd[23722]: PPP server detected.
  Jun 29 10:10:59  daemon  pppd[23722]: PPP session established.
  Jun 29 10:10:59  daemon  pppd[23722]: Using interface pppewan_1
  Jun 29 10:10:59  daemon  pppd[23722]: Connect: ppp_ewan_1 <--> eth0
  Jun 29 10:10:59  daemon  pppd[23722]: Couldn't increase MTU to 1500.
  Jun 29 10:10:59  daemon  pppd[23722]: Couldn't increase MRU to 1500
  Jun 29 10:10:59  daemon  pppd[23722]: Couldn't increase MRU to 1500
  Jun 29 10:10:59  daemon  pppd[23722]: PPP LCP UP.
  Jun 29 10:11:00  daemon  pppd[23722]: Couldn't increase MTU to 1500.
  Jun 29 10:11:00  daemon  pppd[23722]: Couldn't increase MRU to 1500
  Jun 29 10:11:00  daemon  pppd[23722]: Couldn't increase MRU to 1500
  Jun 29 10:11:00  daemon  pppd[23722]: PPP LCP UP.
  Jun 29 10:11:02  user  syslog: ping -c 1 8.8.8.8 &
  Jun 29 10:11:05  daemon  pppd[23722]: local  LL address fe80::05f9:f29b:23a7:xxxx
  Jun 29 10:11:05  daemon  pppd[23722]: remote LL address fe80::0212:7fff:feae:xxxx
  Jun 29 10:11:05  daemon  pppd[23722]: local  IP address 212.69.xxx.xxx
  Jun 29 10:11:05  daemon  pppd[23722]: remote IP address 212.69.63.98
  Jun 29 10:11:05  daemon  pppd[23722]: primary   DNS address 212.69.40.3
  Jun 29 10:11:05  daemon  pppd[23722]: secondary DNS address 212.69.36.3
  Jun 29 10:11:05  daemon  dnsmasq[92]: using nameserver 212.69.36.3#53
  Jun 29 10:11:05  daemon  dnsmasq[92]: using nameserver 212.69.40.3#53
  Jun 29 10:11:05  daemon  pppd[23722]: Received valid IP address from server.  Connection UP.
  Jun 29 10:11:06  user  syslog: wan6Autod start..
  Jun 29 10:11:06  user  syslog: begin: interface: ppp_ewan_1 go to up
  Jun 29 10:11:06  daemon  UPNPD[22411]: received signal 15, good-bye
  Jun 29 10:11:08  user  syslog: Hop limit                : 64
  Jun 29 10:11:08  user  syslog: Stateful address conf.    : No
  Jun 29 10:11:08  user  syslog: Stateful other conf.      : No
  Jun 29 10:11:08  user  syslog: Router preference        : medium
  Jun 29 10:11:08  user  syslog: Router lifetime           : 1800 seconds
  Jun 29 10:11:08  user  syslog: Reachable time           : 0 milliseconds
  Jun 29 10:11:08  user  syslog: Retransmit time          : 0 milliseconds
  Jun 29 10:11:08  user  syslog: Prefix                   : 2a02:390:feed:6109::/64
  Jun 29 10:11:08  user  syslog: Valid time               : 2592000 seconds
  Jun 29 10:11:08  user  syslog: Pref. time               : 604800 seconds
  Jun 29 10:11:08  user  syslog: dhcp6c restart..
  Jun 29 10:11:09  daemon  UPNPD[23991]: HTTP listening on port 2800
  Jun 29 10:11:11  user  syslog: end: interface: ppp_ewan_1 go to up
  Jun 29 10:11:18  user  syslog: dhcp6s restart..
  Jun 29 10:11:18  daemon  radvd[24709]: version 1.0 started

According to a few test sites, IPv6 is working fine.

Router firmware is 1.06e, and I don't have to configure anything for IPv6- just check the "Enable IPv6" box on the WAN Profile page.

I'm also using a Mac, but that shouldn't really matter afaik.

Hope it may be of some help.

[Rachel]

hmm. Thanks for doing that. I can see there's nothing extra in the syslog for a successful ipv6 configuration then. Was hoping there would be lines where it got its ip address, got its upstream router address, etc. But it seems to all be happening invisibly.

I'm actually on a later firmware than you. I was actually running 1.06e last time I had this problem and tried reporting it to support; and naturally they asked if I was on the latest version; turns out there was a later one so I upgraded and it *seemed* to fix it for a while, until the next time it stopped working.

And again, for values of "fixed" that don't include "works when all i do is enable IPv6 like you." :-)

Hmm. The FTTC connection you have (not an option here). I can see from your logs that that's an EWAN connection - ie: the lead goes into the EWAN port on the back of the router. It's using ppp_ewan_1 as its connection.

It gives me another thing to try. I'm only on plain old ADSL2+ here, going into the ADSL port on the router. Maybe it's *that* that doesn't work. As I do still have the draytek vigor 120 (which bridges PPPoA to PPPoE) I can try using that, plugged into the billion's EWAN port to get closer to your setup.

I'm only half-hopeful as of course it's that modem and the PPPoA->PPPoE bridging that I was using when I tried setting it up with my own linux router (I can also see from the logs that Billion routers are running an embedded linux), but still didn't seem to be getting router advertisements. But it's one more thing that's worth a try.

Or maybe it just only works with FTTC/FTTP. Any Billion IDNetters out there using this successfully on ADSL? :-)

[Bill]

I'm actually on a later firmware than you.

I noticed that... I'm a firm believer in "if it ain't broke don't fix it", and as 1.06e worked fine for me I skipped 1.06f, and on the Billion support forum 1.06g seems to have some problems (mainly on the wireless side), so I'm waiting for 1.06h

But as you had the same problem with 1.06e it seems the modem is a possibility... good luck!

[Rachel]

I noticed that... I'm a firm believer in "if it ain't broke don't fix it", and as 1.06e worked fine for me I skipped 1.06f, and on the Billion support forum 1.06g seems to have some problems (mainly on the wireless side), so I'm waiting for 1.06h

But as you had the same problem with 1.06e it seems the modem is a possibility... good luck!

Ironic as the release notes for 1.06g boasted of its "improved wireless driver" and i had had some unreliability about wifi before then anyway, but had put it down to a crowded neighbourhood.

[Rachel]

But as you had the same problem with 1.06e it seems the modem is a possibility... good luck!

Well, two possibilities: There's a bug in the firmware or hardware so that IPv6 autodiscovery doesn't work over PPPoA via the ADSL port, but does work over PPPoE over EWAN. In which case using the external ADSL modem Might Just Work. (assuming its PPPoA->PPPoE bridging is complete and doesn't fail on IPv6 data. I doubt that as PPP should be encapsulated either way, but I did also have little success using that modem on other routers and clients.)

Other possibility is that the idnet ipv6 setup only works properly through the customer-facing servers serving FTTC/FTTP customers, and not ADSL customers, in which case it won't work.

At some point in the next few minutes I'm going to have to actually get up and try it. ;-)

[psp83]

Or maybe it just only works with FTTC/FTTP. Any Billion IDNetters out there using this successfully on ADSL? :-)

When I was on ADSL2+, the Billion 7800n worked fine for me with IPv6.

But I'm on FTTC now and here's my screenshots & log.

Jun 29 11:16:23  daemon  pppd[31918]: PPPoE: Terminating on signal 15.
  Jun 29 11:16:23  daemon  pppd[31918]: Clear IP addresses.  Connection DOWN.
  Jun 29 11:16:23  daemon  pppd[31918]: Clear IP addresses.
  Jun 29 11:16:23  daemon  pppd[31918]: Couldn't increase MTU to 1500.
  Jun 29 11:16:23  daemon  pppd[31918]: Couldn't increase MRU to 1500
  Jun 29 11:16:23  daemon  pppd[31918]: Connection terminated.
  Jun 29 11:16:23  daemon  pppd[31918]: Connect time 1045.4 minutes.
  Jun 29 11:16:23  daemon  pppd[31918]: Sent 158316718 bytes, received 5449185866 bytes.
  Jun 29 11:16:23  user  kernel: dev_shutdown, dec ppp device refcnt, dev->refcnt=6
  Jun 29 11:16:24  daemon  pppd[31918]: Doing disconnect
  Jun 29 11:16:24  user  kernel: unregister_netdevice: waiting for ppp_ewan_1 to become free. Usage count = -1
  Jun 29 11:16:24  user  kernel: dev->name = ppp_ewan_1, dev->refcnt=-1
  Jun 29 11:16:24  user  kernel: after reset to 0, dev->refcnt=0
  Jun 29 11:16:26  daemon  dhcp6c[32188]: client6_send: transmit failed: Network is unreachable
  Jun 29 11:16:27  daemon  pppd[31918]: Exit.
  Jun 29 11:16:27  user  syslog: begin: interface: ppp_ewan_1 go to down
  Jun 29 11:16:27  user  syslog: end: interface: ppp_ewan_1 go to down
  Jun 29 11:16:33  daemon  pppd[322]: pppd 2.4.1 started by admin, uid 0
  Jun 29 11:16:33  daemon  pppd[322]: PPP: Start to connect ...
  Jun 29 11:16:33  daemon  pppd[322]: PPP server detected.
  Jun 29 11:16:33  daemon  pppd[322]: PPP session established.
  Jun 29 11:16:33  daemon  pppd[322]: Using interface pppewan_1
  Jun 29 11:16:33  daemon  pppd[322]: Connect: ppp_ewan_1 <--> eth0
  Jun 29 11:16:33  daemon  pppd[322]: Couldn't increase MTU to 1500.
  Jun 29 11:16:33  daemon  pppd[322]: Couldn't increase MRU to 1500
  Jun 29 11:16:33  daemon  pppd[322]: Couldn't increase MRU to 1500
  Jun 29 11:16:33  daemon  pppd[322]: PPP LCP UP.
  Jun 29 11:16:34  daemon  pppd[322]: Couldn't increase MTU to 1500.
  Jun 29 11:16:34  daemon  pppd[322]: Couldn't increase MRU to 1500
  Jun 29 11:16:34  daemon  pppd[322]: Couldn't increase MRU to 1500
  Jun 29 11:16:34  daemon  pppd[322]: PPP LCP UP.
  Jun 29 11:16:36  user  syslog: ping -c 1 8.8.8.8 &
  Jun 29 11:16:39  daemon  pppd[322]: local  LL address fe80::597b:18a3:9330:xxxx
  Jun 29 11:16:39  daemon  pppd[322]: remote LL address fe80::0212:7fff:feae:xxxx
  Jun 29 11:16:39  daemon  pppd[322]: local  IP address 91.135.xxx.xxx
  Jun 29 11:16:39  daemon  pppd[322]: remote IP address 212.69.63.98
  Jun 29 11:16:39  daemon  pppd[322]: primary   DNS address 212.69.40.3
  Jun 29 11:16:39  daemon  pppd[322]: secondary DNS address 212.69.36.3
  Jun 29 11:16:39  daemon  dnsmasq[91]: using nameserver 212.69.36.3#53
  Jun 29 11:16:39  daemon  dnsmasq[91]: using nameserver 212.69.40.3#53
  Jun 29 11:16:39  daemon  pppd[322]: Received valid IP address from server.  Connection UP.
  Jun 29 11:16:40  user  syslog: wan6Autod start..
  Jun 29 11:16:40  user  syslog: begin: interface: ppp_ewan_1 go to up
  Jun 29 11:16:41  daemon  UPNPD[32199]: received signal 15, good-bye
  Jun 29 11:16:42  user  syslog: Hop limit                : 64
  Jun 29 11:16:42  user  syslog: Stateful address conf.    : No
  Jun 29 11:16:42  user  syslog: Stateful other conf.      : No
  Jun 29 11:16:42  user  syslog: Router preference        : medium
  Jun 29 11:16:42  user  syslog: Router lifetime           : 1800 seconds
  Jun 29 11:16:42  user  syslog: Reachable time           : 0 milliseconds
  Jun 29 11:16:42  user  syslog: Retransmit time          : 0 milliseconds
  Jun 29 11:16:42  user  syslog: Prefix                   : 2a02:390:feed:6353::/64
  Jun 29 11:16:42  user  syslog: Valid time               : 2592000 seconds
  Jun 29 11:16:42  user  syslog: Pref. time               : 604800 seconds
  Jun 29 11:16:42  user  syslog: dhcp6c restart..
  Jun 29 11:16:43  daemon  UPNPD[597]: HTTP listening on port 2800
  Jun 29 11:16:45  user  syslog: end: interface: ppp_ewan_1 go to up
  Jun 29 11:16:48  daemon  radvd[813]: version 1.0 started
  Jun 29 11:16:48  user  syslog: dhcp6s restart..

Hope it helps...

Also, phone support and ask them if IPv6 is setup correctly for your connection.

If it is, ask them if they can disable it and re enable it.

If that doesn't work, have you thought about trying a new router? your 7800n might be on its way out.

[Rachel]

I've plugged in the vigor 120, it works exactly as well as adsl - ie: ipv4 works fine, no ipv6 in exactly the same way. My configuration now looks very like both of yours, now it's doing PPPoE over the EWAN port. All the IPv6 specific configuration (what there is of it) is the same.

I noticed one difference between my logs and both of yours, just now. Yours has:

  Jun 29 11:16:48  daemon  radvd[813]: version 1.0 started

And mine doesn't. Just wondering if I might be encountering this:

http://www.billion.uk.com/forum/viewtopic.php?f=9&t=46

And then what to do about it. Just found it when your reply came in...

[Rachel]

at least I do have absolute confirmation I'm not supposed to have to enter that IP into the LAN IPv6 field. I think whenever that worked for me it was probably a coincidence.

[psp83]

Try a factory reset and flash to 1.06f.dc1, that's what mine is running on.

Other than that, all I can say is that:

A. You buy another 7800n or return your one as faulty
B. Keep bugging Billion for a fix 

[Rachel]

Try a factory reset and flash to 1.06f.dc1, that's what mine is running on.

Other than that, all I can say is that:

A. You buy another 7800n or return your one as faulty
B. Keep bugging Billion for a fix 

Many factory resets have been tried. I was also on that firmware version for a while. No change except sometimes the factory reset lets it work *with the manually-entered lan ipv6 address* for a while. Sometimes.

[Rachel]

i'm opening a ticket with billion now.

[Rachel]

well, no reply yet; wonder if I'll get one. It'll probably be along the lines of "the radvd daemon starts up after the router receives an ipv6 address, and it's not receiving one". after which i suppose will follow an exchange where hopefully i can present something very specific to idnet support about what their routers aren't doing. :-}

In the meantime all the various experiments with the draytek vigor 120 have culminated in me realising it may have its own issues. When I abandoned the billion for a while and tried using that with the airport extreme base station as router (no attempt at ipv6) i kept getting massive packet loss and slow performance. I thought (and hoped) that that was the fault of the AEBS, especially with busy LAN traffic going through its ports, but I've now also been getting that - not as bad but still a problem - with the draytek on the back of the billion. It all worked, but with significant packet loss making web browsing frustrating and web video watching impossible. it's a separate problem entirely to the ipv6 stuff - a performance issue rather than a compatibility issue, but it's a bit of a shame as I had kind of been hoping, after the billion's ipv6 was working, to crib from its config files to set up my own linux router, which I always prefer, being able to Properly Nail Things Down and have it do extra nice stuff like web proxy, openvpn, etc.

It wasn't having these problems when I first got it, before i got the billion, and it's spent most of the time since then just not being used. I don't know whether it's a fault or whether there is in fact bad ADSL weather right now that the billion is better compensating for, its ability to do so being one of its selling points, as I recall.

[Bill]

Just a thought- whose DNS are you using?

IDNet's seems OK for me with IPv6, but some are flakier- I remember I had problems in my early days with OpenDNS (I didn't try Google's).

[Rachel]

Just a thought- whose DNS are you using?

IDNet's seems OK for me with IPv6, but some are flakier- I remember I had problems in my early days with OpenDNS (I didn't try Google's).

Thought of that already. :-) Generally I use the default from idnet; I did try switching to google's directly on a couple of client machines (rather than in the router). Made no difference, so I knew it wasn't that. Besides pinging the upstream (ipv4) idnet router by ip address was showing just as much packet loss as anything further afield.

oh wait, you mean for the ipv6 thing. My fault for going offtopic. Again, we're not actually getting that far. When I was getting that far, when entering my LAN IPv6 address was working, I believe it was idnet's ipv6 dns, but I can't confirm that now. I did notice when it was 'working' when i tried test-ipv6.com one test it *sometimes* failed on was ISP's DNS support. Think if it's a problem at all it's a separate one. With a 'correct' configuration i'm not getting any IPv6 autoconfig at all. DNS is a few steps further down the line than that.

[Rachel]

OK, I have a theory. Bill, psp83, I need a favour.

My theory is - slightly refined from before with a bit more knowledge - that IDNet aren't responding to DHCPv6 requests for prefix delegation from me, but they are from you, and that's why it works for you and not for me.

I've managed to figure out how to run the DHCPv6 client on the Billion router with debug logging enabled, and can see that it's sending requests for prefix delegation information and not getting any answers. Which is exactly what I found when I tried to follow the Gentoo howto in this forum a month or two ago, but now we're trying to prove it using the Billion on its proper configuration.

What I don't know is whether they're sending those answers for you, thus making it all work, or not, in which case it works for you for some completely different reason.

So what I need you to do is to enable debug logging on your Billion routers (instructions below) and paste the results, so that I have a known-good log to compare against, and bring to their attention.

First you need to be able to log into your billion router's shell. We're not going to change any permanent configuration (actually it would be hard to do, there's no editor); we're just going to stop the DHCPv6 client and restart it in exactly the same way but with debug logging turned on. You shouldn't even lose your existing connection. (Though you may want to disconnect/reconnect at the end of all this, just to make sure the original DHCPv6 client is running again and everything is restored to normal.)

For this you need ssh. Excuse me if I'm teaching you to suck eggs here.

If you're on linux or mac this is easy, just do:

Code Select Expand

ssh admin@192.168.1.254

(or whatever your router's LAN IPv4 address is - that's the default.)

If you're on Windows, you need to get putty from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html (just get putty.exe) and open a connection to the router's ip address (ie: 192.168.1.254 most likely) and user "admin". When you connect, a terminal window will open up.

You'll be asked for the admin password. It's the same one used to log into the web interface.

Once in you'll have a simple commandline interface with a prompt like:

>

Firstly, enter the command:

Code Select Expand

sh

That just switches to a slightly more capable commandline environment (the bourne shell - but actually busybox), and the command prompt will change to:

#

from now on.

OK, first I just want to check some configuration; a sanity check that things are configured for you like they are for me. Type the following commands:

Code Select Expand

cat /proc/sys/net/ipv6/conf/ppp_ewan_1/forwarding

Expecting you to get:

0

ie: The Billion is claiming not to be a router on that interface (despite the fact it obviously is one). That way it receives router advertisements. Linux will disregard router advertisements if it thinks it's a router. This may be why I've had some partial success connecting individual hosts to IPv6 directly rather than using a router, or setting up a router.

Code Select Expand

cat /proc/sys/net/ipv6/conf/ppp_ewan_1/accept_ra

Expecting you to get:

1

Which just makes really sure it's set up to listen out for router advertisements.

I think we are all receiving router advertisements. For instance it turns out when I do:

Code Select Expand

ifconfig ppp_0_0_38_1

I can see that my PPP interface has acquired an IP address, even though it doesn't show up in the web interface. I also don't have any ipv6 routing out. I think that's because the DHCPv6 stuff has to work too.

ie:

# ifconfig ppp_0_0_38_1
ppp_0_0_38_1    Link encap:Point-Point Protocol 
                inet addr:93.89.130.22  P-t-P:212.69.63.98  Mask:255.255.255.255
          inet6 addr: 2a02:390:feed:6d2e:7ce6:e21a:e15f:bd3a/64 Scope:Global
          inet6 addr: fe80::7ce6:e21a:e15f:bd3a/10 Scope:Link
                UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
                RX packets:7528 errors:0 dropped:0 overruns:0 frame:0
                TX packets:7698 errors:0 dropped:0 overruns:0 carrier:0
                collisions:0 txqueuelen:3
                RX bytes:2750187 (2.6 MiB)  TX bytes:1028503 (1004.3 KiB)

#

(Again for you to see the same you'd substitute your PPP interface name, eg:)

Code Select Expand

ifconfig ppp_ewan_1

So onto DHCPv6 itself...

Code Select Expand

cat /var/dhcp6c_ppp_ewan_1.conf

You should get back something like:

interface ppp_ewan_1{

         send ia-pd 0;
};
id-assoc pd 0
{
   prefix-interface br0
   {
      sla-id 0;
      sla-len 0;
   };
};

That's basically to confirm that your routers, like mine, are trying to use DHCPv6 to obtain a prefix delegation.

Now:

Code Select Expand

cat /var/run/dhcp6c_eth0.pid

It should reply with just a number. eg:

# cat /var/run/dhcp6c_eth0.pid
16440
#

That's the process ID of the DHCPv6 client daemon already running. We're going to stop it:

Code Select Expand

kill 16440

substitute the number you got back from the command above. Or you can be a bit more elegant and do:

Code Select Expand

kill `cat /var/run/dhcp6c_eth0.pid`

(Those are the backtick character, probably somewhere on the left side of your keyboard, and not the apostrophe character. It basically lets you use the output of one command inside another. The more modern way eg:

Code Select Expand

kill $(cat /var/run/dhcp6c_eth0.pid)

doesn't work on the minimal shell in the Billion.)

Now we start the DHCPv6 daemon again, but with debug logging available:

Code Select Expand

dhcp6c -D -c /var/dhcp6c_ppp_ewan_1.conf -p /var/run/dhcp6c_eth0.pid ppp_ewan_1 &

Breakdown of that command for the paranoid:

dhcp6c	Start the DHCPv6 Client
-D	Turn on debug logging
-c /var/dhcp6c_ppp_ewan_1.conf	Use this config file (same one as usual)
-p /var/run/dhcp6c_eth0.pid	Write process ID to this file. (So the web interface can kill it itself later when you reconnect)
ppp_ewan_1	Send DHCPv6 requests and listen for replies on the PPP interface
&	Put this process into the backgroun, so you get the shell prompt back

Now look at the system log in the web interface, refresh, and see what happened. I got this:

  Jul 01 14:43:27  daemon  dhcp6c[30132]: get_duid: extracted an existing DUID from /var/dhcp6c_duid: 00:03:00:01:00:04:ed:bf:94:9e
  Jul 01 14:43:27  daemon  dhcp6c[30132]: client6_init: failed initialize control message authentication
  Jul 01 14:43:27  daemon  dhcp6c[30132]: client6_init: skip opening control port
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>[interface] (9)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <5>[ppp_0_0_38_1] (12)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>begin of closure [{] (1)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>[send] (4)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>[ia-pd] (5)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>[ 0] (1)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>end of sentence [;] (1)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>end of closure [}] (1)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>end of sentence [;] (1)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>[id-assoc] (8)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <13>[pd] (2)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <13>[ 0] (1)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <13>begin of closure [{] (1)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>[prefix-interface] (16)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <5>[br0] (3)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>begin of closure [{] (1)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>[sla-id] (6)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>[ 0] (1)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>end of sentence [;] (1)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>[sla-len] (7)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>[ 0] (1)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>end of sentence [;] (1)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>end of closure [}] (1)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>end of sentence [;] (1)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>end of closure [}] (1)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: cfdebug_print: <3>end of sentence [;] (1)
  Jul 01 14:43:27  daemon  dhcp6c[30132]: configure_pool: called
  Jul 01 14:43:27  daemon  dhcp6c[30132]: clear_poolconf: called
  Jul 01 14:43:27  daemon  dhcp6c[30132]: dhcp6_reset_timer: reset a timer on ppp_0_0_38_1, state=INIT, timeo=0, retrans=2108
  Jul 01 14:43:29  daemon  dhcp6c[30132]: client6_send: a new XID (edf154) is generated
  Jul 01 14:43:29  daemon  dhcp6c[30132]: copy_option: set client ID (len 10)
  Jul 01 14:43:29  daemon  dhcp6c[30132]: copy_option: set elapsed time (len 2)
  Jul 01 14:43:29  daemon  dhcp6c[30132]: copyout_option: set IA_PD
  Jul 01 14:43:29  daemon  dhcp6c[30132]: client6_send: send solicit to ff02::1:2
  Jul 01 14:43:29  daemon  dhcp6c[30132]: dhcp6_reset_timer: reset a timer on ppp_0_0_38_1, state=SOLICIT, timeo=0, retrans=1097
  Jul 01 14:43:30  daemon  dhcp6c[30132]: copy_option: set client ID (len 10)
  Jul 01 14:43:30  daemon  dhcp6c[30132]: copy_option: set elapsed time (len 2)
  Jul 01 14:43:30  daemon  dhcp6c[30132]: copyout_option: set IA_PD
  Jul 01 14:43:30  daemon  dhcp6c[30132]: client6_send: send solicit to ff02::1:2
  Jul 01 14:43:30  daemon  dhcp6c[30132]: dhcp6_reset_timer: reset a timer on ppp_0_0_38_1, state=SOLICIT, timeo=1, retrans=2103
  Jul 01 14:43:32  daemon  dhcp6c[30132]: copy_option: set client ID (len 10)
  Jul 01 14:43:32  daemon  dhcp6c[30132]: copy_option: set elapsed time (len 2)
  Jul 01 14:43:32  daemon  dhcp6c[30132]: copyout_option: set IA_PD
  Jul 01 14:43:32  daemon  dhcp6c[30132]: client6_send: send solicit to ff02::1:2
  Jul 01 14:43:32  daemon  dhcp6c[30132]: dhcp6_reset_timer: reset a timer on ppp_0_0_38_1, state=SOLICIT, timeo=2, retrans=4406

And it goes on like that, periodically retrying and never getting an answer. Exactly the same as I found with dibbler-client on gentoo.

What I expect you to see is something like:

client6_send: send solicit to ff02::1:2
dhcp6_reset_timer: reset a timer on ppp_ewan_1, state=SOLICIT, timeo=0, retrans=1097
client6_recv: receive reply from fe80::(something)

... and more dhcpv6 data coming in. That's basically what I'm after: what it looks like when it works. If I can prove that, I can take that back to idnet with some degree of confidence.

[Bill]

I'm OK up to the command

cat /var/dhcp6c_ppp_ewan_1.conf

everything returns the same as yours with different numbers, but when I enter

# cat /var/run/dhcp6c_eth0.pid

I get

cat: /var/run/dhcp6c_eth0.pid: No such file or directory

I've also tried

# cat /var/run/dhcp6c_ppp_ewan_1.pid

and

# cat /var/run/dhcp6c_ewan_1.pid

with the same result.

As I don't really have the faintest idea what I'm doing I need HELP PLEASE

[Rachel]

Hm. Right. On the first thing, the missing dhcp6c_eth0.pid, a couple of possibilities:

1: It's written it out to a different filename than it does on mine (possible as you're running a slightly older firmware version)

2: It's not running dhcp6c. It does start it; I can see in your logs the line:

  Jun 29 10:11:08  user  syslog: dhcp6c restart..

but it may have quit; which would surprise me: It's my understanding that even if it works and gets the information it needs at startup, it should still stay in the background and occasionally request again in case the upstream wants to change it.

So let's find out:

At the # prompt, enter the command:

Code Select Expand

ps

and look for a line with dhcp6c in it; a bit like this:

420 admin       384 S   dhcp6c -c /var/dhcp6c_ppp_0_0_38_1.conf -p /var/run/d

That tells us if the dhcp6c daemon is running right now.

Also, do this to find the pid file:

Code Select Expand

ls /var/run/dhcp6*

ie: we'll do a wildcard search for that pid file. Assuming there's one there, substitute that filename in the rest of the instructions.

If you cat that file, you should then see the same number as at the start of the dhcp6d line in the 'ps' output. ie, in the case above, 420. It's bound to be different for you.

If it doesn't seem to be in /var/run at all, we need to start getting really clever. Assuming the process is running and you got a line from 'ps' like:

420 admin       384 S   dhcp6c -c /var/dhcp6c_ppp_0_0_38_1.conf -p /var/run/d

take that first number - 420 in my case - and do this:

Code Select Expand

cat /proc/420/cmdline

And you'll get a line back like this:

dhcp6c-c/var/dhcp6c_ppp_0_0_38_1.conf-p/var/run/dhcp6c_eth0.pidppp_0_0_38_1__eth0

(press return; there's no linefeed at the end so the # prompt will have just got stuck on the end of the line.)

(In fact, just paste back the line you get back; it may forestall other issues later. My later instructions make assumptions that that may prove or disprove.)

This is the commandline used by the system to start dhcp6c (slightly mangled by having spaces chopped out). Look for the sequence in there that starts "-p" and ends ".pid". Everything after the "-p" to the end of ".pid" is the filename.

OK, assuming you can progress through there and get to the later stages I have a slight edit to the command used to launch dhcp6c - realised something I didn't quite get when I was writing the earlier post.

The command to launch dhcp6c should be:

Code Select Expand

dhcp6c -D -c /var/dhcp6c_ppp_ewan_1.conf -p /var/run/dhcp6c_eth0.pid ppp_ewan_1__eth0

(Basically, I didn't quite get what was going on with that __eth0 at the end before. Figured eventually the final interface parameter should just be ppp_ewan_1__eth0 (or in my case ppp_0_0_38_1__eth0). The logged result I get is the same as I pasted earlier, so I don't think it was actually relevant to much.

[Bill]

That worked- it was hiding in /var/run/dhcp6s.pid

Output from the router log:

Jul 01 18:39:13  daemon  dhcp6c[25089]: get_duid: extracted an existing DUID from /var/dhcp6c_duid: 00:03:00:01:00:04:ed:db:20:77
  Jul 01 18:39:13  daemon  dhcp6c[25089]: client6_init: failed initialize control message authentication
  Jul 01 18:39:13  daemon  dhcp6c[25089]: client6_init: skip opening control port
  Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>[interface] (9)
  Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <5>[ppp_ewan_1] (10)
  Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>begin of closure [{] (1)
  Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>[send] (4)
  Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>[ia-pd] (5)
  Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>

• (1)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>end of sentence [;] (1)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>end of closure [}] (1)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>end of sentence [;] (1)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>[id-assoc] (8)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <13>[pd] (2)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <13>
• (1)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <13>begin of closure [{] (1)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>[prefix-interface] (16)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <5>[br0] (3)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>begin of closure [{] (1)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>[sla-id] (6)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>
• (1)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>end of sentence [;] (1)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>[sla-len] (7)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>
• (1)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>end of sentence [;] (1)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>end of closure [}] (1)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>end of sentence [;] (1)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>end of closure [}] (1)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: cfdebug_print: <3>end of sentence [;] (1)
    Jul 01 18:39:13  daemon  dhcp6c[25089]: configure_pool: called
    Jul 01 18:39:13  daemon  dhcp6c[25089]: clear_poolconf: called
    Jul 01 18:39:13  daemon  dhcp6c[25089]: dhcp6_reset_timer: reset a timer on ppp_ewan_1, state=INIT, timeo=0, retrans=9383
    Jul 01 18:39:22  daemon  dhcp6c[25089]: client6_send: a new XID (7b23c6) is generated
    Jul 01 18:39:22  daemon  dhcp6c[25089]: copy_option: set client ID (len 10)
    Jul 01 18:39:22  daemon  dhcp6c[25089]: copy_option: set elapsed time (len 2)
    Jul 01 18:39:22  daemon  dhcp6c[25089]: copyout_option: set IA_PD
    Jul 01 18:39:22  daemon  dhcp6c[25089]: client6_send: send solicit to ff02::1:2
    Jul 01 18:39:22  daemon  dhcp6c[25089]: dhcp6_reset_timer: reset a timer on ppp_ewan_1, state=SOLICIT, timeo=0, retrans=1077
    Jul 01 18:39:22  daemon  dhcp6c[25089]: client6_recv: receive advertise from fe80::212:7fff:feae:411b on ppp_ewan_1
    Jul 01 18:39:22  daemon  dhcp6c[25089]: dhcp6_get_options: get DHCP option server ID, len 10
    Jul 01 18:39:22  daemon  dhcp6c[25089]:   DUID: 00:03:00:01:00:12:7f:ae:41:1b
    Jul 01 18:39:22  daemon  dhcp6c[25089]: dhcp6_get_options: get DHCP option client ID, len 10
    Jul 01 18:39:22  daemon  dhcp6c[25089]:   DUID: 00:03:00:01:00:04:ed:db:20:77
    Jul 01 18:39:22  daemon  dhcp6c[25089]: dhcp6_get_options: get DHCP option DNS, len 16
    Jul 01 18:39:22  daemon  dhcp6c[25089]: dhcp6_get_options: get DHCP option domain search list, len 11
    Jul 01 18:39:22  daemon  dhcp6c[25089]: dhcp6_get_options: get DHCP option IA_PD, len 41
    Jul 01 18:39:22  daemon  dhcp6c[25089]:   IA_PD: ID=0, T1=302400, T2=483840
    Jul 01 18:39:22  daemon  dhcp6c[25089]: copyin_option: get DHCP option IA_PD prefix, len 25
    Jul 01 18:39:22  daemon  dhcp6c[25089]: copyin_option:   IA_PD prefix: 2a02:390:6109::/48 pltime=604800 vltime=2592000
    Jul 01 18:39:22  daemon  dhcp6c[25089]: client6_recvadvert: server ID: 00:03:00:01:00:12:7f:ae:41:1b, pref=-1
    Jul 01 18:39:22  daemon  dhcp6c[25089]: client6_recvadvert: reset timer for ppp_ewan_1 to 0.945000
    Jul 01 18:39:23  daemon  dhcp6c[25089]: select_server: picked a server (ID: 00:03:00:01:00:12:7f:ae:41:1b)
    Jul 01 18:39:23  daemon  dhcp6c[25089]: client6_send: a new XID (334873) is generated
    Jul 01 18:39:23  daemon  dhcp6c[25089]: copy_option: set client ID (len 10)
    Jul 01 18:39:23  daemon  dhcp6c[25089]: copy_option: set server ID (len 10)
    Jul 01 18:39:23  daemon  dhcp6c[25089]: copy_option: set elapsed time (len 2)
    Jul 01 18:39:23  daemon  dhcp6c[25089]: copyout_option: set IA_PD prefix
    Jul 01 18:39:23  daemon  dhcp6c[25089]: copyout_option: set IA_PD
    Jul 01 18:39:23  daemon  dhcp6c[25089]: client6_send: send request to ff02::1:2
    Jul 01 18:39:23  daemon  dhcp6c[25089]: dhcp6_reset_timer: reset a timer on ppp_ewan_1, state=REQUEST, timeo=0, retrans=1079
    Jul 01 18:39:23  daemon  dhcp6c[25089]: client6_recv: receive reply from fe80::212:7fff:feae:411b on ppp_ewan_1
    Jul 01 18:39:23  daemon  dhcp6c[25089]: dhcp6_get_options: get DHCP option server ID, len 10
    Jul 01 18:39:23  daemon  dhcp6c[25089]:   DUID: 00:03:00:01:00:12:7f:ae:41:1b
    Jul 01 18:39:23  daemon  dhcp6c[25089]: dhcp6_get_options: get DHCP option client ID, len 10
    Jul 01 18:39:23  daemon  dhcp6c[25089]:   DUID: 00:03:00:01:00:04:ed:db:20:77
    Jul 01 18:39:23  daemon  dhcp6c[25089]: dhcp6_get_options: get DHCP option DNS, len 16
    Jul 01 18:39:23  daemon  dhcp6c[25089]: dhcp6_get_options: get DHCP option domain search list, len 11
    Jul 01 18:39:23  daemon  dhcp6c[25089]: dhcp6_get_options: get DHCP option IA_PD, len 41
    Jul 01 18:39:23  daemon  dhcp6c[25089]:   IA_PD: ID=0, T1=302400, T2=483840
    Jul 01 18:39:23  daemon  dhcp6c[25089]: copyin_option: get DHCP option IA_PD prefix, len 25
    Jul 01 18:39:23  daemon  dhcp6c[25089]: copyin_option:   IA_PD prefix: 2a02:390:6109::/48 pltime=604800 vltime=2592000
    Jul 01 18:39:23  daemon  dhcp6c[25089]: info_printf: nameserver[0] 2a02:390:2:0:5054:ff:fefa:828b
    Jul 01 18:39:23  daemon  dhcp6c[25089]: info_printf: Domain search list[0] idnet.com.
    Jul 01 18:39:23  daemon  dhcp6c[25089]: get_ia: make an IA: PD-0
    Jul 01 18:39:23  daemon  dhcp6c[25089]: update_prefix: create a prefix 2a02:390:6109::/48 pltime=604800, vltime=2592000
    Jul 01 18:39:23  daemon  dhcp6c[25089]: ifaddrconf: failed to add an address on br0: File exists
    Jul 01 18:39:23  daemon  dhcp6c[25089]: dhcp6_remove_event: removing an event on ppp_ewan_1, state=REQUEST
    Jul 01 18:39:23  daemon  dhcp6c[25089]: dhcp6_remove_event: removing server (ID: 00:03:00:01:00:12:7f:ae:41:1b)
    Jul 01 18:39:23  daemon  dhcp6c[25089]: client6_recvreply: got an expected reply, sleeping.
  

(That was using the "old" command to launch dhcp6c, I hadn't read that far down )

I hope it means more to you than it does to me, but I still seem to have an IPv6 connection

(Not sure about those lines with a single digit in parentheses- they seem to be an artefact of copy/paste as they're not in the log )

Any harm in leaving the router in debug mode, or should I do a re-connect?

[Steve]

I couldn't get the combination of Draytek 120 and AEBS to work on IPv6 either however my 7800N seems to work pretty flawlessly on IPv6 via EWAN . I use the latest g firmware, but if memory serves me right the 'd' firmware was ok on adsl for IPv6.


http://blog.stevenreid.co.uk/2011/07/08/billion-bipac-7800n-1-06d-firmware/ - there's a link to it at the top of the page.

[Rachel]

yay, i owe you many beers! That does illustrate what I wanted and expected to see.

.. besides the point that I'd expect file dhcp6s.pid to refer to the dhcpv6 *server* (s for server, c for client); maybe that's a mistake they fixed in later firmware. But the logs are clearly showing the debug logging on the *client* so it is showing what I was looking for, namely all that stuff from

Jul 01 18:39:22  daemon  dhcp6c[25089]: client6_recv: receive advertise from fe80::212:7fff:feae:411b on ppp_ewan_1

to:

Jul 01 18:39:23  daemon  dhcp6c[25089]: client6_recvreply: got an expected reply, sleeping.

is the conversation that I'm not getting.

It even looks like you're connecting to the same ppp server at idnet that i am, ie: fe80::212:7fff:feae:411b (is also the "Remote LL address" I pick up during my initial connection). So I have to guess that it's not treating all its incoming connections equally.

I have something to take to idnet support now, that I can point at and say, look, it's this!

Many, many beers.

(Not sure about those lines with a single digit in parentheses- they seem to be an artefact of copy/paste as they're not in the log )

Yes, it's insisting on taking a [ followed by 0 followed by ] as a bullet-point markup tag. I had the same problem, and i couldn't find a way of escaping it in that instance. In the end, if you look closely at my pasted log, I inserted a space between the [ and the 0 on those lines.

Any harm in leaving the router in debug mode, or should I do a re-connect?

The dhcp6c daemon on your router has probably quit since you logged out of the shell. It almost certainly doesn't matter, as configuration doesn't change, but if you just want to be extra sure that everything's back to normal, just do a Disconnect/Connect so stuff gets respawned normally.

[Rachel]

I couldn't get the combination of Draytek 120 and AEBS to work on IPv6 either however my 7800N seems to work pretty flawlessly on IPv6 via EWAN . I use the latest g firmware, but if memory serves me right the 'd' firmware was ok on adsl for IPv6.


http://blog.stevenreid.co.uk/2011/07/08/billion-bipac-7800n-1-06d-firmware/ - there's a link to it at the top of the page.

Yes, as I eventually found out, the AEBS only supports IPv6 from an ethernet WAN, not over PPPoE. It's good to know for sure from your findings what I'd suspected; that using a Draytek 120 as the adsl modem on a 7800N does definitely *not* interfere with IPv6 setup.

[Bill]

So I have to guess that it's not treating all its incoming connections equally.

I have something to take to idnet support now, that I can point at and say, look, it's this!

I wonder if it could be anything to do with the "pipe" (correct term?) that you connect with? FWIW, if it's any use I connect with uk.idnet.dsl4 and my IP address is in the 212.69.xxx.xxx block.

The dhcp6c daemon on your router has probably quit since you logged out of the shell. It almost certainly doesn't matter, as configuration doesn't change, but if you just want to be extra sure that everything's back to normal, just do a Disconnect/Connect so stuff gets respawned normally.

Naah, I'll leave it. If I reconnect I'll get a new IPv6 address for the router and have to reset my BQM. Bone idle, me

Good luck with IDNet support, happy to help

[Rachel]

I wonder if it could be anything to do with the "pipe" (correct term?) that you connect with? FWIW, if it's any use I connect with uk.idnet.dsl4 and my IP address is in the 212.69.xxx.xxx block.

Hm, well, I'm in 93.89.x.x so quite a different subnet, but we are both ending up connecting to the same remote server, by IP: 212.69.63.98 / fe80::0212:7fff:feae:411b.

What is interesting is that *your* address being in 212.69.x.x is a much closer neighbour than mine. I'm not sure if that's relevant; it might be for multicast reasons...

Naah, I'll leave it. If I reconnect I'll get a new IPv6 address for the router and have to reset my BQM. Bone idle, me

I don't think the router should be getting a new IPv6 address each time. It looks like it just gets a stateless ip through router advertisement, which should be persistent, I'd have thought. Frankly if it was going to be different, it would have changed when you started the debug dhcp6c I think. :-)

[Rachel]

multicast/broadcast i'm a bit vague about this sort of thing, but basically the client calls out to the network for a reply, but it has to be in the right subnet for a server to respond.

[Rachel]

nah that's a red herring. psp83's ip is 91.135.xxx.xxx which is also in a very different subnet, and it works for him.

It might be a red herring, or it might just mean subnets have to be specifically enabled and mine hasn't been.

[Bill]

I don't think the router should be getting a new IPv6 address each time. It looks like it just gets a stateless ip through router advertisement, which should be persistent, I'd have thought. Frankly if it was going to be different, it would have changed when you started the debug dhcp6c I think. :-)

Well, that's another oddity then- if I disconnect/reconnect then the router gets a new IPv6 address

It may be a matter if timing- normally if it's a glitch on the network it's very brief (just a short spike on the BQM) and doesn't even show in the log. If it's in the log then I get a new address! Maybe I was quick enough between the "kill" and restarting so the remote server didn't notice...

[psp83]

Still want me to do it? I'm pretty sure it will be just like Bills results.

I'm also a @uk.idnet.dsl4 login with ip range of 91.135.xxx.xxx

There was someone on this forum before that had trouble getting a IPv6 address set, I think he phoned up IDnet and found out it wasn't enabled for his account.

I don't know if IDnet still enable account by account or if its for all users now, all I know is that when I got the 7800n, I ticked the enable IPv6 box, connected and got an IPv6 address.

[Rachel]

Still want me to do it? I'm pretty sure it will be just like Bills results.

I'm also a @uk.idnet.dsl4 login with ip range of 91.135.xxx.xxx

Mine's just @idnet; not sure if that's something or just an adsl/fttc difference. Will raise it. (Will be writing the support mail tomorrow; i've started on the wine tonight, so better not try it now. )

There was someone on this forum before that had trouble getting a IPv6 address set, I think he phoned up IDnet and found out it wasn't enabled for his account.

I don't know if IDnet still enable account by account or if its for all users now, all I know is that when I got the 7800n, I ticked the enable IPv6 box, connected and got an IPv6 address.

I tried asking them that already, they say it is enabled. That's probably confirmed by my apparently receiving the initial Router Advertisements, and also the fact it intermittently worked for me if I entered that LAN IPv6 address that shouldn't have been necessary. It's the Prefix Delegation via DHCPv6 that's missing, i think, so it looks like something broken rather than just the whole thing not enabled for me.

[Rachel]

Still want me to do it? I'm pretty sure it will be just like Bills results.

Oh and yes please if you don't mind. The more overwhelming my evidence that they have a problem with a service config somewhere the better.

[Bill]

Mine's just @idnet; not sure if that's something or just an adsl/fttc difference. Will raise it.

I've been on @uk.idnet.dsl4 since I joined 6 or 7 years ago- I think there are several that I can use, it's just that I can remember that one

I'd guess that @idnet connects you to whichever is convenient, the least congested or on a round robin maybe.

[Rachel]

I've been on @uk.idnet.dsl4 since I joined 6 or 7 years ago- I think there are several that I can use, it's just that I can remember that one

I'd guess that @idnet connects you to whichever is convenient, the least congested or on a round robin maybe.

well, that made it worth a try, but uk.idnet.dsl4 doesn't work for me, I just get authentication fail. so it's not that simple.

[Lance]

Mine is @idnet.gw6 but I'm pretty sure they haven't made any difference since the old BT centrals were replaced by the hostlink (meaning all traffic takes the same route into Idnet towers).

I'm another tick the box and it worked person for ipv6 I'm afraid. Have you tried something as basic as a full factory reset of your router?

[Rachel]

Mine is @idnet.gw6 but I'm pretty sure they haven't made any difference since the old BT centrals were replaced by the hostlink (meaning all traffic takes the same route into Idnet towers).

I'm another tick the box and it worked person for ipv6 I'm afraid. Have you tried something as basic as a full factory reset of your router?

many times to satisfy support staff. I'm sick of re-entering config when i damn well know that's not the problem.

[Rachel]

Resolution:

I think I can se a v6 delegation problem for your account in our database. I have now reset your v6 allocation. Please could you try again now?

... and in fact by the time I received it, it was already working, without me needing to restart anything; which makes sense as the router's DHCPv6 client would have just kept running in the background soliciting for a prefix delegation until it finally got it, and could complete its IPv6 configuration. Then all the client machines instantly got their IPv6 configuration as well via router advertisement.

There never was anything wrong with my router. Thank you all for helping me make the winning support mail. I know what it's like manning the helldesk: most problems are user error or user equipment failure; so we have to work extra hard sometimes to prove otherwise.

[Bill]

 

[Lance]

 

[Rachel]

my prefix/delegated changed, i noticed belatedly, and had confirmed it was deliberate/necessary; but that's no biggie

[psp83]

Opps, I've not been around since my last post, been busy with trying to win more clients.

Glad you've got it sorted though.