Re: [vpp-dev] can't establish tcp connection with new introduced transport_endpoint_freelist

2023-03-13 Thread Florin Coras
Hi, 

Could you try this out [1]? I’ve hit this issue myself today but with udp 
sessions. Unfortunately, as you’ve correctly pointed out, we were forcing a 
cleanup only on the non-fixed local port branch. 

Regards, 
Florin

[1] https://gerrit.fd.io/r/c/vpp/+/38473

> On Mar 13, 2023, at 7:35 PM, Zhang Dongya  wrote:
> 
> Hi list,
> 
> We have update coded from the upstream session changes to our code base 
> and find a possible bug which cause tcp connection can't be established 
> anymore.
> 
> Our scenario is that we will connect to a remote tcp server with specified 
> local port and local ip, however, new vpp code have introduced a 
> lcl_endpts_freelist which will be either flushed when pending local endpoint 
> exceeded the limit (32) or when transport_alloc_local_port is called.
> 
> However, since we specify the local port and local ip and the total session 
> count is limited (< 32), in this case, the transport_cleanup_freelist will 
> never be called which cause the previous session which use the specified 
> local port and local ip will not be released after the session aborted.
> 
> I think we should also try to free the list in such case as I did in the 
> following code:
> 
>> int
>> transport_alloc_local_endpoint (u8 proto, transport_endpoint_cfg_t * rmt_cfg,
>> ip46_address_t * lcl_addr, u16 * lcl_port)
>> {
>>   // ZDY:
>>   transport_main_t *tm = _main;
>>   transport_endpoint_t *rmt = (transport_endpoint_t *) rmt_cfg;
>>   session_error_t error;
>>   int port;
>> 
>>   /*
>>* Find the local address
>>*/
>>   if (ip_is_zero (_cfg->peer.ip, rmt_cfg->peer.is_ip4))
>> {
>>   error = transport_find_local_ip_for_remote (_cfg->peer.sw_if_index,
>>  rmt, lcl_addr);
>>   if (error)
>> return error;
>> }
>>   else
>> {
>>   /* Assume session layer vetted this address */
>>   clib_memcpy_fast (lcl_addr, _cfg->peer.ip,
>> sizeof (rmt_cfg->peer.ip));
>> }
>> 
>>   /*
>>* Allocate source port
>>*/
>>   if (rmt_cfg->peer.port == 0)
>> {
>>   port = transport_alloc_local_port (proto, lcl_addr, rmt_cfg);
>>   if (port < 1)
>> return SESSION_E_NOPORT;
>>   *lcl_port = port;
>> }
>>   else
>> {
>>   port = clib_net_to_host_u16 (rmt_cfg->peer.port);
>>   *lcl_port = port;
>> 
>>   // ZDY: need add this to to cleanup because in specified src port
>>   // case, we will not run to transport_alloc_local_port, then
>>   // freelist will only be freeed when list is full (>32).
>>   /* Cleanup freelist if need be */
>>   if (vec_len (tm->lcl_endpts_freelist))
>> transport_cleanup_freelist ();
>> 
>>   return transport_endpoint_mark_used (proto, lcl_addr, port);
>> }
>> 
>>   return 0;
>> }
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22699): https://lists.fd.io/g/vpp-dev/message/22699
Mute This Topic: https://lists.fd.io/mt/97596886/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[vpp-dev] can't establish tcp connection with new introduced transport_endpoint_freelist

2023-03-13 Thread Zhang Dongya
Hi list,

We have update coded from the upstream session changes to our code base
and find a possible bug which cause tcp connection can't be established
anymore.

Our scenario is that we will connect to a remote tcp server with specified
local port and local ip, however, new vpp code have introduced a
lcl_endpts_freelist which will be either flushed when pending local
endpoint exceeded the limit (32) or when transport_alloc_local_port is
called.

However, since we specify the local port and local ip and the total session
count is limited (< 32), in this case, the transport_cleanup_freelist will
never be called which cause the previous session which use the specified
local port and local ip will not be released after the session aborted.

I think we should also try to free the list in such case as I did in the
following code:

int
> transport_alloc_local_endpoint (u8 proto, transport_endpoint_cfg_t *
> rmt_cfg,
> ip46_address_t * lcl_addr, u16 * lcl_port)
> {
>   // ZDY:
>   transport_main_t *tm = _main;
>   transport_endpoint_t *rmt = (transport_endpoint_t *) rmt_cfg;
>   session_error_t error;
>   int port;
>
>   /*
>* Find the local address
>*/
>   if (ip_is_zero (_cfg->peer.ip, rmt_cfg->peer.is_ip4))
> {
>   error = transport_find_local_ip_for_remote
> (_cfg->peer.sw_if_index,
>  rmt, lcl_addr);
>   if (error)
> return error;
> }
>   else
> {
>   /* Assume session layer vetted this address */
>   clib_memcpy_fast (lcl_addr, _cfg->peer.ip,
> sizeof (rmt_cfg->peer.ip));
> }
>
>   /*
>* Allocate source port
>*/
>   if (rmt_cfg->peer.port == 0)
> {
>   port = transport_alloc_local_port (proto, lcl_addr, rmt_cfg);
>   if (port < 1)
> return SESSION_E_NOPORT;
>   *lcl_port = port;
> }
>   else
> {
>   port = clib_net_to_host_u16 (rmt_cfg->peer.port);
>   *lcl_port = port;
>
>
>
>
>
>
> *  // ZDY: need add this to to cleanup because in specified src port
> // case, we will not run to transport_alloc_local_port, then  //
> freelist will only be freeed when list is full (>32).  /* Cleanup
> freelist if need be */  if (vec_len (tm->lcl_endpts_freelist))
> transport_cleanup_freelist ();*
>
>   return transport_endpoint_mark_used (proto, lcl_addr, port);
> }
>
>   return 0;
> }
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22698): https://lists.fd.io/g/vpp-dev/message/22698
Mute This Topic: https://lists.fd.io/mt/97596886/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [vpp-dev] Jenkins Emergency Maintenance

2023-03-13 Thread Vanessa Valderrama
Production upgrade complete. If you have any issues, please open a 
ticket at support.linuxfoundation.org.


Thank you,

Vanessa

On 3/13/23 13:00, Vanessa Valderrama wrote:


Sandbox upgrade complete

Starting on production now

On 3/13/23 12:30, Vanessa Valderrama wrote:


*What*:

The Linux Foundation been made aware of a security issue with the
Jenkins systems that needs immediate resolution

*When*:

We're starting the sandbox upgrade now

Putting production in shutdown mode. The upgrade will be done at 
18:00. (all running jobs will be aborted at this time)


*Why*:

Jenkins SECURITY-3037

https://www.jenkins.io/security/advisory/2023-03-08/

*Impact*:

Jenkins will be unavailable during the upgrade

Thank you,
Vanessa


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22697): https://lists.fd.io/g/vpp-dev/message/22697
Mute This Topic: https://lists.fd.io/mt/97586321/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [vpp-dev] All UDP packet being dropped at “ipsec4_input_node” when IPSEC policy configured

2023-03-13 Thread Varun Tewari
Thank you for bringing this to the fore.
I am noticing something interesting along the same lines as well during my 
investigation.
I am using strongswan as the initiator and VPP Ikev2 as the responder.

My observations are:
1. Strongswan initiator forceencap=yes and VPP responder ikev2 profile set 
udp-encap, my tunnels do not come up. Ike gets established but CHILD_SA fails.
2. Strongswan initiator forceencap=no and VPP responder ikev2 profile set 
udp-encap, my tunnels come up. Traffic drops with 
ESP_DECRYPT_ERROR_TUN_NO_PROTO (all traffic)
3. Strongswan initiator forceencap=yes and VPP responder udp-encap not set in 
profile, my tunnels do come up and traffic flows.

Let me know as well if these are expected observations.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22696): https://lists.fd.io/g/vpp-dev/message/22696
Mute This Topic: https://lists.fd.io/mt/97576487/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [vpp-dev] Jenkins Emergency Maintenance

2023-03-13 Thread Vanessa Valderrama

Sandbox upgrade complete

Starting on production now

On 3/13/23 12:30, Vanessa Valderrama wrote:


*What*:

The Linux Foundation been made aware of a security issue with the
Jenkins systems that needs immediate resolution

*When*:

We're starting the sandbox upgrade now

Putting production in shutdown mode. The upgrade will be done at 
18:00. (all running jobs will be aborted at this time)


*Why*:

Jenkins SECURITY-3037

https://www.jenkins.io/security/advisory/2023-03-08/

