There was documented buffer overflow. Added proper checks to prevent it. Fixed in radvd-1.5-2.fc13. Closing.

rawhide?
This is f12!
So it is not fixed yet here.

radvd-1.5-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/radvd-1.5-1.fc12

[root@epia etc]# /usr/sbin/radvd
[Jan 14 15:10:16] radvd: yacc stack overflow in /etc/radvd.conf, line 2487: ;
[Jan 14 15:10:16] radvd: error parsing or activating the config file: /etc/radvd.conf
[root@epia etc]# rpm -q radvd
radvd-1.5-1.fc12.i686


So it still doesn't work with 64K routes.
Also, when using 256 routes:

[root@epia etc]# service radvd restart
Stopping radvd:                                            [FAILED]
Starting radvd: [Jan 14 15:39:06] radvd: cannot create radvd pid file, terminating: Permission denied
                                                           [FAILED]
[root@epia etc]# ls -l /var/run/radvd/radvd.pid
-rw-r--r-- 1 root root 6 2010-01-14 15:12 /var/run/radvd/radvd.pid

When starting with 256 routes:

[root@epia etc]# service radvd start
Starting radvd:                                            [  OK  ]
[root@epia etc]# service radvd status
radvd dead but subsys locked

When starting with 1 route:

[root@epia etc]# service radvd start
Starting radvd:                                            [  OK  ]
[root@epia etc]# service radvd status
radvd (pid 19223 19222) is running...

radvd-1.5-1.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update radvd'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0602

Please see comment #4

radvd-1.5-2.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/radvd-1.5-2.fc12

Jan has re-made the patch. Parsing re-allocates buffer for config option when necessary. Build is in testing repository. Please, test it

256 routes appears to work, at least start up.
64K routes still fails.

[root@epia ~]# cd /etc
[root@epia etc]# ls -l radvd*
-rw-r--r-- 1 root root   946 2010-01-14 15:42 radvd.conf
-rw-r--r-- 1 root root 24646 2010-01-09 14:40 radvd.conf-huh
-rw-r--r-- 1 root root   946 2010-01-10 16:53 radvd.conf.ok
[root@epia etc]# cp radvd.conf-huh radvd.conf
cp: overwrite `radvd.conf'? y
[root@epia etc]# service radvd restart
Stopping radvd:                                            [  OK  ]
Starting radvd:                                            [  OK  ]
[root@epia etc]# service radvd status
radvd (pid 24085 24084) is running...
[root@epia etc]# cp /root/radvd.conf-64K .
[root@epia etc]# cp radvd.conf-64K radvd.conf
cp: overwrite `radvd.conf'? y
[root@epia etc]# service radvd status
radvd (pid 24085 24084) is running...
[root@epia etc]# service radvd restart
Stopping radvd:                                            [  OK  ]
Starting radvd: [Jan 19 15:03:57] radvd: yacc stack overflow in /etc/radvd.conf, line 2487: ;
[Jan 19 15:03:57] radvd: error parsing or activating the config file: /etc/radvd.conf
                                                           [FAILED]
[root@epia etc]# /usr/sbin/radvd
[Jan 19 15:04:10] radvd: yacc stack overflow in /etc/radvd.conf, line 2487: ;
[Jan 19 15:04:10] radvd: error parsing or activating the config file: /etc/radvd.conf
[root@epia etc]#

xs4all.nl gives me a /48.
I am supposed to route pieces of /64.
So I need 65536 routes of a /64 each to fill a /48.

Maybe we can think of a shorthand kind of config thing to fill a biggish range with /64's instead of specifying 65536 routes?
The radvd.conf file gets kinda big.

[root@epia etc]# ls -l radvd*
-rw-r--r-- 1 root root 6222414 2010-01-19 15:03 radvd.conf
-rw-r--r-- 1 root root 6222414 2010-01-19 15:03 radvd.conf-64K
-rw-r--r-- 1 root root   24646 2010-01-09 14:40 radvd.conf-huh
-rw-r--r-- 1 root root     946 2010-01-10 16:53 radvd.conf.ok

radvd-1.5-2.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update radvd'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0793

