Re: [vpp-dev] [Question] Do you plan to add WireGuard support?

[Neale Ranns via Lists.Fd.Io]

Hi Denis,

It’s something we would like to do, but we have no timeline for it.

/neale

From:  on behalf of Denis Tingajkin 

Date: Monday 16 March 2020 at 16:50
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] [Question] Do you plan to add WireGuard support?

Hello,

I'm interested to use WireGuard tunnel with VPP interfaces, and I've got the 
next question:

1. Do you plan to add WireGuard interface type into VPP?

Also, it will be great if you have any ideas/examples of how WireGuard 
interface can be used with VPP interfaces(AF_PACKET, memif, tap...).


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15798): https://lists.fd.io/g/vpp-dev/message/15798
Mute This Topic: https://lists.fd.io/mt/72001454/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Approve NAT in2out/out2in handoff node index fix in stable/2001 branch also?

[Elias Rudberg]

Hello,

Can someone please approve this change so that we get the fix in the
stable/2001 branch also?

https://gerrit.fd.io/r/c/vpp/+/25861

(it was done in the master branch last week -- see 
https://gerrit.fd.io/r/c/vpp/+/25856 -- then it was cherry picked for
the stable/2001 branch)

Best regards,
Elias
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15799): https://lists.fd.io/g/vpp-dev/message/15799
Mute This Topic: https://lists.fd.io/mt/72020681/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Approve NAT in2out/out2in handoff node index fix in stable/2001 branch also?

[Ole Troan]

Hi Elias,

Merged.

Cheers,
Ole

> On 17 Mar 2020, at 10:59, Elias Rudberg  wrote:
> 
> Hello,
> 
> Can someone please approve this change so that we get the fix in the
> stable/2001 branch also?
> 
> https://gerrit.fd.io/r/c/vpp/+/25861
> 
> (it was done in the master branch last week -- see 
> https://gerrit.fd.io/r/c/vpp/+/25856 -- then it was cherry picked for
> the stable/2001 branch)
> 
> Best regards,
> Elias
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15800): https://lists.fd.io/g/vpp-dev/message/15800
Mute This Topic: https://lists.fd.io/mt/72020681/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] how to create a session from thin air?

[Andreas Schultz]

Hi Florin,

I had a look at how tcp_connection_alloc is used and it looks to me like I
would need to replicate almost all of tcp46_listen_inline to actually get
the TCP connection setup correctly. I was hoping that I could reuse more of
the existing code.

Would you be ok with moving much of the body of tcp46_listen_inline into a
header file, marking it always inline? That way I could reuse it without
having to sync changes back all the time.

Andreas

Am Mo., 16. März 2020 um 19:09 Uhr schrieb Florin Coras <
fcoras.li...@gmail.com>:

> Hi Andreas,
>
> From the info lower, I guess that you want to build a transparent tcp
> terminator/proxy. For that, you’ll be forced to do a) because ip-local path
> is purely for consuming packets whose destination is local ip addresses.
> Moreover, you’ll have to properly classify/match all packets to connections
> and hand them to tcp-input (or better yet tcp-input-nolookup) for tcp
> processing.
>
> Regarding the passing of data, is that at connection establishment or
> throughout the lifetime of the connection? If the former, your classifier
> together with your builtin app will have to instantiate tcp connections and
> sessions “manually” and properly initialize them whenever it detects a new
> flow. APIs like session_alloc and tcp_connection_alloc are already exposed.
>
> Regards,
> Florin
>
> On Mar 16, 2020, at 10:39 AM, Andreas Schultz <
> andreas.schu...@travelping.com> wrote:
>
> Hi,
>
> In our UPF plugin [1], I need to terminate a TCP connection with a
> non-local destination IP *and* pass metadata from the plugin into the
> session.
>
> I have solve this for the moment with some very ugly hacks. Florin Coras
> has rightly criticise those hacks in earlier version of the plugin, but I
> have not found a clean solution, yet.
>
> The UPF plugin is basically a per session mini router instance (that
> wasn't my idea, that is the way the specifications are written). It detects
> a TCP connection that it needs to handle with rules that are unique for a
> given session and then has to apply rules that are also unique per session
> to that TCP connection. For the moment only HTTP with redirect rules are
> handled (your normal captive portal use case).
>
> What I need to do is:
>   a) detect the UPF session and the TCP connection in a packet forwarding
> graph node and create a TCP session from it. The destination IP will not be
> local, so the normal local input does not work.
>   b) pass metadata (the matched session and rule) into the TCP connection.
>
> a) is somewhat doable, but passing metadata from the detection node into
> the session proves challenging (without reimplementing all of the TCP input
> node). There are no fields (except for IP headers) that are passed from the
> vnet buffer into the TCP connection.
>
> Any hints or ideas?
>
> Regards,
> Andreas
>
>
> [1]: https://gerrit.fd.io/r/c/vpp/+/15798
>
> --
>
> Andreas Schultz
>
> --
>
> Principal Engineer
>
> t: +49 391 819099-224
>
> --- enabling your networks
> -
>
> Travelping GmbH
> Roentgenstraße 13
> 39108 Magdeburg
> Germany
>
> t: +49 391 819099-0
> f: +49 391 819099-299
>
> e: i...@travelping.com
> w: https://www.travelping.com/
> Company registration: Amtsgericht Stendal
> Geschaeftsfuehrer: Holger Winkelmann
> Reg. No.: HRB 10578
> VAT ID: DE236673780
> 
>
>
>

