PROFINET Forum

PROFINET Forum
http://forum.profinet.com/

DCE/RPC Fragmentation Problem with Community Stack and Automated RT Tester

http://forum.profinet.com/viewtopic.php?t=1259

Page 1 of 1

DCE/RPC Fragmentation Problem with Community Stack and Automated RT Tester

Posted: 02 Dec 2025, 11:41
by paaaz
Hi everyone!
We are porting the community stack to one of our embedded Linux device by extending and adapting the Raspberry Pi example.
Now we test the device with the Automated RT tester, but unfortunately most of the tests (beyond DCP) fail at the DCE/RPC Connect Request step with this error

ART-Log:

Code: Select all

11:16:57 - Starting Testcase: IP_UDP_RPC_I&M_EPM - SCENARIO 1 (CLRPC)
11:17:17 - Initializing Power Outlet
11:17:19 - First Scenario Part 1: First Scenario: Checking of RPC, IP and UDP Part 1
11:17:39 - First Scenario Part 1: Test step 1: Prepare the DUT for the test run.
11:17:39 - First Scenario Part 1: Test step 2: Sending and validating ICMP ping.
11:17:42 - First Scenario Part 1: Test step 3: Read and validate the I&M0FilterData from the dut.
11:17:42 - First Scenario Part 1: Test step 4: Establish an IOC-AR with 'little endianess'.
11:17:43 - ERROR: DCE/RPC Layer: FragmentNmb not valid.. Requirement: 0x0001. Data: 0x0000
11:17:43 - ERROR: First Scenario Part 1: Test step 5: Failed to establish an IOC-AR with little endianess.
The reason is that the community stack sends two FACKs as answer to the fragmented connection request, because somehow it processes the received connect request packet twice (or does not clear the receive buffer?),
and the second time processing it calls clrpc_sc_send_fack() from line 1087 in clrpc_sc.c

Community-Stack Log:

Code: Select all

