Resolved

Hello Manuel and m0n0wall team,

thanks for adding ayiya support in 1.31 I have a WRAP plattform embedded device and I've discovered a missing linebreak in the ipfilter (ipv6) ruleset. See "status.php" in section "unparsed IPv6 ipfilter rules". You have to activate ipv6 of course  

Code:

# allow link-local traffic on LAN
pass in quick on sis0 from fe80::/10 to fe80::/10
pass out quick on sis0 from fe80::/10 to fe80::/10

# allow access to DHCPv6 server on LAN
pass in quick on sis0 proto udp from any port = 546 to ff02::1:2 port = 547
# allow link-local traffic on opt1pass in quick on sis2 from fe80::/10 to fe80::/10
pass out quick on sis2 from fe80::/10 to fe80::/10

# allow access to DHCP server on opt1
pass in quick on sis2 proto udp from any port = 546 to ff02::1:2 port = 547

The line with "pass in quick on sis2 from fe80::/10 to fe80::/10" is in the comment line instead of its own line. This has direct consequnces on the assembly of the firewall rules. See section "ipfstat -6 -nio":

Code:

@2 pass out quick on sis0 from fe80::/10 to fe80::/10
@3 pass out quick on sis2 from fe80::/10 to fe80::/10
...
@2 pass in quick on sis0 from fe80::/10 to fe80::/10
@3 pass in quick on sis0 proto udp from any port = dhcpv6-client to ff02::1:2/128 port = dhcpv6-server
@4 pass in quick on sis2 proto udp from any port = dhcpv6-client to ff02::1:2/128 port = dhcpv6-server

A line with "pass in quick on sis2 from fe80::/10 to fe80::/10" is missing. Router advertisment and solicitation still seems to be working, as my client on sis2 does get the correct static public ipv6 network prefix set on "opt1".

However, my client on sis2 does not set its ipv6 address according to DHCPv6 static mapping in m0n0wall (it uses stateless autoconfiguration instead), and I'm wondering if the missing link-local input on sis2 is to blame, or if the dhcp client is the problem. Router advertisements on opt1 (==sis2) are set to managed, so that should not be the problem.

Cheers,
Stephen

Update: I've added the missing rule manually and it does not make the slightest difference to the DHCPv6 problem. I'll handle the DHCPv6 problem separately then (probably a client bug). Confirmed: client bug, not all linux distributions ship DHCPv6 along with DHCPv4 by default.

There is a fix committed.