-- 

Andreas Schultz

-- 

Principal Engineer

t: +49 391 819099-224

--- enabling your networks
-

Travelping GmbH
Roentgenstraße 13
39108 Magdeburg
Germany

t: +49 391 819099-0
f: +49 391 819099-299

e: i...@travelping.com
w: https://www.travelping.com/
Company registration: Amtsgericht Stendal
Geschaeftsfuehrer: Holger Winkelmann
Reg. No.: HRB 10578
VAT ID: DE236673780
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15801): https://lists.fd.io/g/vpp-dev/message/15801
Mute This Topic: https://lists.fd.io/mt/72004409/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Unable to ping VPP interface when using SRIOV VF

[Satish Singh]

Hi Jerome, Neale, Ole

We were debugging issue regarding IPV6 ping failure between 
Linux_host_interface-->vpp_SRIOV_VF_interface and also between 
vpp_SRIOV_VF_interface <---> vpp_SRIOV_VPP_interface.
While debugging we found that src interface is sending "Neighbour Solicitation" 
with correct destination multicast IP and mac addresses.
SRIOV PF is receiving "Neighbour Solicitation" message but not forwarding it to 
VPP VF.

To make it work, we explicitly set multicast mac address 
33:33:ff:IPv6_byte[2]:IPv6_byte[1]:IPv6_byte[0] on VPP VF interface , using 
dpdk API rte_eth_dev_set_mc_addr_list during IP assignment and IPV6 ping start 
working.

We want to confirm two points:
1) Do we need to explicitly assign multicast mac address in case of IPV6 in 
VPP?, if yes do we need to raise bug on VPP and provide patch for fix.
2) Are we missing some configuration in VPP which might not need above hack.

Versions:
Kernel version: 3.10.0
VPP version: vpp-20.01



Regards,
Satish Singh

From: Lokesh Chimbili
Sent: 26 February 2020 15:48
To: Jerome Tollet (jtollet) 
Cc: Krishnamoney Elayathu ; Mrityunjaya Kumar Altran 
; Neale Ranns (nranns) ; Damjan 
Marion (damarion) ; Prasad Hiremath 
; Venkatarao M ; 
praveenkumar A S ; Venkatesh Narayanaswamy 
; Ole Troan (otroan) ; Mahesh Sivapuram 
; Prashanth Bhaskar ; 
Basawaraj E N ; Satish Singh 
Subject: RE: Unable to ping VPP interface when using SRIOV VF


Hi Jerome, Neale, Ole,

On running “pcap trace tx intfc vpp_eth1” on the VPP interface, we see that 
“Multicast Listener Report Message” messages are not sent whenever we 
add/remove an IPv6 address on the VPP interface using SRIOV VF.

Aren’t these messages expected to be sent? I see them getting sent whenever I 
add/remove an IPv6 address on a linux interface.

I tried subscribing to vpp-dev mailing list.
I’m not receiving any confirmation email, even though I sent an email with the 
subject “I Use Exchange And I'm Not Receiving Group Emails” to 
supp...@groups.io

I’ll repost as soon as the subscription is complete, meanwhile can you please 
take a look at this issue and suggest.

Please find the VPP startup.conf attached.
Please let me know if I need to share any additional information/logs.

VPP version:
vpp-20.01

VPP start:
vpp -c startup.conf

