suche IPV6 in Freetz config

[docsteel]

Der Build Versuch aus dem aktuellen SVN (Rev. 2746) mit den ipv6 Patches r2741 schlägt hier beim Bau der Busybox 1.1.3 mit einem Segfault fehl.

Ich versuch jetzt noch mal aus sauberen Sourcen (mit neu ausgechecktem SVN und neuer config) das ganze zu bauen.

Bei der config fehlen mir bei den Shared Libraries (Ipv6) folgende Einträge: libip6t_standard.so, libip6t_tcp.so, libip6t_udp.so

Update: Image lässt sich bauen läuft dann aber nicht sauber (kein aiccu, etc.) und die Telefoneinstellungen der Box sind defekt.

Update2: Image läuft, aiccu ist jetzt auch im Webif (danke ollistudent), allerdings wirft das WebIF von avm bei den Telefoneinstellungen mit "lpp_error" und die DECT Telefone existieren nicht mehr. Telefonverbindung via 2. PCV besteht aber lt. Syslog.

 

[olistudent]

Okay. Patches sind im SVN. Das Testen kann beginnen. Danke Andreas.

MfG Oliver

 

[de-wolff]

does radvd work?

Hello,

I have a working 6to4 tunnel from my Fritz WLAN repeater, to the outside world.

When I manually set an ipv6 address and gatewayaddress (my Fritz repeater) to my (vista) PC (laptop, connected using WLAN) I can reach the outside world.

But when I don't set manually, my Vista box don't get an IP address.
According to wireshark, it is doing
a Neighbor solicitation
several Router solicitations,
and several Multicast Listener Report
All from my Vista box, never seeing a response.

Shouldn't radvd respond?

Has anyone radvd working using WLAN on fritz?

Jaap

 

[adangel]