[2025-12-02 10:16:57.869] CHAT libpncs CLRPC_SV sid(1) scall(00000000) ptype(4294967295)
[2025-12-02 10:16:57.966] CHAT libpncs CLRPC_LOWER <<< CLRPC_REQ_LOWER DONE --- lower(accbe0c0) opc(15) rsp(1), user_id(acadb0a8)
[2025-12-02 10:16:57.966] CHAT libpncs CLRPC_SV h(0) rsp(1) lower(accbe0c0) opcode(15)
[2025-12-02 10:16:57.966] CHAT libpncs CLRPC_SV recv.ind: lower(accbe0c0) lower.sock_fd(1)  server.sock_fd(1)
[2025-12-02 10:16:57.966] NOTE libpncs CLRPC_SV <<< server_id(0) --- RECV.ind --- lower(accbe0c0)  ip_addr(c0a80019:49351)  len(1464)
[2025-12-02 10:16:57.966] NOTE_HIGH libpncs CLRPC_SV_PKT === RECV --- ip(c0a80019) port(49351)  server_boot(0)  serial(0)  fragnum(0)  drep0_1_2(0x10 0 0)
[2025-12-02 10:16:57.966] NOTE_HIGH libpncs CLRPC_SV_PKT .RECV ptype(0)  opnum(0)  len(1384)  flags(0x24:F---i-)  flags2(0)
[2025-12-02 10:16:57.966] NOTE_HIGH libpncs CLRPC_SV_PKT .RECV actuid(855ff737-cf70-11f0-91a8-a8bbcc000001)  actseq(0)
[2025-12-02 10:16:57.966] NOTE_HIGH libpncs CLRPC_SV_PKT .RECV ifuuid(dea00001-6c97-11d1-8271-00a02442df7d) vers=0x00000001
[2025-12-02 10:16:57.966] NOTE_HIGH libpncs CLRPC_SV_PKT .RECV objuid(dea00000-6c97-11d1-8271-0001004102b3)
[2025-12-02 10:16:57.966] CHAT libpncs CLRPC_SV sid(0) if_uuid(e1af8308-5d1f-11c9-91a4-08002b14a0fa) != 
[2025-12-02 10:16:57.966] CHAT libpncs CLRPC_SV pkt.if_id(dea00001-6c97-11d1-8271-00a02442df7d)
[2025-12-02 10:16:57.966] CHAT libpncs CLRPC_SV epm_lookup_server found with find_method(1) sid(1)
[2025-12-02 10:16:57.966] NOTE libpncs CLRPC_SV FORWARDING from sid(0) to sid(1)
[2025-12-02 10:16:57.966] CHAT libpncs CLRPC_SV sid(1) scall_cnt(1) max_scalls(123)
[2025-12-02 10:16:57.966] CHAT libpncs CLRPC_SV sid(1) actuid(855ff737-cf70-11f0-91a8-a8bbcc000001)
[2025-12-02 10:16:57.966] CHAT libpncs CLRPC_SV sid(1) new cid(2)(accc67c0)
[2025-12-02 10:16:57.966] CHAT libpncs CLRPC_UPPER hash(acadae98) entry(accc67f0) user_ptr(accc67c0)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_UPPER timeout(7500 msec), running(0)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) DISPATCH: busy(0) in_queue(0)  upper(00000000) lower(accbe0c0) oneshot(0) send(00000000)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) REQUEST: state(1) seq:pkt(0)sc(4294967295) op(0) sem(1) fragnum:pkt(0)sc(0) flags(36) len(1384)
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV cid(2) curr-state(1) new-state(CST_INIT)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_UPPER timeout(7500 msec), running(1)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) curr-state(1) new-state(CST_RECV) seq(4294967295) fragnum(0)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV  pkt.opnum(0).seq(0).sem(1).fragnum(0).flags(0x24).len(1384)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV sid(1) upper(0xaccc1420)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV pkt.len(1384)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV alloc_size(66432)
[2025-12-02 10:16:57.967] UNEXP libpncs CLRPC_SV resize call.alloc_len(66432) to server.alloc_len(8084)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) from.ip(0xc0a80019) from.port(49351) opnum(0) drep(0) sem(1) alloc_len(8084)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) obj_id(dea00000-6c97-11d1-8271-0001004102b3)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_UPPER timeout(7500 msec), running(1)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) send.ptype = PT_FACK  fack_serial(0)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) state(2)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV sid(1) scall(accc67c0) ptype(9)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV dequeue cid(2)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) DISPATCH: busy(1) in_queue(1)  upper(00000000) lower(00000000) oneshot(0) send(accc3fc0)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) => busy.queueing
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV copy pktlen(1384) to offset(0) 
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV recv.provide: lower(accbe0c0) lower.sock_fd(1)  server.sock_fd(2)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV clrpc_sc_dispatch:cid(2) sending(1) loop again: upper(00000000) lower(00000000) oneshot(0) send(accc3fc0)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) SEND_PREPARE: state(2) ptype(9)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV window_size(1) serial_num(0)
[2025-12-02 10:16:57.967] NOTE libpncs CLRPC_SV >>> server_id(1) --- SEND.req --- lower(accc3fc0) ip_addr(c0a80019:49351) len(100) ptype(9)
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT === SEND --- ip(c0a80019) port(49351)  server_boot(2)  serial(0)  fragnum(0)  drep0_1_2(0x10 0 0)
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT .SEND ptype(9)  opnum(0)  len(20)  flags(0:------)  flags2(0)
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT .SEND actuid(855ff737-cf70-11f0-91a8-a8bbcc000001)  actseq(0)
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT .SEND ifuuid(dea00001-6c97-11d1-8271-00a02442df7d) vers=0x00000001
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT .SEND objuid(dea00000-6c97-11d1-8271-0001004102b3)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) state(2) next_state(2)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV clrpc_sc_dispatch:cid(2) sending(0) done.
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_LOWER <<< CLRPC_REQ_LOWER DONE --- lower(accbe750) opc(15) rsp(1), user_id(acadb0a8)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV h(0) rsp(1) lower(accbe750) opcode(15)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV recv.ind: lower(accbe750) lower.sock_fd(1)  server.sock_fd(1)
[2025-12-02 10:16:57.967] NOTE libpncs CLRPC_SV <<< server_id(0) --- RECV.ind --- lower(accbe750)  ip_addr(c0a80019:49351)  len(1464)
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT === RECV --- ip(c0a80019) port(49351)  server_boot(0)  serial(0)  fragnum(0)  drep0_1_2(0x10 0 0)
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT .RECV ptype(0)  opnum(0)  len(1384)  flags(0x24:F---i-)  flags2(0)
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT .RECV actuid(855ff737-cf70-11f0-91a8-a8bbcc000001)  actseq(0)
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT .RECV ifuuid(dea00001-6c97-11d1-8271-00a02442df7d) vers=0x00000001
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT .RECV objuid(dea00000-6c97-11d1-8271-0001004102b3)
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT .RECV ifuuid scall(dea00001-6c97-11d1-8271-00a02442df7d) 
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) DISPATCH: busy(0) in_queue(0)  upper(00000000) lower(accbe750) oneshot(0) send(00000000)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) REQUEST: state(2) seq:pkt(0)sc(0) op(0) sem(1) fragnum:pkt(0)sc(0) flags(36) len(1384)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) curr-state(2) new-state(CST_RECV) seq(0) fragnum(0)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV  pkt.opnum(0).seq(0).sem(1).fragnum(0).flags(0x24).len(1384)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_UPPER timeout(7500 msec), running(1)
[2025-12-02 10:16:57.968] UNEXP libpncs CLRPC_SV frags out of order scall.fragnr(0) + 1 != pkt.fragnr(0), drop pkt
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV cid(2) send.ptype = PT_FACK  fack_serial(0)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV cid(2) state(2)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV sid(1) scall(accc67c0) ptype(9)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV dequeue cid(2)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV cid(2) DISPATCH: busy(1) in_queue(1)  upper(00000000) lower(00000000) oneshot(0) send(accc32a0)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV cid(2) => busy.queueing
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV recv.provide: lower(accbe750) lower.sock_fd(1)  server.sock_fd(2)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV clrpc_sc_dispatch:cid(2) sending(1) loop again: upper(00000000) lower(00000000) oneshot(0) send(accc32a0)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV cid(2) SEND_PREPARE: state(2) ptype(9)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV window_size(1) serial_num(0)
[2025-12-02 10:16:57.968] NOTE libpncs CLRPC_SV >>> server_id(1) --- SEND.req --- lower(accc32a0) ip_addr(c0a80019:49351) len(100) ptype(9)
[2025-12-02 10:16:57.968] NOTE_HIGH libpncs CLRPC_SV_PKT === SEND --- ip(c0a80019) port(49351)  server_boot(2)  serial(0)  fragnum(0)  drep0_1_2(0x10 0 0)
[2025-12-02 10:16:57.968] NOTE_HIGH libpncs CLRPC_SV_PKT .SEND ptype(9)  opnum(0)  len(20)  flags(0:------)  flags2(0)
[2025-12-02 10:16:57.968] NOTE_HIGH libpncs CLRPC_SV_PKT .SEND actuid(855ff737-cf70-11f0-91a8-a8bbcc000001)  actseq(0)
[2025-12-02 10:16:57.968] NOTE_HIGH libpncs CLRPC_SV_PKT .SEND ifuuid(dea00001-6c97-11d1-8271-00a02442df7d) vers=0x00000001
[2025-12-02 10:16:57.968] NOTE_HIGH libpncs CLRPC_SV_PKT .SEND objuid(dea00000-6c97-11d1-8271-0001004102b3)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV cid(2) state(2) next_state(2)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV clrpc_sc_dispatch:cid(2) sending(0) done.
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_LOWER <<< CLRPC_REQ_LOWER DONE --- lower(accc3fc0) opc(14) rsp(1), user_id(acadb1b0)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV h(0) rsp(1) lower(accc3fc0) opcode(14)
[2025-12-02 10:16:57.968] NOTE libpncs CLRPC_SV <<< server_id(1) --- SEND.cnf --- lower(accc3fc0)  rsp(1)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV sid(1) scall(00000000) ptype(4294967295)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_LOWER <<< CLRPC_REQ_LOWER DONE --- lower(accc32a0) opc(14) rsp(1), user_id(acadb1b0)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV h(0) rsp(1) lower(accc32a0) opcode(14)
[2025-12-02 10:16:57.968] NOTE libpncs CLRPC_SV <<< server_id(1) --- SEND.cnf --- lower(accc32a0)  rsp(1)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV sid(1) scall(00000000) ptype(4294967295)
[2025-12-02 10:16:57.969] NOTE libpncs CLRPC_UPPER >>> rqb(0xacaca248) h(255) opc(5)
Is it a bug in the stack or are there any ideas how to suppress the double-processing and the sending of the second FACK packet?

