Opener on STM32F746

[Mykhaylo Galushka]

HI. I'm trying to port OpENer to stm32F746 and meet some difficulties. First is that Device is visible in RSlinx which is fine, but no luck further sucsess. THe problem is that
there no errors, but trying to connect to devise through Ethernet/IP exploref i cannot open forward connection. wireshark shows that there respond from devise but no respond as SSL respond which is correct because i didn't implement ssl. When I connected my board to PLC plc show connection error with number 16#0127 invalid output size. On linux everything is fine all ok everywhere with local software without PLC and with PLC. But I found one strange thing. When i trying to see output with TRACE_LEVEL_INFO - on , on lunux with RSLINX i'm getting output as
List Identity
Data received on global broadcast UDP:
List Identity
Data received on global broadcast UDP:
List Identity
Data received on global broadcast UDP:
but on STM32 i'm getting
2:17:50.484> Data received on UDP unicast:
2:17:50.484> List Identity
2:17:50.484> UDP unicast reply sent:
2:17:50.484> Data received on global broadcast UDP:
2:17:50.484> List Identity
2:17:51.485> Data received on UDP unicast:
2:17:51.485> List Identity
2:17:51.485> UDP unicast reply sent:
2:17:51.485> Data received on global broadcast UDP:
which is not correct as i understand.
All structures are filled, like IP, mask, server 1,2, and so on

can anybody push me in proper direction or give me a hand what to do or how to get this devise work

My devise is STM32F746 + Free RTOS + LWIP

[Mykhaylo Galushka]

Additional information,

when I try to connect to board there one more thing.

:18:14.797> Entering HandleDataOnTcpSocket for socket: 4
2:18:14.797> Data received on TCP: zu
2:18:14.797> Handles data for TCP socket: 4
2:18:14.797> Send Request/Reply Data
2:18:14.797> NotifyMessageRouter: routing unconnected message
2:18:14.797> NotifyMessageRouter: calling notify function of class 'connection manager'
2:18:14.797> notify: found instance 1
2:18:14.797> notify: calling ForwardOpen service
2:18:14.797> ForwardOpen: ConConnID 4294902044, ProdConnID 4294902045, ConnSerNo 34932
2:18:14.797> We have a Non-Null request
2:18:14.797> We have a Non-Matching request
2:18:14.797> classid 4 (assembly)
2:18:14.797> Configuration instance id 151
2:18:14.797> assembly: type bidirectional
2:18:14.797> connection point 150
2:18:14.797> connection point 100
2:18:14.797> Resulting PIT value: 256
2:18:14.797> IO Exclusive Owner connection requested
2:18:14.797> No PIT segment available    <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<THIS
2:18:14.797> connection manager: connect failed
2:18:14.797> AssembleForwardOpenResponse: sending error response
2:18:14.797> notifyMR: notify function of class 'connection manager' returned a reply
2:18:14.797> TCP reply: send zu bytes on 58
2:18:15.485> Data received on UDP unicast:
2:18:15.485> List Identity
2:18:15.485> UDP unicast reply sent:
2:18:15.485> Data received on global broadcast UDP:
2:18:15.485> List Identity
2:18:16.546> Entering HandleDataOnTcpSocket for socket: 4

Probably something wrong there but i dont understand what exactly. THe main code was not changed, only networkconfig.c

Regards

Michael

[Mykhaylo Galushka]

Hi again. I checked Wireshark logs and there the same error which been showed by PLC.

General Status: Connection failure (0x01)

Additional Status: 0x0127

Additional Status: 0x0022

it looks like mistmach data size which ordinator expected and recieved.

Now it little clear why in output were that message

2:18:14.797> No PIT segment available

So there no production inhibit time in connection path.

To  get that interval there is

CipUdint ConnectionObjectGetTToORequestedPacketInterval(const CipConnectionObject *const connection_object)
{
  return connection_object->t_to_o_requested_packet_interval;
}

to set that interval

void ConnectionObjectSetTToORequestedPacketInterval(CipConnectionObject *connection_object, const CipUdint requested_packet_interval)
{
  connection_object->t_to_o_requested_packet_interval = requested_packet_interval;
}

