shemminger at vyatta
Jan 12, 2010, 10:56 AM
Post #2 of 2
(669 views)
Permalink
|
|
Re: [PATCH] bgpd: crash when configuring allowas-in with shutdown
[In reply to]
|
|
On Fri, 20 Nov 2009 11:10:52 -0800 (PST)
Michael Larson <mike [at] vyatta> wrote:
> Here's a patch for a crash when configuring allowas-in and shutdown for bgp:
>
> DUT1(config-router)# neighbor 192.168.74.160 shutdown
> DUT1(config-router)# neighbor 192.168.74.160 allowas-in 2
> Warning: closing connection to bgpd because of an I/O error!
>
> To reproduce a peering session must be established first.
>
> The stack trace is:
>
> #0 0xb7edd0ca in funcname_thread_add_write (m=0x86cc058, func=0x8097c6d <bgp_write>, arg=0x884b118, fd=-1, funcname=0x80e3783 "(bgp_write)") at thread.c:626
> #1 0x08098bc6 in bgp_route_refresh_send (peer=0x884b118, afi=1, safi=1 '\001', orf_type=0 '\0', when_to_refresh=0 '\0', remove=0) at bgp_packet.c:1043
> #2 0x08063e1b in peer_change_action (peer=0x884b118, afi=1, safi=1 '\001', type=peer_change_reset_in) at bgpd.c:2150
> #3 0x080665f0 in peer_allowas_in_set (peer=0x884b118, afi=1, safi=1 '\001', allow_num=2) at bgpd.c:3198
> #4 0x080af996 in neighbor_allowas_in (self=0x81115e0, vty=0x8855db0, argc=2, argv=0xbfcdcf68) at bgp_vty.c:3910
> #5 0xb7ed671b in cmd_execute_command_real (vline=0x8855d60, vty=0x8855db0, cmd=0x0) at command.c:2119
> #6 0xb7ed6834 in cmd_execute_command (vline=0x8855d60, vty=0x8855db0, cmd=0x0, vtysh=0) at command.c:2153
> #7 0xb7ecdd61 in vty_command (vty=0x8855db0, buf=0x8856340 "neighbor 192.168.74.160 allowas-in 2") at vty.c:419
> #8 0xb7ecf9bc in vty_execute (vty=0x8855db0) at vty.c:1281
> #9 0xb7ed1129 in vtysh_read (thread=0xbfcdd4a4) at vty.c:2093
> #10 0xb7ede009 in thread_call (thread=0xbfcdd4a4) at thread.c:1051
> #11 0x0805eda0 in main (argc=7, argv=0xbfcdd5d4) at bgp_main.c:344
>
>
> And a proposed patch (which has been tested):
>
> *** bgpd/bgpd.c 2009-11-19 14:39:15.000000000 -0800
> --- bgpd/bgpd.c_fix 2009-11-19 14:39:05.000000000 -0800
> ***************
> *** 2140,2145 ****
> --- 2140,2149 ----
> if (CHECK_FLAG (peer->sflags, PEER_STATUS_GROUP))
> return;
>
> + if (peer->fd < 0)
> + return;
> +
> if (type == peer_change_reset)
> bgp_notify_send (peer, BGP_NOTIFY_CEASE,
> BGP_NOTIFY_CEASE_CONFIG_CHANGE);
>
>
>
> The peer->fd value is -1. The peer->fd check could be pushed down a level to funcname_thread_add_write, but erred on the side of caution and kept this in peer_change_action().
>
There are also cases where peer connection is still pending (non-blocking connect),
so it should check for peer->state rather than peer->fd
--
_______________________________________________
Quagga-dev mailing list
Quagga-dev [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-dev
|
