[quagga-dev 404] Re: Problems with ripd in quagga-0.96.4

Krzysztof Oledzki oleq at ans.pl
Thu Nov 6 14:30:11 GMT 2003



On Thu, 6 Nov 2003 sowmini.varadhan at sun.com wrote:

> >
> > Anyway, I'm reading the code from rip_interface_multicast_set(). I can see
> > two binds there:
> >
> >   bind (sock, NULL, 0); /* unbind any previous association */
> >   ret = bind (sock, (struct sockaddr *) & from, sizeof (struct sockaddr_in));
> >
> > According to strace, both fail. I'm wonder how RIP can work with this
> > failed bind... but it works ;-) This is the output from tcpdump:
>
> Well, it does a bind for each outgoing packet, to make sure the right
> interface is picked up.
Ah, I see...

> If you bind twice to the same socket with a non-null sockaddr, the
> second bind will fail because the socket is already bound to an address.
True.

> The OS-es I'm familiar with (*BSD, Solaris) allow you to unbind an
> existing associaton by doing a bind(sock, NULL, 0) but evidently this is
> not the behavior on linux.
Ah. Which socket are ripd trying to unbind? It seems that this is the
global 0.0.0.0:520. This is a log from strace:

(...)
bind(6, {sa_family=AF_INET, sin_port=htons(520), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
(...)
bind(6, NULL, 0)                        = -1 EINVAL (Invalid argument)
bind(6, {sa_family=AF_INET, sin_port=htons(520), sin_addr=inet_addr("XXX.XXX.210.1")}, 16) = -1 EINVAL (Invalid argument)
(...)
bind(6, NULL, 0)                        = -1 EINVAL (Invalid argument)
bind(6, {sa_family=AF_INET, sin_port=htons(520), sin_addr=inet_addr("XXX.XXX.210.1")}, 16) = -1 EINVAL (Invalid argument)
(...)

Is it safe? What will happend when someone send us packets while the
socket is being unbinded?

Best regards,

			Krzysztof Olędzki




More information about the Quagga-dev mailing list