I now placed the WL-500g as my main router and tried to setup IPv6, but there seem to be 2 problems:
- default firewall config blocks IPv6 tunnel packets
- radvd won't start
Printable View
I now placed the WL-500g as my main router and tried to setup IPv6, but there seem to be 2 problems:
- default firewall config blocks IPv6 tunnel packets
- radvd won't start
I fixed the two problems. Added some lines to rc/firewall_ex.c which will allow IPv6-tunneled packets to arrive, when the tunnel is enabled. And I changes some code of the radvd, which required that the config file is owned by root, which I updated to allow it to be owned by admin, which is the name of the super-user in the WL-500g.
New firmware is available at same URL:
http://www.p-bierman.nl/~phedny/WL50....7-3b+ipv6.trx
And again, I attached a source patch
phedny, you've done a great job. ;-)
I think your code should be incorporated in the firmware.
In fact, I will probably recompile uclibc with ipv6 and rpc support, so it should be easy to incorporate your stuff.
Won't recompiling uClibC break compatibility with the wl binary?
If it works, then all stuff about the custom ipv6 library can be removed and things will be much cleaner :)
well, it works fine for me. btw, I've put new toolchain here:
http://wl500g.dyndns.org/hndtools-mi...3-full.tar.bz2 (2 MB)
extract it and change the symbolic link in the /opt/brcm, try to cleanup your code then.
indeed, it works. now even ping6 is working.Quote:
Originally Posted by Oleg
i did some cleaning up in my code and removed all the stuff regarding my ipv6-library, since uClibC now handles it.
the file i attached is the result of my work.
Please check your PM...
Is there any update Client for my WL500g to update my freenet6 tunnelendpoint?
Or for any other Tunnelbroker?
Nothing???
Oleg,
How hard is it to get 'traceroute6' and 'ip6tables' into the firmware? No need for fancy webby and nvram things, good old post-boot and a config file on the nvram fs suffice.
These two things would make ipv6 just a little more usable.
traceroute6 is not available in the busybox, ip6tables requires kernel support - bunch of space.
Have you considered using openwrt?
Considered yes, tried no. I'm a bit reluctant because of the install procedure and all the manual configuration. The advantage of openwrt ofcourse is that you only install what you need.
Anyway, if that is my best bet, I'll give it a try. I consider myself an experienced user so I should be able to figure things out.
Is here anyone who uses his wl500g with a dynamic ipv4 adress and a ipv6 tunnel? for exabmle freenet6?
Can the wl500gx with the latest firmware operate as an IPv4/IPv6 dual stack machine? Thanks in advance.
Hey I am running the latest version of Oleg his firmware, but somehow can't get IPV6 to run. Any tips on how to troubleshoot this?
I did all the steps in the following guide:
http://wl500g.info/archive/index.php/t-1685.html
Thanks!
Dennis
I am using Olegs 1.9.2.7-3 (I think.) on a wl500gx
Is there a way to disable IPv6? I notice running ifconfig that there are IPv6 entries, even though I do not have IPv6 configured or enabled via the Webpage configuration. I see in the syslog that a daemon for IPv6 v0.8 for NET4.0 is loaded. I will like to disable it from starting. I like to keep things trim.
So my main question is where is the config file to disble/not start?
I beleive it is Inet or something like that, I am a half noob half itermiddiate user.
Anyone thing there will be any disadvantages to disabling?
tokyoturnip
Has anyone cross-compiled dhcpv6 for the wl500gx? An ipkg package would be wonderful, but google tells me that there is none.
I am trying to use a wl500gx with Oleg's firmware to connect natively to IPv6 on Wanadoo here in France, and dncpv6 is required.
Thanks in advance.
My conclusion is that a wl500gx running Oleg's firmware does not handle an ICMPv6 Neighbor Solicitation correctly. Another, peripheral conclusion is that my Fedora Core 4 box does not handle neighbor discovery 100% correctly. Let me explain.
My setup is as follows:
ADSL2+ Modem
|
wl500gx as router
|
Wired Ethernet LAN
/ | \
PC running wl500gP as a PC running
Windows XP wireless access Linux
point Fedora C4
A laptop with Two wl500gx’s
Windows XP as wireless access
connected point clients
wirelessly to
the wl500gP
All the wl500g’s are running Oleg’s latest firmware.
Remark: The wl500gP works correctly as a wireless bridge, and the wl500gx router appears ok, too.
Remark: In the following experiments the order in which tests are conducted is important: tests cause state changes.
Experiment 1: The Windows PC ping6s the Windows laptop. Everything works according to the text book. In particular, one can see all the ICMPv6 packets going back and forth. The first and most important one is the neighbor solicitation packet going from the PC to the laptop.
Experiment 2: ping6ing in the reverse direction works perfectly, too.
Remark: All these ICMPv6 packets had to go through wl500gx router and the wl500gP wireless bridge.
Experiment 3: The Windows PC tries to ping6 one of the wl500gx wireless access point clients. Since the address of this access point client is not in the PC’s neighbor cache, the PC sends out a neighbor solicitation packet which is not answered, and it is supposed to be answered.
Experiment 4: The wl500gx wireless access point client ping6s the Windows PC. This is Experiment 3 in the reverse direction. It works because the Windows PC replies, as it should, to the neighbor solicitation packet which it receives from the wl500gx.
Remark: It is only the neighbor solicitation packets that are not be treated correctly. Echo request and echo reply always work. (I ran no experiment regarding ICMPv6 router packets.)
Experiment 5: The Windows PC again tries to ping6 the wl500gx wireless access point client. THIS TIME IT WORKS. It works because the Windows PC put the address of the wl500gx in its neighbor cache during Experiment
4. It knows the address now, and it does not have to send out a neighbor solicitation packet.
Experiment 6: Now conduct the same sequence of experiments with the Linux PC substituted for the Windows PC. The wl500gx can ping6 the Linux PC because the PC’s version of Linux accepts neighbor solicitation packets; however, it, the PC, still cannot ping6 the wl500gx because the wl500gx’s address was not entered into the neighbor cache of the PC. In other words, there is a different bug here.
Remark: There are no problems when IPv4 is used.
Remark: I realize that I could make things work by manually entering addresses here and there, but that is asking for trouble later.
Of course, I may have missed some obvious point, and all this may be nonsense.
My careful editing got garbled after submission.
On the wired Ethernet LAN are a PC running Windows XP, a wl500gP acting as a wireless access point, and a PC running Linux.
Wirelessly connected to the wl500gP access point are a laptop running Windows XP, and two wl500gx's acting as wireless access point clients.
I now know a bit more about ipv6 neighbor solicitation in systems using wl500gx’s and wl500gP’s. I will refer here to my system setup which I described a couple of messages ago.
First consider the wl500gx router. It works correctly, that is, it accepts all NS’s (neighbor solicitations). I had entered an ipv6 address in the LAN Internet Interface, and ifconfig showed this address in br0. In addition, br0, eth0, eth1, vlan0, and vlan1 showed the automatically generated fe80 link-layer address. (Only one because there is only one MAC address.) NS’s to both these addresses were accepted.
Remark: I was a bit surprised that I did not see an automatically configured address based on the prefix and the MAC address. However, I finally decided that this is intended. Later I saw that in the Access mode as opposed to Home Gateway mode this address is generated.
The file dev_mcast in /proc/net shows the MAC addresses that each interface is listening for. These addresses look a bit strange because they are derived from solicited-node addresses and some standard multicast addresses. Without going into detail, one could see that br0, eth0, eth1, vlan0, and vlan1 were listening for the fe80 link-layer address and br0 was additionally listening for the ipv6 address that I had entered manually. That this latter address is in br0 only is important.
The NS’s arrived over a wired connection, and they were responded to correctly. I underlined the word “wired” because wired versus wireless seems to be the problem.
Second, consider the wl500gx access point clients which are the extremities of my set up. They have a wireless connection to the rest of the system. Their addresses and dev_mcast are similar to the router discussed above. Now, however, some NS’s are accepted and some are not.
If an NS is sent to the fe80 address, it is accepted. If it is sent to the address which appears in br0 only it is not accepted. This latter address is the problem address. I think that the fe80 address is accepted because it is associated with every interface in dev_mcast and, therefore, has many possibilities whereas the problem address is associated with br0 only. Although brctl says that eth1, the wireless interface, is in br0, the behavior is as if it were not. To check I added the problem address to eth1, and all NS’s were then accepted.
So I have a theory: there is something wrong with the br0 in the wl500gx access point clients. I will now attack this beautiful theory with an ugly fact.
Third, now consider the wl500gP which is acting as an access point. It is between the router and the access point clients. Its addresses and dev_mast are similar to those of the preceding devices. The ugly fact is that it works correctly whether the connection is wired or wireless. For example, an NS with a problem address going wirelessly from an access point client to the access point is accepted. In other words, in the wl500gP br0 has no problem with a wireless connection. I don’t understand.
I can think of two possibilities. Perhaps the set ups of the wl500gx’s and the wl500gP differ in some way that affects br0; I’ve looked, of course. Or, perhaps, there is a difference in the software between the two boxes, the Deluxe and the Premium, which explains this behavior. I just don’t know.
In any event, I can make things work by adding the problem address to eth1, which is obviously not elegant.
When I tried to enter some standard ipv6 things in "Additional pppd options" of the internet interface the wl500gx would no longer connect to internet. This was even the case when I entered the benign PPPD_EXTRA="".
Then looking in the source code for the firmware 1.9.2.7-7e I see that in the two places where HAVE_INET6=y appears it is commented out. Therefore, I assume that the currently installed ppp does not support ipv6.
I am hesitant to uncomment in these two places and recompile because I do not know what side effects there will be. For example, assuming that the recompilation works will the resulting firmware still fit in the wl500gx.
Any ideas will be appreciated.
Thanks
I have recompiled 1.9.2.7-7e with every #HAVE_INET6=y changed to HAVE_INET=y. I lack the courage to upload it into my wl500gx because I am afraid that it might be too big. How can I tell?
Here are the few numbers that I have.
Modified firmware .trx file 3,510,272
Unmodified 3,506,176
Difference 4096
Modified target.cramfs 2,803,187
Unmodified 2,797,695
Difference 5492
The vmlinuz are almost the same: the new one is smaller than the old one by 86
Thanks in advance for any ideas.
I uploaded the modified firmware, and it seems to be working. I say "seems" because I have used it for just a couple of days.
Looking at the output of dmesg immediately after reboot shows the following flash memory layout:
pmon 0 to 262,144
linux 262,144 to 4,063,232
rootfs 967,792 to 4,063,232 Note: rootfs is inside linux
config 4,063,232 to 4,128,768
nvram 4,128,768 to 4,194,304
The only change caused by the modification of the firmware was that the rootfs increased by 86 bytes. Apparently, this did not "break" anything.
Whew!
The recompilation was relatively straightforward. I followed the wiki here step-by-step. However, before I did so I had to replace the gcc and g++ on my Fedora Core 4 box with gcc and g++ 3.2. How to do this is described elsewhere on this site. From then on I had a few "path" problems where the compiler could not find something. These were caused by my hasty deviations from the wiki: do what it says. Note that the wiki DOES NOT tell you to "make uclibc"! You will be using the binary, and it is already made. As the last step I picked "make image-WL500gx", and it worked fine.
The change I made was to replace #HAVE_INET6=y by HAVE_INET6=y. At each step I took time to search, and make the change everywhere possible.
The recompilation took a long time on my 500Mhz Linux box.
And I can see that ipv6 is now enabled in ppp. More later.
I now have a native ipv6 connection through my wl500gx router.
In the "Additional pppd options" window of IP Config-WAN&LAN in the internet interface I entered
ipv6 , ipv6cp-use-persisten
The comma and spaces are intended. If I did this before I re-compiled the firmware to enable ipv6 in ppp, the router would not signon to internet. Now it does. I could sniff the exchange of packets between the router and the ADSL modem, and I could see ipv6 being set up.
To sniff the packets I used the Tethereal ipkg package. I assume Tcpdump would work, too. The command
killall -1 pppd
disconnects, not reboots, the router and reconnects it about 30 seconds later. This gives time to start Tethereal. The command
tethereal -i vlan1
sniffs the packets going through the WAN interface. Note that rebooting will not work because Tethereal will not be running during the connection of the router.
An ipv6 global default route is not set up automatically so I added one.
ip -f inet6 route add 2000::/3 dev ppp0 metric 9999
The huge metric is to avoid packets bouncing back and forth between me and my ISP. At the moment this route is added manually after each reboot.
Normally my ISP expects me to use dhcpv6 to get my prefix, but I do not have it on the wl500gx router yet. However, I do have dhcpv6 on my Linux box, and I got the prefix using it. Apparently my ISP uses dhcpv6 just to give out prefixes and, at the moment, nothing else.
My connection to internet is now dual-stack; that is, either ipv4 or ipv6 is used as appropriate. This is not something that I did; it is built in.
My evidence that I really do have ipv6 connection capability in addition to ipv4 is that several ipv6 sites have told me that I do. Some have even sent back my ipv6 address.
The set up here is fragile, and I need to play with the system more, and I would like to have a dhcpv6 ipkg.
Hello Oleg,
I'm a happy user of your firmware. It is great that your firmware supports IPv6 (since 1.9.2.7-4). However, there does not seem to be IPv6 support regarding the PPP daemon.
My ISP is supplying me with IPv6 connectivity (static IPv6-subnet assigned to my account) over PPP. It has been working fine for over two years, where I used an x86 Linux machine as router. However, this machine has blown up and I need to use my WL-500gx for routing purposes.
So I'm asking you: Would you like to enable IPv6 for pppd at the next firmware release?
Thank you!
Xuân.
Well, in fact, IPv6 support is broken in the firmware. There is only basic support, i.e. no firewall, etc. So, I'm thinking of removing this, as it's really dangerous and rarely used feature.
If you like to use ipv6 I would suggest you to use OpenWRT instead.
For me, it is no problem of having no IPv6 firewall at the WL-500gx level. (In my view, network security should be applied to the network peer level, not the network router level.) (If IPv6, which is not firewalled at the IPv6 router, is dangerous for a given user, this user should not enable it.) OpenWRT, on the other hand, does not seem to be as user friendly as you firmware.
The ASUS WL router series is the only kind of WLAN routers I know of which support IPv6 both at the network level and the GUI level. People expect IPv6 getting a breakthrough within the next two years, so IPv6 support is a large advantage. (Also because IPv6 solves all the NetworkAddressTranslation and PortForwarding mess.)
So I'd plead for extending IPv6 support instead of removing it. For being usable, there is barely more needed than a IPv6-enabled pppd. :-)
Although it is true that ipv6 on the wl500g's has a few bugs, one can connect natively to an ISP through a bridging modem using pppoe and pppd. See my remarks elsewhere on this site.
I also would hate to see the support for ipv6 dropped from the firmware.
Hello!
Is there a way to use IPv6 using 6to4, not a tunnel from sixxs?
If I connest my computer direct to my modem, I automaticalli get a IPv6 Address and cna connect to IPv6 sites.
Can I make this work with the router?
please add full support for IPv6 for WL-500gx with DHCP or IPv6 tuneling on IPv4 with IPv6 DHCP from my internet provider
thanx:rolleyes:
OK, I did it :)
go to this site:
http://6to4.version6.net/?show_op_sys=Linux&lang=en_GB
copy the first (which begins with ip tunnel add...) block of commands to your post-firewall file.
In the Web Interface set the IPv6 local Settings to 2002:your IP in hex::1.
So if your IP is 1.2.3.4 set it to 2002:0102:0304::1
Set the netsize to 64 and the advertisements to yes!
Hello,
Can some skilled user please compile this software?
It is used to create a free IPv6 Tunnel, and the registration at Go6 is a lot easyer than at sixxs!
Here is the Software.
http://go6.net/4105/application.asp
There is even a OpenWRT port!
Wrong forum, sorry
I used this to install IPV6 on my V2.
(The Dynamic part,) but somehow the IPV6 adresses do not get ditributed our routed.
Did someone succeed in making the WL500Gp worl as a gateway voor IPV6 (from sixxs) Tunnel Type : Dynamic (ayiya)
I have it (alomst running).
The Tunnel, and local network with ipv6
Only radvd does not start. Does someone have a radvd.conf for the wl-500gp V2?
Or can someone tell me how to run that under Oleg? Latest version?
Ok. I realize the title isn't very descriptive here. What I need to do is be able to setup some actual ipv6 dns servers on the router. In addition I also wish to have the router broadcast itself as an ipv6 dns server as well as an ipv4 one. Sixxs.net is providing ipv6 dns servers that are usable via the tunnel.
I have been able to add the required dns servers, at least temporarily, by adding them directly to the /etc/resolv.conf file. At that point both dig and host can get an ipv6 address for www.google.com (one doesn't exist on most ipv4 dns servers...). I just need to make it broadcast that it can do that so my computers will use them.
Its actually for me too...
Anybody can solve this task?
it's possible with tunnelbroker.net tunnel