Portable Wireshark

[Hebe Zuelke]

Buttonsare per profile. Is appdata/wireshark/dbutton_filters the Default profile and is that the current profile in Wireshark?

On Windows 10, there is an extra level in the directory: AppData\Roaming\Wireshark

Do create one from the GUI. Then see what the resulting file looks like. In particular file ownership and stuff like that.My laptop is pain this way as Wireshark will barf a lot and fail to load the files if I just replace them. If wireshark creates them they have rather different access rights and ownership.

Has anyone seen this issue and can offer help? This is the second time I have encountered this issue, with a complete OS wipe and reinstall and a change in the additional NIC between the two times. OS is Windows 7 Ultimate x64, onboard NIC is a Realtek connected to my LAN. Everything works perfectly until...

I'm setting up a dedicated monitor port to connect to my Cisco lab, using an additional NIC on the PC and installing Wireshark/winpcap. That in itself works, but I start to get a lot of network problems:

. Pages in my browser (Firefox and IE) often fail to load compeltely, or I get a page of code, a page that never stops loading or just a blank page. . Images in web pages often look garbled or truncated. . Sometimes I get browser errors such as SSL failures or page encoding errors. . FTP transfers (in any client) give corrupt or truncated files, without giving any error messages. . Problems browing fileshares on the LAN and using RDP.

The above happen so often that it's completely obvious there's a problem, and when it started. I've just done a system restore to before installing Wireshark/winpcap, and everything is back to normal.

I didn't change anything in wireshark's configuration and the only thing I did to the NIC was to disable all the services in network properties. I don't know if that's the right thing to do, but it seems to work for a quiet monitor port and I cannot see how it should cause my problems. Besides, even after reinstating all the network protocols I still had the problems, until I did the roll-back.

Earlier this evening (about two hours ago) I installed just winpcap 4.1.3 and so far have not seen the issues recur. I've tried to provoke them with lots of web browsing and ftp, but so far everything works. I have not unticked anything on the additional NIC's settings... yet.

Hmm... so far, so good. I installed Wireshark this morning, without replacing winpcap. Despite my best efforts, I've not managed to provoke the issues that I saw the last two times. Given how obvious they were, I would say that things are working this time.

I'm setting up a dedicated monitor port to connect to my Cisco lab, using an additional NIC

on the PC and installing Wireshark/winpcap. That in itself works, but I start to get

a lot of network problems:

P1: If the problems only occurs while you capture traffic, it could be related to IP forwarding being enabled on the Monitoring PC, which will then inject the monitored packets into the network again.

P2: The monitoring port on your switch could be an access port. Some switches don't disable access functionality on monitor ports. So, your PC would get a second IP address from the same subnet via DHCP with a second default route, which could cause problems (depends on the metric of the default routes). You'll see that with ipconfig /all.

Not mentioned in my OP was that I also tried reseting winsock and tcp on the PC, of course, and reinstalling the NIC drivers and even nmy browsers. The first time I had the problem I was using an Intel dual-port server NIC. I thought that might just be a driver issue (since there wasn't officially a Windows 7 driver). A clean OS resintall and new Realtek standard NIC still got the problems though.

well, then it has either to do with WinPcap, however I've never heard of such a problem, or with some security software on your PC, like Symantec Endpoint Security or similar tools (AV, IPS, VPN Client, etc.).

Agreed. I'm certain it will be something odd about my setup. The lack of any search hits on my problem say it's unlikely to be Wireshark or winpcap themselves. Actually, I've just realised I did do something different this time, other than installing them seperately...

...I uninstalled Microsoft Security Essentials after I did the roll-back, simply becase I was going to install something better and was killing two birds with one new system restore point. I never even thought that might make any difference.

What I am about to post is not really a question but more of a request for help. (I hope this is not against the rule of this forum).So far my workflow when writing a new dissector has been the following:

Obviously, this is pretty painful. I am aware that you can debug your code while running Wireshark. However, I feel like opening and closing Wireshark over and over again to reload the dissector is still a pain.This is why I have been working on Wirebait over the past few weeks. It is a small Lua library which enables you to run/debug your dissectors on the fly without the need for Wireshark. You can use a .pcap file or a made up hexadecimal string to feed your dissector.

Getting started is really quick, you download the wirebait.lua file in your Lua path, add a code snippet at the top of your dissector file, and now you can run your dissector directly (without Wireshark). I would appreciate any form of feedback/contribution.

I would recommend posting this to the wireshark-dev mailing list (and possibly even to the wireshark-users mailing list as well). I would be willing to bet that more people will see it on the mailing list than here, and it's probably a better place to discuss it than the Q&A site anyway.

Small world it seems :), and again very helpful information. I agree with you this is not the right place, I simply wasn't aware of that mailing list. I'll take your advice and try emailing the devs. I should probably take down that question as well.

