Skip to main content

Building Wireshark on Win32

It was a tedious process, but here's how I got it done. I first tried to follow the:
http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html

However, it's not as straightforward as it seems. Here's the lowdown on how I got the source to build:

First, I tried building using the following environment:
- Microsoft Visual Studio .NET 2003
- Cygwin 1.6 with unzip, bison, flex, perl, patch, wget
- Python 3.1
- Subversion 1.6.6-4
- TortoiseSVN 1.6.6

One of the source files, epan/dissectors/packet-dcerpc-netlogon.c, uses a variadic macro, which is only supported in MSVC 2005 and later. Wasn't interested in commenting out the code only to find more problems, so I abandoned this idea.

I then tried to come up with an environment that was probably more supported by Wireshark:
- Microsoft Visual Studio C++ 2008 Express Edition
- Cygwin 1.7 with unzip, bison, flex, perl, patch, wget
- Python 2.6.4
- Subversion 1.6.6-4
- TortoiseSVN 1.6.6

Things went well except a couple things:
- libssp0 needs to be installed in cygwin. Maybe it's because Cygwin 1.7 is so new and the Wireshark documentation has yet to be updated, but this is needed for the latest version of perl in cygwin.
- I cannot run the finished executable without the msvcr71.dll somewhere on the system, despite the fact that I built it against the VC 2008EE compiler. I am completely baffled.

Update: I found out that the current unstable version links to the MIT Kerberos build, which relies on MSVC .NET 2003 (msvcr71.dll), which appears to be the problem. I logged a bug on Wireshark's bugzilla, but I'll probably move forward with a stable branch to be productive.

Comments

Popular posts from this blog

Software Design Principles - SOLID

The SOLID software design principles weren't called SOLID while I was in grad school, but the concepts were there in my Object Oriented Design course. They're worth mentioning here, primarily because I think once you start coding and become dangerous, it's one of the best ways to stay organized once you incorporate it into your daily coding routines, and it even changes your way of thinking for the better: https://en.wikipedia.org/wiki/SOLID

The TL;DR guide to git

While in the past I've held a pretty high opinion to using mercurial for version control, the majority of version control these days seems to done in git.  Here were the commands I found most useful to get productive with git right away. # Clone a repository from an origin, i.e. my github MaskingUtils repository git clone git@github.com:caelumvox/masking-utils.git # Add a file after it's been updated to stage it for commit, or add a new file git add filename # Commit the file to local repo git commit # Push the file to the origin so the rest of the team can see it git push # List all locally tracked branches git branch git branch --list # Get a list of all branches from the remote git branch -r # Create branch locally git branch develop # Push the branch to the origin repository to make sure it is tracked there git push --set-upstream origin develop # Pulls latest from all local branches tracked from origin; won't pull non-tracked branches git pull --all # Fetch the branch

AWS Development On A Budget

I was interested in hosting a small portfolio of applications in AWS, but I wanted to keep costs down.  I was willing to maybe host about $30-$40 a month of servers just to showcase some of the applications I was putting together.  Here's what I came up with. The basic capabilities here were: serve up about 6-10 applications that would require some level of web application hosting, database, file storage for larger items, and possibly queuing or email schedule jobs to run periodically to either scrape websites for new data or access APIs regularly These were the services in mind, all out of US-East-1 (Virginia): EC2 instances are pretty cheap.  You can run a t3a.nano for about $3.38 a month, or a t3a.micro for about double that for $6.77.  The more things can run on one of these instances, the better. Lambdas also don't really add up to much if they are scheduled jobs that do not consume large amounts of memory or computing.   The cost of a Lambda run as part of an API gateway