Am Montag, 8. Januar 2007 03:47 schrieb Thorsten Glaser: > Wow, finally, someone else who demands support for > the current version of the Internet Protocol! ;-)
it's just a point of view which version is really "current". At least ipv4 isn't marked deprecated and my setup wouldn't work without ipv4. Ipv6 is just quite nice (for the moment). The linux ipv6 stack isn't that great anyway and also ip6tables wasn't able to use connection tracking on ipv6 for a long time, so for professional use ipv4 is still better, because it's implementation is a lot better and has proved it's stability. But if freewrt supports ipv6, then it should be working correctly. And especially not in a way where the default setup may be attackable, because ipv6 on eth0 could mean that each vlan (port) can access another vlan over eth0. I am not sure, because I haven't checked yet, but it would be better to fix that anyway. I don't want to see an article about freewrt, where somewhere is written: "But ipv6 is broken and that maybe with an security impact on all connected networks. So better disable it!". Bad press! > >I noticed that IPv6 is not working as expected. > > I remember several commits that further disabled > IPv6 support, leaving one with deprecated IPv4. I am looking at freewrt for a week and for me ipv6 is fully enabled and working, besides that eth0 shouldn't have a ipv6 adress at all. > Unluckily, I am only doing build system stuff and > am not familiar with the GNU/Linux implementations > (AFAIK there are several) of IPv6, so I won't be > of much help here, except to second the proposal > and maybe testing (I have working IPv6 at home due > to using BSD). The implementation of ipv6 is not so hard to understand (at least for the parts that might be important here): if ipv6 is available (as module or compiled in the kernel) then each time a interface gets configured, so that it has the status "up", it automaticly gets an ipv6 link-local address. Additional the ipv6 stack will scan on the interface for routers that are announcing networks. If it recieves a network, then the stack also configures an additional (local or global) ip for the announced network. A default route also might be added when annouced. So if eth0 gets activated at boot time it binds at least a link local address. If a router is annoucing a network also a ip from this network get activated. Later on eth0.0 is initialized. It binds THE SAME link local address, because eth0 and eth0.0 has the same mac adress (the same link local address for two devices can also be not correct in my opinion). But eth0.0 doesn't bind additional announced ip/network on eth0.0. I think this is because the same ip is already on eth0. In the end this means that ipv6 traffic is handeld by eth0 and not by the correct eth0.0 device. The only correct solution can be to no activate ipv6 on eth0. But this is not configurable via proc or something like this. You can disable "autoconf" and "accept_ra" and stuff like this on eth0. But you can only set this AFTER the interface is up and at this point the link local adress at least is also already active and would need to gets deactivated manually (by a script or something like that). I also manipulated the kernel and disabled autoconf by default. This hack needs to be done in a .c file of the kernel and cannot be set at runtime. But even without autoconf the link local adress is set up on eth0. Just an annouced network gets ignored. So hacking addrconf.c isn't clever too. The best solution is to run "ip -6 addr flush eth0" to disable ipv6 on eth0 completely. Because on other embedded devices this could also be eth1 or some other device I thought it would be the best to handle this via the /etc/network/interfaces file, so it's not hardcoded anywhere and easily changeable to another devices for another embedded device. With my "/etc/network/if-up.d/ipv6" script installed, you just have to set "ipv6-flush 1" for eth0 and it's get deactivated at boot time. This also allows eth0.0 to bind all ip adresses correctly. I have also checked ipv6 connectivity and it is still working perfectly. > >I just started to play with freewrt boxes, but after one week it seems to > > me that this is a really cool system. so keep up the good work! > > It's improving. At the moment we're reducing the > massive amount of redundancy in the former Buildroot, > soon ADK, in two steps. I think you can look forward > to the progress. I have took a look at the adk and it's quite impressive but also quite compilcated. I already found some things that I would like to fix, but for now I am not familiar enough with the buildsystem. for example you can choose "shorewall" with make menuconfig, but you don't get a shorewall ipkg after compiling... what's happening here? or I am asking myself why the last trunk build that works for me is 1490. At least since then freewrt is complining, but finally it fails when compiling zlib: opt/svn/freewrt/staging_dir_mipsel/bin/mipsel-linux-uclibc-gcc -lc -o libz.so.1.2.3 adler32.o compress.o crc32.o gzio.o uncompr.o deflate.o trees.o zutil.o inflate.o infback.o inftrees.o inffast.o /opt/svn/freewrt/staging_dir_mipsel/lib/gcc/mipsel-linux-uclibc/3.4.4/../../../../mipsel-linux-uclibc/lib/crt1.o: In function `__start': crt1.S:(.text+0x1c): undefined reference to `main' collect2: ld returned 1 exit status gmake[6]: *** [libz.so.1.2.3] Error 1 But because nobody else is screaming, it could also be something that has to do with my host system?!? I am using Debian Sid (unstable) on my buildhost. > bye, > //mirabile bye, Ralph _______________________________________________ freewrt-developers mailing list [email protected] https://www.freewrt.org/lists/listinfo/freewrt-developers
