Since we didn't ask it, could you post the network config, just in case?
Also I would reset the counters and run some iptraf at the same time to check for consistency.
ifconfig -a; uci show network
ifconfig -a; uci show network
6in4-henet Link encap:IPv6-in-IPv4
inet6 addr: 2001:470:xx:zzzz::2/64 Scope:Global
inet6 addr: fe80::8b14:4613/64 Scope:Link
UP POINTOPOINT RUNNING NOARP MTU:1280 Metric:1
RX packets:8180150 errors:0 dropped:0 overruns:0 frame:0
TX packets:3460167 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:9496385625 (8.8 GiB) TX bytes:651770369 (621.5 MiB)
br-lan Link encap:Ethernet HWaddr xx:xx:xx:3C:69:C3
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::xxxx:xxff:fe3c:69c3/64 Scope:Link
inet6 addr: 2001:470:xxyy:1::1/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:171382 errors:0 dropped:11 overruns:0 frame:0
TX packets:340453 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:14475119 (13.8 MiB) TX bytes:428669991 (408.8 MiB)
eth0 Link encap:Ethernet HWaddr xx:xx:xx:3C:69:C3
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:5
eth1 Link encap:Ethernet HWaddr xx:xx:xx:3C:69:C5
inet addr:x.x.x.x Bcast:x.x.x.255 Mask:255.255.255.0
inet6 addr: fe80::xxxx:xxff:fe3c:69c5/64 Scope:Link
inet6 addr: 2001:470:xy:zzzz::1/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:12273968 errors:0 dropped:22929 overruns:281 frame:0
TX packets:11369625 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1996874844 (1.8 GiB) TX bytes:1378747354 (1.2 GiB)
Interrupt:4
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:31 errors:0 dropped:0 overruns:0 frame:0
TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:3263 (3.1 KiB) TX bytes:3263 (3.1 KiB)
sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
wlan0 Link encap:Ethernet HWaddr xx:xx:xx:3C:69:C4
inet6 addr: fe80::xxxx:xxff:fe3c:69c4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:171379 errors:0 dropped:0 overruns:0 frame:0
TX packets:340518 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16874407 (16.0 MiB) TX bytes:437826076 (417.5 MiB)
network.loopback=interface
network.loopback.ifname='lo'
network.loopback.proto='static'
network.loopback.ipaddr='127.0.0.1'
network.loopback.netmask='255.0.0.0'
network.globals=globals
network.lan=interface
network.lan.ifname='eth0'
network.lan.force_link='1'
network.lan.type='bridge'
network.lan.proto='static'
network.lan.ipaddr='192.168.1.1'
network.lan.netmask='255.255.255.0'
network.lan.ip6addr='2001:470:xxyy:1::1/64'
network.lan.ip6prefix='2001:470:xxyy:1::/64'
network.wan=interface
network.wan.ifname='eth1'
network.wan.proto='static'
network.wan.ipaddr='x.x.x.x'
network.wan.netmask='255.255.255.0'
network.wan.gateway='x.x.x.xyz'
network.wan.dns='x.x.x.y x.x.x.z'
network.wan.ip6addr='2001:470:xy:zzzz::1/64'
network.wan.ip6prefix='2001:470:xy:zzzz::/64'
network.@switch[0]=switch
network.@switch[0].name='switch0'
network.@switch[0].reset='1'
network.@switch[0].enable_vlan='1'
network.@switch_vlan[0]=switch_vlan
network.@switch_vlan[0].device='switch0'
network.@switch_vlan[0].vlan='1'
network.@switch_vlan[0].ports='0 1 2 3 4'
network.henet=interface
network.henet.proto='6in4'
network.henet.ipaddr='x.x.x.x'
network.henet.peeraddr='216.66.86.114'
network.henet.ip6addr='2001:470:xx:zzzz::2/64'
network.henet.sourcerouting='0'
network.henet.ip6prefix='2001:470:xxyy::/48 2001:470:xy:zzzz::/64'
network.@route6[0]=route6
network.@route6[0].interface='henet'
network.@route6[0].source='2001:470:xy:zzzz::/64'
network.@route6[0].target='::/0'
#/etc/config/network
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
config interface 'lan'
option ifname 'eth0'
option force_link '1'
option type 'bridge'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6addr '2001:470:xxyy:1::1/64'
option ip6prefix '2001:470:xxyy:1::/64'
config interface 'wan'
option ifname 'eth1'
option proto 'static'
option ipaddr 'x.x.x.x'
option netmask '255.255.255.0'
option gateway 'x.x.x.xyz'
option dns 'x.x.x.y x.x.x.z'
option ip6addr '2001:470:xy:zzzz::1/64'
option ip6prefix '2001:470:xy:zzzz::/64'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0 1 2 3 4'
config interface 'henet'
option proto '6in4'
option ipaddr 'x.x.x.x'
option peeraddr '216.66.86.114'
option ip6addr '2001:470:xx:zzzz::2/64'
option sourcerouting '0'
option ip6prefix '2001:470:xxyy::/48 2001:470:xy:zzzz::/64'
config route6
option interface 'henet'
option source '2001:470:xy:zzzz::/64'
option target '::/0
What are these doing under WAN interface?
Assigning the WAN interface an IPv6 address from the delegated prefix, and also defining the prefix that is used in that network segment (remember: the box is only connected to my network via the WAN interface and acts solely as an IPv6 gateway. Well, lan/wifi bridge interface is also usable, but that's just bonus). Should the WAN interface not be assigned an IPv6 address?
With whom will the WAN interface communicate with this IPv6?
Moreover I don't see any reason using the ip6prefix option since you are not delegating anything under this interface. The same applies to LAN interface.
Hm, it will communicate with this IP with the internet or other devices in this network segment. For the latter the link-local fe80::/64 will work as well, of course, but assigning an additional IPv6 shouldn't matter.
But I am delegating IPv6 addresses on this interface. The WAN-interface (or eth1 for that matter) is connected to the switch that the other machines that I want to get IPv6 addresses also connect to. So IPv6 is distributed via WAN interface. Another IPv6 subnet/prefix is distributed to clients connected to the LAN interface.
If I remove ip6prefix or even just ip6addr all clients connected to WAN lose IPv6 connectivity (and SLAAC also stops working), even though the gateway on manually configured IPv6 clients is set to the fe80:: address, so also routing is ignored.
First things first. With the current setup you are not delegating anything. In order to delegate some network you need to provide a different prefix and you have defined the same. The same applies to both LAN and WAN.
Second if you have connected clients on WAN interface that use the IPv6 connection to communicate with each other could explain the extra traffic on the HEnet interface.
Third the RA and DHCPv6 are defined in /etc/config/dhcp
so if it doesn't work properly maybe you have something wrong there.
Keep in mind that IPv6 (mostly) ignores interface metrics, making the routing decision based on the longest common (prefix-) match instead.
@trendy Ok, the term delegating was wrong. But I am advertising on the interfaces. Since HENET is a virtual interface, you can't physically connect a device, apparently. Let me list the setup of prefixes more simplified:
HENET -> 2001:470:xx:zzzz::/64
WAN -> 2001:470:xy:zzzz::/64 <- this is a different prefix than above, and is routed by HE to my tunnel endpoint.
LAN -> 2001:470:xxyy:1::/64 <- this prefix is out of my additional 2001:470:xxyy::/48
So, I have a /64 and a /48, which both are routed by HE to my tunnel. Then there another /64 which is used for communication between HE and my tunnel endpoint, where HE has 2001:470:xx:zzzz::1/64 and my tunnel endpoint has to be set to 2001:470:xx:zzzz::2/64.
If the clients communicate via HENET interface, they are still first connected to the WAN interface, so traffic still would have to go to WAN first. Also, if they are communicating with each other they should be able to do that directly using link-local addresses or even the public ones, but traffic should flow only through the switch, and not the OpenWrt box.
Yes, you define if you wanna use RA inside dhcp config, but the prefix that is used for RA seems to be taken from network config. At least I don't see any option for odhcpd/dhcp to define the desired prefix.
@slh true. But how would that affect what I observed? It IPv6 traffic goes through the OpenWrt box, it would still need to enter it through the WAN interface first.
You have a point on that. So I guess the only thing left is to sniff the interface and see what is causing all these packets.
You should use the ip6assign
to delegate a prefix from the pool you have from HE and ip6hint
to add to the subprefix, in your case the :1:
for the LAN.
Regardless of that the ip6prefix
option is for prefixes routed on this interface for use in other interfaces.
I have just updated my LEDE install to the most current LEDE snapshot (17.01). The traffic quota seems to be counted correctly now.
Too soon: after one night it's off again I give up. But I also don't really care anymore...
Now on 17.01.07 / kernel 4.4.194 the problem really seems gone ^^ WAN counts correctly now
ARRRG, AGAIN not really...BUT, the problem is not the counting...for some reason, WAN traffic stats got reset (was previously more than 5 GB, now back to 1 GB), but uptime of interface didn't change. So no idea what caused the reset. But in general the counts are getting added correctly.
Now on 19.07-snapshot and a new device (ramips), kernel 4.14.193, WAN doesn't seem to get reset anymore.