> >         when there's no IPv4 address assigned to the multicast outgoing
> >         interface (specified by setsockopt), kernel made panic.  i've 
> > committed
> >         the following change to avoid the kernel panic.  historic behavior
> >         was to use 0.0.0.0 as source.
> >         my question is, which behavior look better?  do any of you know
> >         apps that assumes "0.0.0.0 as source" behavior?
> >
> >         reasoning for using 0.0.0.0 as source:
> >                 "0.0.0.0 as source" is legal only while the interface is
> >                 being initialized (RFC1122 p30), therefore, if there's some
> >                 user program that uses multicast for interface 
> > initialization,
> >                 they want the behavior.
> >         reasoning for forbidding packet transmission:
> >                 IP source address must be one of the interface addresses that
> >                 belong to outgoing interface (RFC1112 p6).  if there's none,
> >                 we shouldn't send packet.
> 
> If NetBSD supported unnumbered interfaces, then the proper thing would be to
> use the parent interface's primary address.  If the the parent's primary 
> address
> wasn't set, then you'd default back to the router-id of the system.  If no
> router-id was set, you'd return EADDRNOTAVAIL.  You would never use 0.0.0.0 as
> the source address.

Why not?
It's about the best address for the dhcpc request...

We don't want to have to use bpf to send it now, do we....

    David