It seems that the udpserver app is trying to read on a session that vcl hasn’t yet marked as open. Are you by chance calling read on a listen session (i.e., before accept returns?). As previously mentioned on the list, the session layer does not support connectionless transports so protocols like udp still need to accept connections and only afterwards read from the fifos. I guess you followed that approach for tcp and that’s why it worked. Either way, we’re aware of the issue and we’ll be looking into it. For the time being, you could just replicate the tcp server logic for the udp server.
Regards, Florin > On Mar 29, 2018, at 3:47 PM, satish karunanithi <satish.f...@gmail.com> wrote: > > Hi Florin, > > I get the below error reported in VPP when we start the app. > > vpp# 0: vl_mem_send_client_keepalive_w_reg:539: REAPER: binary API client > 'ldp-2673-app' died > 0: svm_client_scan_this_region_nolock:1247: /vpe-api: cleanup ghost pid 2673 > 0: svm_client_scan_this_region_nolock:1247: /vpe-api: cleanup ghost pid 2673 > > > > When i tried to enable VCL_DEBUG to check the issue, VCL library crashing. I > think there is some issue in DEBUG log code but when i disable Debug it did > not crash. > Anyways below crash is not the reason for UDP connection failure because when > i disable the VCL_DEBUG no crash but still no server APP. > > > ocket:1158: LDP<2024>: : calling vppcom_session_create(): proto 1 > (VPPCOM_PROTO_UDP), is_nonblocking 0 > vppcom_session_create:2430: VCL<2024>: sid 0 > socket:1200: LDP<2024>: : returning fd 512 (0x200) > bind:1317: LDP<2024>: fd 512 (0x200): calling vppcom_session_bind(): sid 0 > (0x0), addr 0x7fffffffdeb0, len 16 > vppcom_session_bind:2632: VCL<2024>: sid 0: binding to local IPv4 address > 172.28.128.3 port 7891, proto UDP > bind:1352: LDP<2024>: fd 512 (0x200): returning 0 (0x0) > > Thread 1 "udpserver" received signal SIGSEGV, Segmentation fault. > strlen () at ../sysdeps/x86_64/strlen.S:106 > 106 ../sysdeps/x86_64/strlen.S: No such file or directory. > (gdb) bt > #0 strlen () at ../sysdeps/x86_64/strlen.S:106 > #1 0x00007ffff7ab425b in do_percent (va=0x7fffffffdc58, fmt=<optimized out>, > _s=<synthetic pointer>) at /vpp/build-data/../src/vppinfra/format.c:332 > #2 va_format (s=0x7fffe307b1b4 "vppcom_session_read_internal:3117: > VCL<2024>: vpp handle 0x", 'f' <repeats 16 times>, ", sid 0: ", > fmt=fmt@entry=0x7ffff7ba2580 "VCL<%d>: vpp handle 0x%llx, sid %u: %s > session is not open! state 0x%x (%s), returning %d (%s)", > va=va@entry=0x7fffffffdc58) > at /vpp/build-data/../src/vppinfra/format.c:404 > #3 0x00007ffff7aaed31 in _clib_error (how_to_die=how_to_die@entry=4, > function_name=function_name@entry=0x7ffff7b9fe70 <__FUNCTION__.63886> > "vppcom_session_read_internal", > line_number=line_number@entry=3117, fmt=fmt@entry=0x7ffff7ba2580 > "VCL<%d>: vpp handle 0x%llx, sid %u: %s session is not open! state 0x%x (%s), > returning %d (%s)") > at /vpp/build-data/../src/vppinfra/error.c:127 > #4 0x00007ffff7a97f99 in vppcom_session_read_internal (peek=0 '\000', > n=1024, buf=0x7fffffffdf40, session_index=0) at > /vpp/build-data/../src/vcl/vppcom.c:3113 > #5 vppcom_session_read (session_index=session_index@entry=0, > buf=buf@entry=0x7fffffffdf40, n=n@entry=1024) at > /vpp/build-data/../src/vcl/vppcom.c:3185 > #6 0x00007ffff7a9f1e3 in vppcom_session_recvfrom > (session_index=session_index@entry=0, buffer=buffer@entry=0x7fffffffdf40, > buflen=buflen@entry=1024, flags=flags@entry=0, > ep=ep@entry=0x7fffffffde10) at /vpp/build-data/../src/vcl/vppcom.c:5602 > #7 0x00007ffff7a7fc00 in recvfrom (fd=512, buf=0x7fffffffdf40, n=1024, > flags=0, addr=0x7fffffffdec0, addr_len=0x7fffffffdea0) at > /vpp/build-data/../src/vcl/ldp.c:2121 > #8 0x00000000004009ab in main () at udpserver.c:36 > > > > > > > > On Thu, Mar 29, 2018 at 6:00 PM, Florin Coras <fcoras.li...@gmail.com > <mailto:fcoras.li...@gmail.com>> wrote: > Could you retry udp and see if it reports an error? > > Thanks, > Florin > >> On Mar 29, 2018, at 3:25 PM, Satish <satish.f...@gmail.com >> <mailto:satish.f...@gmail.com>> wrote: >> >> Hi Florin, >> >> Looks like server is not successfully UP when we use UDP APP. But on TCP it >> is successful. Below is the app server details. >> >> UDP: >> vpp# show app server >> Connection App >> vpp# >> >> >> TCP: >> vpp# show app server >> Connection App >> [#0][T] 172.28.128.3:7891->0.0.0.0:0 <http://0.0.0.0:0/> ldp-2519-app >> >> >> Thanks, >> Satish. >> >> >> On Thu, Mar 29, 2018 at 5:49 PM, Florin Coras <fcoras.li...@gmail.com >> <mailto:fcoras.li...@gmail.com>> wrote: >> Hi Satish, >> >> What does “show app server” report? >> >> Thanks, >> Florin >> >> >> >>> On Mar 29, 2018, at 3:14 PM, Satish <satish.f...@gmail.com >>> <mailto:satish.f...@gmail.com>> wrote: >>> >>> Hi, >>> >>> I am trying to use Host stack of VPP for UDP connection through VCL >>> library. >>> Server application listen on port 7891. >>> >>> But when i try to connect to this server, the connection is not successful >>> saying (no listener). >>> >>> But the same app when i change to use TCP it works fine. >>> >>> Below is the trace info and VPP version information. Could some one please >>> let me know what is >>> the issue in this? Does any one tried with VCL for UDP before and succeeded? >>> >>> Thanks & Regards, >>> Satish. >>> >>> >>> vpp# show trace >>> ------------------- Start of thread 0 vpp_main ------------------- >>> Packet 1 >>> >>> 00:52:47:772356: dpdk-input >>> GigabitEthernet0/8/0 rx queue 0 >>> buffer 0x3333: current data 14, length 46, free-list 0, clone-count 0, >>> totlen-nifb 0, trace 0x0 >>> ext-hdr-valid >>> l4-cksum-computed l4-cksum-correct l2-hdr-offset 0 >>> l3-hdr-offset 14 >>> PKT MBUF: port 0, nb_segs 1, pkt_len 60 >>> buf_len 2176, data_len 60, ol_flags 0x0, data_off 128, phys_addr >>> 0x1f8ccd40 >>> packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 >>> IP4: 08:00:27:02:dd:ad -> 08:00:27:f9:67:0c >>> UDP: 172.28.128.5 -> 172.28.128.3 >>> tos 0x00, ttl 64, length 37, checksum 0x38e9 >>> fragment id 0xa99d, flags DONT_FRAGMENT >>> UDP: 37797 -> 7891 >>> length 17, checksum 0x63da >>> 00:52:47:772392: ip4-input >>> UDP: 172.28.128.5 -> 172.28.128.3 >>> tos 0x00, ttl 64, length 37, checksum 0x38e9 >>> fragment id 0xa99d, flags DONT_FRAGMENT >>> UDP: 37797 -> 7891 >>> length 17, checksum 0x63da >>> 00:52:47:772396: ip4-lookup >>> fib 0 dpo-idx 7 flow hash: 0x00000000 >>> UDP: 172.28.128.5 -> 172.28.128.3 >>> tos 0x00, ttl 64, length 37, checksum 0x38e9 >>> fragment id 0xa99d, flags DONT_FRAGMENT >>> UDP: 37797 -> 7891 >>> length 17, checksum 0x63da >>> 00:52:47:772398: ip4-local >>> UDP: 172.28.128.5 -> 172.28.128.3 >>> tos 0x00, ttl 64, length 37, checksum 0x38e9 >>> fragment id 0xa99d, flags DONT_FRAGMENT >>> UDP: 37797 -> 7891 >>> length 17, checksum 0x63da >>> 00:52:47:772401: ip4-udp-lookup >>> UDP: src-port 37797 dst-port 7891 (no listener) >>> 00:52:47:772406: ip4-icmp-error >>> UDP: 172.28.128.5 -> 172.28.128.3 >>> tos 0x00, ttl 64, length 37, checksum 0x38e9 >>> fragment id 0xa99d, flags DONT_FRAGMENT >>> UDP: 37797 -> 7891 >>> length 17, checksum 0x63da >>> >>> >>> >>> vpp# show version >>> vpp v18.04-rc0~482-gf6647e0 built by vagrant on localhost at Mon Mar 26 >>> 23:54:12 PDT 2018 >>> >>> >>> >> >> > > > > > >
