On Tue, 2007-05-22 at 09:08 +0200, Andrea Lusuardi - UoVoBW wrote: > The debian config of radvd was quite simple and yes, this is true.I set > this up on my access point and it behaved as you described. > How can this be fixed?
Well, I'd start by showing the main developers how to reproduce it :) If you can test it at a time the network is otherwise fairly idle, and just bring your bcm43xx up with 'ip link set eth1 up' rather than assigning it a Legacy IP address, then there should be _very_ little traffic -- but it _should_ do router discovery and pick up an IPv6 address. Use tcpdump at both ends, and compare the results. I have a very strong suspicion that you'll find there are multicast Ethernet packets getting lost in transit. > is there a way to use radvd to talk to the other radvd - which i asked > and is used to configure ip6 connectivity at my university - ad force > it to send the configurations? No. radvd only advertises routes for a single subnet. It advertises the 'prefix' -- the upper 64 bits -- and the lower 64 bits are generated by the individual station, from a permutation of that station's MAC address. The station assumes the default route is out via the machine which was running radvd. If you want to run radvd with a 'real' global address and provide proper connectivity, then you have to have a subnet of your own for radvd to advertise. With '6to4' that's actually dead easy -- you get a whole /48 of IPv6 addresses for every public IPv4 address, which means 65536 separate /64 subnets of your own. It's better to get 'proper' IPv6 connectivity though, if you can -- either through a tunnel such as from somewhere like sixxs.net, or just ask the university to assign you some space and tunnel it to you. -- dwmw2 _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