Please find attached the wireshark trace, the ART tester log and the stack application log (CLRPC trace mode enabled with level CHAT)
RPC_Frag_Problem.zip
(7.26 KiB) Downloaded 479 times
Thank you very much for your help!

Re: DCE/RPC Fragmentation Problem with Community Stack and Automated RT Tester

Posted: 03 Dec 2025, 10:49
by Benjamin.C
paaaz wrote: ↑02 Dec 2025, 11:41 Hi everyone!
We are porting the community stack to one of our embedded Linux device by extending and adapting the Raspberry Pi example.
Now we test the device with the Automated RT tester, but unfortunately most of the tests (beyond DCP) fail at the DCE/RPC Connect Request step with this error

ART-Log:

Code: Select all

11:16:57 - Starting Testcase: IP_UDP_RPC_I&M_EPM - SCENARIO 1 (CLRPC)
11:17:17 - Initializing Power Outlet
11:17:19 - First Scenario Part 1: First Scenario: Checking of RPC, IP and UDP Part 1
11:17:39 - First Scenario Part 1: Test step 1: Prepare the DUT for the test run.
11:17:39 - First Scenario Part 1: Test step 2: Sending and validating ICMP ping.
11:17:42 - First Scenario Part 1: Test step 3: Read and validate the I&M0FilterData from the dut.
11:17:42 - First Scenario Part 1: Test step 4: Establish an IOC-AR with 'little endianess'.
11:17:43 - ERROR: DCE/RPC Layer: FragmentNmb not valid.. Requirement: 0x0001. Data: 0x0000
11:17:43 - ERROR: First Scenario Part 1: Test step 5: Failed to establish an IOC-AR with little endianess.
The reason is that the community stack sends two FACKs as answer to the fragmented connection request, because somehow it processes the received connect request packet twice (or does not clear the receive buffer?),
and the second time processing it calls clrpc_sc_send_fack() from line 1087 in clrpc_sc.c

Community-Stack Log:

Code: Select all

