[Frage] ICMPv6 reply to ping6 from the internet

[guylhem]

Hello

I am looking for a way to enable ICMPv6 replies (ie ping6 reply) for the machines connected to the fritzbox.

A lenghty search on google found no answer. Apparently, the user interface does not provide an option for this (only UDP and TCP port opening on the IPv6 firewall), and ar7.cfg can not be edited in a way to enable it. Some "grep" to avm binaries revealed nothing.

With tcpdump, likewise I see nothing arriving on dsl, but what looks like the request and the replies on adsl (it is a bit garbled - I suppose due to pppoe)

If I manually create a sit1 interface as a 6to4 for sixxs.net, and if I enable it (some echos 0> in proc/sys/net/ipv6/conf/sit1), then it does not respond to ping6, since it is not handled by the usual avm bridge.

Even then, the clients still receive "Administratively prohibited" anyway, which let me think it must come from daemons like dsld since I can just see with tcpdump the incoming icmpv6 echo request for the non responding local ipv6 address.

I would welcome any solution to this issue, since being able to ping6 my devices from the internet would be very handy.

The iptables solutions proposed for another problem http://www.ip-phone-forum.de/showthread.php?t=231938&page=1 could be interesting, but I fear it will only serve to block more traffic, not to enable some already blocked traffic such as icmpv6, if it simply adds another layer.

I really wonder how it is blocked by the avm firewall - to the best of my understanding, dsld just reads and write to adsl, and only expose to dsl the parts he did not block.

Thanks,
Guylhem

 

[DualIP]

but what looks like the request and the replies on adsl

On my 7340 with PPPoA, tcpdump-ing on adsl interface only shows outgoing NATted packets. Neither tcpdump nor wireshark "understands" these packets (bogus ip header length).
First 18 bytes are just L2 ppp header, the rest is plain IP. In hex pane, you can view source/detination addresses

With tcpdump, likewise I see nothing arriving on dsl

Over here, packets on dsl interface aren't natted and I see 2 way traffic with some linux cooked header.
AFAIK, this is inside of "ar7.cfg" firewall

ipv6 {
     ----lines cut---
        firewall {
               enabled = yes;

You could just try to disable fritz ipv6 firewall entirely, then use freetz ip6tables.
Remember, these 2 firewalls are placed in tandem, so you only need to have one running

 

[guylhem]

Hello

On my 7340 with PPPoA, tcpdump-ing on adsl interface only shows outgoing NATted packets. Neither tcpdump nor wireshark "understands" these packets (bogus ip header length).
First 18 bytes are just L2 ppp header, the rest is plain IP. In hex pane, you can view source/detination addresses

Over here, packets on dsl interface aren't natted and I see 2 way traffic with some linux cooked header.

Great idea- I will see how it is possible to "cut" the first 18 bytes to better see the outgoing traffic, even if it natted. Thanks a lot!

Regarding the icmpv6 filtering on dsl interface, try to ping6 a machine on your lan from your lan - you will see the reply.

Now try to ping6 this machine on your lan from the internet - you will get the administratively denied remotely, but nothing locally besides the "ICMP6, neighbor solicitation" and "ICMP6, neighbor advertisement": I mean in this case tcpdump on dsl does not show the icmpv6 request or "administratively denied" replies. They seem to show up in tcpdump on the adsl interface - at least I recognize the ipv6 address in the packet, and it looks like a ping (even it tcpdump can not decode the packet)

So it must have been made by the dsld daemon.

It might be possible to forge and add ICMP replies if the administratively denied packets could somehow be removed or intercepted. Not possible with iptables since avm firewall precedes it for the adsl interface :-/

Another solution would then be making dsld "bind" to a fake interface, on which a daemon would just remove such "administratively denied" packets before passing everything else to the real interface.

It would however require some deeper understanding of the adsl packet format. Also, I wonder if packets we see on that interface are not mixed with other packets to optimise the payload.

AFAIK, this is inside of "ar7.cfg" firewall

ipv6 {
     ----lines cut---
        firewall {
               enabled = yes;

You could just try to disable fritz ipv6 firewall entirely, then use freetz ip6tables.
Remember, these 2 firewalls are placed in tandem, so you only need to have one running

I believe this only activates or disactivate the given rule, not the firewall- ie not even the ports I opened will come though.
After mya quick try, this is confirmed : changing yes to no, or adding "ICMP " or anything else (IPv6-ICMP, etc) to the rules just make them fail, ie they are not applied and nothing comes to the machine :-/

This could be used to strace the program and see which functions load these rules, to try to remplace it with LD_PRELOAD and do some tests... it's a dynamic binary, however it has been stripped :-/

At this moment, the best option seems to create a fake interface for dsld, to intercept its replies, and forge true replies. I used a similar approach on the 7050 to tweak DSCP values. See http://www.ip-phone-forum.de/archive/index.php/t-225215.html

But it was way easier since it just dealt with packets going to the dsl inteface, for which a tcpdump decoding was possible and helpfull. This would require dealing with packets going to the adsl interace.

It might be overkill to just add icmpv6 reply, but that's the only idea I see.

Guylhem