So the problem probably is - why i can't get that interval???

May be I went somwhere in wrong way so correct me please

[Alois Zoitl]

Hi,

from all the info would say that you have a mismatch in your PLC configuration. You need to have the same size as the default OpENer configuration, if you
haven't changed it, uses for its assemblies used in that specific connection.

Alois

> --
> You received this message because you are subscribed to the Google Groups "EIP Stack Group OpENer users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eip-stack-group-open...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/eip-stack-group-opener-users/08680c17-6f07-402b-bbe0-125f61e53f5an%40googlegroups.com.

[Mykhaylo Galushka]

Hi As I said I did not change anything in configuration, sample application is original.

THe problem is that i compiled same code in linux and everything works fine.

[Alois Zoitl]

On Wed, 2020-08-26 at 19:13 -0700, Mykhaylo Galushka wrote:
> Hi As I said I did not change anything in configuration, sample application is original.
> THe problem is that i compiled same code in linux and everything works fine.

Hi, sorry I missed that. In that case it is really strange.

> To view this discussion on the web visit https://groups.google.com/d/msgid/eip-stack-group-opener-users/85e2ee89-ecaa-47b6-8b4d-b4716382e4ccn%40googlegroups.com.

[martin...@gmail.com]

Hi,

to your first issue

> > > List Identity
> > > Data received on global broadcast UDP:
> > > List Identity
> > > Data received on global broadcast UDP:
> > > List Identity
> > > Data received on global broadcast UDP:
> > > but on STM32 i'm getting
> > > 2:17:50.484> Data received on UDP unicast:
> > > 2:17:50.484> List Identity
> > > 2:17:50.484> UDP unicast reply sent:
> > > 2:17:50.484> Data received on global broadcast UDP:
> > > 2:17:50.484> List Identity
> > > 2:17:51.485> Data received on UDP unicast:
> > > 2:17:51.485> List Identity
> > > 2:17:51.485> UDP unicast reply sent:
> > > 2:17:51.485> Data received on global broadcast UDP:
> > > which is not correct as i understand. 

in the standard version unicast and  broadcast packes are separated via two sockets, one which binds to the own address and one that binds to broadcast, so this is dependent on how the IP stack works.

I have no experience with LWIP I cannot say how this stack will behave in this case.

For your other problem, could you please provide a Wireshark trace.

Best regards,

Martin

[Mykhaylo Galushka]

HI Martin. So there is request

Frame 39: 144 bytes on wire (1152 bits), 144 bytes captured (1152 bits) on interface \Device\NPF_{165D06FF-C4E7-4291-A605-668718CC24C6}, id 0
    Interface id: 0 (\Device\NPF_{165D06FF-C4E7-4291-A605-668718CC24C6})
        Interface name: \Device\NPF_{165D06FF-C4E7-4291-A605-668718CC24C6}
        Interface description: LOCAL
    Encapsulation type: Ethernet (1)
    Arrival Time: Aug 27, 2020 19:43:47.614261000 Тихоокеанское время США (лето)
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1598582627.614261000 seconds
    [Time delta from previous captured frame: 0.000035000 seconds]
    [Time delta from previous displayed frame: 0.000035000 seconds]
    [Time since reference or first frame: 19.724484000 seconds]
    Frame Number: 39
    Frame Length: 144 bytes (1152 bits)
    Capture Length: 144 bytes (1152 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:tcp:enip:cip:cipcm]
    [Coloring Rule Name: TCP]
    [Coloring Rule String: tcp]