vppctl commands executed:
set interface state vpp_eth1 up
set interface ip address vpp_eth1 fd02:298c:8dfe:0402::::126b/124

i40e driver version:
[root@n4bng1 ~]# ethtool -i sriov0
driver: i40e
version: 2.8.10-k
firmware-version: 4.00 0x800014f3 1.2228.0
expansion-rom-version:
bus-info: :67:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes

NIC Hardware:
67:00.1 Ethernet controller: Intel Corporation Ethernet Connection X722 for 
10GbE SFP+ (rev 09)

OS version:
CentOS Linux release 7.7.1908 (Core)

Kernel version:
3.10.0-1062.el7.x86_64


Thanks and Regards,
Lokesh.C

From: Jerome Tollet (jtollet) [mailto:jtol...@cisco.com]
Sent: 25 February 2020 23:46
To: Lokesh Chimbili
Cc: Krishnamoney Elayathu; Mrityunjaya Kumar Altran; Neale Ranns (nranns); 
Damjan Marion (damarion); Prasad Hiremath; Venkatarao M; praveenkumar A S; 
Venkatesh Narayanaswamy; Ole Troan (otroan); Mahesh Sivapuram; Prashanth 
Bhaskar; Basawaraj E N; Satish Singh
Subject: Re: Unable to ping VPP interface when using SRIOV VF

Hi Lokesh,
May I ask you to repost this question on public mailing list?
Other persons in the future may have similar issue 😉
Jerome

De : Lokesh Chimbili mailto:lchimb...@altiostar.com>>
Date : mardi 25 février 2020 à 18:55
À : Jerome Tollet mailto:jtol...@cisco.com>>
Cc : Krishnamoney Elayathu 
mailto:kelaya...@altiostar.com>>, Mrityunjaya Kumar 
Altran mailto:kmrityunj...@altiostar.com>>, "Neale 
Ranns (nranns)" mailto:nra...@cisco.com>>, Damjan Marion 
mailto:damar...@cisco.com>>, Prasad Hiremath 
mailto:phirem...@altiostar.com>>, Venkatarao M 
mailto:venkatar...@altiostar.com>>, praveenkumar A S 
mailto:pkuma...@altiostar.com>>, Venkatesh 
Narayanaswamy mailto:nve...@altiostar.com>>, Ole Troan 
mailto:otr...@cisco.com>>, Mahesh Sivapuram 
mailto:msivapu...@altiostar.com>>, Prashanth Bhaskar 
mailto:pbhas...@altiostar.com>>, Basawaraj E N 
mailto:bnadaga...@altiostar.com>>, Satish Singh 
mailto:ssi...@altiostar.com>>
Objet : Unable to ping VPP interface when using SRIOV VF

Hi Jerome,

When we use VPP with SRIOV VF we are unable to ping the static IPv6 address 
assigned to the VPP interface.
We tried ping from another SRIOV VF interface bound to the linux 
driver(iavf/i40e) and having a static IPv6 address in the same subnet as shown 
in the figures below,
In both cases we don’t see the IPv6 Neighbour Solicit message reaching the VPP 
interface.

[cid:image001.png@01D5F7A3.2593A2A0]
 Figure (a)

[cid:image002.png@01D5F7A3.2593A2A0]
Figure (b)


However we are able to ping from VPP interface to external

[vpp-dev] Coverity run FAILED as of 2020-03-17 14:00:25 UTC

[Noreply Jenkins]

Coverity run failed today.

Current number of outstanding issues are 2
Newly detected: 0
Eliminated: 0
More details can be found at  
https://scan.coverity.com/projects/fd-io-vpp/view_defects
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15803): https://lists.fd.io/g/vpp-dev/message/15803
Mute This Topic: https://lists.fd.io/mt/72024563/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VPP memif ping taking ~20ms

[Aloys Augustin (aloaugus) via Lists.Fd.Io]

Hi Vyshakh,

This is only configurable in the startup config file. For performance reasons, 
we do not want the VPP threads to move across CPUs.

Thanks
Aloÿs