I had never come to hear about that feature when it came out, and there is no doubt it makes the process easier. It is still not that great if you want to keep on testing different scenarios as you are writing your dissector.

when i launch the program, it opens too high on the screen. the title bar, and the top 90% of the window is above my screen. if i try to use 'move', 'restore' or maximize they don't work. i couldn't find a .ini file, and struck out looking in the registry.

Believe it or not, when I taught classes in NT (not so much for NetWare), one of the things I used to make my students do was to navigate Windows w/o a mouse. KVM back in the days had a way of losing signals!

To move any active pane (visible or not), highlight the application in the task bar so it has the focus. Then hit ALT-SPACE Bar, then hit the letter "m" Alt-spacebar brings up the "move, minimize" dialog and "m" tells Windows you want to move/relocate the application.

This is the same reason why every Unix admin should know "vi" When you bring up a system from scratch (or after a crash), there's no emacs or anything other than "vi" 'course, it's been ages since I had to actually build a Unix system, so maybe things have changed.

Back in the days, I swore nothing was better than EDT editor on VAX I had my Procomm mapped out for like you wouldn't believe!!! Then I saw "vi" in action and fell in love. Now, while I still like vi, "Ultraedit" is pretty damn powerful.

the system was set up as a dual monitor system with only one monitor attached. monitor 2 was configured as 640x480, and the wireshark window opens at 800x600. so naturally when i launched wireshark it tries to open in monitor 2, so all i saw was the bottom of the wireshark window overlapping onto monitor 1.

i'm a hardware guy working on MRI systems that needs to know the software to navigate my systems. the systems have been VMS and Open VMS, and the workstations have always been some flavor of unix. i have been playing with those two operating systems for over 20 years. now everything is windows XP.

I have two wireshark captures. One showing the packets leaving one location. The other capture shows packets arriving at the destination. What is a good reference point to look at in the leaving packet so I can tell it's the packet that arrived at the destination. I thought I could do that with sequence numbers but it doesn't seem to work that way. So any unique fixed value in the packet should help. Thanks, Gary

If I'm assuming that the sequence number you are referring to is the TCP sequence number and that these TCP packets are transported by IPv4, then indeed the sequence number might be changed by devices in between the client and the server (firewalls tend to do that for instance). A field this is mostly not altered is the IP identification in the IP header. This field is only changed when there is an application level proxy in between (loadbalancers often also behave as application level proxies, so they often create new IP identification values).

So if you look at the ip.id of the packet at the client end, you will most likely find it also at the server end. You can copy it in the client trace (rightclick on the ip.id in the packet details and choose "Copy as filter") and then use "Edit -> Find Packet" (or -F) in the server trace and paste the filter in and click on "Find".

Thank you both for your comments. First off I'm looking now at the Identification number to see if that will work and I really appreciate the idea. It gives me something to try. Some additional details I should have included in the original question are: I'm looking at TCP and the packets I'm looking at are keeping the far end device alive. The far end device will reset periodically as in randomly once a day or every other day. The packets are all in the same subnet but are making it to the far end through a wireless bridge. It appears that they stop going through then the far end device resets and when it comes back up the packets are fine for another 24 or 48 hours (but not exactly) for example once at 4:49 am and the other capture of the failure was at 9:19 am on the following day. I believe the packets are actually stopped and lost rather than late as a result of the failure. Thanks again, Gary

3a8082e126