Ethernet II, Src: Micro-St_21:fc:53 (30:9c:23:21:fc:53), Dst: ASUSTekC_48:10:25 (75:d0:2b:48:10:25)
    Destination: ASUSTekC_48:10:25 (75:d0:2b:48:10:25)
        Address: ASUSTekC_48:10:25 (75:d0:2b:48:10:25)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: Micro-St_21:fc:53 (30:9c:23:21:fc:53)
        Address: Micro-St_21:fc:53 (30:9c:23:21:fc:53)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.3, Dst: 192.168.1.155
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 130
    Identification: 0x7741 (30529)
    Flags: 0x4000, Don't fragment
        0... .... .... .... = Reserved bit: Not set
        .1.. .... .... .... = Don't fragment: Set
        ..0. .... .... .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (6)
    Header checksum: 0xff45 [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.168.1.3
    Destination: 192.168.1.155
Transmission Control Protocol, Src Port: 1698, Dst Port: 44818, Seq: 29, Ack: 29, Len: 90
    Source Port: 1698
    Destination Port: 44818
    [Stream index: 1]
    [TCP Segment Len: 90]
    Sequence number: 29    (relative sequence number)
    Sequence number (raw): 566962916
    [Next sequence number: 119    (relative sequence number)]
    Acknowledgment number: 29    (relative ack number)
    Acknowledgment number (raw): 6539
    0101 .... = Header Length: 20 bytes (5)
    Flags: 0x018 (PSH, ACK)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Nonce: Not set
        .... 0... .... = Congestion Window Reduced (CWR): Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...1 .... = Acknowledgment: Set
        .... .... 1... = Push: Set
        .... .... .0.. = Reset: Not set
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set
        [TCP Flags: ·······AP···]
    Window size value: 64212
    [Calculated window size: 64212]
    [Window size scaling factor: -2 (no window scaling used)]
    Checksum: 0x2560 [unverified]
    [Checksum Status: Unverified]
    Urgent pointer: 0
    [SEQ/ACK analysis]
        [This is an ACK to the segment in frame: 38]
        [The RTT to ACK the segment was: 0.000035000 seconds]
        [iRTT: 0.002264000 seconds]
        [Bytes in flight: 90]
        [Bytes sent since last PSH flag: 90]
    [Timestamps]
        [Time since first frame in this TCP stream: 0.004247000 seconds]
        [Time since previous frame in this TCP stream: 0.000035000 seconds]
    TCP payload (90 bytes)
    [PDU Size: 90]
EtherNet/IP (Industrial Protocol), Session: 0x00000001, Send RR Data
    Encapsulation Header
        Command: Send RR Data (0x006f)
        Length: 66
        Session Handle: 0x00000001
        Status: Success (0x00000000)
        Sender Context: 0000000000000000
        Options: 0x00000000
    Command Specific Data
        Interface Handle: CIP (0x00000000)
        Timeout: 0
        Item Count: 2
            Type ID: Null Address Item (0x0000)
                Length: 0
            Type ID: Unconnected Data Item (0x00b2)
                Length: 50
        [Response In: 40]
Common Industrial Protocol
    Service: Unknown Service (0x54) (Request)
        0... .... = Request/Response: Request (0x0)
        .101 0100 = Service: Unknown (0x54)
    Request Path Size: 2 words
    Request Path: Connection Manager, Instance: 0x01
        Path Segment: 0x20 (8-Bit Class Segment)
            001. .... = Path Segment Type: Logical Segment (1)
            ...0 00.. = Logical Segment Type: Class ID (0)
            .... ..00 = Logical Segment Format: 8-bit Logical Segment (0)
            Class: Connection Manager (0x06)
        Path Segment: 0x24 (8-Bit Instance Segment)
            001. .... = Path Segment Type: Logical Segment (1)
            ...0 01.. = Logical Segment Type: Instance ID (1)
            .... ..00 = Logical Segment Format: 8-bit Logical Segment (0)
            Instance: 0x01
CIP Connection Manager
    Service: Forward Open (Request)
        0... .... = Request/Response: Request (0x0)
        .101 0100 = Service: Forward Open (0x54)
    Command Specific Data
        ...0 .... = Priority: 0
        .... 1010 = Tick time: 10
        Time-out ticks: 10
        Actual Time Out: 10240ms
        O->T Network Connection ID: 0xffff002e
        T->O Network Connection ID: 0xffff002f
        Connection Serial Number: 0x9954
        Originator Vendor ID: Unknown (0xfada)
        Originator Serial Number: 0x8badf00d
        Connection Timeout Multiplier: *4 (0)
        Reserved: 0x000000
        O->T RPI: 200,000ms
        O->T Network Connection Parameters: 0x4626
            0... .... .... .... = Owner: Exclusive (0)
            .10. .... .... .... = Connection Type: Point to Point (2)
            .... 01.. .... .... = Priority: High Priority (1)
            .... ..1. .... .... = Connection Size Type: Variable (1)
            .... ...0 0010 0110 = Connection Size: 38 bytes
        T->O RPI: 200,000ms
        T->O Network Connection Parameters: 0x4022
            0... .... .... .... = Owner: Exclusive (0)
            .10. .... .... .... = Connection Type: Point to Point (2)
            .... 00.. .... .... = Priority: Low Priority (0)
            .... ..0. .... .... = Connection Size Type: Fixed (0)
            .... ...0 0010 0010 = Connection Size: 34 bytes
        Transport Type/Trigger: 0x01, Direction: Client, Trigger: Cyclic, Class: 1
            0... .... = Direction: Client (0)
            .000 .... = Trigger: Cyclic (0)
            .... 0001 = Class: 1 (1)
        Connection Path Size: 4 words
        Connection Path: Assembly, Instance: 0x97, Connection Point: 0x96, Connection Point: 0x64
            Path Segment: 0x20 (8-Bit Class Segment)
                001. .... = Path Segment Type: Logical Segment (1)
                ...0 00.. = Logical Segment Type: Class ID (0)
                .... ..00 = Logical Segment Format: 8-bit Logical Segment (0)
                Class: Assembly (0x04)
            Path Segment: 0x24 (8-Bit Instance Segment)
                001. .... = Path Segment Type: Logical Segment (1)
                ...0 01.. = Logical Segment Type: Instance ID (1)
                .... ..00 = Logical Segment Format: 8-bit Logical Segment (0)
                Instance: 0x97
            Path Segment: 0x2c (8-Bit Connection Point Segment)
                001. .... = Path Segment Type: Logical Segment (1)
                ...0 11.. = Logical Segment Type: Connection Point (3)
                .... ..00 = Logical Segment Format: 8-bit Logical Segment (0)
                Connection Point: 0x96
            Path Segment: 0x2c (8-Bit Connection Point Segment)
                001. .... = Path Segment Type: Logical Segment (1)
                ...0 11.. = Logical Segment Type: Connection Point (3)
                .... ..00 = Logical Segment Format: 8-bit Logical Segment (0)
                Connection Point: 0x64

and here is answer

Frame 40: 112 bytes on wire (896 bits), 112 bytes captured (896 bits) on interface \Device\NPF_{165D06FF-C4E7-4291-A605-668718CC24C6}, id 0
    Interface id: 0 (\Device\NPF_{165D06FF-C4E7-4291-A605-668718CC24C6})
        Interface name: \Device\NPF_{165D06FF-C4E7-4291-A605-668718CC24C6}
        Interface description: LOCAL
    Encapsulation type: Ethernet (1)
    Arrival Time: Aug 27, 2020 19:43:47.616139000 Тихоокеанское время США (лето)
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1598582627.616139000 seconds
    [Time delta from previous captured frame: 0.001878000 seconds]
    [Time delta from previous displayed frame: 0.001878000 seconds]
    [Time since reference or first frame: 19.726362000 seconds]
    Frame Number: 40
    Frame Length: 112 bytes (896 bits)
    Capture Length: 112 bytes (896 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:tcp:enip:cip:cipcm]
    [Coloring Rule Name: TCP]
    [Coloring Rule String: tcp]
Ethernet II, Src: ASUSTekC_48:10:25 (75:d0:2b:48:10:25), Dst: Micro-St_21:fc:53 (30:9c:23:21:fc:53)
    Destination: Micro-St_21:fc:53 (30:9c:23:21:fc:53)
        Address: Micro-St_21:fc:53 (30:9c:23:21:fc:53)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: ASUSTekC_48:10:25 (75:d0:2b:48:10:25)
        Address: ASUSTekC_48:10:25 (75:d0:2b:48:10:25)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.155, Dst: 192.168.1.3
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 98
    Identification: 0x0003 (3)
    Flags: 0x0000
        0... .... .... .... = Reserved bit: Not set
        .0.. .... .... .... = Don't fragment: Not set
        ..0. .... .... .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 255
    Protocol: TCP (6)
    Header checksum: 0x37a4 [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.168.1.155
    Destination: 192.168.1.3
Transmission Control Protocol, Src Port: 44818, Dst Port: 1698, Seq: 29, Ack: 119, Len: 58
    Source Port: 44818
    Destination Port: 1698
    [Stream index: 1]
    [TCP Segment Len: 58]
    Sequence number: 29    (relative sequence number)
    Sequence number (raw): 6539
    [Next sequence number: 87    (relative sequence number)]
    Acknowledgment number: 119    (relative ack number)
    Acknowledgment number (raw): 566963006
    0101 .... = Header Length: 20 bytes (5)
    Flags: 0x018 (PSH, ACK)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Nonce: Not set
        .... 0... .... = Congestion Window Reduced (CWR): Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...1 .... = Acknowledgment: Set
        .... .... 1... = Push: Set
        .... .... .0.. = Reset: Not set
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set
        [TCP Flags: ·······AP···]
    Window size value: 2802
    [Calculated window size: 2802]
    [Window size scaling factor: -2 (no window scaling used)]
    Checksum: 0xa353 [unverified]
    [Checksum Status: Unverified]
    Urgent pointer: 0
    [SEQ/ACK analysis]
        [This is an ACK to the segment in frame: 39]
        [The RTT to ACK the segment was: 0.001878000 seconds]
        [iRTT: 0.002264000 seconds]
        [Bytes in flight: 58]
        [Bytes sent since last PSH flag: 58]
    [Timestamps]
        [Time since first frame in this TCP stream: 0.006125000 seconds]
        [Time since previous frame in this TCP stream: 0.001878000 seconds]
    TCP payload (58 bytes)
    [PDU Size: 58]
EtherNet/IP (Industrial Protocol), Session: 0x00000001, Send RR Data
    Encapsulation Header
        Command: Send RR Data (0x006f)
        Length: 34
        Session Handle: 0x00000001
        Status: Success (0x00000000)
        Sender Context: 0000000000000000
        Options: 0x00000000
    Command Specific Data
        Interface Handle: CIP (0x00000000)
        Timeout: 0
        Item Count: 2
            Type ID: Null Address Item (0x0000)
                Length: 0
            Type ID: Unconnected Data Item (0x00b2)
                Length: 18
        [Request In: 39]
        [Time: 0.001878000 seconds]
Common Industrial Protocol
    Service: Unknown Service (0x54) (Response)
        1... .... = Request/Response: Response (0x1)
        .101 0100 = Service: Unknown (0x54)
    Status: Connection failure:

        General Status: Connection failure (0x01)

        Additional Status Size: 2 words
        Additional Status

            Additional Status: 0x0127
            Additional Status: 0x0022

    [Request Path Size: 2 words]
    [Request Path: Connection Manager, Instance: 0x01]
        [Path Segment: 0x20 (8-Bit Class Segment)]
            [001. .... = Path Segment Type: Logical Segment (1)]
            [...0 00.. = Logical Segment Type: Class ID (0)]
            [.... ..00 = Logical Segment Format: 8-bit Logical Segment (0)]
            [Class: Connection Manager (0x06)]
        [Path Segment: 0x24 (8-Bit Instance Segment)]
            [001. .... = Path Segment Type: Logical Segment (1)]
            [...0 01.. = Logical Segment Type: Instance ID (1)]
            [.... ..00 = Logical Segment Format: 8-bit Logical Segment (0)]
            [Instance: 0x01]
CIP Connection Manager
    Service: Forward Open (Response)
        1... .... = Request/Response: Response (0x1)
        .101 0100 = Service: Forward Open (0x54)
    Status: Connection failure, Extended: Invalid O->T size

        General Status: Connection failure (0x01)

        Additional Status Size: 2 words
        Extended Status: Invalid O->T size (0x0127)
        Maximum Size: 34
    Command Specific Data
        Connection Serial Number: 0x9954
        Originator Vendor ID: Unknown (0xfada)
        Originator Serial Number: 0x8badf00d
        Remaining Path Size: 0 words
        Reserved: 0x00

tried to debug LWIP today and got as folows may be that will help somehow as well

21:17:18.952> tnetif: added interface st IP addr 192.168.1.155 netmask 255.255.255.0 gw 192.168.1.1

21:17:18.952> netif: setting default interface st
21:17:18.952> tcpip_thread: PACKET 0x20037db0
21:17:18.952> TCP header:
21:17:18.952> +-------------------------------+
21:17:18.952> |     1924      |    44818      | (src port, dest port)
21:17:18.952> +-------------------------------+
21:17:18.952> |           2712345453          | (seq no)
21:17:18.952> +-------------------------------+
21:17:18.952> |           0000006693          | (ack no)
21:17:18.952> +-------------------------------+
21:17:18.952> |  5 |   |011000|     65392     | (hdrlen, flags (PSH ACK
21:17:18.952> ), win)
21:17:18.952> +-------------------------------+
21:17:18.952> |    0x0f27     |         0     | (chksum, urgp)
21:17:18.952> +-------------------------------+
21:17:18.952> +-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags PSH ACK
21:17:18.952> -+-+-+-+-+-+-+-+-+-+-+-+-+-+
21:17:18.952> tcpip_thread: PACKET 0x20037db0
21:17:18.952> lwip_socket(PF_INET, SOCK_STREAM, 6) = 0
21:17:18.952> lwip_setsockopt(0, SOL_SOCKET, optname=0x4, ..) -> on
21:17:18.952> lwip_ioctl(0, FIONBIO, 1)
21:17:18.952> lwip_socket(PF_INET, SOCK_DGRAM, 17) = 1
21:17:18.952> lwip_socket(PF_INET, SOCK_DGRAM, 17) = 2
21:17:18.952> lwip_setsockopt(1, SOL_SOCKET, optname=0x4, ..) -> on
21:17:18.952> lwip_ioctl(1, FIONBIO, 1)
21:17:18.952> lwip_setsockopt(2, SOL_SOCKET, optname=0x4, ..) -> on
21:17:18.952> lwip_ioctl(2, FIONBIO, 1)
21:17:18.952> lwip_bind(0, addr=192.168.1.155 port=44818)
21:17:18.952> tcp_bind: bind to port 44818
21:17:18.952> lwip_bind(0) succeeded
21:17:18.952> lwip_bind(2, addr=192.168.1.155 port=44818)
21:17:18.952> udp_bind(ipaddr = 192.168.1.155, port = 44818)
21:17:18.952> udp_bind: bound to 192.168.1.155, port 44818)
21:17:18.952> lwip_bind(2) succeeded
21:17:18.952> lwip_setsockopt(2, IPPROTO_IP, IP_TOS, ..)-> 108
21:17:18.952> lwip_setsockopt(1, SOL_SOCKET, optname=0x20, ..) -> on
21:17:18.952> lwip_bind(1, addr=0.0.0.0 port=44818)
21:17:18.952> udp_bind(ipaddr = 0.0.0.0, port = 44818)
21:17:18.952> udp_bind: bound to 0.0.0.0, port 44818)
21:17:18.952> lwip_bind(1) succeeded
21:17:18.952> lwip_setsockopt(1, IPPROTO_IP, IP_TOS, ..)-> 108
21:17:18.952> lwip_setsockopt(0, IPPROTO_IP, IP_TOS, ..)-> 108
21:17:18.952> lwip_listen(0, backlog=10)

[Mykhaylo Galushka]

and one more.

I found that in cipconnectionmanager.c in finction HandleNonNullNonMatchingForwardOpenRequest

connection_management_entry->open_connection_function( &g_dummy_connection_object, &connection_status);

returns 1

so when I trying to connect fail connect comes from there, I tried to find the open_connection_functionbut there only prototype, and i can't understand which function exactly were called to understand the reason.

On Thursday, August 27, 2020 at 1:06:42 AM UTC-7 martin...@gmail.com wrote: