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.

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

Fix spawn source subcommand #954

Merged
merged 33 commits into from
Jul 3, 2020
Merged

Fix spawn source subcommand #954

merged 33 commits into from
Jul 3, 2020

Conversation

tobim
Copy link
Member

@tobim tobim commented Jun 26, 2020

No description provided.

@tobim tobim added the bug Incorrect behavior label Jun 26, 2020
@tobim tobim force-pushed the story/ch17783/fix-spawn-source branch from 406781c to 561a969 Compare June 28, 2020 21:14
@tobim tobim marked this pull request as ready for review June 29, 2020 09:44
@tobim tobim requested a review from a team June 29, 2020 11:28
mavam
mavam previously requested changes Jun 29, 2020
libvast/src/system/node.cpp Show resolved Hide resolved
libvast/src/system/node.cpp Outdated Show resolved Hide resolved
libvast/src/detail/line_range.cpp Show resolved Hide resolved
@mavam
Copy link
Member

mavam commented Jun 29, 2020

I haven't seen any unit or integration tests yet. What was your strategy in this regard?

@mavam
Copy link
Member

mavam commented Jun 29, 2020

When I test this locally, I get the following warning in vast start:

2020-06-29T14:09:19.767 spawn_command got an error from spawn_component: none

@mavam
Copy link
Member

mavam commented Jun 29, 2020

I tried vast spawn source pcap -i em0 and get a segfault:

Target 0: (vast) stopped.
(lldb) bt
* thread #2, name = 'caf.multiplexer', stop reason = EXC_BAD_ACCESS (code=1, address=0x368)
  * frame #0: 0x00007fff6e6b3148 libpcap.A.dylib`pcap_stats + 4
    frame #1: 0x0000000100597d7d libvast.2020.dylib`::status() at pcap.cpp:127:18 [opt]
    frame #2: 0x00000001003755b8 libvast.2020.dylib`::send_report() at source.hpp:181:30 [opt]
    frame #3: 0x0000000100374b0e libvast.2020.dylib`::operator()() [inlined] operator() at source.hpp:261:12 [opt]

@tobim
Copy link
Member Author

tobim commented Jun 29, 2020

When I test this locally, I get the following warning in vast start:

2020-06-29T14:09:19.767 spawn_command got an error from spawn_component: none

I missed that. I think this is because of the eraser. spawn_node tries to create one but spawn_eraser returns early with ec::no_error if no aging query is configured. I believe this should be handled by explicitly not printing a warning in case of no_error.

@tobim
Copy link
Member Author

tobim commented Jun 29, 2020

I tried vast spawn source pcap -i em0 and get a segfault:

I don't know what's causing this, can you vast import pcap -i em0?

@tobim tobim force-pushed the story/ch17783/fix-spawn-source branch from 21a2df9 to da11c90 Compare June 29, 2020 14:13
@tobim
Copy link
Member Author

tobim commented Jun 29, 2020

I haven't seen any unit or integration tests yet. What was your strategy in this regard?

Commands should be covered by integration tests in general. I'm still thinking about how this can be worked into the dsl.

@mavam
Copy link
Member

mavam commented Jun 29, 2020

I'm already getting a segfault when I run vast spawn source pcap, without any params.

Backtrace:

    frame #0: 0x000000010042b7b9 libvast.2020.dylib`::spawn_command() [inlined] __tree at __tree:1726:42 [opt]
    frame #1: 0x000000010042b784 libvast.2020.dylib`::spawn_command() [inlined] __tree at __tree:1721 [opt]
    frame #2: 0x000000010042b784 libvast.2020.dylib`::spawn_command() [inlined] map at map:1031 [opt]
    frame #3: 0x000000010042b784 libvast.2020.dylib`::spawn_command() [inlined] map at map:1032 [opt]
  * frame #4: 0x000000010042b784 libvast.2020.dylib`::spawn_command() [inlined] dictionary at dictionary.hpp:89 [opt]
    frame #5: 0x000000010042b784 libvast.2020.dylib`::spawn_command() [inlined] dictionary at dictionary.hpp:89 [opt]
    frame #6: 0x000000010042b784 libvast.2020.dylib`::spawn_command() [inlined] get<caf::dictionary<caf::config_value> > at settings.hpp:61 [opt]
    frame #7: 0x000000010042b765 libvast.2020.dylib`::spawn_command() at node.cpp:341 [opt]
    frame #8: 0x0000000100131cff libvast.2020.dylib`::run() [inlined] __invoke<caf::message (*const &)(const vast::invocation &, caf::actor_system &), vast::invocation &, caf::actor_system &> at type_traits:4425:1 [opt]
    frame #9: 0x0000000100131cf7 libvast.2020.dylib`::run() [inlined] invoke<caf::message (*const &)(const vast::invocation &, caf::actor_system &), vast::invocation &, caf::actor_system &> at functional:2848 [opt]
    frame #10: 0x0000000100131cf7 libvast.2020.dylib`::run() at command.cpp:433 [opt]

@mavam
Copy link
Member

mavam commented Jun 29, 2020

I don't know what's causing this [...]

How did you test invalid parameters on the command line? This always causes segfaults for me, like this one ☝️.

@dominiklohmann
Copy link
Member

I'll give this a spin to try reproducing the issues locally.

@dominiklohmann
Copy link
Member

I can reproduce the changes mentioned by @tobim locally on macOS.

The PCAP source spawned by the node hangs after forwarding to the importer once. Sadly we don't have good enough trace logs for the PCAP source, which is what we should start with.

I cannot, however, reproduce the issues mentioned by @mavam. I think something may be messed up on your end.

@dominiklohmann
Copy link
Member

Upon further investigation, the PCAP source inside the node seems to be down after a while. Sending a status atom to the source returns with request_receiver_down after the configured timeout.

tobim and others added 10 commits July 2, 2020 10:13
When a line_range was created on stdin in an actor context, the
actor would wait until data was available, and would not be able
to handle other messages in the meantime.

This happened with the `spawn source` command, which was an easy
way to "dos" the node.
Co-authored-by: Matthias Vallentin <matthias@tenzir.com>
@dominiklohmann dominiklohmann force-pushed the story/ch17783/fix-spawn-source branch from da47787 to 8bc4946 Compare July 2, 2020 08:18
fixture: ServerTester
steps:
- command: spawn source suricata -r @./data/suricata/eve.json
- command: import -b zeek
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a comment explaining why this is necessary?

@dominiklohmann
Copy link
Member

We should add changelog entries for the other fixes we made as well @tobim.

@dominiklohmann dominiklohmann force-pushed the story/ch17783/fix-spawn-source branch from 86a48e9 to e5ec970 Compare July 3, 2020 06:11
@tobim tobim force-pushed the story/ch17783/fix-spawn-source branch 2 times, most recently from dd97b28 to cb640ae Compare July 3, 2020 09:04
@tobim tobim force-pushed the story/ch17783/fix-spawn-source branch from cb640ae to d301f6f Compare July 3, 2020 10:33
Copy link
Member Author

@tobim tobim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I consider the changes by @dominiklohmann in this PR ready to merge.

Copy link
Member

@dominiklohmann dominiklohmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving @tobim's side of things here.

@tobim tobim merged commit aeb3f46 into master Jul 3, 2020
@tobim tobim deleted the story/ch17783/fix-spawn-source branch July 3, 2020 13:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Incorrect behavior
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants