Ah, so my assumption was wrong. I’ll let Albert provide more details then!
Florin > On Feb 14, 2017, at 10:54 PM, José Miguel Guzmán <jmguz...@whitestack.com> > wrote: > > 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 <mailto: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 <http://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 > <http://192.168.1.0/24>) in the database. > [2017/2/15 2:54:7] DEBUG: Balancing locator vector for 0.0.0.0/32 > <http://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 >>> <mailto: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 >>> <mailto: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 >>>> <mailto: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 >>>> <mailto:lorand.ja...@gmail.com>>) escribió: >>>> On Wed, Feb 15, 2017 at 4:47 AM, José Miguel Guzmán >>>> <jmguz...@whitestack.com <mailto: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 <tel:+16502482490> >>>> +56 (9) 9064-2780 <tel:+56990642780> >>>> >>>> jmguz...@whitestack.com <mailto:jmguz...@whitestack.com> >>>> >>>> jmguzmanc <> >>>> _______________________________________________ >>>> Users mailing list >>>> Users@openoverlayrouter.org <mailto:Users@openoverlayrouter.org> >>>> http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users >>>> <http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users> >>> -- >>> >>> >>> José Miguel Guzmán >>> Senior Network Consultant >>> Latin America & Caribbean >>> >>> +1 (650) 248-2490 <tel:+16502482490> >>> +56 (9) 9064-2780 <tel:+56990642780> >>> >>> jmguz...@whitestack.com <mailto:jmguz...@whitestack.com> >>> >>> jmguzmanc <> > > -- > > > José Miguel Guzmán > Senior Network Consultant > Latin America & Caribbean > > +1 (650) 248-2490 <tel:+16502482490> > +56 (9) 9064-2780 <tel:+56990642780> > > jmguz...@whitestack.com <mailto:jmguz...@whitestack.com> > > jmguzmanc <> > -- > > José Miguel Guzmán > Senior Network Consultant > Latin America & Caribbean > +1 (650) 248-2490 <tel:+16502482490> > +56 (9) 9064-2780 <tel:+56990642780> > jmguz...@whitestack.com <mailto:jmguz...@whitestack.com> > jmguzmanc > <><whitestack_signature.png><email-icon.png><phone-icon.png><skype-icon.png><skype-icon.png>
_______________________________________________ Users mailing list Users@openoverlayrouter.org http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users