> On 17 Mar 2020, at 06:29, Vyshakh Krishnan  wrote:
> 
> Thanks Aloys. Setting the main-core to different CPUs helped. ping is taking 
> less than a ms now.
> Is there a way to do it from the code rather than from configuration file? or 
> a way to let linux scheduling decide the CPU?
> 
> Thanks
> Vyshakh
> 
> On Thu, Mar 12, 2020 at 7:24 PM Aloys Augustin (aloaugus)  > wrote:
> Hello,
> 
> For what it’s worth, I observed ~10ms memif pings when both VPPs were 
> scheduled on the same CPU, which happens with the default configuration (VPP 
> takes CPU 1 by default). You can try changing the configuration of one of 
> your VPPs by setting the main-core in the cpu section: 
> https://fd.io/docs/vpp/master/gettingstarted/users/configuring/startup.html 
>  
> 
> Cheers,
> Aloÿs
> 
>> On 12 Mar 2020, at 14:30, vyshakh krishnan > > wrote:
>> 
>> Hi Damjan,
>> 
>> Please find the trace on both side
>> 
>> vpp1 (10.1.1.1)  (10.1.1.2) vpp2
>> 
>> DBGvpp# ping 10.1.1.2
>> 116 bytes from 10.1.1.2 : icmp_seq=1 ttl=64 time=31.8174 ms
>> 116 bytes from 10.1.1.2 : icmp_seq=2 ttl=64 time=47.9716 ms
>> 116 bytes from 10.1.1.2 : icmp_seq=3 ttl=64 time=40.0259 ms
>> 116 bytes from 10.1.1.2 : icmp_seq=4 ttl=64 time=19.9210 ms
>> 116 bytes from 10.1.1.2 : icmp_seq=5 ttl=64 time=39.9568 ms
>> 
>> Statistics: 5 sent, 5 received, 0% packet loss
>> 
>> 
>> VPP1:
>> **
>> 
>> Packet 3
>> 
>> 01:35:02:872114: memif-input
>>   memif: hw_if_index 1 next-index 4
>> slot: ring 0
>> 01:35:02:872132: ethernet-input
>>   frame: flags 0x1, hw-if-index 1, sw-if-index 1
>>   IP4: 02:dc:5c:30:00:00 -> 02:dc:5c:30:00:00
>> 01:35:02:872142: ip4-input
>>   ICMP: 10.1.1.2 -> 10.1.1.1
>> tos 0x00, ttl 64, length 96, checksum 0x36e4
>> fragment id 0x2db5
>>   ICMP echo_reply checksum 0xf86f
>> 01:35:02:872153: ip4-lookup
>>   fib 0 dpo-idx 8 flow hash: 0x
>>   ICMP: 10.1.1.2 -> 10.1.1.1
>> tos 0x00, ttl 64, length 96, checksum 0x36e4
>> fragment id 0x2db5
>>   ICMP echo_reply checksum 0xf86f
>> 01:35:02:872206: ip4-local
>> ICMP: 10.1.1.2 -> 10.1.1.1
>>   tos 0x00, ttl 64, length 96, checksum 0x36e4
>>   fragment id 0x2db5
>> ICMP echo_reply checksum 0xf86f
>> 01:35:02:872215: ip4-icmp-input
>>   ICMP: 10.1.1.2 -> 10.1.1.1
>> tos 0x00, ttl 64, length 96, checksum 0x36e4
>> fragment id 0x2db5
>>   ICMP echo_reply checksum 0xf86f
>> 01:35:02:872224: ip4-icmp-echo-reply
>>   ICMP4 echo id 50293 seq 1 send to cli node 620
>> 
>> Packet 4
>> 
>> 01:35:02:872114: memif-input
>>   memif: hw_if_index 1 next-index 4
>> slot: ring 0
>> 01:35:02:872132: ethernet-input
>>   frame: flags 0x1, hw-if-index 1, sw-if-index 1
>>   ARP: 02:dc:5c:30:00:00 -> ff:ff:ff:ff:ff:ff
>> 01:35:02:872150: arp-input
>>   request, type ethernet/IP4, address size 6/4
>>   02:dc:5c:30:00:00/10.1.1.2  -> 
>> 00:00:00:00:00:00/10.1.1.1 
>> 01:35:02:872163: arp-reply
>>   request, type ethernet/IP4, address size 6/4
>>   02:dc:5c:30:00:00/10.1.1.2  -> 
>> 00:00:00:00:00:00/10.1.1.1 
>> 01:35:02:872219: memif11/11-output
>>   memif11/11 l2_hdr_offset_valid l3_hdr_offset_valid 
>>   ARP: 02:dc:5c:30:00:00 -> 02:dc:5c:30:00:00
>>   reply, type ethernet/IP4, address size 6/4
>>   02:dc:5c:30:00:00/10.1.1.1  -> 
>> 02:dc:5c:30:00:00/10.1.1.2 
>> 
>> Packet 5
>> 
>> 01:35:03:136170: memif-input
>>   memif: hw_if_index 1 next-index 4
>> slot: ring 0
>> 01:35:03:136186: ethernet-input
>>   frame: flags 0x1, hw-if-index 1, sw-if-index 1
>>   IP6: 02:dc:5c:30:00:00 -> 33:33:00:00:00:01
>> 01:35:03:136195: ip6-input
>>   ICMP6: fe80::dc:5cff:fe30:0 -> ff02::1
>> tos 0x00, flow label 0x0, hop limit 255, payload length 32
>>   ICMP router_advertisement checksum 0x57bf
>> 01:35:03:136201: ip6-mfib-forward-lookup
>>   fib 0 entry 4
>> 01:35:03:136209: ip6-mfib-forward-rpf
>>   entry 4 itf 1 flags Accept,
>> 01:35:03:136212: ip6-replicate
>>   replicate: 2 via [@1]: dpo-receive
>> 01:35:03:136217: ip6-local
>> ICMP6: fe80::dc:5cff:fe30:0 -> ff02::1
>>   tos 0x00, flow label 0x0, hop limit 255, payload length 32
>> ICMP router_advertisement checksum 0x57bf
>> 01:35:03:136225: ip6-icmp-input
>>   ICMP6: fe80::dc:5cff:fe30:0 -> ff02::1
>> tos 0x00, flow label 0x0, hop limit 255, payload length 32
>>   ICMP router_advertisement checksum 0x57bf
>> 01:35:03:136228: icmp6-router-advertisement
>>   ICMP6: fe80::dc:5cff:fe30:0 -> ff02::1
>> tos 0x00, flow label 0x0, hop limit 255, payload length 32
>>   ICMP router_advertisement checksum 

