DHCPv6, as you can see, is configured by default...
- What kind of IPv6 service does your ISP provide?
DHCPv6, as you can see, is configured by default...
Also verify that you have the following rules in firewall to allow the DHCPv6
config rule
option target 'ACCEPT'
option src 'wan'
option proto 'udp'
option dest_port '547'
option name 'Allow DHCPv6 (546-to-547)'
option family 'ipv6'
option src_port '546'
config rule
option target 'ACCEPT'
option src 'wan'
option proto 'udp'
option dest_port '546'
option name 'Allow DHCPv6 (547-to-546)'
option family 'ipv6'
option src_port '547'
Also make sure that you have enabled the default openwrt ipv6 icmp input rules.
Dhcpv6 doesn't give out a default gateway to the clients. Instead NDP is used for what.
I was experimenting with this yesterday (what a coincidence again...)
Because i wanted to completely get rid of icmp for ipv6.
The plan was to use a mtu of 1280 (should always be routeable and no icmp for pmtud is needed).
Then disable all icmpv6 allow rules.
But then odhcp6c failed because it was not able to send a router solicitation.(i have output set to deny and also use icmpv6 output rules)
So make sure NDP is allowed. (default config should cover this)
And for dhcpv6 itself
I only have this rule:
config rule
option name 'WAN6-INPUT-Accept-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
Which is also default and works fine.
//edit
Default icmpv6 rule:
# Allow essential incoming IPv6 ICMP traffic
config rule
option name Allow-ICMPv6-Input
option src wan
option proto icmp
list icmp_type echo-request
list icmp_type echo-reply
list icmp_type destination-unreachable
list icmp_type packet-too-big
list icmp_type time-exceeded
list icmp_type bad-header
list icmp_type unknown-header-type
list icmp_type router-solicitation
list icmp_type neighbour-solicitation
list icmp_type router-advertisement
list icmp_type neighbour-advertisement
option limit 1000/sec
option family ipv6
option target ACCEPT
Maybe you want to remove echo-request icmp type and adjust the limit a bit...
i use
option limit '1/sec'
option limit_burst '10'
for a small network.
Or even switch to the hashlimit module to have a per host limit rather then a global limit.
Both firewall entries are there ...
What kind of IPv6 service does your ISP provide?
no idea, it works with dd-wrt but I can't get it running under openwrt. Is there anything I could look/search for in the logs?
Interesting...I didn't know IPv6 worked "out-of-the-box" in DD-WRT without a config (their WIki describes using the command line).
Since you don't know about your IPv6 service (and it doesn't appear to be DHCPv6-based), that's difficult. Since you stated that it worked in DD-WRT, perhaps you can take a screenshot there.
ifstatus wan6
one thing that might be wrong is that the DHCP-PD might be tied to the DUID or MAC or whatever of the DD-WRT router and so when requesting a PD the OpenWrt router doesn't get a response. Calling the ISP and requesting to reset the ipv6 setttings could be in order.
There is not much to configure in dd-wrt, you just enable IPv6, set it to "DHCPv6 with prefix delegation" add two IPv6 DNS servers et voila ...
ifstatus wan6
{
"up": false,
"pending": true,
"available": true,
"autostart": true,
"dynamic": false,
"proto": "dhcpv6",
"device": "eth0.2",
"data": {
}
}
@dlakelan
will try that, but I doubt they are willing to do, probably they will tell me to use the original box that was shipped when the contract started.
Is there anything else I could check out logwise?
I've never heard of that behavior. What would you do if that box was say burned out by a power surge? If it's pinned to a particular device, there will be a method to unpin it.
tcpdump -v -i eth0.2 udp port 546 &
killall -SIGUSR1 odhcp6c
I've heard if it...but if you're in the US (and also Germany I believe), they cannot require you to use a particular device.
Tell them to unpin it.
Also, the WAN doesn't get IPv6 Internet like a PC/laptop client - that sounds like what you're describing with DD-WRT. In that instance, the LAN shouldn't get IPv6. When I used DD-WRT, it wass not as simple as you describe. For the setup you need in OpenWrt, see:
Its true that they cannot require you to use a particular device, but they tell you that everything is working and don't give you any service unless you use their crappy provider box. Unfortunately that's the truth with my cable provider in Germany....
Regarding IPv6 and dd-wrt:
the infos on how to setup IPv6 is quite outdated, at least for my dd-wrt (kongmod) its now just as easy as I described before.
When checking on http://ipv6-test.com I get an IPv6 that is detected as being a native IPv6 coming from my cable service provider and not from a tunnel broker like HE.
kill -SIGUSR1 $(pidof odhcp6c)
this is the output:
09:03:11.038942 IP6 (flowlabel 0x18388, hlim 1, next-header UDP (17) payload length: 112) fe80::4231:3cff:fed7:46c1.546 > ff02::1:2.547: [bad udp cksum 0xc2d1 -> 0xc5c4!] dhcp6 solicit (xid=be0f94 (elapsed-time 6551) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server AFTR-Name opt_67 opt_82 opt_94 opt_95 opt_96 opt_82) (client-ID hwaddr type 1 40313cd746c1) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0))
means there is a IPv6 coming, but it is not accepted ?
Any ideas what else I could try?
I also found this bug:
OK, so I did bisection to find that hardware NAT offload is the culprit: $ git bisect good There are only 'skip'ped commits left to test. The first bad commit could be any of: 424a9ae128bd2045cd4bfd6e3229f2529d150a25 bfed38254076d576914251689a2e1f85d514783d We cannot bisect more! Where is the proper place to report this bug? Here?
I am quite new to openwrt but would really like to solve the problem / in case it is a bug help solving it.
seems to be a bug with current version as with an older version it works out of the box. Where should I report it?
@thorsten97: If the Xiaomi 3g also has an MT7621 chip (which IIRC it does), perhaps you can try the workaround in https://bugs.openwrt.org/index.php?do=details&task_id=1763 to disable the CONFIG_NET_MEDIATEK_OFFLOAD option.
thanks, will give it a try and report back!
works!! someone should include it in the official source or fix the bug!
That's great news!
Hm, I think I probably reported the bug in the wrong place... Anybody know how to get in contact with the right people?
using this patch works for me. It was taken from the bug report page (https://bugs.openwrt.org/index.php?do=details&task_id=1763)
Hello guys, i have this issue but i'm a total noob and i can't find where i have to disable the "CONFIG_NET_MEDIATEK_OFFLOAD" line.
Someone can explain me?