Hi Jaap,
I am just had the same experience (radvd doesn't respond to router soliciation).
I suppose one has to add the router multicast address "ff02::2" manually to the device radvd uses (but I'm not quite sure ... still testing)

But as long as radvd is running, radvd announces the prefix every 5 minutes, so you have to wait not more the 5 minutes to get a address assigned. This works for me with WLAN, too.

Andreas

Edit:
I tested it again, and it works even without setting ff02::2/8 to dev lan. Usually radvd assignes the route ff00::/8 to the interface (if it does not exist). And that's enough.

Is the router solicitation received by fritz? You can check this with ip6tables: ip6tables -I INPUT -p icmpv6 --icmpv6-type 133
This will add an accounting rule; do the counters increase (ip6tables -vnL INPUT)?
Is radvd really running? (ps | grep radvd)
Start syslogd and check /var/log/messages for errors from radvd.
Do you get an ip address, if you restart radvd? (radvd sends a router advertisment on startup in any case)
Could this be a firewall issue? (e.g. too restrictive icmp rules on fritzbox or vista)

 

[de-wolff]

Thanks for your response. You give me good hints.
Answers:
radvd is really running,
I don't have ip6tables, nor syslogd, I have to compile them in my next image (will be in the weekend). I don't get an address when restarting radvd. I turned (for the test) the firewall off on the vista box, and as far as I know there is no firewall installed on the fritzbox. I don't see any icmpv6 packets coming from the fritzbox to the vista box.

 

[adangel]

syslogd is included with busybox, perhaps it is already enabled.
It seems that the problem you have is caused by radvd, as the network works, when you configure it manually. So there is no problem with missing ip addresses on fritzbox (I indeed tried to run radvd on interface lan without an ip address assigned and it still works).
By the way: If you don't have ip6tables, then there is for sure no ipv6 firewall on fritzbox.
Maybe you can also try with linux instead of vista (or knoppix), just to see if the problem is vista related.

 

[de-wolff]

Today I created 4 images, at first the same image with only syslog enabled. There where no special messages related to radvd.

Then I created a not-working image, so I had to recover.
Because of this recovery I had to connect my laptop by wired ethernet to the fritzbox.
After I recover I got an ipv6 address!
I did some more tests, and it turned out that using wired ethernet radvd is working as expected (reacts on router sollicitations, sends router advertisements)
So it looks like the wlan is not really bridged.

Now I am trying with the latest SVN, which has ipv6 support in it, so I don't have to patch it before using. I selected some options, and now I get strange ipv6 addresses:
ifconfig lan gives:
lan Link encap:Ethernet HWaddr xxxxxxxxxx
inet addr:192.168.2.2 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: │*/64 Scope:Link
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
and ip -f inet6 route gives lines like:
(null)/64 dev lan metric 256

I think this is because uclibc is not compiled the right way, and until I solved this problem I can't go on with the radvd tests, to be continued....
Now

 

[adangel]

Hi docsteel,

Bei der config fehlen mir bei den Shared Libraries (Ipv6) folgende Einträge: libip6t_standard.so, libip6t_tcp.so, libip6t_udp.so

die libs heißen mit dem neuen iptables jetzt libxt_standard.so, libxt_tcp.so und libxt_udp.so und sind im Menü "Select shared libraries (both IPv4 and IPv6)" eingeordnet. Das sind die Libs, die gleichermaßen für IPv4 und IPv6 verwendet werden.

Grüße
Andreas

 

[adangel]

I think this is because uclibc is not compiled the right way, and until I solved this problem I can't go on with the radvd tests, to be continued....

Did you check, that the toolchain is really build (and not downloaded?).
That is in menuconfig "Advanced options", "Compiler options", "Toolchains": "Build toolchain". Also be sure, that "uClibc config" is set to "mod" (which should be the default).

If there are are any problems (e.g. that uclibc isn't build again), a "make dirclean" may help (but you have to compile the whole toolchain and all programs again).

Andreas

 

[olistudent]

He opened a ticket and I fixed this error.

Oliver

 

[de-wolff]

radvd not on wlan?

Did you check, that the toolchain is really build (and not downloaded?).
Andreas

I did check, and no, the toolchain was not built, but downloaded. I changed this .
I also changed the Gateway6, to be build with uClibc++ instead of stdlibc++, so it fits on my box (I still have 11K free) (Not yet configured, not everything at the same moment)

But my base problem what I tried to tackle is still not solved, and I have a new challenge:

I have two fritz boxes, A is connected to my dsl line, and B is my repeater.
And I have a vista laptop with wlan.

Now I can create a tunnel to the outside world from box B (configured by hand as described in an more early article)
From my vista box, with a connection to box B, I have an ipv6 connection via box B to the outside world.
But from box A, where I have set all routes correct, I can ping to box B, but not to the outside world. Unfortunately, traceroute6 can't resolv libresolv (it is only 2K, so the next image ...), so I can't see why it is going wrong.

But I started with the problem radvd is not working.

I checked it with linux, and with vista. I put on etherreal/wireshark, but no show. When I use a cable ethernet connection, everything works fine, but with wlan no show.
And syslog gives a strange message:
fritz user.warn kernel: ICMPv6 NA: someone advertises our address on lan!
I did check, no other connected device had the same address.
At this moment I configured box A to have private::1,
box B to have private::2
and vista box to have private::3
(There are more devices, but they are not configured for ipv6)
Also box B is configured with public::2, while somewhere at my provider public::1 does exist. Thats where my tunnel is.

So I have 3 questions:
Who is advertising my address on lan
Why is radvd not working on wlan (I think those are releted)
and how is it possible that I can reach the outside world from the vista box, but not from fritz box A.

Results from Box A
/var/mod/root # ip -f inet6 ro
PRIVATE::/64 dev lan metric 256 expires 81827sec
default via PRIVATE::2 dev lan metric 1024
/var/mod/root # ifconfig lan
lan Link encap:Ethernet HWaddr 00:1F:3F:B0:7F:5A
inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: PRIVATE::1/128 Scope:Global
inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
inet6 addr: PRIVATE:0:21f:3fff:feb0:7f5a/64 Scope:Global
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:48236 errors:0 dropped:0 overruns:0 frame:0
TX packets:17318 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4842812 (4.6 MiB) TX bytes:3578778 (3.4 MiB)

Results from box B
/var/flash # ip -f inet6 ro
PUBLIC::/64 via :: dev xs6all metric 256
PRIVATE::/64 dev lan metric 1024
default via PUBLIC::1 dev xs6all metric 1024
/var/flash # ifconfig lan
lan Link encap:Ethernet HWaddr 00:1A:4F:0E:77:98
inet addr:192.168.2.2 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: PRIVATE::2/128 Scope:Global
inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:71295 errors:0 dropped:0 overruns:0 frame:0
TX packets:32249 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5785532 (5.5 MiB) TX bytes:9450516 (9.0 MiB)

 

[adangel]

Hi Jaap,

I did check, and no, the toolchain was not built, but downloaded. I changed this .
I also changed the Gateway6, to be build with uClibc++ instead of stdlibc++, so it fits on my box (I still have 11K free) (Not yet configured, not everything at the same moment)

Could you please tell me, what you did? I tried this once but ran into errors... uclibc++ is the better solution for the boxes.

And syslog gives a strange message:
fritz user.warn kernel: ICMPv6 NA: someone advertises our address on lan!

That's interesting. If a ipv6 device is brought up, linux kernel configures automatically a link-local address (begins with fe80). NA means "neigbour advertisement". And somehow your two boxes are using the same addresses:

inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link

Usually the address is constructed from the mac, but here it seems that the mac "00:00:00:00:00:00" was used...

I think you can solve this manually by assigning an other address on fritzbox A:

ip -6 addr del  fe80::200:ff:fe00:0/64 dev lan
ip -6 addr add  fe80::200:ff:fe00:1/64 dev lan

One other thing that seems strange to me:

inet6 addr: PRIVATE::1/128 Scope:Global

Did you assign this address by hand? I think you should use "PRIVATE::1/64", to tell the interface, on which network it is (otherwise the routing table will not be updated, but I saw that you have the routing entries PRIVATE::/64 in your table, so this should not be an issue).

Andreas

 

[de-wolff]

Hi Jaap,
Could you please tell me, what you did? I tried this once but ran into errors... uclibc++ is the better solution for the boxes.
Andreas

I opened a ticket with a description, changed patches and makefiles

 

[de-wolff]

I think you can solve this manually by assigning an other address on fritzbox A:

ip -6 addr del  fe80::200:ff:fe00:0/64 dev lan
ip -6 addr add  fe80::200:ff:fe00:1/64 dev lan

Yes it did solve this problem, thanks
But no other problem is solved yet
Maybe the bad physical address did raise because lan is a bridge and not a real interface?
And I am curious if someone else did try a fritzbox with repeater, and they have the same problem?

One other thing that seems strange to me:
Did you assign this address by hand? I think you should use "PRIVATE::1/64", to tell the interface, on which network it is (otherwise the routing table will not be updated, but I saw that you have the routing entries PRIVATE::/64 in your table, so this should not be an issue).

Yes, I did a lot ipv6 configuration by hand.
However, I did change the PRIVATE::1/128 to PRIVATE::1/64, and it did not change anything in behaviour.
I think my knowledgment of ipv6 is not yet enough, but still learning
After I have everything up and running, I restart from scratch, and make a note of everything, so I can reproduce it

 

[adangel]

Results from Box A
/var/mod/root # ip -f inet6 ro
PRIVATE::/64 dev lan metric 256 expires 81827sec
default via PRIVATE::2 dev lan metric 1024

Results from box B
/var/flash # ip -f inet6 ro
PUBLIC::/64 via :: dev xs6all metric 256
PRIVATE::/64 dev lan metric 1024
default via PUBLIC::1 dev xs6all metric 1024

Is this your complete routing table?
On my box, I have additional entries for each interface:

fe80::/64 dev cpmac0  metric 256 
fe80::/64 dev lan  metric 256 
fe80::/64 dev eth0  metric 256 
fe80::/64 dev sixxs  metric 256 
fe80::/64 dev tiwlan0  metric 256 
fe80::/64 dev wdsup0  metric 256 
fe80::/64 dev wdsdw0  metric 256 
fe80::/64 dev wdsdw1  metric 256 
fe80::/64 dev wdsdw2  metric 256 
fe80::/64 dev wdsdw3  metric 256

And radvd added some more:

ff00::/8 dev lan  metric 256 
ff00::/8 dev tiwlan0  metric 256 
ff00::/8 dev wdsup0  metric 256 
ff00::/8 dev wdsdw0  metric 256 
ff00::/8 dev wdsdw1  metric 256 
ff00::/8 dev wdsdw2  metric 256 
ff00::/8 dev wdsdw3  metric 256

But these routes should be automatically there - if not, some other problem exists.

 

[docsteel]

Ich habe hier:
http://www.ip-phone-forum.de/showthread.php?t=180904
mal eine neuen Thread aufgemacht der sich NUR mit den Problemen von

ipv6 auf 7270

beschäftigen soll, da es hier ja auch um die 7170 geht.

 

[de-wolff]

Is this your complete routing table?

No the complete table is:

/var/mod/root # ip -6 ro
2001:888 :public::/64 via :: dev xs6all  metric 256
2001:888 :private::/64 dev lan  metric 1024
fe80::/64 dev cpmac0  metric 256
fe80::/64 dev lan  metric 256
fe80::/64 dev eth0  metric 256
fe80::/64 via :: dev xs6all  metric 256
fe80::/64 dev tiwlan0  metric 256
fe80::/64 dev wdsdw0  metric 256
fe80::/64 dev wdsdw1  metric 256
fe80::/64 dev wdsdw2  metric 256
fe80::/64 dev wdsdw3  metric 256
fe80::/64 dev wdsup0  metric 256
ff00::/8 dev cpmac0  metric 256
ff00::/8 dev lan  metric 256
ff00::/8 dev eth0  metric 256
ff00::/8 dev xs6all  metric 256
ff00::/8 dev tiwlan0  metric 256
ff00::/8 dev wdsdw0  metric 256
ff00::/8 dev wdsdw1  metric 256
ff00::/8 dev wdsdw2  metric 256
ff00::/8 dev wdsdw3  metric 256
ff00::/8 dev wdsup0  metric 256
default via 2001:888 :public::1 dev xs6all  metric 1024

 

[dakraut]

Bei mir läuft das mit aiccu gar nicht rund, hab meist zwischen 95-98% packetloss. Wenn ich mir den Traffic über das dsl-Interface anschaue, wenn ich über den sixxs-Tunnel zu noc.sixxs.net pinge, siehts sehr suspekt aus:

1.
01:46:16.167071 IP host-091-097-035-083.ewe-ip-backbone.de > deham01.sixxs.net: IP6 2001:6f8:900:c01::2 > 2001:6f8:900:c01::1: ICMP6, echo request, seq 25, length 64
2.
01:46:16.194427 IP deham01.sixxs.net > 169.254.2.1: IP6 2001:6f8:900:c01::1 > 2001:6f8:900:c01::2: ICMP6, echo reply, seq 25, length 64
3.
01:46:16.211473 IP host-091-097-035-083.ewe-ip-backbone.de > deham01.sixxs.net: IP6 2001:6f8:900:c01::2 > 3829:c0bd:d4e0:bc:a9fe:201:6000:0: ICMP6, parameter problem[|icmp6]
4.
01:46:17.176440 IP host-091-097-035-083.ewe-ip-backbone.de > deham01.sixxs.net: IP6 2001:6f8:900:c01::2 > 2001:6f8:900:c01::1: ICMP6, echo request, seq 26, length 64
5.
01:46:17.204427 IP deham01.sixxs.net > 169.254.2.1: IP6 2001:6f8:900:c01::1 > 2001:6f8:900:c01::2: ICMP6, echo reply, seq 26, length 64
6.
01:46:17.221122 IP host-091-097-035-083.ewe-ip-backbone.de > deham01.sixxs.net: IP6 2001:6f8:900:c01::2 > 3829:c0bd:d4e0:bc:a9fe:201:6000:0: ICMP6, parameter problem[|icmp6]
7.
01:46:18.188167 IP host-091-097-035-083.ewe-ip-backbone.de > deham01.sixxs.net: IP6 2001:6f8:900:c01::2 > 2001:6f8:900:c01::1: ICMP6, echo request, seq 27, length 64
8.
01:46:18.214427 IP deham01.sixxs.net > 169.254.2.1: IP6 2001:6f8:900:c01::1 > 2001:6f8:900:c01::2: ICMP6, echo reply, seq 27, length 64
9.
01:46:18.232770 IP host-091-097-035-083.ewe-ip-backbone.de > deham01.sixxs.net: IP6 2001:6f8:900:c01::2 > 3829:c0bd:d4e0:bc:a9fe:201:6000:0: ICMP6, parameter problem[|icmp6]

Das Paket kommt korrekt zurück und wird dann mit komischen Parametern und einer komischen DST verwurschtelt. Jemand eine Idee was da schief läuft?

(Aktueller Trunk auf einer 7170)

 

[cuma]

Hi, hab auch 'ne Frage zu ipv6. Aus welchem Grund werden (mindestens) die iptables-module libip6t_dst, libip6t_icmp6 und libip6t_policy per default ausgewählt?

 

[adangel]

komischen Parametern und einer komischen DST verwurschtelt. Jemand eine Idee was da schief läuft?

Welchen Tunneltyp verwendest du? Zufällig 6in4-static oder 6in4-heartbeat?
Bei mir läuft AYIYA (IPv6-in-UDP-in-IPv4), was problemlos funktioniert.

Dein Problem kommt mir bekannt (dasselbe passiert, wenn ein 6to4-Tunnel eingerichtet wird). Das erste Paket funktioniert, und alle weiteren nicht mehr. Nach einer Weile geht wieder das erste Paket.
Mit iptables habe ich dann gesehen, dass die Pakete nicht beim Tunnel-Interface rauskommen, sondern beim Interface dsl. Ich vermute, dass dsld bzw. kdslmod die Ursache ist, also der Teil von AVM, der NAT, Firewall und Bridge macht.

Aus welchem Grund werden (mindestens) die iptables-module libip6t_dst, libip6t_icmp6 und libip6t_policy per default ausgewählt?

Die libs werden benötigt, um ip6tables-Regeln zu erstellen und lesen.
OK, libip6t_dst wird wohl eher selten benötigt (Destinations Options Header).
Und ich hab grade nachgeschaut, libip6t_policy wohl auch nicht (hatte vermutet, das wäre nötig, um default policies zu setzen).

Bleibt also noch libip6t_icmp6 übrig, das auf jeden Fall für icmpv6-Regeln benötigt wird (wobei man das auch manuell machen kann, muss ja schließlich jeder selbst wissen, ob er icmpv6-Pakete filtern will).

Aber ich hoffe, dass außer den drei Modulen noch libxt_standard.so, libxt_tcp.so und libxt_udp.so per default ausgewählt werden, ansonsten könnte man gar keine Regel erstellen.

Achso, was vlt. noch interessant ist: Man benötigt diese Module nur, um die Regeln zu erstellen (z.B. ip6tables -A INPUT -p tcp --dport 80 -j DROP) oder um die aktuellen Regeln anzuzeigen (ip6tables -vnL). Die eigentliche Arbeit machen dann die Kernel-Module.