*Impact*:

Jenkins will be unavailable during the upgrade

Thank you,
Vanessa


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22695): https://lists.fd.io/g/vpp-dev/message/22695
Mute This Topic: https://lists.fd.io/mt/97586321/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[vpp-dev] Jenkins Emergency Maintenance

2023-03-13 Thread Vanessa Valderrama

*What*:

The Linux Foundation been made aware of a security issue with the
Jenkins systems that needs immediate resolution

*When*:

We're starting the sandbox upgrade now

Putting production in shutdown mode. The upgrade will be done at 18:00. 
(all running jobs will be aborted at this time)


*Why*:

Jenkins SECURITY-3037

https://www.jenkins.io/security/advisory/2023-03-08/

*Impact*:

Jenkins will be unavailable during the upgrade

Thank you,
Vanessa

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22694): https://lists.fd.io/g/vpp-dev/message/22694
Mute This Topic: https://lists.fd.io/mt/97586321/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[vpp-dev] All UDP packet being dropped at “ipsec4_input_node” when IPSEC policy configured

2023-03-13 Thread Tripathi, VinayX
Hi Team,

All UDP packet being dropped at “ipsec4_input_node”  if ipsec inbound and 
outbound policy configured. Not that udp_encp is not enabled.
Where TCP and ICMP has no such issue.
System is treating normal UDP and UDP encapsulated ESP packet in same way. 
Probably we have to use DST and SRC port of UDP
With compliance of RFC :- 3948.
Used Topology :-

PKT-G0 — dut1_eth0 -- dut1_eth1 --- dut2_eth0  dut2_eth1 - 
PKT-G1

In file : src/vnet/ipsec/ipsec_input.c
  if (PREDICT_TRUE
  (ip0->protocol == IP_PROTOCOL_IPSEC_ESP
   || ip0->protocol == IP_PROTOCOL_UDP))
{

  esp0 = (esp_header_t *) ((u8 *) ip0 + ip4_header_bytes (ip0));
  if (PREDICT_FALSE (ip0->protocol == IP_PROTOCOL_UDP))
{
  /* FIXME Skip, if not a UDP encapsulated packet */
  esp0 = (esp_header_t *) ((u8 *) esp0 + sizeof (udp_header_t));
}

CFG :
DUT 1
set int ip address dut1_eth0 192.168.3.1/24
set int promiscuous on dut1_eth0
set ip neighbor dut1_eth0 192.168.0.1 11:22:33:44:55:66
set int ip address dut1_eth1 30.30.30.1/30
set int promiscuous on dut1_eth1
set ip neighbor dut1_eth1 30.30.30.2 11:22:33:44:55:66
ipsec spd add 1
set interface ipsec spd dut1_eth0 1
set interface ipsec spd dut1_eth1 1

ipsec sa add 0 spi 0 esp crypto-alg aes-gcm-128 crypto-key 
31323334353637383930313233343536 salt 0x31323334
ipsec sa add 1 spi 1 esp crypto-alg aes-gcm-128 crypto-key 
31323334353637383930313233343536 salt 0x31323334
ipsec policy add spd 1 priority 10 outbound action protect sa 1 local-ip-range 
10.64.0.0 - 10.64.0.5 remote-ip-range 20.64.0.0 - 20.64.0.5
ipsec policy add spd 1 priority 10 outbound action bypass local-ip-range 
20.64.0.0 - 20.64.0.5 remote-ip-range 10.64.0.0 - 10.64.0.5
ipsec policy add spd 1 priority 10 inbound action protect sa 0 local-ip-range 
10.64.0.0 - 10.64.0.5 remote-ip-range 20.64.0.0 - 20.64.0.5
ip route add 10.64.0.0/30 via 192.168.0.1 dut1_eth0
ip route add 20.64.0.0/30 via 30.30.30.2 dut1_eth1


Proposed solution :  “ipsec4_input_node”   node can compare ingress packet with 
sa->udp_hdr.dst_port and ipsec_sa_is_set_UDP_ENCAP (sa0) at first level of 
check.
That will help in distinguish normal UDP and UDP encapsulated ESP packet. At 
this stage , SA will be fetch from protected inbound policy.


--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22693): https://lists.fd.io/g/vpp-dev/message/22693
Mute This Topic: https://lists.fd.io/mt/97576487/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-