What's new

[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

It seems also dhcp6c doesnt even attempt to start automatically, I have to run service start_dhcp6c. Dhcpv6 is ticked in the ipv6 settings page.
All your symptoms say that ipv6 isn't enabled. If it's not getting a response from your ISP the various services can't start.

EDIT: Just for info, check your syslog for a line like this....

Dec 31 17:00:50 dhcp6c: dhcp6c state change detected REQUEST
 
It is enabled john, I am using ipv6 right now :)

Why dhcp6c isnt been called looks like some sort of bug. What normally triggers it? Also why is there not even a config generated for it?

You wanted testers :) so I tested :)

What I can tell you is my isp requires the router to send a request for the prefix range before asking for a wan ip, I think this is a bit non standard but what someone on the forums mentioned.

For now I have added service start_dhcp6c to my wan_start script. It does check nvram variables to see if dhcp6 is enabled in the settings first.

Code:
dhcp6=`nvram get ipv6_service`
if [ "$dhcp6" = "dhcp6" ]; then
service start_dhcp6c
fi

I do see lines such as this

Sep 1 16:07:39 dhcp6c: dhcp6c state change detected RENEW

But they only appear "after" I start dhcp6c, without my intervention the daemon does not start.

It looks like from your reply, the code is waiting for some kind of request from the isp first before starting dhcp6c, instead I think dhcp6c should be started regardless of state changes as long as the option is activated in the settings.

Also some info on radvd when using non /64 wan prefixes.

http://superuser.com/questions/662851/radvd-wont-accept-non-64-subnets
 
Last edited:
It is enabled john, I am using ipv6 right now :)

Why dhcp6c isnt been called looks like some sort of bug. What normally triggers it? Also why is there not even a config generated for it?

You wanted testers :) so I tested :)

What I can tell you is my isp requires the router to send a request for the prefix range before asking for a wan ip, I think this is a bit non standard but what someone on the forums mentioned.

For now I have added service start_dhcp6c to my wan_start script. It does check nvram variables to see if dhcp6 is enabled in the settings first.

Code:
dhcp6=`nvram get ipv6_service`
if [ "$dhcp6" = "dhcp6" ]; then
service start_dhcp6c
fi

I do see lines such as this

Sep 1 16:07:39 dhcp6c: dhcp6c state change detected RENEW

But they only appear "after" I start dhcp6c, without my intervention the daemon does not start.

It looks like from your reply, the code is waiting for some kind of request from the isp first before starting dhcp6c, instead I think dhcp6c should be started regardless of state changes as long as the option is activated in the settings.

Also some info on radvd when using non /64 wan prefixes.

http://superuser.com/questions/662851/radvd-wont-accept-non-64-subnets

Interesting read......according to that you have to move to a Stateful configuration if using larger than a /64 subnet. Did you try selecting Stateful under Auto Configuration?

(If that works, I'll change to force stateful for subnets larger than /64)

EDIT: @Chrysalis After re-reading that a couple of times, I may have embarked on a fools errand in that radvd may not support other than a /64 prefix length. Will be interested to see if using a stateful config works.
 
Last edited:
John I will send you a pm later, there is work to be done on ipv6 QoS also. ip6tables mangle table is missing the MAC rules. :)


Since i set my default priority level to very low everything was going at a crawl until I added my MAC to the ip6tables mangle table. :)
 
John I will send you a pm later, there is work to be done on ipv6 QoS also. ip6tables mangle table is missing the MAC rules. :)


Since i set my default priority level to very low everything was going at a crawl until I added my MAC to the ip6tables mangle table. :)
Fixed in the next beta....

EDIT: Does this mean you have IPv6 working?:)
 
Last edited:
yep its working, I had to manually fix dhcp6c as I posted earlier but it works with my dhcp6c.conf config in /jffs/configs and the command added to wan-start :)

/56 prefix

/64 prefix in radvd.conf although I actually now have moved to a more exotic config so I can use DHCP preservation with ipv6, so installed dhvp6 server from opkg to handle lan ipv6 allocation. :)
 
regarding radvd.conf the stateful/stateless option had no affect on it. It was only happy when it was configured to /64.

All documentation i have read points to that prefixes larger than /64 should be split into smaller /64 prefixes lan side, which is probably why radvd moans.
 
Possible bug in Firewall>Network Services Filter:

When I try and block 192.168.100.1 in the Destination IP field for TCP it dosen't work. I can still acess this from my browser; Chrome or Firefox. I'm fairly certain this worked in earlier versions of this fork. I'm on the latest version 18E3 and AC66U.
 
Possible bug in Firewall>Network Services Filter:

When I try and block 192.168.100.1 in the Destination IP field for TCP it dosen't work. I can still acess this from my browser; Chrome or Firefox. I'm fairly certain this worked in earlier versions of this fork. I'm on the latest version 18E3 and AC66U.
I just tried it and it works fine on my AC68.
Is that your modem and what is your router/LAN subnet?
 
Possible bug in Firewall>Network Services Filter:
Confirmed. This is an old bug that appears when you have enabled parental control;

Without parental control:
-A FORWARD -d 192.168.100.1 -i br0 -o eth0 -p tcp -j DROP
-A FORWARD -i br0 -o eth0 -j ACCEPT
-A PControls -j ACCEPT


With parental control:
-A FORWARD -i br0 -m mac --mac-source 34:14:5F:3E:C7:8B -j DROP
-A PControls -i eth0 -m state --state INVALID -j DROP
-A PControls -d 192.168.100.1 -i br0 -o eth0 -p tcp -j DROP
-A PControls -i br0 -o eth0 -j ACCEPT
-A PControls -j ACCEPT


So it seems that enabling parental control moves the NSF rules into the PControls chain, whilst putting the parental control rule into the FORWARD chain. :confused:

I'm not sure how the PControls chain is intended to be used as it isn't called from anywhere.

EDIT: To see this bug parental control must be enabled AND have at least one rule setup.
 
Last edited:
John is it possible for you to do a build with a newer version of dhcp6c (wide-dhcp) client? I think this is an old version and sla-id seems broken and its missing a new important flag 'ifid'. I am now also having issues as well getting my isp to respond to solicit packets so I want to see if the latest version resolves things.

Also interestingly on my last reboot dhcp6c did automatically start. as I had removed it from wan-start and was surprised to see it started itself.
 
Confirmed. This is an old bug that appears when you have enabled parental control;

Without parental control:
-A FORWARD -d 192.168.100.1 -i br0 -o eth0 -p tcp -j DROP
-A FORWARD -i br0 -o eth0 -j ACCEPT
-A PControls -j ACCEPT


With parental control:
-A FORWARD -i br0 -m mac --mac-source 34:14:5F:3E:C7:8B -j DROP
-A PControls -i eth0 -m state --state INVALID -j DROP
-A PControls -d 192.168.100.1 -i br0 -o eth0 -p tcp -j DROP
-A PControls -i br0 -o eth0 -j ACCEPT
-A PControls -j ACCEPT


So it seems that enabling parental control moves the NSF rules into the PControls chain, whilst putting the parental control rule into the FORWARD chain. :confused:

I'm not sure how the PControls chain is intended to be used as it isn't called from anywhere.

EDIT: To see this bug parental control must be enabled AND have at least one rule setup.
Interesting......time for a bug hunt :)

BTW....the PControls chain is called when you activate a schedule for the client. Otherwise it's just a simple DROP.
 
John is it possible for you to do a build with a newer version of dhcp6c (wide-dhcp) client? I think this is an old version and sla-id seems broken and its missing a new important flag 'ifid'. I am now also having issues as well getting my isp to respond to solicit packets so I want to see if the latest version resolves things.

Also interestingly on my last reboot dhcp6c did automatically start. as I had removed it from wan-start and was surprised to see it started itself.
I'm really, REALLY, REALLY nervous about touching that one. I've made some tweaks to the conf files based on the DD-WRT thread, including externalizing another options in the gui to try. I'll probably put up a new beta later today.
 
BTW....the PControls chain is called when you activate a schedule for the client. Otherwise it's just a simple DROP.
OK. I can see it inserting an additional rule for the timeslot and invoking PControls but the logic is completely messed up.

-A FORWARD -i br0 -m time --days Mon -m mac --mac-source 34:14:5F:3E:C7:8B -j PControls
-A FORWARD -i br0 -m mac --mac-source 34:14:5F:3E:C7:8B -j DROP
-A PControls -i eth0 -m state --state INVALID -j DROP
-A PControls -d 192.168.100.1 -i br0 -o eth0 -p tcp -j DROP
-A PControls -i br0 -o eth0 -j ACCEPT
-A PControls -j ACCEPT


Looking at the source code it looks like it might be trying to copy any parental controls rules from FORWARD into the PControl chain, but is picking up the NSF instead by mistake. (just guessing)

EDIT: I misunderstood what you meant by "simple DROP".:rolleyes:
 
Last edited:
I'm really, REALLY, REALLY nervous about touching that one. I've made some tweaks to the conf files based on the DD-WRT thread, including externalizing another options in the gui to try. I'll probably put up a new beta later today.
The beta would be really appreciated please as it seems this version has issues for me.
 
That's the right logic......if it's in the scheduled window, jump to PControls and ACCEPT....otherwise fall through and DROP
OK that makes sense, but what, other than ACCEPT, is meant to be in the PControls chain? It just seems to have copied 3 unrelated rules.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top