search

jilir / wl500g

Automatically exported from code.google.com/p/wl500g
0 stars 0 forks source link

Garbage IPv6-addresses are seen on ppp0 with IPv6 Connection Type: Stateless #295

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
> What steps will reproduce the problem?
1. Settings in Web UI:
===
IPv6 Connection Type: Stateless
IPv6 Interface: WAN

LAN IPv6 Setting
Get IPv6 automatically? Yes
Advertise LAN Prefix?   Yes

WAN IPv6 Setting
Get IPv6 automatically? Yes

WAN DNSv6 Setting
Get DNS Server automatically?   Yes
===
All other fields on "IPv6" page are empty.

2. BRAS initiates IPCP6 negotiation and uses ICMPv6 RA to advertise prefix for 
ppp-link

> What is the expected output? What do you see instead?
Expected output should be as follows:
===
[root@home ~]$ ifconfig ppp0
ppp0      Link encap:Point-to-Point Protocol  
          inet addr:94.233.192.135  P-t-P:85.175.1.63  Mask:255.255.255.255
          inet6 addr: 2a02:8040:ffff:ffff:cd1:ae6d:748e:931e/64 Scope:Global
          inet6 addr: fe80::cd1:ae6d:748e:931e/10 Scope:Link
          UP POINTOPOINT RUNNING MULTICAST  MTU:1492  Metric:1
          RX packets:1401421 errors:0 dropped:0 overruns:0 frame:0
          TX packets:844015 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:1865228206 (1.7 GiB)  TX bytes:58709031 (55.9 MiB)
===
Only two addresses (with the same interface-id) have to be assigned on ppp0:
1) link-local address fe80::<inf-id>/10
2) global unicast address <SLAAC prefix>::<intf-id>/64

What version of the product are you using?
RT-N16-1.9.2.7-rtn-r3702.trx

> Please provide any additional information below.
I attempted to bring up IPv6 over PPPoE session to E320 (it's under my control 
as well).
Configuration on BRAS-side is pretty straight-forward:
 1. BRAS initiates IP6CP negotiation 
 2. Interface-IDs are randomly generated on both sides (no forced interface-ids)
 3. After Interface-Id negotiation BRAS starts announcing ICMPv6 RA messages with the following PrefixInformation option:
 ===
 RA-wide Flags: 0x40: the only "Other" flag is set PrefixInformation Flags:
 0x40: "O" is not set, "A" is set Valid lifetime: 2678400 Preferred lifetime:
 2678400
 Prefix: 2a02:8040:ffff:ffff::
 ===
 packet dump of PPPoE/PPP/IPCP/IP6CP negotiation is attached.

Everything looks fine from BRAS-side, however there are few possibly unexpected 
things on RT-N16 side:

ppp0 sucessfully brings up, but two garbage addresses assigned:
===
 inet6 addr: ee3f:7b04:80:ab2a:214:4000:afe7:aa2a/128 Scope:Global
 inet6 addr: ::6cdd:4200:ac85:4000:55d9:ec7f/128 Scope:Global 
===
[root@home root]$ ifconfig ppp0
 ppp0      Link encap:Point-to-Point Protocol
           inet addr:94.233.192.116  P-t-P:85.175.1.63 Mask:255.255.255.255
           inet6 addr: ee3f:7b04:80:ab2a:214:4000:afe7:aa2a/128 Scope:Global
           inet6 addr: ::6cdd:4200:ac85:4000:55d9:ec7f/128 Scope:Global
           inet6 addr: 2a02:8040:ffff:ffff:d996:849a:41fd:b730/64 Scope:Global
           inet6 addr: fe80::d996:849a:41fd:b730/10 Scope:Link
           UP POINTOPOINT RUNNING MULTICAST  MTU:1492  Metric:1
           RX packets:835643 errors:0 dropped:0 overruns:0 frame:0
           TX packets:525230 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:3
           RX bytes:1121749663 (1.0 GiB)  TX bytes:33343527 (31.7 MiB)

[root@home root]$ ip -6 addr show dev ppp0
 9: ppp0: <POINTOPOINT,MULTICAST,UP,LOWER_UP> mtu 1492 qlen 3
     inet6 2a02:8040:ffff:ffff:d996:849a:41fd:b730/64 scope global dynamic
        valid_lft 2678399sec preferred_lft 2678399sec
     inet6 ee3f:7b04:80:ab2a:214:4000:afe7:aa2a/128 scope global
        valid_lft forever preferred_lft forever
     inet6 ::6cdd:4200:ac85:4000:55d9:ec7f/128 scope global
        valid_lft forever preferred_lft forever
     inet6 fe80::d996:849a:41fd:b730/10 scope link
        valid_lft forever preferred_lft forever 

[root@home root]$ nvram show | grep ipv6_addr
 size: 15939 bytes (16829 left)
 wan0_ipv6_addr=/64
 lan_ipv6_addr=::/64
 wan0_ipv6_addr_t=ee3f:7b04:80:ab2a:214:4000:afe7:aa2a
===

First garbage address is ee3f:7b04:80:ab2a:214:4000:afe7:aa2a/128 and it
is the same each time after reconnect.
====
1st attempt, ee3f:7b04:80:ab2a:214:4000:afe7:aa2a/128 Scope:Global
2nd attempt, ee3f:7b04:80:ab2a:214:4000:afe7:aa2a/128 Scope:Global
3rd attempt, ee3f:7b04:80:ab2a:214:4000:afe7:aa2a/128 Scope:Global
====
Second garbage address is ::6cdd:4200:ac85:4000:55d9:ec7f/128 and it changes 
each time in second byte:
====
1st attempt, ::6cdd:4200:ac85:4000:55d9:ec7f/128 Scope:Global
2nd attempt, ::6cdd:4200:ac85:4000:55b9:ac7f/128 Scope:Global
3rd attempt, ::6cdd:4200:ac85:4000:5579:c07f/128 Scope:Global
====

If I change IPv6 Connection Type: to DHCPv6, garbage addresses disappear, but 
one of them is still seen in nvram:
====
[root@home ~]$ nvram get wan0_ipv6_addr_t
ee3f:7b04:80:ab2a:214:4000:afe7:aa2a
====

Original issue reported on code.google.com by Les...@gmail.com on 16 Jan 2012 at 11:09

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by Les...@gmail.com on 16 Jan 2012 at 6:02

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by lly.dev on 26 Jan 2012 at 6:41