Re: [tcpdump-workers] So which is cooler - tcpdump on your wrist or tcpdump on your Mac's Touch Bar?
--- Begin Message ---
i don't know about iOS, but on Android tcpdump is only on engineering
builds ("userdebug" and "eng" builds, for those familiar with such
things), not shipped on production devices ("user builds").
(at least not by default. an OEM could change that, but they tend to lean
in the opposite direction.)
On Tue, Jan 5, 2021 at 5:58 PM Guy Harris via tcpdump-workers <
tcpdump-workers@lists.tcpdump.org> wrote:
>
>
>
> -- Forwarded message --
> From: Guy Harris
> To: tcpdump-workers
> Cc:
> Bcc:
> Date: Tue, 5 Jan 2021 17:58:14 -0800
> Subject: So which is cooler - tcpdump on your wrist or tcpdump on your
> Mac's Touch Bar?
> $ curl -s
> https://opensource.apple.com/source/tcpdump/tcpdump-100/tcpdump.xcodeproj/project.pbxproj.auto.html
> | egrep SUPPORTED_PLATFORMS
> SUPPORTED_PLATFORMS = macosx
> iphoneos appletvos watchos bridgeos;
> SUPPORTED_PLATFORMS = macosx
> iphoneos appletvos watchos bridgeos;
>
> (bridgeOS is the apparently-watchOS-derived OS that runs on the T-series
> chips that run the Touch Bar on Touch Bar Macs and that handle secure
> booting and possibly some other security stuff.)
>
> I don't know whether it ships on iOS/iPadOS/tvOS/watchOS/bridgeOS or is
> just built to be used in-house.
>
>
> -- Forwarded message --
> From: Guy Harris via tcpdump-workers
> To: tcpdump-workers
> Cc:
> Bcc:
> Date: Tue, 5 Jan 2021 17:58:14 -0800
> Subject: [tcpdump-workers] So which is cooler - tcpdump on your wrist or
> tcpdump on your Mac's Touch Bar?
> ___
> tcpdump-workers mailing list
> tcpdump-workers@lists.tcpdump.org
> https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] clean exit from tcpdump with asan
--- Begin Message --- On Tue, Oct 27, 2020 at 5:42 AM Michael Richardson wrote: > > > enh via tcpdump-workers wrote: > > this patch fixes the use-after-free of `pd`, and also fixes the leak > > of `device`. let me know if you need this uploaded to github > > instead... > > Please make a pull request. > That enables all sorts of cross-builds. done: https://github.com/the-tcpdump-group/tcpdump/pull/888 > I am thinking about how we might test signals during processing in a > deterministic way. yeah, the crash dump i have is from someone's test device. personally i added sleep()s to be able to win races manually, but i don't know how to unit test this. > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works|IoT architect [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails > [ > --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] clean exit from tcpdump with asan
--- Begin Message ---
this patch fixes the use-after-free of `pd`, and also fixes the leak
of `device`. let me know if you need this uploaded to github
instead...
diff --git a/tcpdump.c b/tcpdump.c
index 658d8b34..4fa390fd 100644
--- a/tcpdump.c
+++ b/tcpdump.c
@@ -2239,8 +2239,12 @@ main(int argc, char **argv)
error("%s", pcap_geterr(pd));
if (dflag) {
bpf_dump(, dflag);
- pcap_close(pd);
+ /* Clear pd so our signal handler won't use-after-free it. */
+ pcap_t *to_free = pd;
+ pd = NULL;
+ pcap_close(to_free);
free(cmdbuf);
+ free(device);
pcap_freecode();
exit_tcpdump(S_SUCCESS);
}
@@ -2559,7 +2563,10 @@ DIAG_ON_CLANG(assign-enum)
*/
info(1);
}
- pcap_close(pd);
+ /* Clear pd so our signal handler won't use-after-free it. */
+ pcap_t *to_free = pd;
+ pd = NULL;
+ pcap_close(to_free);
if (VFileName != NULL) {
ret = get_next_file(VFile, VFileLine);
if (ret) {
@@ -2640,6 +2647,7 @@ DIAG_ON_CLANG(assign-enum)
PLURAL_SUFFIX(packets_captured));
free(cmdbuf);
+ free(device);
pcap_freecode();
exit_tcpdump(status == -1 ? 1 : 0);
}
@@ -2692,7 +2700,8 @@ cleanup(int signo _U_)
* to do anything with standard I/O streams in a signal handler -
* the ANSI C standard doesn't say it is).
*/
- pcap_breakloop(pd);
+ if (pd != NULL)
+ pcap_breakloop(pd);
#else
/*
* We don't have "pcap_breakloop()"; this isn't safe, but
On Wed, Oct 14, 2020 at 2:28 PM enh wrote:
>
> i haven't reproduced it myself yet (though i'll try shortly) but we
> got an automated crash report from tcpdump on Android via
> [gwp-asan](https://developer.android.com/ndk/guides/gwp-asan).
>
> the bug is a use-after-free, specifically when pcap_breakloop() tries
> to write to the already-freed struct pcap_t. this happens if a signal
> is received during tcpdump shutdown (which is presumably why we
> haven't hit this more often on ASan/HWASan builds).
>
> i assume the fix is to disable the signal handlers before calling
> pcap_close() to free the struct pcap_t, but i thought i'd bring this
> up on the list before i (a) look at reproducing this locally and (b)
> send a patch...
diff --git a/tcpdump.c b/tcpdump.c
index 658d8b34..4fa390fd 100644
--- a/tcpdump.c
+++ b/tcpdump.c
@@ -2239,8 +2239,12 @@ main(int argc, char **argv)
error("%s", pcap_geterr(pd));
if (dflag) {
bpf_dump(, dflag);
- pcap_close(pd);
+ /* Clear pd so our signal handler won't use-after-free it. */
+ pcap_t *to_free = pd;
+ pd = NULL;
+ pcap_close(to_free);
free(cmdbuf);
+ free(device);
pcap_freecode();
exit_tcpdump(S_SUCCESS);
}
@@ -2559,7 +2563,10 @@ DIAG_ON_CLANG(assign-enum)
*/
info(1);
}
- pcap_close(pd);
+ /* Clear pd so our signal handler won't use-after-free it. */
+ pcap_t *to_free = pd;
+ pd = NULL;
+ pcap_close(to_free);
if (VFileName != NULL) {
ret = get_next_file(VFile, VFileLine);
if (ret) {
@@ -2640,6 +2647,7 @@ DIAG_ON_CLANG(assign-enum)
PLURAL_SUFFIX(packets_captured));
free(cmdbuf);
+ free(device);
pcap_freecode();
exit_tcpdump(status == -1 ? 1 : 0);
}
@@ -2692,7 +2700,8 @@ cleanup(int signo _U_)
* to do anything with standard I/O streams in a signal handler -
* the ANSI C standard doesn't say it is).
*/
- pcap_breakloop(pd);
+ if (pd != NULL)
+ pcap_breakloop(pd);
#else
/*
* We don't have "pcap_breakloop()"; this isn't safe, but
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] clean exit from tcpdump with asan
--- Begin Message --- i haven't reproduced it myself yet (though i'll try shortly) but we got an automated crash report from tcpdump on Android via [gwp-asan](https://developer.android.com/ndk/guides/gwp-asan). the bug is a use-after-free, specifically when pcap_breakloop() tries to write to the already-freed struct pcap_t. this happens if a signal is received during tcpdump shutdown (which is presumably why we haven't hit this more often on ASan/HWASan builds). i assume the fix is to disable the signal handlers before calling pcap_close() to free the struct pcap_t, but i thought i'd bring this up on the list before i (a) look at reproducing this locally and (b) send a patch... --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Precompiled binaries or compile script needed for Android
On Sat, Jul 21, 2018 at 2:34 PM Michael Richardson wrote: > > enh wrote: > >> secur...@tcpdump.org is not an appropriate place to ask about > binaries. > >> Sometime on tcpdump-workers might be able to help you. > >> https://www.androidtcpdump.com/ also is around. > >> I don't know who runs it. > >> > >> I spent some time trying to integrate the Android (ASOP) build > system > >> Makefiles into tcpdump, but it never went upstream, and I ran out of > >> time. > > > as the AOSP maintainer of external/tcpdump and external/libpcap, i > don't > > think that would help you or me. it's usually just a pain for us > when an > > upstream project has an Android.mk because then we have to > coordinate for > > build system changes that no-one outside of AOSP actually cares > about. > > And if we could bring you into the fold, then you could maintain the file > you want? > even for projects where i have an upstream commit bit, it's not helpful to either side to have the Android.mk in the upstream project. Android's compiler toolchain gets updated frequently, so it's often necessary to slip in a -Wno-new-warning-that-a-project-doesn't-care-about or whatever. there's also the need to work around the mismatch between autoconf (or equivalent) and Android's single tree for four architectures with generated files checked in: that sometimes leads to Android.mk effectively taking over the role of config.h itself. and at the same time, there's no benefit to upstream from keeping an Android.mk that's only useful in AOSP and that they can't usually test themselves anyway. and why would they? even on very beefy machines, an AOSP build isn't quick. and the download is even worse. what _would_ be useful: 1. if it was easier for folks to build with the NDK. but we think it scales better if we get to the point where it's trivial to cross compile. like i said, if you know how to set up a suitable cross-compilation toolchain you can already build tcpdump out of the box with configure/make. and as i said, the next step is to remove the need to set up a cross-compilation toolchain ( https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md). and i really need to get around to publishing a script that hides even that, so it's more of an "apt-get" kind of experience. we're working on it... 2. if AOSP was always up to date. i know historically a lot of projects were added to external/ and then left to rot, but my team has been trying to clean that up, and libpcap/tcpdump were actually fairly early beneficiaries. i removed all local hacks some time ago and the reason i'm on this mailing list is because there isn't a separate -announce mailing list :-) i have someone working on automating updates of projects hosted on github, though, so hopefully we'll be able to take the human out of the loop for libpcap this (1.9.0 release... > (luckily since we switched to Android.bp i haven't seen any upstream > > project even think it might be a good idea for them to have one of > those!) > > ha. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works| network > architect [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on > rails[ > > ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Precompiled binaries or compile script needed for Android
On Fri, Jul 20, 2018 at 4:12 PM Michael Richardson wrote: > secur...@tcpdump.org is not an appropriate place to ask about binaries. > Sometime on tcpdump-workers might be able to help you. > https://www.androidtcpdump.com/ also is around. > I don't know who runs it. > > I spent some time trying to integrate the Android (ASOP) build system > Makefiles into tcpdump, but it never went upstream, and I ran out of time. > as the AOSP maintainer of external/tcpdump and external/libpcap, i don't think that would help you or me. it's usually just a pain for us when an upstream project has an Android.mk because then we have to coordinate for build system changes that no-one outside of AOSP actually cares about. (luckily since we switched to Android.bp i haven't seen any upstream project even think it might be a good idea for them to have one of those!) > Emin Kokalari via tcpdump-security wrote: > > Hello there, i have tried many way to generate working binary for x86 > > Android tcpdump binary but can't build it. > > My application is : > > > https://play.google.com/store/apps/details?id=com.eakteam.networkmanager > > > I think that this is the best Network app with almost everything > > implemented and included and tcpdump is missing there :) , i think > > would be great to implement it too. > > > Can you please help me with precompiled binaries for : > > armeabi-v7a , arm64, x86 , or provide a working script to compile it > > myself ? > > P.s i have tried many scripts in GitHub and other sources but no > > working with latest NDK (R17B) , i have tried Cross Compiling too and > > it's the same.. > tcpdump and libpcap build out of the box with the NDK. you'll want to use a standalone toolchain and point configure at it. instructions and an example are on the web: https://developer.android.com/ndk/guides/standalone_toolchain > > Best regards. > > > Emin Kokalari > > > IT Specialist ; Programmer > > Cel : +355695852885 > > http://www.eakteam.com/ > > " The more quieter you become, the more you are able to hear ... " > > > > > > Alternatives: > > > > > ___ > > tcpdump-security mailing list > > tcpdump-secur...@tcpdump.org > > https://lists.sandelman.ca/mailman/listinfo/tcpdump-security > > ___ > tcpdump-workers mailing list > tcpdump-workers@lists.tcpdump.org > https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers > ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