(In reply to comment #12)
> radvd-1.5-2.fc12 has been pushed to the Fedora 12 testing repository.

Please see comment #10.

I'm upstream radvd maintainer and I was pointed to this bug.

There's some terminology clash, when speaking of "routes" you're actually implying "prefix information options".  (With more specific routes, you can send any prefix lengths you want etc.)

Udo, it's not obvious why you need to configure 64K prefixes in radvd.
I think you're misunderstanding something.

Each prefix information option takes 32B in an advertisement.  Assuming that 64k prefixes would need to be distributed, each router advertisement would need to be split to about 1400 different advertisements instead of just one(!!).  This is just not the way to handle this.

Radvd code is currently written with the assumption that all prefix information, route, rdnss, etc. options will fit in a single packet.  The proposed patch does not change this. It is possible to add this behaviour (see RFC4861 Section 6.2.3, last paragraph).  So the suggested patch may syntactically work, but it does not really work AFAICS.

So, I'd like to suggest that the proposed patch be dropped.  Udo, if you describe what you really would like to achieve (off-list or here), I can try to help you find a better solution to satisfy your needs.

A better patch (if one is needed at all) could be one that sets some sensible  limit to prefix information, route, etc. options the parser is willing to accept and/or documents limitations in the man page.

Hi Pekka,
I'm convinced some patch is necessary due to two things:
- each buffer have to be prevented from overflowing
- thanks to this patch Jan found following bug (a piece of patch):

 @@ -134,7 +159,7 @@ send_ra(int sock, struct Interface *ifac
 	addr.sin6_port = htons(IPPROTO_ICMPV6);
 	memcpy(&addr.sin6_addr, dest, sizeof(struct in6_addr));
 
-	memset(&buff, 0, sizeof(buff));
+	memset(buff, 0, allocated);
 	radvert = (struct nd_router_advert *) buff;
 
 	radvert->nd_ra_type  = ND_ROUTER_ADVERT;

I see two possible ways:
1. to add limitation to current patch
2. to prevent overflowing only (Jan's first patch).

I suppose you prefer second approach of these two. Unfortunately this one makes difficulties with SElinux on Fedora (SElinux blocks pid file removing).

I prefer fix that is acceptable to upstream.

Jiri

Thanks for explaining.
I just have to divide a /80 in /64's so that I conform to some IPv6 standard.
I would like to be able to do this in a most efficient manner (i.e. maybe not with 65536 prefix/route thingies in radvd.conf).
I you say that you cannot advertise 65536 prefixes due to some reasonable limitation that is OK.

Although radvd now doesn't choke on radvd.conf with 256 prefixes, it appears to only advertise prefix 0 until 7e inclusive according to radvdump.
If this is intended behaviour, please document thoroughly.

Please also document solutions for advertising more prefixes.

Thanks.

[Jan 25 17:58:54] radvdump: option length greater than total length in RA (type 3, optlen 32, len 16)
[Jan 25 17:58:54] radvdump: option length greater than total length in RA (type 3, optlen 32, len 16)

(??)

I've applied the initial patch and the memset fix above.

If this is causing issues with selinux, I wonder if those could be mitigated in some other manner?

In addition, I've applied a patch that decreases MSG_SIZE to around 1500 (and actually splits it to send and receive sizes) in order to avoid sending out fragmented RAs.  I've also added a note about the size limitations in the man page.

Do I need to test anythingnewer than radvd-1.5-2.fc12.i686 ?
What do the radvdump messages that I posted mean?

The radvdump messages mean (in this case) that it received a packet which exceeded the length of the buffer and the packet was "cut off" at the end, so the last option was incomplete.  This should not be a concern.

I noticed some `extra` addresses assigned to my eth0 on the workstation, not the firewall:

         inet6 addr: 2001:888:1abc:e:21f:d0ff:feb1:f836/64 Scope:Global
          inet6 addr: 2001:888:1abc:d:21f:d0ff:feb1:f836/64 Scope:Global
          inet6 addr: 2001:888:1abc:c:21f:d0ff:feb1:f836/64 Scope:Global
          inet6 addr: 2001:888:1abc:b:21f:d0ff:feb1:f836/64 Scope:Global
          inet6 addr: 2001:888:1abc:a:21f:d0ff:feb1:f836/64 Scope:Global
          inet6 addr: 2001:888:1abc:9:21f:d0ff:feb1:f836/64 Scope:Global
          inet6 addr: 2001:888:1abc:8:21f:d0ff:feb1:f836/64 Scope:Global
          inet6 addr: 2001:888:1abc:7:21f:d0ff:feb1:f836/64 Scope:Global
          inet6 addr: 2001:888:1abc:6:21f:d0ff:feb1:f836/64 Scope:Global
          inet6 addr: 2001:888:1abc:5:21f:d0ff:feb1:f836/64 Scope:Global
          inet6 addr: 2001:888:1abc:4:21f:d0ff:feb1:f836/64 Scope:Global
          inet6 addr: 2001:888:1abc:3:21f:d0ff:feb1:f836/64 Scope:Global
          inet6 addr: 2001:888:1abc:2:21f:d0ff:feb1:f836/64 Scope:Global
          inet6 addr: 2001:888:1abc:1:21f:d0ff:feb1:f836/64 Scope:Global
          inet6 addr: 2001:888:1abc:0:21f:d0ff:feb1:f836/64 Scope:Global

How come? I did not assign/configure these. They are in the global scope but have a hardware address thingie at the end. I did not change the configuration for eth0 so what could be the cause? A relation to radvd?

They're autoconfigured addresses based on received router advertisement messages.  I'd double check your radvd configuration. Most likely it advertised all those prefixes and your host autoconfigured addresses from each.  Checking the address lifetime with "ip -6 a l" and/or running tcpdump may give hints whether this was a one-time event or if these advertisements are still ongoing.

As described earlier I want radvd to advertise my /48.
Due to some logic this is to be done in /64's.
I have 256 /64's in radvd.conf and that works.
But why does somethign nsee the need to autoconfigure for each /64 advertised? 
I mean: *I* am the admin and I already had stuff set up. I do not need the numbers-space (16?) on my eth0 wasted by whatever.

Is this a bug, is IPv6 sub-optimal or what?

If you want to shoot yourself in the foot, I cannot help you.

You can however advertise prefixes but tell the clients not to autoconfigure addresses from them.  This can be done by setting "AdvAutonomous off".

Why would a PC want to configure itself for an *extra* /64 when it already CAN communicate with that very same router.
This is quite unlogical and has nothing to do with feet.

Yes, this is why you should not be configuring all those prefixes in radvd.
Doing so is indeed very illogical.  Radvd and client hosts are only doing what you're telling them to do.

radvd-1.5-2.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

So currently radvd cannot advertise a full /64, as reported in comment 17.
Why is the bug closed?

This is a different problem than the 256 /64 prefixes someone would want to advertise since it is an issue with just one /64.

Comment 17 appears to discuss scenarios with 256 /64's.  Please clarify what you mean with (one) "full /64".

I get a /48 from my ISP.
IPv6 networks are separated in /64's for some weird reason.
So radvd should advertise /64's.
This gives me 65536 /64 networks to advertise.
radvd chokes on the config for that situation.
radvd does not choke on the config for 256 prefixes.
Yet it advertises only 127 of them (0 until 7e) without any message about that.

So, this is not a question of one /64 after all, but that radvd silently ignores prefixes after the size of the message gets too big.

Upstream radvd-1.6 fixes this (IMHO minor) issue by "choking on the config".

Nope.
The `65536 /64's choking issue` is understandable. That is not what my remark is about.

Radvd does accept the 256 /64's without any issue yet silently it does NOT advertise all of the 256 /64 networks, according to radvdump.

You misunderstand my comment 32.  I'm saying that on radvd-1.6 (upstream), if there are more options that will fit in a packet (about 44 prefixes), radvd will not start, will not advertise anything.  So the "silent ignore" mode has been changed.  You seem to be saying that you think this feature should be included in the patch.  The maintainer will judge whether this is serious enough issue for that.

I obviously don't understand stuff.
I see 127 prefixes advertised (using radvdump) when the config has 256 prefixes.
You mention a number of 44.
If that is the new reality we are truly in a feature downgrade spiral.
Or I am missing some information here.

Also: why and how should I run N instances of radvd (N > 1) to get close to advertising the prefixes that my isp gave me?
That is the core of the whole issue here: how can I most easily advertise my prefixes. And /that/ is still not solved.

See:

Jan  4 18:00:27 epia radvd[10681]: version 1.6 started
Jan  4 18:00:27 epia radvd[10683]: Too many prefixes or routes. Exiting.

We restart the service with a conf of 256 prefixes.
The service is started OK.
The daemon silently exits. Unnoticed by the startup scripts.

The maximum (i.e. what is 'too many') is undocumented in `man radvd.conf`.
Why can't I just configure my /48 and let radvd handle the stuff it should do?
Announce /64's if it wants to?

By blindly following the weird ipv6 architecture without creativity or fresh insights we are stuck with tools like this which are not user friendly nor 'enterprise' ready.

I think you misunderstand the IPv6 architecture, but I don't see the point in debating that here.

But FWIW, the following man page notice exists in the CVS version of radvd. radvd-1.7 will be released shortly that also includes this update.

BUGS
       radvd does not support splitting up RAs to  multiple  packets  (RFC4861
       6.2.3 last paragraph).  In practise this limits advertising to ~45 pre-
       fixes on a link, but there is no reason to be able to so.

Also the 'TODO' file describes the issue:

radvd does not support splitting up RAs to multiple packets (RFC4861 6.2.3
last paragraph). In practise this limits advertising to ~45 prefixes on a
link, but there is no reason to be able to so.  In order to avoid
fragmenting packets yet support receiving full-size frames, our hack is to   
have a bigger receive than send buffer. We could try using setsockopt
IPV6_DONTFRAG, but at least Linux glibc doesn't appear to support it yet.

We'll wait for the documentation-fix.
Why can't radvd send out multiple RA packets?
I have a reason to do so, a /48.

I.e.: fill up a frame, send it out, fill up send out, etc, until all RA's are sent out.

Correction: man page change was already present in radvd-1.6, released in March 5, 2010.

There is no practical reason for radvd to send out multiple RA packets.
The fact that you have a /48 does not mean that you need or should advertise it all to a LAN. You don't.  You only need to advertise those /64's that you're actually using.  

The only reason I can think of that one would want to advertise all of them is to configure hundreds of IPs on a single machine from multiple /64's, in order to do spamming or other anti-social behaviour.  I don't think radvd needs to support that use case.

I see Pekka's arguments 'saying all'.

Every piece of software is developed for its purpose and it should be respected.

> By blindly following the weird ipv6 architecture without creativity ...

Networking software is based on architecture that is normalized. Thanks to this all system are able communicate. Creativity is not acceptable because this can lead to ineligible issues.

Due to this I consider this bug fixed enough.

- The man page text mentioned is not in my radvd-1.6-2.fc14.i686.
- why would a protocol place such an early limit on such important info?