[vpp-dev] Unit Test Results in Random directories

[Neale Ranns via Lists.Fd.Io]

Hi All,

Am I the only one who finds the use of random directories for the unit-tests an 
unnecessary annoyance?

I would suggest that random names are not needed for security purposes, since 
these files do not exist on a field system. Also, all directories are wiped 
before the next test run so it can't be to support saving runs nor multiple 
users.

I find it annoying because I can't just reload log.txt or core in my editor or 
debugger.

It's a simple change if there's consensus, or you can just call me and old 
grump and we can all move on __

/neale

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15805): https://lists.fd.io/g/vpp-dev/message/15805
Mute This Topic: https://lists.fd.io/mt/72029031/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Unit Test Results in Random directories

[Klement Sekera via Lists.Fd.Io]

Hi Neale,

When originally designing this, I opted in for `mktemp` as that’s the usual way 
to avoid clashes as at that time I assumed that this might be used on boxes 
where there are multiple users and they might like to run tests in parallel. At 
that time I didn’t expect issues like multiple vpps causing problems and it all 
kinda stuck.

The way I deal with this is using `less /tmp/vpp-unittest-*/log.txt’ (which 
lately requires SANITY=no as it tends to pick log.txt from sanity run). For 
core I use DEBUG=core which gives me gdb without having to think about any of 
the paths.

Having said all that, I don’t see any reason to keep random names. I’m not 
aware of any issues this change my cause…

Regards,
Klement

> On 17 Mar 2020, at 17:56, Neale Ranns via Lists.Fd.Io 
>  wrote:
> 
> 
> Hi All,
> 
> Am I the only one who finds the use of random directories for the unit-tests 
> an unnecessary annoyance?
> 
> I would suggest that random names are not needed for security purposes, since 
> these files do not exist on a field system. Also, all directories are wiped 
> before the next test run so it can't be to support saving runs nor multiple 
> users.
> 
> I find it annoying because I can't just reload log.txt or core in my editor 
> or debugger.
> 
> It's a simple change if there's consensus, or you can just call me and old 
> grump and we can all move on __
> 
> /neale
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15806): https://lists.fd.io/g/vpp-dev/message/15806
Mute This Topic: https://lists.fd.io/mt/72029031/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] how to create a session from thin air?

[Florin Coras]

Hi Andreas, 

Is this [1] enough for now? I'll eventually do some additional tcp refactor to 
make sure we have a generic set of functions that are available for use cases 
when only parts of tcp are re-used. 

Regards,
Florin

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

> On Mar 17, 2020, at 4:20 AM, Andreas Schultz  
> wrote:
> 
> Hi Florin,
> 
> I had a look at how tcp_connection_alloc is used and it looks to me like I 
> would need to replicate almost all of tcp46_listen_inline to actually get the 
> TCP connection setup correctly. I was hoping that I could reuse more of the 
> existing code.
> 
> Would you be ok with moving much of the body of tcp46_listen_inline into a 
> header file, marking it always inline? That way I could reuse it without 
> having to sync changes back all the time.
> 
> Andreas
> 
> Am Mo., 16. März 2020 um 19:09 Uhr schrieb Florin Coras 
> mailto:fcoras.li...@gmail.com>>:
> Hi Andreas, 
> 
> From the info lower, I guess that you want to build a transparent tcp 
> terminator/proxy. For that, you’ll be forced to do a) because ip-local path 
> is purely for consuming packets whose destination is local ip addresses. 
> Moreover, you’ll have to properly classify/match all packets to connections 
> and hand them to tcp-input (or better yet tcp-input-nolookup) for tcp 
> processing.
> 
> Regarding the passing of data, is that at connection establishment or 
> throughout the lifetime of the connection? If the former, your classifier 
> together with your builtin app will have to instantiate tcp connections and 
> sessions “manually” and properly initialize them whenever it detects a new 
> flow. APIs like session_alloc and tcp_connection_alloc are already exposed. 
> 
> Regards,
> Florin
> 
>> On Mar 16, 2020, at 10:39 AM, Andreas Schultz 
>> mailto:andreas.schu...@travelping.com>> 
>> wrote:
>> 
>> Hi,
>> 
>> In our UPF plugin [1], I need to terminate a TCP connection with a non-local 
>> destination IP *and* pass metadata from the plugin into the session.
>> 
>> I have solve this for the moment with some very ugly hacks. Florin Coras has 
>> rightly criticise those hacks in earlier version of the plugin, but I have 
>> not found a clean solution, yet.
>> 
>> The UPF plugin is basically a per session mini router instance (that wasn't 
>> my idea, that is the way the specifications are written). It detects a TCP 
>> connection that it needs to handle with rules that are unique for a given 
>> session and then has to apply rules that are also unique per session to that 
>> TCP connection. For the moment only HTTP with redirect rules are handled 
>> (your normal captive portal use case).
>> 
>> What I need to do is:
>>   a) detect the UPF session and the TCP connection in a packet forwarding 
>> graph node and create a TCP session from it. The destination IP will not be 
>> local, so the normal local input does not work.
>>   b) pass metadata (the matched session and rule) into the TCP connection.
>> 
>> a) is somewhat doable, but passing metadata from the detection node into the 
>> session proves challenging (without reimplementing all of the TCP input 
>> node). There are no fields (except for IP headers) that are passed from the 
>> vnet buffer into the TCP connection.
>> 
>> Any hints or ideas?
>> 
>> Regards,
>> Andreas
>> 
>> 
>> [1]: https://gerrit.fd.io/r/c/vpp/+/15798 
>> 
>> 
>> -- 
>> Andreas Schultz
>> 
>> -- 
>> 
>> Principal Engineer
>> 
>> t: +49 391 819099-224
>> 
>> 
>> --- enabling your networks 
>> -
>> 
>> Travelping GmbH 
>> Roentgenstraße 13
>> 39108 Magdeburg
>> Germany
>> 
>> 
>> t: +49 391 819099-0
>> f: +49 391 819099-299
>> 
>> e: i...@travelping.com 
>> w: https://www.travelping.com/ 
>> Company registration: Amtsgericht Stendal 
>> Geschaeftsfuehrer: Holger Winkelmann
>> Reg. No.: HRB 10578
>> VAT ID: DE236673780
>> 
> 
> 
> 
> -- 
> Andreas Schultz
> 
> -- 
> 
> Principal Engineer
> 
> t: +49 391 819099-224
> 
> 
> --- enabling your networks 
> -
> 
> Travelping GmbH 
> Roentgenstraße 13
> 39108 Magdeburg
> Germany
> 
> 
> t: +49 391 819099-0
> f: +49 391 819099-299
> 
> e: i...@travelping.com 
> w: https://www.travelping.com/ 
> Company registration: Amtsgericht Stendal 
> Geschaeftsfuehrer: Holger Winkelmann
> Reg. No.: HRB 10578
> VAT ID: DE236673780

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15807): https://lists.fd.io/g/vpp-dev/message/15807
Mute This Topic: https://lists.fd.io/mt/72004409/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Unit Test Results in Random directories

[Paul Vinciguerra]

I'm ok with a change, but are you thinking about setting the tempdir to a
constant, or do you want to remove the unix { runtime-dir } option from the
startup?

On Tue, Mar 17, 2020 at 1:04 PM Klement Sekera via Lists.Fd.Io  wrote:

> Hi Neale,
>
> When originally designing this, I opted in for `mktemp` as that’s the
> usual way to avoid clashes as at that time I assumed that this might be
> used on boxes where there are multiple users and they might like to run
> tests in parallel. At that time I didn’t expect issues like multiple vpps
> causing problems and it all kinda stuck.
>
> The way I deal with this is using `less /tmp/vpp-unittest-*/log.txt’
> (which lately requires SANITY=no as it tends to pick log.txt from sanity
> run). For core I use DEBUG=core which gives me gdb without having to think
> about any of the paths.
>
> Having said all that, I don’t see any reason to keep random names. I’m not
> aware of any issues this change my cause…
>
> Regards,
> Klement
>
> > On 17 Mar 2020, at 17:56, Neale Ranns via Lists.Fd.Io  cisco@lists.fd.io> wrote:
> >
> >
> > Hi All,
> >
> > Am I the only one who finds the use of random directories for the
> unit-tests an unnecessary annoyance?
> >
> > I would suggest that random names are not needed for security purposes,
> since these files do not exist on a field system. Also, all directories are
> wiped before the next test run so it can't be to support saving runs nor
> multiple users.
> >
> > I find it annoying because I can't just reload log.txt or core in my
> editor or debugger.
> >
> > It's a simple change if there's consensus, or you can just call me and
> old grump and we can all move on __
> >
> > /neale
> >
> >
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15808): https://lists.fd.io/g/vpp-dev/message/15808
Mute This Topic: https://lists.fd.io/mt/72029031/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Unit Test Results in Random directories

