Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Packetbeat] - Enhance DHCPv4 to assocate request/response #7956

Closed
andrewkroh opened this issue Aug 13, 2018 · 2 comments
Closed

[Packetbeat] - Enhance DHCPv4 to assocate request/response #7956

andrewkroh opened this issue Aug 13, 2018 · 2 comments
Labels
enhancement needs_team Indicates that the issue/PR needs a Team:* label Packetbeat Stalled

Comments

@andrewkroh
Copy link
Member

The current DHCPv4 protocol implementation does not associate requests with responses. The protocol is not strictly request -> response or simply one request, one response (there can be one response from each DHCP server for a high-availability deployment).

I think response times could be measured for both discover/offer and request/ack exchanges.

  • DHCPDISCOVER -> DHCPOFFER (multiple offers are possible)
    • Send one event for each offer so that we report the response time for each server.
  • DHCPREQUEST -> DHCPACK/NAK (should be just one)
  • DHCPDECLINE (no measurement)
  • DHCPRELEASE (no measurement)

original comment: #7647 (comment)
@andrewkroh andrewkroh mentioned this issue Jan 15, 2019
Merged
andrewkroh added a commit to andrewkroh/beats that referenced this issue Jan 16, 2019
@andrewkroh
Update DHCPv4 protocol to use ECS fields
2123e0e 
The DHCPv4 protocol dataset works on uni-flows (it's not transacted, see elastic#7956) so
the `source` and `destination` will indicate the original packet header data. Meanwhile
the `client` / `server` fields are copies of the `source`/`destination`, but they are
copied based on which side is the client and server.

Here's a summary of what fields changed.

Part of elastic#7968

Changed

- bytes_in -> source.bytes
- transport -> network.transport = udp

Added

- source
- destination
- event.dataset = dhcpv4
- event.start
- network.bytes
- network.community_id
- network.protocol = dhcpv4
- network.type

Unchanged Packetbeat Fields

- status
- type = dhcpv4 (we might remove this since we have event.dataset)
andrewkroh added a commit that referenced this issue Jan 17, 2019
@andrewkroh
Update DHCPv4 protocol to use ECS fields (#10089)
a16cd5b 
The DHCPv4 protocol dataset works on uni-flows (it's not transacted, see #7956) so
the `source` and `destination` will indicate the original packet header data. Meanwhile
the `client` / `server` fields are copies of the `source`/`destination`, but they are
copied based on which side is the client and server.

Here's a summary of what fields changed.

Part of #7968

Changed

- bytes_in -> source.bytes
- transport -> network.transport = udp

Added

- source
- destination
- event.dataset = dhcpv4
- event.start
- network.bytes
- network.community_id
- network.protocol = dhcpv4
- network.type

Unchanged Packetbeat Fields

- status
- type = dhcpv4 (we might remove this since we have event.dataset)
@botelastic
Copy link

botelastic bot commented Jul 9, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@botelastic botelastic bot added Stalled needs_team Indicates that the issue/PR needs a Team:* label labels Jul 9, 2020
@botelastic
Copy link

botelastic bot commented Jul 9, 2020

This issue doesn't have a Team:<team> label.

@botelastic botelastic bot closed this as completed Aug 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement needs_team Indicates that the issue/PR needs a Team:* label Packetbeat Stalled
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@andrewkroh