summaryrefslogtreecommitdiffstats
path: root/src/vnet/dhcp/client.c
AgeCommit message (Collapse)AuthorFilesLines
2019-05-13Fix VPP-1528 get the same IP address from DHCP server for two VPP DHCP clientsjackiechen19851-1/+1
Change-Id: I18dfe51000758f44b991d2dd065c9aa2bc5863d5 Signed-off-by: jackiechen1985 <xiaobo.chen@tieto.com>
2019-05-07Fix af_packet issues:jackiechen19851-2/+3
1. Fix af_packet memory leak; 2. Fix close socket twice; 3. Adjust debug log for syscall; 4. Adjust dhcp client output log; Change-Id: I96bfaef16c4fad80c5da0d9ac602f911fee1670d Signed-off-by: jackiechen1985 <xiaobo.chen@tieto.com>
2019-05-06Fix VPP-1487 DHCP client does not support option 6-domain serverjackiechen19851-5/+23
Change-Id: I36ad1ef2a53af3d3f3a6348bc189b17e9e4e21bd Signed-off-by: jackiechen1985 <xiaobo.chen@tieto.com>
2019-03-29dhcp: only register UDP ports that are neededMatthew Smith1-1/+1
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>
2018-10-23dns, dhcp: on-demand udp port registrationDave Barach1-0/+1
Change-Id: I8bf411adc6c5f4caa349d161174b544d2de3ad1d Signed-off-by: Dave Barach <dave@barachs.net>
2018-10-23c11 safe string handling supportDave Barach1-4/+4
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab Signed-off-by: Dave Barach <dave@barachs.net>
2018-06-07DHCP Client DumpNeale Ranns1-11/+23
- use types on the DHCP API so that the same data is sent in comfing messages and in dumps - add the DHCP client dump API - update VOM to refelct API changes - rename VOM class dhcp_config* dhcp_client* - the VOM dhcp_client class maintains the lease data (which it reads on a dump) for clients to read Change-Id: I2a43463937cbd80c01d45798e74b21288d8b8ead Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
2018-05-27VPP-1294: add missing feature arc constraintDave Barach1-4/+20
the ip4-dhcp-client-detect feature MUST run prior to nat44-out2in, or inbound dhcp broadcast packets will be dropped. Certain dhcp servers answer lease renewal dhcp-request packets with broadcast dhcp-acks, leading to unrecoverable lease loss. In detail, this constraint: VNET_FEATURE_INIT (ip4_snat_out2in, static) = { .arc_name = "ip4-unicast", .node_name = "nat44-out2in", .runs_after = VNET_FEATURES ("acl-plugin-in-ip4-fa"), }; doesn't get the job done: ip4-unicast: [17] nat44-out2in [23] ip4-dhcp-client-detect [26] ip4-not-enabled Add a proper constraint: VNET_FEATURE_INIT (ip4_snat_out2in, static) = { .arc_name = "ip4-unicast", .node_name = "nat44-out2in", .runs_after = VNET_FEATURES ("acl-plugin-in-ip4-fa", "ip4-dhcp-client-detect"), }; and the interface feature order is OK, at least in this regard: ip4-unicast: [17] ip4-dhcp-client-detect [18] nat44-out2in [26] ip4-not-enabled We need to carefully audit (especially) the ip4-unicast feature arc, which has [gasp] 37 features on it! Change-Id: I5e749ead7ab2a25d80839a331de6261e112977ad Signed-off-by: Dave Barach <dave@barachs.net>
2018-05-10DHCP4 client process replies when renewing leaseMatthew Smith1-16/+24
When a DHCP client is in the bound state, it wakes up halfway through it's lease (by default) to try and renew the lease. The ip4-dhcp-client-detect is not enabled as a feature at this point, so replies sent from the DHCP server do not get applied to the lease. Eventually the lease expires, the address is removed from the interface, a new discovery is performed and the same address is added back to the interface. Before sending a request to renew in the bound state, enable the feature to process the reply. Change-Id: I95332ee0596f47df6f3c8bf8e3f0698dde9a1fc5 Signed-off-by: Matthew Smith <mgsmith@netgate.com>
2018-03-23Drop dhcp pkts w/ hardware address mismatchesDave Barach1-11/+37
Add a few dhcp client rx packet/state counters Temporarily disable the dhcp client unit test, since it trips over the newly-added hardware address check. Change-Id: I7f68607e6ed3d738cba357c3fe76664a99b71cd8 Signed-off-by: Dave Barach <dave@barachs.net>
2018-03-21VPP_1202: handle DHCP NAK packetsDave Barach1-1/+27
Change-Id: I469a734747099cef2d135d77e4db0244e24bf0bc Signed-off-by: Dave Barach <dbarach@cisco.com>
2018-02-14Reenable dhcp client detect when lease expiresDave Barach1-1/+50
We disable the client detect feature when we bind a DHCP address. Turn it back on again when the lease expires. Otherwise, if the DHCP server replies after an outage, we'll never see the reply. Add dhcp packet tx counters, by packet type Change-Id: Id54b05647d5d7bd8d3ab99e6584ee86d9e4ff7f9 Signed-off-by: Dave Barach <dave@barachs.net>
2018-02-12Fix DHCP client crash with worker threadsMatthew Smith1-49/+54
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>
2018-01-23For DHCP client configuration control the setting of the broadcast flag in theNeale Ranns1-98/+53
DISCOVER message sent. According to RFC2131: In the case of a client using DHCP for initial configuration (before the client's TCP/IP software has been completely configured), DHCP requires creative use of the client's TCP/IP software and liberal interpretation of RFC 1122. The TCP/IP software SHOULD accept and forward to the IP layer any IP packets delivered to the client's hardware address before the IP address is configured; DHCP servers and BOOTP relay agents may not be able to deliver DHCP messages to clients that cannot accept hardware unicast datagrams before the TCP/IP software is configured. To work around some clients that cannot accept IP unicast datagrams before the TCP/IP software is configured as discussed in the previous paragraph, DHCP uses the 'flags' field [21]. The leftmost bit is defined as the BROADCAST (B) flag. The semantics of this flag are discussed in section 4.1 of this document. The remaining bits of the flags field are reserved for future use. They MUST be set to zero by clients and ignored by servers and relay agents. Figure 2 gives the format of the 'flags' field. this changes means VPP conforms to the: "SHOULD accept and forward to the IP layer any IP packets delivered to the client's hardware address before the IP address is configured" with the caveat that VPP allows DHCP packets destined to the stanard client DHCP port to be delivered. With this enhancement the control-plane is now able to choose the setting of the broadcast flag. Change-Id: Ia4eb2c9bb1e30c29f9192facc645e9533641955a Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-12-09VPP-249 Coding standards cleanup - vnet/vnet/dhcpkhemendra kumar1-430/+402
Change-Id: I45a166b5780675d2bc6fe90595f413725704eaa8 Signed-off-by: khemendra kumar <khemendra.kumar13@gmail.com>
2017-09-20Fix DHCP client so it works for worker threadsJohn Lo1-2/+14
Fix dhcp_client_for_us() function to utilize rpc_call_main_thread to call vlib_process_signal_event() to ensure proper handling irrespective of it being called in main thread or worker thread. Added ASSERT to vlib_process_sinal.. path to make sure it is called in main thread. Change-Id: I4109cc049d8e4225d896ce492ce201011dc9c911 Signed-off-by: John Lo <loj@cisco.com>
2017-08-08L2 over MPLSNeale Ranns1-3/+3
[support for VPWS/VPLS] - switch to using dpo_proto_t rather than fib_protocol_t in fib_paths so that we can describe L2 paths - VLIB nodes to handle pop/push of MPLS labels to L2 Change-Id: Id050d06a11fd2c9c1c81ce5a0654e6c5ae6afa6e Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-08-03DHCP Client: receive unicast ACKsNeale Ranns1-1/+78
despite VPP DHCP client setting neither ciaddr nor giaddr and setting the broadcast bit (see RFC 2131 section 4.1) some DHCP servers will still send a unicast DCHPACK. So as not to drop this VPP must have both 1) a receive FIB entry for the OFFERED IP adress and 2) a 'don't drop me because of uRPF' FIB entry for the DHCP server's address. Change-Id: I167d858deb45629318cbdccf5bf67d971730a42f Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-07-18DHCP client option 61 "client_id"Neale Ranns1-1/+14
the existing seeting of client_id to a VPP version number was unused and so overridden Change-Id: If9ebea936336f1fcca8d07e67186c95f8f8f0ccd Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-07-18DHCP client - remove interface address when DHCP de-configuredNeale Ranns1-0/+1
Change-Id: I63c59e3c13859b51999d283774f7783ef0a6a5ed Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-07-06DHCP complete event sends mask lengthNeale Ranns1-1/+2
Change-Id: I4a529dfab5d0ce6b0bbc0ccbbd89c6b109dbf917 Signed-off-by: Neale Ranns <nranns@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-1/+1
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-1/+1
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>
2017-02-21dhcp: multiple additionsNeale Ranns1-0/+1
DHCP additions: 1) DHCPv4 will only relay a message back to the client, if the Option82 information is present. So make this the default. 2) It is no longer possible to select via the API to "insert circuit ID" - since this is now default 3) Remove the version 2 API since it's now the same as version 1. 4) Adding the VSS option is now conditional only on the presence of VSS config (not the 'insert' option in the set API) 5) DHCP proxy dump via API Change-Id: Ia7271ba8c1d4dbf34a02c401d268ccfbb1b74f17 Signed-off-by: Neale Ranns <nranns@cisco.com>
2016-12-28Reorganize source tree to use single autotools instanceDamjan Marion1-0/+1031
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23 Signed-off-by: Damjan Marion <damarion@cisco.com>