aboutsummaryrefslogtreecommitdiffstats
path: root/src/vnet/dhcp/dhcp4_proxy_node.c
AgeCommit message (Collapse)AuthorFilesLines
2019-08-15vlib: copy trace_handle in vlib_buffer_copy/clone() functionsJohn Lo1-1/+0
Since vlib_buffer_copy() and vlib_buffer_clone() both preserve VLIB_BUFFER_IS_TRACED bit in flags field, it should also copy trace_handle which would add minimal overhead. Thus, callers of these functions do not have to call vlib_buffer_copy_trace_flags() to copy trace_handle. Type: refactor Signed-off-by: John Lo <loj@cisco.com> Change-Id: Iff6a3f81660dd62b36a2966033eb380305340310
2019-03-29dhcp: only register UDP ports that are neededMatthew Smith1-8/+11
When configuring a DHCP client, both the UDP ports for DHCP client and server are registered. Packets to the server port end up being dropped unless you have also configured a DHCP proxy. This breaks a common home/office gateway use case where the WAN interface gets configured using a DHCP client and devices attached to a LAN interface attempt to configure themselves using DHCP. If you try to punt to an external DHCP daemon to handle the LAN client requests, the packets never make it to the external daemon because of the server port being registered. Modify dhcp_maybe_register_udp_ports() to accept a parameter that controls which ports get registered. For a DHCP client, only the client port is registered. For a DHCP proxy, both client and server ports are registered. Change-Id: I2182d9827e4c7424b03ebb94952c3d2dc37abdb6 Signed-off-by: Matthew Smith <mgsmith@netgate.com>
2019-02-25buffer chain linearizationKlement Sekera1-3/+10
Rewrite vlib_buffer_chain_linearize function so that it works as intended. Linearize buffer chains coming out of reassembly to work around some dpdk-tx issues. Note that this is not a complete workaround as a sufficiently large packet will still cause the resulting chain to be too long. Drop features from reassembly code which relies on knowing which and how many buffers were freed during linearization, buffer counts and tracing capabilities for these cases. Change-Id: Ic65de53ecb5c78cd96b178033f6a576ab4060ed1 Signed-off-by: Klement Sekera <ksekera@cisco.com>
2019-02-18DHCP: trace flags copied from old to new not vice-versaNeale Ranns1-1/+1
Change-Id: I6c13af7e97753da013cdd5b212302d008cbd616d Signed-off-by: Neale Ranns <nranns@cisco.com>
2018-11-29DHCP: Initialise trace for copied buffers.Ole Troan1-0/+2
DHCP tests failed intermittantly with a core dump. Let's see if this fixes it. Change-Id: I42829a2c7e7f5a9a6775330d37bf972ff0008210 Signed-off-by: Ole Troan <ot@cisco.com>
2018-11-20dhcp4:(VPP-1483) linearize chained packets before handlingEyal Bari1-41/+41
dhcp packets might (when flooded) arrive in chains of cloned buffers Change-Id: Ifddecd656b6a5d6ba8cd94184f5c021684e35548 Signed-off-by: Eyal Bari <ebari@cisco.com>
2018-10-23dns, dhcp: on-demand udp port registrationDave Barach1-5/+20
Change-Id: I8bf411adc6c5f4caa349d161174b544d2de3ad1d Signed-off-by: Dave Barach <dave@barachs.net>
2018-10-23c11 safe string handling supportDave Barach1-3/+3
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab Signed-off-by: Dave Barach <dave@barachs.net>
2018-02-12Fix DHCP client crash with worker threadsMatthew Smith1-1/+1
Crash occurring With a worker thread configured and dhcp client active on an interface. When a DHCP reply packet is received, call to ethernet_get_main() from dhcp_proxy_to_client_input() was causing a crash. Replaced with a call to vnet_get_ethernet_main(). Once that was resolved, calling dhcp_client_acquire_address() from a worker thread also caused a crash. Changed so the main thread will do the address/route configuration. Change-Id: Ib23984787102dea8cf6cfcde86188a751f15c1e1 Signed-off-by: Matthew Smith <mgsmith@netgate.com>
2017-12-09VPP-249 Coding standards cleanup - vnet/vnet/dhcpkhemendra kumar1-578/+591
Change-Id: I45a166b5780675d2bc6fe90595f413725704eaa8 Signed-off-by: khemendra kumar <khemendra.kumar13@gmail.com>
2017-11-16Add Support of DHCP VSS Type 0 where VPN-ID is ASCIIJohn Lo1-89/+72
Enhence support of DHCP VSS (Virtual Subnet Selection) to include VSS type 0 where VSS info is a NVT (Network Virtual Terminal) ASCII VPN ID where the ASCII string MUST NOT be terminated with a zero byte. Existing code already support VSS type 1, where VSS information is a RFC 2685 VPN-ID of 7 bytes with 3 bytes OUI and 4 bytes VPN index, and VSS type 255 indicating global VPN. Change-Id: I54edbc447c89a2aacd1cc9fc72bd5ba386037608 Signed-off-by: John Lo <loj@cisco.com>
2017-09-11FIB table add/delete APINeale Ranns1-4/+5
part 2; - this adds the code to create an IP and MPLS table via the API. - but the enforcement that the table must be created before it is used is still missing, this is so that CSIT can pass. Change-Id: Id124d884ade6cb7da947225200e3bb193454c555 Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-07-14Introduce l{2,3,4}_hdr_offset fields in the buffer metadataDamjan Marion1-1/+1
To save space in the first cacheline following is changed: - total_length_not_including_first_buffer moved to the 2nd cacheline. This field is used only when VLIB_BUFFER_TOTAL_LENGTH_VALID and VLIB_BUFFER_NEXT_PRESENT are both set. - free_list_index is now stored in 4bits inside flags, which allows up to 16 free lists. In case we need more we can store index in the 2nd cachelin Change-Id: Ic8521350819391af470d31d3fa1013e67ecb7681 Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-04-13Remove unsed parameter from fib_table_entry_special_add() (only used in FIB ↵Neale Ranns1-2/+1
tests). The DPO was incorrectly initialised with FIB_PROTO_MAX Change-Id: I962df9e162e4dfb6837a5ce79ea795d5ff2d7315 Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-03-07DHCP Multiple Servers (VPP-602, VPP-605)Neale Ranns1-33/+118
Multiple DHCP (4 and/or 6) servers can be added and removed through multiple calls to the 'set dhcp server' API. All 4/6/ discover/solicit messages will then be replicated to all servers in the list. The expectation is that the servers/system is configured in such a way that this is viable. If VSS information is providied for the clinet VRF which also has multiple servers configured, then the same VSS information is sent to each server. Likewise the source address of packets sent to from VPP to each server is the same. Change-Id: I3287cb084c84b3f612b78bc69cfcb5b9c1f8934d Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-02-16Consolidate DHCP v4 and V6 implementation. No functional change intendedNeale Ranns1-0/+983
The DHCP proxy and VSS information maintained by VPP is the same for v4 and v6, so we can manage this state using the same code. Packet handling is cleary different, so this is kept separate. Change-Id: I10f10cc1f7f19debcd4c4b099c6de64e56bb0c69 Signed-off-by: Neale Ranns <nranns@cisco.com>