[2025-12-02 10:16:57.869] CHAT libpncs CLRPC_SV sid(1) scall(00000000) ptype(4294967295)
[2025-12-02 10:16:57.966] CHAT libpncs CLRPC_LOWER <<< CLRPC_REQ_LOWER DONE --- lower(accbe0c0) opc(15) rsp(1), user_id(acadb0a8)
[2025-12-02 10:16:57.966] CHAT libpncs CLRPC_SV h(0) rsp(1) lower(accbe0c0) opcode(15)
[2025-12-02 10:16:57.966] CHAT libpncs CLRPC_SV recv.ind: lower(accbe0c0) lower.sock_fd(1)  server.sock_fd(1)
[2025-12-02 10:16:57.966] NOTE libpncs CLRPC_SV <<< server_id(0) --- RECV.ind --- lower(accbe0c0)  ip_addr(c0a80019:49351)  len(1464)
[2025-12-02 10:16:57.966] NOTE_HIGH libpncs CLRPC_SV_PKT === RECV --- ip(c0a80019) port(49351)  server_boot(0)  serial(0)  fragnum(0)  drep0_1_2(0x10 0 0)
[2025-12-02 10:16:57.966] NOTE_HIGH libpncs CLRPC_SV_PKT .RECV ptype(0)  opnum(0)  len(1384)  flags(0x24:F---i-)  flags2(0)
[2025-12-02 10:16:57.966] NOTE_HIGH libpncs CLRPC_SV_PKT .RECV actuid(855ff737-cf70-11f0-91a8-a8bbcc000001)  actseq(0)
[2025-12-02 10:16:57.966] NOTE_HIGH libpncs CLRPC_SV_PKT .RECV ifuuid(dea00001-6c97-11d1-8271-00a02442df7d) vers=0x00000001
[2025-12-02 10:16:57.966] NOTE_HIGH libpncs CLRPC_SV_PKT .RECV objuid(dea00000-6c97-11d1-8271-0001004102b3)
[2025-12-02 10:16:57.966] CHAT libpncs CLRPC_SV sid(0) if_uuid(e1af8308-5d1f-11c9-91a4-08002b14a0fa) != 
[2025-12-02 10:16:57.966] CHAT libpncs CLRPC_SV pkt.if_id(dea00001-6c97-11d1-8271-00a02442df7d)
[2025-12-02 10:16:57.966] CHAT libpncs CLRPC_SV epm_lookup_server found with find_method(1) sid(1)
[2025-12-02 10:16:57.966] NOTE libpncs CLRPC_SV FORWARDING from sid(0) to sid(1)
[2025-12-02 10:16:57.966] CHAT libpncs CLRPC_SV sid(1) scall_cnt(1) max_scalls(123)
[2025-12-02 10:16:57.966] CHAT libpncs CLRPC_SV sid(1) actuid(855ff737-cf70-11f0-91a8-a8bbcc000001)
[2025-12-02 10:16:57.966] CHAT libpncs CLRPC_SV sid(1) new cid(2)(accc67c0)
[2025-12-02 10:16:57.966] CHAT libpncs CLRPC_UPPER hash(acadae98) entry(accc67f0) user_ptr(accc67c0)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_UPPER timeout(7500 msec), running(0)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) DISPATCH: busy(0) in_queue(0)  upper(00000000) lower(accbe0c0) oneshot(0) send(00000000)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) REQUEST: state(1) seq:pkt(0)sc(4294967295) op(0) sem(1) fragnum:pkt(0)sc(0) flags(36) len(1384)
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV cid(2) curr-state(1) new-state(CST_INIT)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_UPPER timeout(7500 msec), running(1)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) curr-state(1) new-state(CST_RECV) seq(4294967295) fragnum(0)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV  pkt.opnum(0).seq(0).sem(1).fragnum(0).flags(0x24).len(1384)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV sid(1) upper(0xaccc1420)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV pkt.len(1384)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV alloc_size(66432)
[2025-12-02 10:16:57.967] UNEXP libpncs CLRPC_SV resize call.alloc_len(66432) to server.alloc_len(8084)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) from.ip(0xc0a80019) from.port(49351) opnum(0) drep(0) sem(1) alloc_len(8084)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) obj_id(dea00000-6c97-11d1-8271-0001004102b3)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_UPPER timeout(7500 msec), running(1)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) send.ptype = PT_FACK  fack_serial(0)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) state(2)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV sid(1) scall(accc67c0) ptype(9)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV dequeue cid(2)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) DISPATCH: busy(1) in_queue(1)  upper(00000000) lower(00000000) oneshot(0) send(accc3fc0)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) => busy.queueing
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV copy pktlen(1384) to offset(0) 
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV recv.provide: lower(accbe0c0) lower.sock_fd(1)  server.sock_fd(2)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV clrpc_sc_dispatch:cid(2) sending(1) loop again: upper(00000000) lower(00000000) oneshot(0) send(accc3fc0)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) SEND_PREPARE: state(2) ptype(9)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV window_size(1) serial_num(0)
[2025-12-02 10:16:57.967] NOTE libpncs CLRPC_SV >>> server_id(1) --- SEND.req --- lower(accc3fc0) ip_addr(c0a80019:49351) len(100) ptype(9)
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT === SEND --- ip(c0a80019) port(49351)  server_boot(2)  serial(0)  fragnum(0)  drep0_1_2(0x10 0 0)
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT .SEND ptype(9)  opnum(0)  len(20)  flags(0:------)  flags2(0)
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT .SEND actuid(855ff737-cf70-11f0-91a8-a8bbcc000001)  actseq(0)
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT .SEND ifuuid(dea00001-6c97-11d1-8271-00a02442df7d) vers=0x00000001
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT .SEND objuid(dea00000-6c97-11d1-8271-0001004102b3)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) state(2) next_state(2)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV clrpc_sc_dispatch:cid(2) sending(0) done.
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_LOWER <<< CLRPC_REQ_LOWER DONE --- lower(accbe750) opc(15) rsp(1), user_id(acadb0a8)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV h(0) rsp(1) lower(accbe750) opcode(15)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV recv.ind: lower(accbe750) lower.sock_fd(1)  server.sock_fd(1)
[2025-12-02 10:16:57.967] NOTE libpncs CLRPC_SV <<< server_id(0) --- RECV.ind --- lower(accbe750)  ip_addr(c0a80019:49351)  len(1464)
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT === RECV --- ip(c0a80019) port(49351)  server_boot(0)  serial(0)  fragnum(0)  drep0_1_2(0x10 0 0)
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT .RECV ptype(0)  opnum(0)  len(1384)  flags(0x24:F---i-)  flags2(0)
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT .RECV actuid(855ff737-cf70-11f0-91a8-a8bbcc000001)  actseq(0)
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT .RECV ifuuid(dea00001-6c97-11d1-8271-00a02442df7d) vers=0x00000001
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT .RECV objuid(dea00000-6c97-11d1-8271-0001004102b3)
[2025-12-02 10:16:57.967] NOTE_HIGH libpncs CLRPC_SV_PKT .RECV ifuuid scall(dea00001-6c97-11d1-8271-00a02442df7d) 
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) DISPATCH: busy(0) in_queue(0)  upper(00000000) lower(accbe750) oneshot(0) send(00000000)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) REQUEST: state(2) seq:pkt(0)sc(0) op(0) sem(1) fragnum:pkt(0)sc(0) flags(36) len(1384)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV cid(2) curr-state(2) new-state(CST_RECV) seq(0) fragnum(0)
[2025-12-02 10:16:57.967] CHAT libpncs CLRPC_SV  pkt.opnum(0).seq(0).sem(1).fragnum(0).flags(0x24).len(1384)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_UPPER timeout(7500 msec), running(1)
[2025-12-02 10:16:57.968] UNEXP libpncs CLRPC_SV frags out of order scall.fragnr(0) + 1 != pkt.fragnr(0), drop pkt
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV cid(2) send.ptype = PT_FACK  fack_serial(0)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV cid(2) state(2)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV sid(1) scall(accc67c0) ptype(9)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV dequeue cid(2)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV cid(2) DISPATCH: busy(1) in_queue(1)  upper(00000000) lower(00000000) oneshot(0) send(accc32a0)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV cid(2) => busy.queueing
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV recv.provide: lower(accbe750) lower.sock_fd(1)  server.sock_fd(2)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV clrpc_sc_dispatch:cid(2) sending(1) loop again: upper(00000000) lower(00000000) oneshot(0) send(accc32a0)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV cid(2) SEND_PREPARE: state(2) ptype(9)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV window_size(1) serial_num(0)
[2025-12-02 10:16:57.968] NOTE libpncs CLRPC_SV >>> server_id(1) --- SEND.req --- lower(accc32a0) ip_addr(c0a80019:49351) len(100) ptype(9)
[2025-12-02 10:16:57.968] NOTE_HIGH libpncs CLRPC_SV_PKT === SEND --- ip(c0a80019) port(49351)  server_boot(2)  serial(0)  fragnum(0)  drep0_1_2(0x10 0 0)
[2025-12-02 10:16:57.968] NOTE_HIGH libpncs CLRPC_SV_PKT .SEND ptype(9)  opnum(0)  len(20)  flags(0:------)  flags2(0)
[2025-12-02 10:16:57.968] NOTE_HIGH libpncs CLRPC_SV_PKT .SEND actuid(855ff737-cf70-11f0-91a8-a8bbcc000001)  actseq(0)
[2025-12-02 10:16:57.968] NOTE_HIGH libpncs CLRPC_SV_PKT .SEND ifuuid(dea00001-6c97-11d1-8271-00a02442df7d) vers=0x00000001
[2025-12-02 10:16:57.968] NOTE_HIGH libpncs CLRPC_SV_PKT .SEND objuid(dea00000-6c97-11d1-8271-0001004102b3)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV cid(2) state(2) next_state(2)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV clrpc_sc_dispatch:cid(2) sending(0) done.
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_LOWER <<< CLRPC_REQ_LOWER DONE --- lower(accc3fc0) opc(14) rsp(1), user_id(acadb1b0)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV h(0) rsp(1) lower(accc3fc0) opcode(14)
[2025-12-02 10:16:57.968] NOTE libpncs CLRPC_SV <<< server_id(1) --- SEND.cnf --- lower(accc3fc0)  rsp(1)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV sid(1) scall(00000000) ptype(4294967295)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_LOWER <<< CLRPC_REQ_LOWER DONE --- lower(accc32a0) opc(14) rsp(1), user_id(acadb1b0)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV h(0) rsp(1) lower(accc32a0) opcode(14)
[2025-12-02 10:16:57.968] NOTE libpncs CLRPC_SV <<< server_id(1) --- SEND.cnf --- lower(accc32a0)  rsp(1)
[2025-12-02 10:16:57.968] CHAT libpncs CLRPC_SV sid(1) scall(00000000) ptype(4294967295)
[2025-12-02 10:16:57.969] NOTE libpncs CLRPC_UPPER >>> rqb(0xacaca248) h(255) opc(5)
Is it a bug in the stack or are there any ideas how to suppress the double-processing and the sending of the second FACK packet?

