I needed to do some packet capturing in windows, so I added a USB network interface to an ultra-book. Upon running wireshark the USB network adapter was conspicuous by its absence from the interface list. After a bit of mulling over I wondered if WinPCap was not aware of the adapter; as these days WinPCap runs as a service. The service is called NPF (NetGroup Packet Filter). So: net stop npf and

There are numerous ways to do this. However using the WMI from a command prompt does the job: wmic diskdrive list brief It is quick and easy to remember, having the benefit that it can be run remotely using a remote shell like Powershell or psexec. Sample output: C:\windows\system32>wmic diskdrive list brief Caption DeviceID Model Partitions Size LITEONIT LMT-128M3M \.\PHYSICALDRIVE0 LITEONIT LMT-128M3M 2 128034708480 Even though it is easy to remember, I’m putting it here as I’ll forget.

I needed to use the wired connection at the same time as the wireless connection recently and was unable to. I guess it is not often required to have multiple connections but every now and then it crops up. Historically drivers sometimes caused issues and usually due to power options, understandability to reduce load on batteries. However this time it turned out to be windows that is causing this. TLDR, to find the culprit setting run:

From an administrative command prompt type: fsutil fsinfo ntfsinfo d: The output will include: Bytes Per Cluster : 4096 In this case Bytes Per Cluster is 4096.

You can use this wireshark filter to restrict results to the network you are interested in: ip.addr == 10.10.0.0/16 Since we are not specifying a source or destination (i.e. ip.src or ip.dst), the filter will match both. If you want to reverse it then: !(ip.addr == 10.10.0.0/16) I’ll often use the same method to filter the results on a specific IP address, preserving both ends of the conversation: ip.addr == 10.

Nslookup under osx is tricky to use interactively as it doesn’t support readline. When you try to use the command history you get the following: > ^[[A Argh! This means more typing. As far as I can remember it has always returned ^[[A or ^[[B depending on the arrow key used. After a bit of research it seems you can fix it with rlwrap which you can install via mac ports.

Rather than installing the remote exchange management tools and the pain that can cause, you can use powershell remoting. To setup powershell to connect to the exchange server pop the following into a powershell prompt on your client machine: $cred = get-credential $myremote = New-PSSession -configurationname Microsoft.Exchange -connectionURI http://server_name/Powershell -credential $cred Import-PSSession $myremote The first line prompts you for the account details to connect/manage exchange. Once you’ve entered the next two lines you should be able to run remote powershell commands.

Sometimes you need to find out if you are running a 32bit or a 63bit Windows operating system. You can do this quickly from the command line using WMI: wmic os get osarchitecture Another option is using the following environmental variable: echo %PROCESSOR_ARCHITECTURE% Short and sweet.

As of the 25/06/12 you need to use the bloody release and will also need to have a floppy drive attached. You can add the floppy drive through the VMware gui or add the following to your vmx file: floppy0.fileType = "file" floppy0.fileName = "path_to_/floppy_image/Omni.flp" floppy0.clientDevice = "FALSE" floppy0.startConnected = "FALSE" If you want to create a virtual floppy image then use the following on Os X: touch path_to_/floppy_image/Omni.flp I’m not sure you need to point to a real image, however if you are using the Fusion gui, it requires you to have one.

Use the following from a terminal to get the file size in bytes: wc -c ~/screenlog.0 Which in this case will output: 76974 /Users/edward/screenlog.0 Showing my screenlog.0 is 76974 bytes.