[OOR-Users] Segmentation Fault
José Miguel Guzmán
jmguzman at whitestack.com
Wed Feb 15 07:53:10 CET 2017
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
>> <jmguzman at whitestack.com <mailto:jmguzman at 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 at 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 at entry=0xbefff7a4) at iface_list.c:354
>> #1 0x00021660 in tun_control_dp_get_output_ctrl_sock (data=0x68cb0,
>> udp_conn=udp_conn at 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.lists at gmail.com <mailto:fcoras.lists at gmail.com>>) escribió:
>>
>> Hi,
>>
>> Did you try: handle SIG35 noprint nostop?
>>
>> Florin
>>
>>> On Feb 14, 2017, at 10:00 PM, José Miguel Guzmán
>>> <jmguzman at whitestack.com <mailto:jmguzman at 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.jakab at gmail.com <mailto:lorand.jakab at gmail.com>>) escribió:
>>>
>>> On Wed, Feb 15, 2017 at 4:47 AM, José Miguel
>>> Guzmán<jmguzman at whitestack.com
>>> <mailto:jmguzman at 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>
>>>
>>> jmguzman at whitestack.com <mailto:jmguzman at whitestack.com>
>>>
>>> jmguzmanc
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at openoverlayrouter.org <mailto:Users at 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 <tel:+16502482490>
>> +56 (9) 9064-2780 <tel:+56990642780>
>>
>> jmguzman at whitestack.com <mailto:jmguzman at 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>
jmguzman at whitestack.com <mailto:jmguzman at whitestack.com>
jmguzmanc <skype:jmguzmanc>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openoverlayrouter.org/pipermail/users/attachments/20170215/6d9cea38/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: whitestack_signature.png
Type: image/png
Size: 11505 bytes
Desc: not available
URL: <http://mail.openoverlayrouter.org/pipermail/users/attachments/20170215/6d9cea38/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: phone-icon.png
Type: image/png
Size: 484 bytes
Desc: not available
URL: <http://mail.openoverlayrouter.org/pipermail/users/attachments/20170215/6d9cea38/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: email-icon.png
Type: image/png
Size: 402 bytes
Desc: not available
URL: <http://mail.openoverlayrouter.org/pipermail/users/attachments/20170215/6d9cea38/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: skype-icon.png
Type: image/png
Size: 732 bytes
Desc: not available
URL: <http://mail.openoverlayrouter.org/pipermail/users/attachments/20170215/6d9cea38/attachment-0007.png>
More information about the Users
mailing list