Please find attached the wireshark trace, the ART tester log and the stack application log (CLRPC trace mode enabled with level CHAT) RPC_Frag_Problem.zip

Thank you very much for your help!

Hi,

I am looking into this issue. My first guess could be that it could be related to some network-filters.
But I will come back with an answer as soon as I know more.

BR
Benni

Re: DCE/RPC Fragmentation Problem with Community Stack and Automated RT Tester

Posted: 03 Dec 2025, 12:16
by paaaz
Benjamin.C wrote: ↑03 Dec 2025, 10:49 Hi,

I am looking into this issue. My first guess could be that it could be related to some network-filters.
But I will come back with an answer as soon as I know more.

BR
Benni
Hi Benni,
Thank you for your investigation! In the meantime I found out, that this behaviour only occurs on the embedded device (Kernel 5.15.6), but not on my Desktop Linux (Kernel 6.17.9).

I further discovered that in the failing device case the Connect-Request UDP datagram is read 2 times from the socket for whatever reason -> the function recvfrom in line 430 of sock_low_anyip.c does not return with EWOULDBLOCK the second time reading in comparison to the Desktop version, which leads to enqueing of two SOCK_OPC_UDP_RECEIVE RQBs instead of 1.... see the two SOCK_UPPER lines in this log-excerpt:

Code: Select all

[2025-12-03 11:01:42.825] CHAT libpncs SOCK_PROTOCOL socket_fd(0x11) in read mask
[2025-12-03 11:01:42.825] NOTE libpncs SOCK_UPPER <<< rqb(0xaccd22d0) h(0) opc(15) rsp(1) f-h(0)
[2025-12-03 11:01:42.825] NOTE libpncs SOCK_UPPER <<< rqb(0xaccd2960) h(0) opc(15) rsp(1) f-h(0)
[2025-12-03 11:01:42.825] CHAT libpncs CLRPC_LOWER <<< CLRPC_REQ_LOWER DONE --- lower(accd22d0) opc(15) rsp(1), user_id(acaf00a8)
[2025-12-03 11:01:42.825] CHAT libpncs CLRPC_SV h(0) rsp(1) lower(accd22d0) opcode(15)
Unfortunately upgrading the kernel version is not an option for now. Do you have any further ideas?
BR Patrick

Re: DCE/RPC Fragmentation Problem with Community Stack and Automated RT Tester

Posted: 03 Dec 2025, 14:45
by Blameless
paaaz wrote: ↑03 Dec 2025, 12:16
Benjamin.C wrote: ↑03 Dec 2025, 10:49 Hi,

I am looking into this issue. My first guess could be that it could be related to some network-filters.
But I will come back with an answer as soon as I know more.

BR
Benni
Hi Benni,
Thank you for your investigation! In the meantime I found out, that this behaviour only occurs on the embedded device (Kernel 5.15.6), but not on my Desktop Linux (Kernel 6.17.9).

I further discovered that in the failing device case the Connect-Request UDP datagram is read 2 times from the socket for whatever reason -> the function recvfrom in line 430 of sock_low_anyip.c does not return with EWOULDBLOCK the second time reading in comparison to the Desktop version, which leads to enqueing of two SOCK_OPC_UDP_RECEIVE RQBs instead of 1.... see the two SOCK_UPPER lines in this log-excerpt:

Code: Select all

[2025-12-03 11:01:42.825] CHAT libpncs SOCK_PROTOCOL socket_fd(0x11) in read mask
[2025-12-03 11:01:42.825] NOTE libpncs SOCK_UPPER <<< rqb(0xaccd22d0) h(0) opc(15) rsp(1) f-h(0)
[2025-12-03 11:01:42.825] NOTE libpncs SOCK_UPPER <<< rqb(0xaccd2960) h(0) opc(15) rsp(1) f-h(0)
[2025-12-03 11:01:42.825] CHAT libpncs CLRPC_LOWER <<< CLRPC_REQ_LOWER DONE --- lower(accd22d0) opc(15) rsp(1), user_id(acaf00a8)
[2025-12-03 11:01:42.825] CHAT libpncs CLRPC_SV h(0) rsp(1) lower(accd22d0) opcode(15)
Unfortunately upgrading the kernel version is not an option for now. Do you have any further ideas?
BR Patrick
Hi Patrick,
do you use af_packet or an own adaption to ethernet controller?
if using linux netdev driver, is GRO disabled?

Best,
Marcel

Re: DCE/RPC Fragmentation Problem with Community Stack and Automated RT Tester

Posted: 04 Dec 2025, 09:18
by paaaz
Blameless wrote: ↑03 Dec 2025, 14:45
paaaz wrote: ↑03 Dec 2025, 12:16
Benjamin.C wrote: ↑03 Dec 2025, 10:49 Hi,

I am looking into this issue. My first guess could be that it could be related to some network-filters.
But I will come back with an answer as soon as I know more.

BR
Benni
Hi Benni,
Thank you for your investigation! In the meantime I found out, that this behaviour only occurs on the embedded device (Kernel 5.15.6), but not on my Desktop Linux (Kernel 6.17.9).

I further discovered that in the failing device case the Connect-Request UDP datagram is read 2 times from the socket for whatever reason -> the function recvfrom in line 430 of sock_low_anyip.c does not return with EWOULDBLOCK the second time reading in comparison to the Desktop version, which leads to enqueing of two SOCK_OPC_UDP_RECEIVE RQBs instead of 1.... see the two SOCK_UPPER lines in this log-excerpt:

Code: Select all

[2025-12-03 11:01:42.825] CHAT libpncs SOCK_PROTOCOL socket_fd(0x11) in read mask
[2025-12-03 11:01:42.825] NOTE libpncs SOCK_UPPER <<< rqb(0xaccd22d0) h(0) opc(15) rsp(1) f-h(0)
[2025-12-03 11:01:42.825] NOTE libpncs SOCK_UPPER <<< rqb(0xaccd2960) h(0) opc(15) rsp(1) f-h(0)
[2025-12-03 11:01:42.825] CHAT libpncs CLRPC_LOWER <<< CLRPC_REQ_LOWER DONE --- lower(accd22d0) opc(15) rsp(1), user_id(acaf00a8)
[2025-12-03 11:01:42.825] CHAT libpncs CLRPC_SV h(0) rsp(1) lower(accd22d0) opcode(15)
Unfortunately upgrading the kernel version is not an option for now. Do you have any further ideas?
BR Patrick
Hi Patrick,
do you use af_packet or an own adaption to ethernet controller?
if using linux netdev driver, is GRO disabled?

Best,
Marcel
Hi Marcel!