[Neale Ranns via Lists.Fd.Io]

Hi Paul,

My only intent is to remove the randomness of mktemp:
  https://gerrit.fd.io/r/c/vpp/+/25973

/neale

From: Paul Vinciguerra 
Date: Wednesday 18 March 2020 at 02:11
To: "Klement Sekera -X (ksekera - PANTHEON TECH SRO at Cisco)" 

Cc: "Neale Ranns (nranns)" , vpp-dev 
Subject: Re: [vpp-dev] Unit Test Results in Random directories

I'm ok with a change, but are you thinking about setting the tempdir to a 
constant, or do you want to remove the unix { runtime-dir } option from the 
startup?

On Tue, Mar 17, 2020 at 1:04 PM Klement Sekera via 
Lists.Fd.Io 
mailto:cisco@lists.fd.io>> wrote:
Hi Neale,

When originally designing this, I opted in for `mktemp` as that’s the usual way 
to avoid clashes as at that time I assumed that this might be used on boxes 
where there are multiple users and they might like to run tests in parallel. At 
that time I didn’t expect issues like multiple vpps causing problems and it all 
kinda stuck.

The way I deal with this is using `less /tmp/vpp-unittest-*/log.txt’ (which 
lately requires SANITY=no as it tends to pick log.txt from sanity run). For 
core I use DEBUG=core which gives me gdb without having to think about any of 
the paths.

Having said all that, I don’t see any reason to keep random names. I’m not 
aware of any issues this change my cause…

Regards,
Klement

> On 17 Mar 2020, at 17:56, Neale Ranns via Lists.Fd.Io 
> mailto:cisco@lists.fd.io>> wrote:
>
>
> Hi All,
>
> Am I the only one who finds the use of random directories for the unit-tests 
> an unnecessary annoyance?
>
> I would suggest that random names are not needed for security purposes, since 
> these files do not exist on a field system. Also, all directories are wiped 
> before the next test run so it can't be to support saving runs nor multiple 
> users.
>
> I find it annoying because I can't just reload log.txt or core in my editor 
> or debugger.
>
> It's a simple change if there's consensus, or you can just call me and old 
> grump and we can all move on __
>
> /neale
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15809): https://lists.fd.io/g/vpp-dev/message/15809
Mute This Topic: https://lists.fd.io/mt/72029031/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-