Closed sekineh closed 2 years ago
It's been another year and it would be great to see this project maintained again.
I'd be happy to transfer ownership of this crate to someone else who is more interested in maintaining it.
It looks things changed a bit since this issue was reported.
rustcap
and pcap-sys
combination crates Nov 2018.
cargo build
only, though).pcap_compile
, etc) generated by bindgen
.So, if rustcap
and pcap-sys
ecosystem would grow in a good direction, migrating to their crates might be a possible option in a near future.
I would be interested in taking over maintainership of this crate. Sharing the responsibility with others who are also willing to participate. I think it's pretty clear there is interest in this crate and it's still the first search engine hit for "rust pcap".
Over the last week I've been working on my own fork to bring this code base up to date: https://github.com/Wojtek242/pcap:
tokio-core
to the most recent tokio
and futures
immediate_mode
(which is why I bothered forking the crate and doing all this in the first place)I've tried to avoid making any subjective/opinonated decisions so far. The changes above reflect issues that have been raised against this crate over the last few years and that I wanted fixed for myself. There are still some questions to answer going forward, such as what is the oldest version of libpcap that is to be supported. Issue #68 suggested to go from 0.8. When I tried to do that I realised much of the existing API depends on library calls introduced by version 1.0.0 so I decided to go from 1.0.0 instead. However, 1.0.0 is from 2008 and perhaps it would just be easier to not bother going back that far. For example, immediate mode support would be much easier if it went only from 1.5.0 (which was in 2013). Then again, WinPcap is based on 1.0.0.
I've had a look at rustcap
and pcap-sys
, but it appears that after that one PR six months ago it went quiet. It seems that the maintainers have little interest in having anything beyond the FFI bindings. The crates.io also has not been updated. Nothing wrong with that, but I do find the Rust API offered by this crate quite neat. Great work @ebfull!
I'm going to assume @ebfull has no interest in maintaining this crate (though do let me know if anything changed since last year) so I'd be happy to manage the crate on crates.io. Not sure what to do about repositories though. Should I just keep working on the fork? Should an GitHub org be created? Something else?
I've had a look at rustcap and pcap-sys, but it appears that after that one PR six months ago it went quiet. It seems that the maintainers have little interest in having anything beyond the FFI bindings.
I'm not actively using it, and it's not really clear that anyone is (the person who made that PR never followed up on my suggestion to take over ownership). I'd be happy to update the README to point to a well-maintained solution
@jmmk FYI, I'm still using it in production. I can passively maintain the crate no problem. You can add myself and @Wojtek242 as admins to reduce the bus factor.
@ilya-epifanov Ok good to know. I have added @Wojtek242 as a contributor and I see you listed now as an owner on crates.io so hopefully you have the full ability to manage it.
Let me know if you would like to transfer the git repo.
Sorry for the confusion, but I meant that I'm not interested in rustcap
and the related pcap-sys
:) That crate seems to only provide the FFI bindings, whereas this crate pcap
provides a safe Rust interface on top as well. I'm only interested in the pcap
crate as I do want this safe interface.
@Wojtek242 rustcap
has limited usefulness. I wrapped a very small part of the API to accomplish what I was doing at the time. pcap-sys
is maybe somewhat more useful in that it contains a (hopefully) repeatable way to generate complete libpcap bindings.
I agree that the pcap
crate takes a nice approach and in general is more ergonomic and useful. I don't think they are necessarily exclusive however. pcap-sys
for example could be used in place of the raw
module here. Potentially there could be both a low-level API and a high-level API as part of the same crate instead of dividing efforts.
Anyway, I'll leave those decision up to people who actually plan to use/maintain these solutions, but I want you to have the option to change things as needed to suit your use case
I think keeping the pcap-sys
crate around is a good idea, I ran into bugs with the abstractions in the pcap
crate and had to write my own, so I'm depending on it directly.
@Wojtek242
I would be interested in taking over maintainership of this crate. Sharing the responsibility with others who are also willing to participate. I think it's pretty clear there is interest in this crate and it's still the first search engine hit for "rust pcap".
I think I can help the maintenance of this crate. I'm especially interested in windows support and CI. (I also have my own folk of pcap
with Windows CI, but never sent PR.)
I'm going to assume @ebfull has no interest in maintaining this crate (though do let me know if anything changed since last year) so I'd be happy to manage the crate on crates.io. Not sure what to do about repositories though. Should I just keep working on the fork? Should an GitHub org be created? Something else?
I vote for a GitHub org like rust-packet
, rust-capture
, or alike. (Similar to rust-embedded
. I first thought pcap-rs
is the good org name, but it appeared to be taken by another crate name.)
I think keeping the
pcap-sys
crate around is a good idea, I ran into bugs with the abstractions in thepcap
crate and had to write my own, so I'm depending on it directly.
Another option might be to add pcap-raw
feature which exposes raw
module of this crate. Separate repo for -sys
is cleaner setup, but it might duplicate work on both repos.
I agree that the
pcap
crate takes a nice approach and in general is more ergonomic and useful. I don't think they are necessarily exclusive however.pcap-sys
for example could be used in place of theraw
module here. Potentially there could be both a low-level API and a high-level API as part of the same crate instead of dividing efforts.
I agree they are not exclusive. Both crates might be useful and they could probably at some point in the future interact in the way you describe.
Anyway, I'll leave those decision up to people who actually plan to use/maintain these solutions, but I want you to have the option to change things as needed to suit your use case
That's a good point
I think I can help the maintenance of this crate. I'm especially interested in windows support and CI. (I also have my own folk of
pcap
with Windows CI, but never sent PR.)
That would be great. Whilst I made an attempt to get the Windows builds and tests working, I don't actually do dev on Windows. This would be a very complementary setup.
So now, we just need to wait for @ebfull and see what he thinks. If he wants to pass maintainership it would be best if we could also keep this repository with all the issues and PRs, but moved to a github org.
I vote for a GitHub org like rust-packet, rust-capture, or alike. (Similar to rust-embedded. I first thought pcap-rs is the good org name, but it appeared to be taken by another crate name.)
rust-pcap
?
The feasible steps I see are:
ebfull/pcap
to @Wojtek242 and @sekineh if @ebfull would like :-)
1-1. @Wojtek242 and @sekineh will submit code change as a PR, one by one.
1-2. @Wojtek242 and @sekineh will review PRs each other.
1-3. Eventually, other contributors will come.
1-4. Release new version of the crate by @ebfull or team.ebfull/pcap
repository may limit bandwidth (ex. relying on @ebfull for crate release and CI setting changes).rust-pcap/pcap
.What do you whink? @ebfull and @Wojtek242
I'm happy with either. I like the idea of splitting ownership and reviewing each other. Solution 2 would be better if @ebfull doesn't want to maintain the project anymore though, but I'm fine with solution 1 as well.
@sekineh, I got in touch with @ebfull and now we've been added as contributors to the project so we should decide what our next steps should be before we close this issue.
There are two things we should do:
rust-pcap
so that we have full access to settings (CI might require a move). If so, we should just set up the org and have the repo moved.I'll start by preparing the PRs and let @sekineh review them. In the mean-time we can think about where this repo should live.
Following these changes we might as well go straight away and release 0.8.0
before figuring out what next.
Looking forward to your release.
@Wojtek242 your plan looks good to me. Let's start reviewing existing PRs and yours. @ebfull Thanks for the invitation!
Since this issue was last update a while ago, has there been any momentum in the future plans for this crate or maintainer-ship?
@0b00001101 so far Wojtek242 have done a lot of work for the crate, I also want to help but I know little on tokio internal needed so I'm a little limited to the help I can give, but it's on my todo list since I use this in production. But I have not a lot of time left for this currently.
@0b00001101 yes, I'm maintaining the crate right now. I check in roughly once a month to go through PRs and issues as that seems to match the average level of activity. If you have ideas/want to contribute that's more than welcome. I maintain this crate in my spare time so it always takes a back seat to my day job which does keep me busy.
So, I finally hit a snag with ownership in that I cannot modify the settings for GitHub pages to publish code coverage reports :-). Therefore, I guess it's time to follow up with a suggestion that has been thrown some time ago in this thread
I vote for a GitHub org like rust-packet, rust-capture, or alike. (Similar to rust-embedded. I first thought pcap-rs is the good org name, but it appeared to be taken by another crate name.)
@ebfull, could you transfer ownership to the new GitHub organization I created rust-pcap? Also let me know if you would like to added as member/owner of that organization.
For everybody else in this thread. I'm happy to add any contributors so far as a member so just let me know. @sekineh, in particular, let me know if you would like to be added as owner.
Edit: for anybody that's curious I have the current code coverage report on my fork at https://wojtek242.github.io/pcap/. Coverage is pretty poor so I was going for publishing the code coverage and then work on testing.
@Wojtek242 thanks for the work you’ve done. I’d be happy to be included as an owner in the new org though I’m not confident that I can use my time enough for the oss work.
Repo is now in new org closing issue.
@sekineh - in that case, I'll leave the owners as is for now. If you would like to be added to the owners at any point just send me a message saying that you explicitly would like to be added when you feel like it.
First, I like this crate very much and I'd like to say thank you to the author @ebfull .
Unfortunately, the development of the crate is rather inactive since the last Aug 2017. It's about one year. The interesting PRs seem exist but they were never merged nor explicitly rejected (closed). My experience is that I have encountered a trouble building on Windows 64 bit, so I must use the folked version instead of the crates.io version:
Possible organizational improvement I could think of is:
The features I'd like to see in near future includes.
pcap_compile()
.pcap-sys
. Because thepcap
crate tries to be safe by design!pcap
depend onpcap-sys
(Optional)Any ideas?