Yes I use an adapted version of the hal_afpacket.c from the Raspberry Pi example, but because we have a dual-port-switch on the hardware and therefore I added sockets for each phy port.
Is this approach correct or should I just keep one socket for the bridge interface? But when I just have one raw socket, how can I recognize at which port the frames have arrived to forward it to PNU_DDB->RxTask->cb_ReceiveFrame(portID, pRxBuffer, buflen, rxTimeStamp)?
On which interface should GRO be disabled? On the bridge or on the PHY interfaces?

Thanks a lot!

UPDATE:
I found the socket option PACKET_ORIGDEV, which can be used to find the original receive port.... so I will try again with just 1 socket on the bridge interface.

Re: DCE/RPC Fragmentation Problem with Community Stack and Automated RT Tester

Posted: 04 Dec 2025, 11:17
by Blameless
paaaz wrote: ↑04 Dec 2025, 09:18 Hi Marcel!

Yes I use an adapted version of the hal_afpacket.c from the Raspberry Pi example, but because we have a dual-port-switch on the hardware and therefore I added sockets for each phy port.
Is this approach correct or should I just keep one socket for the bridge interface? But when I just have one raw socket, how can I recognize at which port the frames have arrived to forward it to PNU_DDB->RxTask->cb_ReceiveFrame(portID, pRxBuffer, buflen, rxTimeStamp)?
On which interface should GRO be disabled? On the bridge or on the PHY interfaces?

Thanks a lot!

UPDATE:
I found the socket option PACKET_ORIGDEV, which can be used to find the original receive port.... so I will try again with just 1 socket on the bridge interface.
To use PROFINET in your scenario, it's necessary to implement a three-port switch: your local interface plus the two physical ports.

From a PROFINET perspective, the following points are important:

* Switch Configuration: Targeted configuration of the switch
* Port-specific Sending: Send frames to specific ports (e.g., LLDP frames)
* Normal Interface Access: Access via the normal interface, where the switch makes the routing decision

If your switch supports DSA (Distributed Switch Architecture):

The ports are addressed as separate network interfaces (e.g., eth0 for the CPU port and lan1@eth0, lan2@eth0 for the physical ports). For implementation:

* DSA Framework for switch management
* Raw Sockets (AF_PACKET) for targeted peer-to-peer frame sending on specific ports
* Bridge Setup for normal TCP/IP communication
* FDB Management with bridge fdb for static MAC entries

If your switch does not support DSA:
You would need to work with low-level APIs or vendor-specific drivers, which can be more complex.

The critical question remains: How do you control the filter database of the switch? Insufficient control could be the reason for duplicate packets when opening multiple sockets

Best,
Marcel

PS: Generic Receive Offload shall be disabled for all interfaces that are used in community stack.

Re: DCE/RPC Fragmentation Problem with Community Stack and Automated RT Tester

Posted: 05 Dec 2025, 14:11
by paaaz
Blameless wrote: ↑04 Dec 2025, 11:17
paaaz wrote: ↑04 Dec 2025, 09:18 Hi Marcel!

Yes I use an adapted version of the hal_afpacket.c from the Raspberry Pi example, but because we have a dual-port-switch on the hardware and therefore I added sockets for each phy port.
Is this approach correct or should I just keep one socket for the bridge interface? But when I just have one raw socket, how can I recognize at which port the frames have arrived to forward it to PNU_DDB->RxTask->cb_ReceiveFrame(portID, pRxBuffer, buflen, rxTimeStamp)?
On which interface should GRO be disabled? On the bridge or on the PHY interfaces?

Thanks a lot!

UPDATE:
I found the socket option PACKET_ORIGDEV, which can be used to find the original receive port.... so I will try again with just 1 socket on the bridge interface.
To use PROFINET in your scenario, it's necessary to implement a three-port switch: your local interface plus the two physical ports.

From a PROFINET perspective, the following points are important:

* Switch Configuration: Targeted configuration of the switch
* Port-specific Sending: Send frames to specific ports (e.g., LLDP frames)
* Normal Interface Access: Access via the normal interface, where the switch makes the routing decision

If your switch supports DSA (Distributed Switch Architecture):

The ports are addressed as separate network interfaces (e.g., eth0 for the CPU port and lan1@eth0, lan2@eth0 for the physical ports). For implementation:

* DSA Framework for switch management
* Raw Sockets (AF_PACKET) for targeted peer-to-peer frame sending on specific ports
* Bridge Setup for normal TCP/IP communication
* FDB Management with bridge fdb for static MAC entries

If your switch does not support DSA:
You would need to work with low-level APIs or vendor-specific drivers, which can be more complex.

The critical question remains: How do you control the filter database of the switch? Insufficient control could be the reason for duplicate packets when opening multiple sockets

Best,
Marcel

PS: Generic Receive Offload shall be disabled for all interfaces that are used in community stack.
Hi again,
Thank you for your clarifications!
Unfortunately I can reproduce now the error on my desktop machine WITHOUT switch hardware, bridge interface and just one raw socket! In my opinion the reason is, that the SOCK component also binds to a UDP socket on CLRPC port 34964 and IP 0.0.0.0 (all interfaces). So if the CLRPC Connect-Request frame additionally gets forwarded to the stack via the raw socket in hal_afpacket.c, then I observe the duplicated datagram processing (and then fragmentation error). If I drop the CLRPC frame in hal_afpacket, the fragmentation error disappears!

Does that mean one should drop all UDP/TCP packets in the hal_afpacket, because the stack recognizes them via socket polling on its own?
Have a nice weekend!

Re: DCE/RPC Fragmentation Problem with Community Stack and Automated RT Tester

Posted: 18 Dec 2025, 08:32
by paaaz
paaaz wrote: ↑05 Dec 2025, 14:11
Blameless wrote: ↑04 Dec 2025, 11:17
paaaz wrote: ↑04 Dec 2025, 09:18 Hi Marcel!

Yes I use an adapted version of the hal_afpacket.c from the Raspberry Pi example, but because we have a dual-port-switch on the hardware and therefore I added sockets for each phy port.
Is this approach correct or should I just keep one socket for the bridge interface? But when I just have one raw socket, how can I recognize at which port the frames have arrived to forward it to PNU_DDB->RxTask->cb_ReceiveFrame(portID, pRxBuffer, buflen, rxTimeStamp)?
On which interface should GRO be disabled? On the bridge or on the PHY interfaces?

Thanks a lot!

UPDATE:
I found the socket option PACKET_ORIGDEV, which can be used to find the original receive port.... so I will try again with just 1 socket on the bridge interface.
To use PROFINET in your scenario, it's necessary to implement a three-port switch: your local interface plus the two physical ports.

From a PROFINET perspective, the following points are important:

* Switch Configuration: Targeted configuration of the switch
* Port-specific Sending: Send frames to specific ports (e.g., LLDP frames)
* Normal Interface Access: Access via the normal interface, where the switch makes the routing decision

If your switch supports DSA (Distributed Switch Architecture):

The ports are addressed as separate network interfaces (e.g., eth0 for the CPU port and lan1@eth0, lan2@eth0 for the physical ports). For implementation:

* DSA Framework for switch management
* Raw Sockets (AF_PACKET) for targeted peer-to-peer frame sending on specific ports
* Bridge Setup for normal TCP/IP communication
* FDB Management with bridge fdb for static MAC entries

If your switch does not support DSA:
You would need to work with low-level APIs or vendor-specific drivers, which can be more complex.

The critical question remains: How do you control the filter database of the switch? Insufficient control could be the reason for duplicate packets when opening multiple sockets

Best,
Marcel

PS: Generic Receive Offload shall be disabled for all interfaces that are used in community stack.
Hi again,
Thank you for your clarifications!
Unfortunately I can reproduce now the error on my desktop machine WITHOUT switch hardware, bridge interface and just one raw socket! In my opinion the reason is, that the SOCK component also binds to a UDP socket on CLRPC port 34964 and IP 0.0.0.0 (all interfaces). So if the CLRPC Connect-Request frame additionally gets forwarded to the stack via the raw socket in hal_afpacket.c, then I observe the duplicated datagram processing (and then fragmentation error). If I drop the CLRPC frame in hal_afpacket, the fragmentation error disappears!

Does that mean one should drop all UDP/TCP packets in the hal_afpacket, because the stack recognizes them via socket polling on its own?
Have a nice weekend!





This is how I solved this issue, in case somebody comes across the same situation:
  • I ran into this issue probably because I activated the TCIP (with anyip) component to support SNMP, and this component individually opens and polls UDP sockets
  • I created a BPF packet filter which only allows Ethernet frames with EtherType LLDP, ARP and PROFINET to be forwarded to the stack and attached it to the raw socket in hal_afpacket.c
  • Now no test shows the fragmentation error anymore because the fragmented connect request is only processed once and only one FACK is sent.
Here is the cBPF code i used:

Code: Select all

        // We had problems with DCE RPC Fragmentation due to duplicated UDP datagram processing (data can be read from socket two times until recvfrom in sock_low_anyip.c returns with EWOULDBLOCK)

        // Attach BPF filter to accept only ARP, LLDP and PROFINET frames
        // Handles both untagged and VLAN-tagged (802.1Q) frames
        // EtherTypes: ARP=0x0806, LLDP=0x88CC, PROFINET=0x8892, VLAN=0x8100
        struct sock_filter bpf_code[] = {
            // Load EtherType at offset 12
            BPF_STMT(BPF_LD + BPF_H + BPF_ABS, 12),

            // Check if it's a VLAN tag (0x8100)
            BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, ETH_P_8021Q, 0, 1),
            // If VLAN: load EtherType at offset 16 (skip 4-byte VLAN tag)
            BPF_STMT(BPF_LD + BPF_H + BPF_ABS, 16),

            // Now we have the actual EtherType (either from offset 12 or 16)
            // Check for ARP (0x0806)
            BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, 0x0806, 3, 0),

            // Check for PROFINET (0x8892)
            BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, 0x8892, 2, 0),

            // Check for LLDP (0x88CC)
            BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, 0x88CC, 1, 0),

            // Reject packet (return 0)
            BPF_STMT(BPF_RET + BPF_K, 0),

            // Accept packet (return -1 = entire packet)
            BPF_STMT(BPF_RET + BPF_K, 0xFFFFFFFF),
        };

        struct sock_fprog bpf_prog = {
            .len = sizeof(bpf_code) / sizeof(bpf_code[0]),
            .filter = bpf_code,
        };

        if (setsockopt(sockfd, SOL_SOCKET, SO_ATTACH_FILTER, &bpf_prog, sizeof(bpf_prog)) < 0) {
            return PNU_STS_ERR_HW;
        }
BR Patrick
All times are UTC+02:00
Page 1 of 1

Powered by phpBB® Forum Software © phpBB Limited