[Wireshark-dev] [PATCH] Enhancements to dissecting proxy CONNECT sessions
Hi, At the moment I'm looking into a problem that James Small has reported on the users-list: http://www.wireshark.org/lists/wireshark-users/200704/msg00047.html Although the problem seems to be a non-functional re-assembly of the SSL packets when they are proxied. I will take some time to get familiar with the re-assembly code in wireshark... While looking into the http-dissector I improved a few things on how it dissects a proxy CONNECT session. This is what I have changed: - added the fields hf_http_proxy_connect_host and -port - changed proto_tree_add_text to proto_tree_add_string and -uint so that it's possible to filter on them - make these two fields PROTO_ITEM_SET_GENERATED - removed the alteration of the ports within pinfo, now the ports in the column info are not changed to the port used to connect to the backend server. It is now possible to use follow-tcp-stream again on proxied ssl sessions. The patch has been tested on FC4. Could someone review this patch? Cheers, Sake proxy-connect.patch.gz Description: application/gunzip ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] no more Python 2.1.1
My Solaris builds now fail with: Making register.c with python Traceback (most recent call last): File ../../tools/make-dissector-reg.py, line 98, in ? cur_mtime = os.fstat(file.fileno()).st_mtime AttributeError: 'tuple' object has no attribute 'st_mtime' with Python 2.1.1 . I guess it's time to upgrade. No big deal for me, but should it be mentioned somewhere (before the next release)? Or better yet, tested for in, say, 'configure'? (Sorry, I'm very short on time at the moment but I wanted to mention it before I forget.) ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Displayed button grayed in Save FIle As dialog
Hello, I haven't been following the list recently, and don't know if this is know issue or not, but could not find anythyng about it: I noticed today that in current build, the Save/Print dialogs, the Displayed column shows zeroes even if there is display filter active, and there are packets displayed. The status bar shows the real displayed packet count. Version 0.99.6 (SVN Rev 20899) Compiled with GTK+ 2.8.20 Running on Linux. Best regards, Cvetan -- Cvetan Ivanov System Administrator SpectrumNet Jsc. +35929657613 Office ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 21452: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-ieee80211.c
Hi, My build is failing to link from this revision onwards. The error output is the following: gcc -DINET6 -D_U_=__attribute__((unused)) -Wall -Wpointer-arith -W -g -O2 -Wdeclaration-after-statement -I/usr/local/include -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/opt/gnome/include/gtk-2.0 -I/opt/gnome/lib/gtk-2.0/include -I/usr/X11R6/include -I/opt/gnome/include/atk-1.0 -I/opt/gnome/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/opt/gnome/include/glib-2.0 -I/opt/gnome/lib/glib-2.0/include -o .libs/wireshark capture-pcap-util-unix.o capture_errs.o capture-pcap-util.o capture_stop_conditions.o capture_ui_utils.o cfile.o clopts_common.o conditions.o disabled_protos.o packet-range.o print.o ps.o pcapio.o ringbuffer.o timestats.o util.o version_info.o airpcap_loader.o alert_box.o capture.o capture_info.o capture_opts.o capture_sync.o color_filters.o file.o fileset.o filters.o g711.o merge.o proto_hier_stats.o sync_pipe_write.o summary.o tempfile.o .libs/wiresharkS.o -Wl,--export-dynamic -Wl,--export-dynamic -L/usr/local/lib gtk/libui.a codecs/libcodec.a wiretap/.libs/libwiretap.so -L/opt/gnome/lib epan/.libs/libwireshark.so -L/usr/lib -lpcap -pthread /opt/gnome/lib/libgtk-x11-2.0.so /opt/gnome/lib/libgdk-x11-2.0.so /opt/gnome/lib/libatk-1.0.so /opt/gnome/lib/libgdk_pixbuf-2.0.so -lm /opt/gnome/lib/libpangoxft-1.0.so /opt/gnome/lib/libpangox-1.0.so /opt/gnome/lib/libpango-1.0.so /opt/gnome/lib/libgobject-2.0.so /opt/gnome/lib/libgmodule-2.0.so -ldl /opt/gnome/lib/libgthread-2.0.so -lpthread /opt/gnome/lib/libglib-2.0.so /usr/lib/libgnutls.so /usr/lib/libgcrypt.so -lnsl /usr/lib/libgpg-error.so -lz epan/.libs/libwireshark.so: undefined reference to `.LC1698' epan/.libs/libwireshark.so: undefined reference to `.LC1695' epan/.libs/libwireshark.so: undefined reference to `.LC1694' epan/.libs/libwireshark.so: undefined reference to `.LC1692' epan/.libs/libwireshark.so: undefined reference to `.LC1697' epan/.libs/libwireshark.so: undefined reference to `.LC1696' epan/.libs/libwireshark.so: undefined reference to `.LC1693' collect2: ld returned 1 exit status I recently updated my version of gcc from 3.4.3 - 3.4.6. Here is the version info from Help | About Wireshark : Compiled with GTK+ 2.4.9, with GLib 2.4.6, with libpcap 0.8.3, with libz 1.2.1, without libpcre, without Net-SNMP, without ADNS, without Lua, with GnuTLS 1.0.13, with Gcrypt 1.2.0, without Kerberos, without PortAudio, without AirPcap. NOTE: this build doesn't support the matches operator for Wireshark filter syntax. Running on Linux 2.6.8-24-smp, with libpcap version 0.8.3. Built using gcc 3.4.6. I wondered if maybe I had some libraries built with the older version of the compiler, but I don't see anything in the diff that suggests it would pull in any more library code than before. Going back to the earlier version of the compiler isn't an easy option (but I will do if no-one else has the same problem...). Any ideas? Best regards, Martin On 4/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21452 User: gerald Date: 2007/04/17 12:34 AM Log: More .11k/n updates from Dustin Johnson: - Measurement Pilot frame support - Various Block Ack fields - Various Power fields - Measurement Pilot field - Country String field - Channel Width field - QoS Information fields Directory: /trunk/epan/dissectors/ ChangesPath Action +1025 -394 packet-ieee80211.cModified ___ Wireshark-commits mailing list [EMAIL PROTECTED] http://www.wireshark.org/mailman/listinfo/wireshark-commits ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] redback dissector update #2
Hi,
here is another round - Now we see ISIS again correctly together with
PPPoE PPP handshakes handed from the Packet Forwarding Asic.
Please commit.
Flo
--
Florian Lohoff [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
Index: epan/dissectors/packet-redback.c
===
--- epan/dissectors/packet-redback.c(revision 21454)
+++ epan/dissectors/packet-redback.c(working copy)
@@ -6,7 +6,7 @@
* By Gerald Combs [EMAIL PROTECTED]
*
* Start of RedBack SE400/800 tcpdump trace disassembly
- * Copyright 2005,2006 Florian Lohoff [EMAIL PROTECTED]
+ * Copyright 2005-2007 Florian Lohoff [EMAIL PROTECTED]
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -41,6 +41,7 @@
static dissector_handle_t eth_handle;
static dissector_handle_t clnp_handle;
static dissector_handle_t arp_handle;
+static dissector_handle_t ppp_handle;
/* wrapper for passing the PIC type to the generic ATM dissector */
static void
@@ -81,47 +82,69 @@
Layer3 Offset: %u, l3off);
tisub = proto_tree_add_text (subtree, tvb, 22, 2,
Data Offset: %u, dataoff);
- next_tvb = tvb_new_subset(tvb, l3off, -1, -1);
/* Mark the gap as Data for now */
if (dataoff l3off) {
proto_tree_add_text (subtree, tvb, 24, l3off-24, Data (%d bytes),
l3off-24);
}
- /*
- * Just a guess - In case we see a difference in dataoff vs l3off
- * we assume there is an ethernet header. Traces from an OC12 didnt
- * show any header in here
- */
- if (dataoff l3off) {
-call_dissector(eth_handle, next_tvb, pinfo, tree);
- } else {
-switch(proto) {
- case 0x01:
+ switch(proto) {
+case 0x01:
/*
* IP - We assume IPv6 has a different protocol although
* i might be wrong - Havent seen any traces
*/
-call_dissector(ipv4_handle, next_tvb, pinfo, tree);
-break;
- case 0x02:
+ next_tvb = tvb_new_subset(tvb, dataoff, -1, -1);
+ call_dissector(ipv4_handle, next_tvb, pinfo, tree);
+ break;
+case 0x02:
/*
-* It is CLNP although it seem the Packet Asic fills
-* some data in the packet so we have a broken packet in
-* the trace
+* Most of the time i have seen this protocol type
+* as 802.3 Ethernet containing CLNP for ISIS.
+*
+* Sometimes the 802.3 header is missing and the packet
+* seems to be CLNP anyway. Dissecting this shows
+* a broken packet for an unknown reason.
+*
*/
-call_dissector(clnp_handle, next_tvb, pinfo, tree);
-break;
- case 0x03: /* Unicast Ethernet tx - Seen with PPPoE PADO */
- case 0x04: /* Unicast Ethernet rx - Seen with ARP */
- case 0x08: /* Broadcast Ethernet rx - Seen with PPPoE PADI */
+ next_tvb = tvb_new_subset(tvb, l3off, -1, -1);
+ if (dataoff l3off) {
+ call_dissector(eth_handle, next_tvb, pinfo, tree);
+ } else {
+ call_dissector(clnp_handle, next_tvb, pinfo, tree);
+ }
+ break;
+case 0x06:
+
+ /* HACK This is a guess - i dont know what this flag means
+ * but my best guess is that it means incoming e.g.
+ * the direction of the packet. In case of incoming PPP
+ * packets there seems to be some padding which does
+ * not get reflected in the l3off/dataoff
+ */
+ if (flags 0x0040) {
+next_tvb = tvb_new_subset(tvb, l3off, -1, -1);
+ } else {
+proto_tree_add_text (subtree, tvb, l3off, 4, Unknown Data (%d
bytes), 4);
+next_tvb = tvb_new_subset(tvb, l3off+4, -1, -1);
+ }
+
+ if (l3off == dataoff) {
+call_dissector(ppp_handle, next_tvb, pinfo, tree);
+ } else {
call_dissector(eth_handle, next_tvb, pinfo, tree);
-break;
- default:
- tisub = proto_tree_add_text (subtree, tvb, 24, length-24,
+ }
+ break;
+case 0x03: /* Unicast Ethernet tx - Seen with PPPoE PADO */
+case 0x04: /* Unicast Ethernet rx - Seen with ARP */
+case 0x08: /* Broadcast Ethernet rx - Seen with PPPoE PADI */
+ next_tvb = tvb_new_subset(tvb, l3off, -1, -1);
+ call_dissector(eth_handle, next_tvb, pinfo, tree);
+ break;
+default:
+ tisub = proto_tree_add_text (subtree, tvb, 24, length-24,
Unknown Protocol Data %u, proto);
-break;
-}
+ break;
}
return;
}
@@ -147,6 +170,7 @@
eth_handle = find_dissector(eth_withoutfcs);
clnp_handle = find_dissector(clnp);
arp_handle = find_dissector(arp);
+ ppp_handle = find_dissector(ppp);
redback_handle = create_dissector_handle(dissect_redback, proto_redback);
Re: [Wireshark-dev] [Wireshark-commits] rev 21452: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-ieee80211.c
I just noticed (when trying to build with packet-ieee80211.c removed from epan/dissectors/Makefile.common) that my config.h has the following: /* Enable AirPDcap (WPA/WPA2 decryption) */ #define HAVE_AIRPDCAP 1 Is this correct? Martin On 4/17/07, Martin Mathieson [EMAIL PROTECTED] wrote: I've tried various things today, including: make distclean ; ./autogen; ./configure ; make ; makeclean with the same result. I've been poking around with nm looking for where the unresolved symbols might be defined, but no joy yet... Thanks, Martin On 4/17/07, Joerg Mayer [EMAIL PROTECTED] wrote: On Tue, Apr 17, 2007 at 05:31:02PM +0100, Martin Mathieson wrote: epan/.libs/libwireshark.so: undefined reference to `.LC1693' collect2: ld returned 1 exit status I recently updated my version of gcc from 3.4.3 - 3.4.6. Here is the version info from Help | About Wireshark : Did you do a make distclean after the upgrade? If not, please try to do that. ciao Joerg -- Joerg Mayer [EMAIL PROTECTED] We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] no more Python 2.1.1
Jeff Morriss wrote: My Solaris builds now fail with: Making register.c with python Traceback (most recent call last): File ../../tools/make-dissector-reg.py, line 98, in ? cur_mtime = os.fstat(file.fileno()).st_mtime AttributeError: 'tuple' object has no attribute 'st_mtime' with Python 2.1.1 . I guess it's time to upgrade. No big deal for me, but should it be mentioned somewhere (before the next release)? Or better yet, tested for in, say, 'configure'? (Sorry, I'm very short on time at the moment but I wanted to mention it before I forget.) I've checked in a change (in r21459) that should fix the immediate mtime issue. The Python section Developer's Guide says version 2.2 and above should be working fine. Should we enforce Python = 2.2 in autoconf and/or win32-setup.sh? ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Debug build of wireshark w/installer built on XP with 99.5 sources using MSVC8 will not load on Server 2003
I've built Wireshark 99.5 on an XP Pro (SP-2) machine with MSVC8 (from Visual Studio 2005 Pro). Wireshark runs perfectly on the XP box; if I generate an installer and use the installer to install on a Server 2003 R2 (SP-2) system, Wireshark fails to launch, with VC++ runtime error R6034. (app attempted to load C runtime incorrectly) One suggestion I've seen to fixing this is to rebuild with release libraries, but I have not been able to do so successfully. I edited config.nmake and tried changing /MD to /MT in LOCAL_CFLAGS as well as removing /DEBUG from LOCAL_LDFLAGS; running 'Nmake -f Makefile.nmake distclean' followed by 'nmake -f Makefile.nmake' exploded and left a toxic cloud of link errors floating over my monitor. MSVC_VARIANT is set to MSVC2005. Will using release libs instead of debug libs correct the problem? (I rather suspect it would, assuming I haven't screwed something else up) If so, am I missing something blatantly obvious in reconfiguring the makefile? Or did I miss a step in the rebuild? -- Phil ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] no more Python 2.1.1
Gerald Combs wrote: Jeff Morriss wrote: My Solaris builds now fail with: Making register.c with python Traceback (most recent call last): File ../../tools/make-dissector-reg.py, line 98, in ? cur_mtime = os.fstat(file.fileno()).st_mtime AttributeError: 'tuple' object has no attribute 'st_mtime' with Python 2.1.1 . I guess it's time to upgrade. No big deal for me, but should it be mentioned somewhere (before the next release)? Or better yet, tested for in, say, 'configure'? (Sorry, I'm very short on time at the moment but I wanted to mention it before I forget.) I've checked in a change (in r21459) that should fix the immediate mtime issue. The Python section Developer's Guide says version 2.2 and above should be working fine. Should we enforce Python = 2.2 in autoconf and/or win32-setup.sh? I can confirm the workaround works. It seems reasonable to me to force a more modern Python--I imagine 2.1 is quite ancient by now and it's not like upgrading should be terribly painful (unlike the Gtk1-Gtk2 switch). ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Solaris 8 buildbot not building Wireshark
Is there a reason the Solaris 8 buildbot doesn't build Wireshark (just tshark)? checking for GTK+ - version = 2.0.0... no *** Could not run GTK+ test program, checking why... *** The test program failed to compile or link. See the file config.log for the *** exact error that occured. This usually means GTK+ is incorrectly installed. [...] Use GTK+ v2 library : yes Should it use --disable-gtk2? Or should 'configure' fall back to GTK1 if it can't find GTK2? [I noticed this because gtk/graph_analysis.c won't compile on Solaris 9 (it complains about size_t not being defined in emem.h) and I was wondering how the Solaris buildbot was getting by it, only to discover it wasn't compiling that file at all.] ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 21452: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-ieee80211.c
Martin Mathieson wrote: Hi, My build is failing to link from this revision onwards. The error output is the following: [...] epan/.libs/libwireshark.so: undefined reference to `.LC1698' epan/.libs/libwireshark.so: undefined reference to `.LC1695' epan/.libs/libwireshark.so: undefined reference to `.LC1694' epan/.libs/libwireshark.so: undefined reference to `.LC1692' epan/.libs/libwireshark.so: undefined reference to `.LC1697' epan/.libs/libwireshark.so: undefined reference to `.LC1696' epan/.libs/libwireshark.so: undefined reference to `.LC1693' collect2: ld returned 1 exit status I recently updated my version of gcc from 3.4.3 - 3.4.6. Here is the version info from Help | About Wireshark : That looks suspiciously similar to bug 156: http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=156 which turned out to be a bug in GCC: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157308 Otherwise I'm not sure how something _we_ are doing wrong can cause an undefined reference to something named .LC*. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Compile broken on 64-bit Linux -- packet-dtls.c
Guy Harris wrote: On Apr 16, 2007, at 3:16 PM, Mike Duigou wrote: packet-dtls.c: In function 'dissect_dtls': packet-dtls.c:433: warning: cast to pointer from integer of different size That call happens to do something that's probably safe on platforms where 1) int has no more bits than a pointer and 2) converting from int to pointer doesn't mangle the bits which is true of all the platforms we currently support. ... and I thought compilers were (generally) supposed to not warn you if you're explicitly casting (on the assumption you should know what you're doing). However, it's still a good idea to fix it. There is no code in Wireshark that actually *uses* the DTLS tap, so we could just get rid of the tap. It seems a bit odd that the data passed to the tap is the proto_dtls value - that doesn't seem like very interesting information to pass to a tap, as it doesn't change from call to call. The same warning shows up in packet-ssl.c (same problem). There seem to be a lot of unused taps in there so I just changed the parameter to NULL for now--I guess if someone eventually wants to use it they can fill in some interesting data. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Compiling under MSVC 6.0 - simple Q, clear cut A ?
I read through this thread with keen interest as I am experiencing similar issues. I am a UNIX developer (literally) but am currently developing Wireshark on Windows so there could be operator error involved. I've been successfully building using MSVC and nmake for the past couple years and only recently decided to use MSDEV for debugging. I get the usual initial pause in ..\gtk\main.c but pressing F5 to continue causes the unrecoverable error - Unhandled exception in wireshark.exe (LIBGLIB-2.0.0.DLL) Access violation. If I run wireshark.exe outside of the debugger it performs perfectly. Has anyone seen this before and know the root cause? I've carefully followed the advice on the wiki and have pointed MSDEV to the source code and .bsc file. I've tried both attaching MSDEV to a running instance of wireshark and also allowing MSDEV to spawn the instance. Both experience the same failure. Cheers Bryan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Johansson Sent: Friday, December 01, 2006 5:31 AM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Compiling under MSVC 6.0 - simple Q, clear cut A ? An alternative way to do this is to: 1. Start wireshark.exe and msdev separately. 2. In MSDEV 6, choose menu Build - Start Debug - Attach to process 3. From the list of processes, choose wireshark.exe (most certainly one of the topmost items). 4. Load the source file in which you would want to set a breakpoint using the menu File - Open. 5. Set a breakpoint at the desired line in the source code. 6. Wireshark will pause its execution once the breakpoint gets hit. Note that if you upon closing MSDEV answer yes to the question whether the debug session's opt file should be saved or not, then you can open MSDEV the next time and just reload the debug workspace from the menu File - Recent workspaces. Once the workspace has been loaded, you can start the Wireshark execution (in the debugger from the beginning) using for instance F5, F10, or F11. / Regards, Peter Martin Warnes wrote: The following works for me when debugging a plugin it should be the same for a built in dissector: 1. Open wireshark.exe in MSVC and F5 to start debug. 2. When it pauses in ..\gtk\main.c press F5 again to continue Wireshark startup. 3. Once you see the main display window open your dissector code in MSVC and insert your break point(s). 4. Open capture file used by your dissector and it should halt at the required breakpoints (at least it does for me) Martin Sleep Less wrote the following on 01/12/2006 11:55: Well not quite - the compiler still disables breakpoint in the dissector, as it fails to see the (symbolic) connection. Methinks you need .bsc files for that, which MSVC generates when you compile from the IDE, but apprently nmake does not. any ideas? */Douglas Pratley [EMAIL PROTECTED]/* wrote: Not tried exactly that myself, but Id have thought that you could single step into main.c, pause, then put a breakpoint in packet-h263.c and then just run. It should then stop on the breakpoint. *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Sleep Less *Sent:* 01 December 2006 11:42 *To:* Developer support list for Wireshark *Subject:* Re: [Wireshark-dev] Compiling under MSVC 6.0 - simple Q,clear cut A ? Thanks. Done all the wiki recommendations. I can now single/step debug main.c, but as you can imagine, my interest lies deep in one of the dissectors - e.g. packet-h263.c etc. How to I get to the situation I can single step through those? thanks */Douglas Pratley [EMAIL PROTECTED]/* wrote: [Apologies if this message appears twice - I am having some trouble persuading exchange to be consistent about which SMTP address it uses for outgoing email, and my first try bounced as a non-menber] The wiki tips page has a couple of useful sections on debugging and setting up browse info for MSVC. http://wiki.wireshark.org/Development/Tips Ive also done it by creating a dummy static library project and using Wireshark as the program under the debug settings (useful for putting a breakpoint in start-up code). Cheers Doug *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Sleep Less *Sent:* 01 December 2006 10:36 *To:* Developer support list for Wireshark *Subject:* Re: [Wireshark-dev] Compiling under MSVC 6.0 - simple Q,clear cut A ? Hi, thanks for the willingness to assist. I did one thing : created an empty directory c:\wireshark-win32-libs and then ran the
