Just if it helps
(gdb) print iface_it
$1 = (glist_entry_t *) 0x0
(gdb) print interface_list
$2 = (glist_t *) 0x202c3120
El mié., 15 feb. 2017 a las 3:53, José Miguel Guzmán (<
jmguz...@whitestack.com>) escribió:
> Hi
>
> It parsed the config file, that is in /etc/config/oor, I could see in the
> log lines like
>
> [2017/2/15 2:54:7] WARNING: Rights: Effective [4294967295] Permitted
> [4294967295]
> [2017/2/15 2:54:7] INFO: Building address to interface hash table
> [2017/2/15 2:54:7] INFO: Control created!
> [2017/2/15 2:54:7] DEBUG: Creating map cache and local mapping database
> [2017/2/15 2:54:7] DEBUG: Finished Constructing xTR
> [2017/2/15 2:54:7] INFO: Device working in mode xTR registering with
> control
> [2017/2/15 2:54:7] DEBUG: bind_socket: Binded socket 5 to source address
> 192.168.123.90 and port 0 with afi 2
> [2017/2/15 2:54:7] DEBUG: add_rule: Add rule -> Send packets with source
> address 192.168.123.90 and destination address _NULL_ to the table 3 with
> priority 3.
> [2017/2/15 2:54:7] DEBUG: RLOC Probing Interval: 30
> [2017/2/15 2:54:7] DEBUG: Added 192.168.200.100 to map-resolver list
> [2017/2/15 2:54:7] DEBUG: Added 192.168.200.100 to map-server list
> [2017/2/15 2:54:7] DEBUG: Balancing locator vector for (IID 13000/32, EID
> 192.168.1.0/24):
> [2017/2/15 2:54:7] DEBUG: IPv4 locators vector (1 locators):
> 192.168.123.90
> [2017/2/15 2:54:7] DEBUG: IPv6 locators vector (0 locators):
> [2017/2/15 2:54:7] DEBUG: IPv4 & IPv6 locators vector (0 locators):
> [2017/2/15 2:54:7] DEBUG: Added EID prefix (IID 13000/32, EID
> 192.168.1.0/24) in the database.
> [2017/2/15 2:54:7] DEBUG: Balancing locator vector for 0.0.0.0/32:
> [2017/2/15 2:54:7] DEBUG: IPv4 locators vector (0 locators):
> [2017/2/15 2:54:7] DEBUG: IPv6 locators vector (0 locators):
> [2017/2/15 2:54:7] DEBUG: IPv4 & IPv6 locators vector (0 locators):
> [2017/2/15 2:54:8] DEBUG: TUN/TAP mtu set to 1440
> [2017/2/15 2:54:8] DEBUG: TUN interface UP.
> [2017/2/15 2:54:8] DEBUG: add_route: added route to the system: src addr:
> -, dst prefix:-, gw: -, table: 100
> [2017/2/15 2:54:8] DEBUG: add_route: added route to the system: src addr:
> -, dst prefix:-, gw: -, table: 100
> [2017/2/15 2:54:8] DEBUG: bind_socket: Binded socket 8 to source address
> _NULL_ and port 4341 with afi 2
> [2017/2/15 2:54:8] DEBUG: bind_socket: Binded socket 10 to source address
> _NULL_ and port 4341 with afi 10
>
> Actually, oor ran for about 10 mins, before dying
>
> I am using it as a xTR, and there is no interface config item (although it
> is required for the MS and RTR modes)
>
> Thanks for your help (and your comment about gdb.. It is a very exciting
> utility)
>
>
>
>
>
>
>
> El 15/02/2017 a las 3:36 AM, Florin Coras escribió:
>
> I’d say you’re doing pretty well for a first time gdb user ;-)
>
> I’m guessing: p interface_list returns 0, so it looks like OOR has no
> interfaces configured. I’m guessing it started without parsing the config
> file. Try something like:
>
> sudo gdb --args $binary -f $config_file
>
> Cheers,
> Florin
>
> On Feb 14, 2017, at 10:16 PM, José Miguel Guzmán <jmguz...@whitestack.com>
> wrote:
>
> Great, I didn´t know about how to hable SIG35 (first time using gdb
>
> I saw several logs like these
> [2017/2/15 3:13:3] WARNING: write signal 35: Bad file descriptor
> [2017/2/15 3:13:4] WARNING: write signal 35: Bad file descriptor
> [2017/2/15 3:13:5] WARNING: write signal 35: Bad file descriptor
> [2017/2/15 3:13:6] WARNING: write signal 35: Bad file descriptor
> [2017/2/15 3:13:7] WARNING: write signal 35: Bad file descriptor
> [2017/2/15 3:13:8] WARNING: write signal 35: Bad file descriptor
> [2017/2/15 3:13:9] WARNING: write signal 35: Bad file descriptor
>
>
> And finally:
>
> [2017/2/15 3:13:30] DEBUG: Sending Map-Reply->
> flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply->
> flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply->
> flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply->
> flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply->
> flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply->
> flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply->
> flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply->
> flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply->
> flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply->
> flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply->
> flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply->
> flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply->
> flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply->
> flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply->
> flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply->
> flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply->
> flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply->
> flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply->
> flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply->
> flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,ecord-count: 1, nonce:
> 9473ea437bfbf19e
>
> *Program received signal SIGSEGV, Segmentation fault.*
> 0x0003e8a4 in get_interface_with_address (address=address@entry=0xbefff7a4)
> at iface_list.c:354
> 354 glist_for_each_entry(iface_it,interface_list){
> (gdb)
> (gdb)
> (gdb)
> (gdb)
> (gdb)
> (gdb) bt
> #0 0x0003e8a4 in get_interface_with_address
> (address=address@entry=0xbefff7a4)
> at iface_list.c:354
> #1 0x00021660 in tun_control_dp_get_output_ctrl_sock (data=0x68cb0,
> udp_conn=udp_conn@entry=0xbefff7a4) at
> control/control-data-plane/tun/cdp_tun.c:411
> #2 0x00021784 in tun_control_dp_send_msg (ctrl=<optimized out>,
> buff=0xb6e01a90, udp_conn=0xbefff7a4) at
> control/control-data-plane/tun/cdp_tun.c:191
> #3 0x0001ddf0 in tr_recv_map_request (uc=0xbefff7a4, buf=<optimized out>,
> xtr=0xb6de8150) at control/lisp_xtr.c:467
> #4 xtr_recv_msg (dev=0xb6de8150, msg=<optimized out>, uc=0xbefff7a4) at
> control/lisp_xtr.c:2127
> #5 0x00021228 in tun_control_dp_recv_msg (sl=<optimized out>) at
> control/control-data-plane/tun/cdp_tun.c:171
> #6 0x0003a40c in sock_process_fd (lst=0xb6de8070, fdset=0xb6de8080) at
> lib/sockets.c:245
> #7 sockmstr_process_all (m=0xb6de8070) at lib/sockets.c:271
> #8 0x000123ec in main (argc=<optimized out>, argv=<optimized out>) at
> oor.c:503
>
> I will keep gdb console open, in case you need something else.
>
>
> El mié., 15 feb. 2017 a las 3:09, Florin Coras (<fcoras.li...@gmail.com>)
> escribió:
>
> Hi,
>
> Did you try: handle SIG35 noprint nostop?
>
> Florin
>
> On Feb 14, 2017, at 10:00 PM, José Miguel Guzmán <jmguz...@whitestack.com>
> wrote:
>
> I have been trying to run it under gdb, but I am not sure if I am doing it
> correctly
>
> When running in gdb, it fails immediately (not the same when running w/o
> gdb)
>
> With gdb:
> *# rm /var/run/oor.pid; gdb --directory /root/oor-1.1.1/oor /usr/sbin/oor*
>
> [2017/2/15 2:58:55] WARNING: No Proxy-ETR defined. Packets to non-LISP
> destinations will be forwarded natively (no LISP encapsulation). This may
> prevent mobility in some scenarios.
>
> Program received signal SIG35, Real-time event 35.
> 0xb6fd41a4 in __clone () from /lib/ld-musl-armhf.so.1
> (gdb) bt full
> #0 0xb6fd41a4 in __clone () from /lib/ld-musl-armhf.so.1
> No symbol table info available.
> #1 0xb6fd4ec8 in ?? () from /lib/ld-musl-armhf.so.1
> No symbol table info available.
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> I am not sure if this is what you need.
>
>
> El mié., 15 feb. 2017 a las 2:37, Lori Jakab (<lorand.ja...@gmail.com>)
> escribió:
>
> On Wed, Feb 15, 2017 at 4:47 AM, José Miguel Guzmán <
> jmguz...@whitestack.com> wrote:
>
> Hi
>
> I think I understand the configuration of OOR much better now, but I
> realized that OOR is crashing (about every 30m)
>
>
> [...]
>
>
>
> What kind of information would be useful to collect, to be able to
> troubleshoot?
>
>
> Is it possible to start OOR under gdb on OpenWrt? In that case, when the
> segmentation fault occurs you can get a backtrace, which would show the
> call graph causing the crash.
>
> -Lori
>
> --
>
>
> *José Miguel Guzmán *Senior Network Consultant
> Latin America & Caribbean
>
> +1 (650) 248-2490 <+16502482490>
> +56 (9) 9064-2780 <+56990642780>
>
> jmguz...@whitestack.com
>
> jmguzmanc
>
> _______________________________________________
> Users mailing list
> Users@openoverlayrouter.org
> http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users
>
>
> --
>
>
> *José Miguel Guzmán *Senior Network Consultant
> Latin America & Caribbean
>
> +1 (650) 248-2490 <+16502482490>
> +56 (9) 9064-2780 <+56990642780>
>
> jmguz...@whitestack.com
>
> jmguzmanc
>
>
>
> --
>
>
> *José Miguel Guzmán * Senior Network Consultant
> Latin America & Caribbean
>
> +1 (650) 248-2490 <+16502482490>
> +56 (9) 9064-2780 <+56990642780>
>
> jmguz...@whitestack.com
>
> jmguzmanc
>
--
*José Miguel Guzmán*Senior Network Consultant
Latin America & Caribbean
+1 (650) 248-2490 <+16502482490>
+56 (9) 9064-2780 <+56990642780>
jmguz...@whitestack.com
jmguzmanc
_______________________________________________
Users mailing list
Users@openoverlayrouter.org
http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users
