Tool - InSimSniffer

[DarkTimes]

InSimSniffer (http://insimsniffer.codeplex.com/) is a InSim packet sniffer for the racing simulator Live for Speed. It connects to the game and displays the contents of each InSim packet that is received. This is useful both as a debugging aid and also in learning about how certain operations are handled by InSim.

Getting Started

Download the latest version InSimSniffer and unzip the archive, double click the InSimSniffer.exe executable to run the program. InSimSniffer can automatically launch LFS and configure it for InSim. To do this follow these steps.


Go to InSim > Options and select the General tab
Set the location of LFS.exe and make sure the Auto-connect after launching checkbox is enabled. Note: the location of LFS.exe should be filled in automatically if you have a normal LFS installation.
If your LFS client requires a game admin password, you can set this option under the InSim tab.
Click Save to save the options to settings
Go to InSim > Launch LFS to automatically start the game and connect. InSimSniffer sets the correct InSim port argument when starting LFS, so you don't need to do this yourself.


Download

You can download the latest version of InSimSniffer from the official CodePlex page.

http://insimsniffer.codeplex.com/

Note

A lot of the discussion in this thread applies to old versions of the program that had different features.

Thanks!

[KuHS]

Good work :)

[amp88]

Quite interesting. An improvement suggestion would be to display the player's actual name along with the PLID value as it would be a bit more human readable.

[DarkTimes]

Yes that's already on the todo list, along with a few other things. I need a better way to display the packets first, but I have a couple of ideas for that.

[amp88]

Ah, OK.

Here's an error. With the default Host Address of "localhost" I got the following error:

Version: 1.0.0.0
Date: 12/08/2009 14:29:43
OS: Microsoft Windows NT 6.0.6002 Service Pack 2
Culture: en-US
Message: None of the discovered or specified addresses match the socket address family.
Parameter name: context
Source: System
Target: Void EndConnect(System.IAsyncResult)
Stack Trace: at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)
at LFSPoints.InSim.InSimClient.ConnectCallback(IAsync Result r)
at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
at System.Net.ContextAwareResult.CompleteCallback(Obj ect state)
at System.Threading.ExecutionContext.runTryCode(Objec t userData)
at System.Runtime.CompilerServices.RuntimeHelpers.Exe cuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.ExecutionContext.RunInternal(Exec utionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ExecutionContext.Run(ExecutionCon text executionContext, ContextCallback callback, Object state)
at System.Net.ContextAwareResult.Complete(IntPtr userToken)
at System.Net.LazyAsyncResult.ProtectedInvokeCallback (Object result, IntPtr userToken)
at System.Net.LazyAsyncResult.InvokeCallback(Object result)
at System.Net.Sockets.Socket.DnsCallback(IAsyncResult result)
at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
at System.Net.ContextAwareResult.Complete(IntPtr userToken)
at System.Net.LazyAsyncResult.ProtectedInvokeCallback (Object result, IntPtr userToken)
at System.Net.Dns.ResolveCallback(Object context)
at System.Threading._ThreadPoolWaitCallback.PerformWa itCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
at System.Threading._ThreadPoolWaitCallback.PerformWa itCallback(Object state)
Inner Exception:

With Vista Home Premium SP2. Changing the address from "localhost" to "127.0.0.1" sorted the problem.

[DarkTimes]

OK thanks for the report. Strange as 'localhost' works fine for me.

[misiek08]

Thank you very much! I was going to make that for myself but you were faster! Thank you again!

[DarkTimes]

Thanks. :)

Uploaded 1.0.1 to the first post.


Fixed bug with PLIDs in IS_REO packet
Changes to options dialog to prevent invalid info from being added (host IP, admin pass etc..)


I'm still trying to settle on a good way to display the packets, everything I've tried has been a bit crap. The current ListBox flickers too much, and I'm having issues fixing that, a ListView appears limited to 260 characters, which isn't long enough, and any custom controls I've tried have been slow and clunky. I'm seriously considering switching to WPF and rendering the packet info myself.

[AndroidXP]

Have a look here for attempts to make a flickerfree listview:
http://www.codeproject.com/KB/list/listviewff.aspx
http://geekswithblogs.net/CPound/archive/2006/02/27/70834.aspx

Not tested if they work, but Google has a lot of results regarding this issue, so it seems to be a relatively common problem.

[DarkTimes]

I can do it on a ListView, the 2nd method works great, but that simply does not work on a ListBox. With the ListBox you need to go into OwnerDraw mode and render the items yourself, but I'm having nightmares getting the horizontal scrolling to work. Anyway, I have a better idea for how to display the packets now.

[AndroidXP]

Ah right, but isn't the listview able to perform the same tasks (and more) than the listbox? IIRC you can make it look pretty much the same. Of course I don't know if it's capable of handling thousands of items, though. In general I have the impression that .NET win form controls can be pretty shit in regards to performance.

[DarkTimes]

Something in the back of my head says I read around 10,000 items for a ListView once, before its performance starts to really suffer. I did try to use a ListView earlier, but it appears (although I cannot find any confirmation of this) that items in a ListView are limited to 260 characters in length. The packets can be longer than that.

[AndroidXP]

Just tested it and it seems to be true that it's limited to 200something characters. Though, could it maybe make sense to simply use multiple columns then? It's not like you have to display the properties as comma separated list :)

[DarkTimes]

Yeah, well it's 260 characters exactly, I counted them. :)

Anyway, the problem I realised was not with the WinForm controls, but really with the way I was displaying the packets. As you said it doesn't have to be a comma-delimited string.

I've uploaded a new version (and a new screenshot) to the first post, with a new layout. It makes viewing the packets much more readable, and importantly lends itself much better to future features. Obviously I still have work to do here though.

Only other interesting change is that the packet reflection code now deals correctly with packets that contain arrays, such as Tyres in NPL and other similar instances.

Note: I have actually disabled MCI/NLP updates, as I really haven't figured out a good way to handle those yet, but I have a few ideas. More ideas than time. :)

[AndroidXP]

Yes, much nicer :). I see the newest packets are now added at the bottom? If so an auto-scroll functionality would be very nice. (I haven't had a chance to actually try it out, so sorry if I'm suggesting things that are already implemented.)

[DarkTimes]

Another new version updated to the first post. Also I renamed the program InSimSniffer. :)

It's funny, I've actually learned a lot during the testing of this, it gives you a much better feel for what's going on when you can see all the packet data in a nice little window.

The new version will have some bugs. :)

[Silox]

Great application DarkTimes, I sure will use it!

I'm sure this will help (new) programmers encovering new packets and more information.

[DarkTimes]

Uploaded 1.0.4 to first post.

[amp88]

Nice improvements :thumb:

A small suggestion. If the user has auto scroll enabled but they have moved the scroll bar on the scroll pane to look up at previous packets the application shouldn't auto scroll to the bottom. It should only scroll if the scroll bar is at the bottom already.

[DarkTimes]

OK - a good suggestion. I think what I'll do is if the user selects a packet or scrolls the bar themselves, it will turn those features off automatically. I think only auto-scrolling when at the bottom would be confusing though.

[AndroidXP]

I think autoscroll only at the bottom is a pretty standard feature of similar log tools, though turning it off when the user scrolls is probably OK too (since you can clearly see the option there and notice immediately if the checkstate changes).

[amp88]

[shameless plug]
Yeah, my qualifying ticker application (http://www.lfsforum.net/showthread.php?t=60422) does this (autoscroll when the scroll bar is at the bottom only).
[/shameless plug]

[Ant0niS]

Really nice :thumb:

[DarkTimes]

Thanks :)

1.0.5 uploaded.

[DarkTimes]

Spent the day working on LFSPoints and needed to make some changes to this, so I've uploaded 1.0.6 with some small updates.

[Marco1]

one question

but what can i do with dis program ?

[amp88]

one question

but what can i do with dis program ?

Think of it as a learning/diagnostic tool. New users (and experienced users!) can see exactly what packets are being sent through InSim quickly and easily.

[DarkTimes]

Yes, that's correct.

Added Request menu, which allows you to send IS_TINY and IS_SMALL requests to InSim, plus some other small changes and fixes.

[Dygear]

I just wanted to say, great job. Fantastic little tool!

[DarkTimes]

Uploaded 1.0.10, which includes a new option to display raw enum values. This means it will show the actual int value of an enum instead of a string.

[DarkTimes]

Uploaded 1.0.11 to the first post, with some decent tweaks and bug fixes.

Edit: Forum works properly now. :)

[MariusMM]

This program is ace! Thanks :D

[DarkTimes]

Thanks, I'm glad people like it. :)

Uploaded 1.0.12, which contains some extremely large optimisations to the packet receive code, resulting in packets being decoded several hundred times faster. :)

Internally I'd been using reflection with a lookup table to instantiate the packets, and while I knew this was slightly slow, I didn't realise how slow until I started doing some tests. I switched the lookup table to a giant switch statement, and while it looks messy (huge switches always do), it has resulted in a colossal performance improvememt.

In addition to this I also rewrote socket buffer code, as a I knew a lot of performance was being lost there through heavy use of generic lists. Again, the code doesn't look as nice, but it runs many times faster.

To sum up, the program now updates far more responsively than it did before, and it's very noticeable. Obviously these are some quite large changes to the core of the app, so there may be a couple of new bugs or three in there. Because of this I've left 1.0.11 up as well, which is the stable/slow version of the program.

[Dygear]

Uploaded 1.0.12, which contains some extremely large optimisations to the packet receive code, resulting in packets being decoded several hundred times faster. :)

Fantastic! I always wondered myself what is better, pretty code or fast code? I'm not sure that's a mutually exclusive statement, but it always feels that way.

[BurnOut69]

As for the flickering, if you're still having problems with it, it might be worth a shot using a double-buffered databound GridView control.

I used it a few times and its heaps faster than any ListView, and a lot more customizable :)

[DarkTimes]

I don't have any problems with flickering any more, now that I'm using a double-buffered ListView (well not on my machine anyway :p). I will have a look at using a GridView, or actually just data-binding in general, as at the moment I'm just updating the lists programmatically.

I've uploaded 1.0.13 which contains improvements to the packet filter. I've moved the filter from the options dialog onto a second tab on the main GUI. This means you can filter packets on the fly while the program is running. It doesn't let you filter previously received packets yet, but that is something on the todo list.

I also spent more time cleaning up the InSim library, so hopefully things should be running even smoother.

[DarkTimes]

Uploaded 1.0.15 to the first post, mainly with some more changes to the packet filter.

[DarkTimes]

Uploaded 1.0.16 which fixes a couple of bugs caused by changes to the packet filter.

[DarkTimes]

I've uploaded V1.0.17, which adds a couple of new view options, such as keeping the window always on top, and making the window transparent. I realised that for the most part you are always using the program alongside the main LFS window, and I hope these options make doing so easier.

In addition I have decided to make both InSimSniffer and the DarkInSim library open-source, and so have uploaded their source-code to the first post. InSimSniffer is released under the GPL, and DarkInSim is released under the LGPL. I hope someone finds the source useful, and that no one thinks it's the most horribly coded program of all time! It's definitely not perfect in any way, but it works and, well, is what it is. :)

Thanks!

[Dygear]

In addition I have decided to make both InSimSniffer and the DarkInSim library open-source, and so have uploaded their source-code to the first post. InSimSniffer is released under the GPL, and DarkInSim is released under the LGPL.

Huge thumbs up for adding to the community in this way!

[DarkTimes]

A few notes on the DarkInSim library included with the source code. Basically this is my own InSim library, which started out as an experiment to see how accurately I could port pyinsim to .NET. It turns out - pretty accurately. DarkInSim has a very similar API to pyinsim and a lot of improvements. :)

Edit: All this is now obsolete, you should have a look for the Spark/InSim.NET thread.

[Dygear]

I downloaded the latest version of this (about 20 minutes ago) and was doing a check to see what ^[a-z] was for each of the code pages. When you choose some of the code pages, the datapacket's message area is some times empty even tho the message has content. Can anyone else confirm this?

[DarkTimes]

I don't understand from your message what the issue is. Could you clarify a bit for me please? Like what steps I can do myself to reproduce it.

[Dygear]

When I read the contents of some of the packets (Such as MSO) that have been sent using the ^J tag to change the format to Japanese, the contents of the message is blank on the packet sniffer screen even tho there is content to the message in LFS.

[DarkTimes]

How are you setting the ^J tag? If I change the encoding to Japanese and send a message with Japanese characters, it's displayed correctly as Japanese in InSimSniffer.

Could you give step-by-step instructions as how to do this please? I've tried lots of different combinations of changing the encoding, but they all work correctly as far as I can see. I can't get the message to be blank.

[Dygear]

How are you setting the ^J tag? If I change the encoding to Japanese and send a message with Japanese characters, it's displayed correctly as Japanese in InSimSniffer.

Could you give step-by-step instructions as how to do this please? I've tried lots of different combinations of changing the encoding, but they all work correctly as far as I can see. I can't get the message to be blank.

You know what it might be then, I might not have that character map installed on my computer. If you can see it, but I can't that might be it. (Leads me to wonder, does LFS uses it's own character sheets for this, or is it rendering based off the Window's character maps. My insinuation assumes that LFS uses it's own build in system.)

(Basically, I'm not meeting a dependency requirement for the Japanese Language (http://www.microsoft.com/downloads/details.aspx?FamilyID=24A66277-CD9F-4332-A6F1-52B85A6470BD&displaylang=EN) to be displayed in Windows.)

[Heiko1]

Realy nice tool!
great for us insim creaters :)

[DarkTimes]

Uploaded 1.0.18 to the first post.

I realised that I was doing a lot of unnecessary array copying in the socket buffer code, so I have rewritten the code to reduce as much of this as possible. This should yield a fair performance improvement.

I also added the ability to delete packets from the packet list, both by pressing the DEL key and also by selecting the delete option from the right-click menu. By default you must click through a confirmation dialog before deleting them, but you can disable this in InSim > Options.

The changes to the options means that you must make sure you delete your old settings.dat file (or make sure you unzip to a new directory), otherwise you will see some complaining messages when you first start the new version.

Edit: Also uploaded new screenshot.

[DarkTimes]

Uploaded 1.0.19 to first post with a couple of small fixes.

[tmehlinger]

Very nice app, very helpful.

I've been using DarkInSim a bit too and it's absolutely wonderful. Beats the pants off LFS_External and LFSLib.Net... much cleaner, clearer, and easier to use.

[DarkTimes]

Very nice app, very helpful.

I've been using DarkInSim a bit too and it's absolutely wonderful. Beats the pants off LFS_External and LFSLib.Net... much cleaner, clearer, and easier to use.
Thanks, I'm glad you like it.

As I've said DarkInSim started out as an attempt to port pyinsim to C# and I think it turned out pretty well really (although I could have spent more time on it). I've always had half a urge to release is as a proper InSim module, but I know that what the world really needs right now is another .NET InSim library. :)

[Dygear]

I've always had half a urge to release is as a proper InSim module, but I know that what the world really needs right now is another .NET InSim library. :)

If the code is clean, why not! Hell, I need something to use as a base for a plugin programming with PAWN. Granted, I still have alot of work to do with that ... Hell, maybe you could help. It's just that it requires some pretty nuts programming on the module end.

[DarkTimes]

If the code is clean, why not!
I know what you are saying, but I really cannot justify releasing yet another .NET InSim library (especially seeing as I already maintain pyinsim). Anyway, DarkInSim was created to accomplish four criteria which were lacking in the other libraries, without which InSimSniffer would not be possible:


Exact representation of InSim packets
Full access to underlying byte data when needed
Support for asynchronous operations
Very lightweight performance

If the program you are making requires those parameters to be matched, then DarkInSim may be the right choice for you. Otherwise you are much better off sticking with the old tried and tested libraries like LFS_External and LFSlib.

Note: I will be releasing InSimSniffer and DarkInSim 1.1 in the next few days, so you might wanna hold off for the new versions to be released, as they are even simpler and even faster. :p

[Dygear]

It's more because I want to expose the raw packet data within the context of a struct to the program, that is then handed off to the plugin for interpretation. I've stoped my work on the C++ version of this, as I want to clarify my idea in PHP (My native language if you will.) and then see where the short comings of the PHP project are and do it better a second time with C++ (With both speed, obviously, and implementation.)

[DarkTimes]

I've spent the last week or so refactoring the code for this program and have made a lot of changes and improvements. There aren't really any new features to shout about, except that I now use .NET config files which should work seamlessly on Vista and Windows 7. Aside from that you should notice even better performance and a lot of the packet info has been tweaked and a few weird issues have been resolved. Of course a bunch of old weird issues are still there, but no one ever seems to notice those :p. The code itself still isn't awesome, it's not an example of perfect code by any means, but I'm definitely a lot happier with it than I was before.

Note: DarkInSim has also moved to version 1.1.0, has been heavily rewritten and now supports InSimRelay.

[tmehlinger]

Note: DarkInSim has also moved to version 1.1.0, has been heavily rewritten and now supports InSimRelay.

You're a superstar, I was going to ask for it. :thumbsup:

[Dygear]

10 billion points to you sir, excellent upgrade.

[DarkTimes]

Oh crap, I forgot I actually compiled this release without the Relay connection code. I do have working relay code, but I forgot I still need to fix a couple of issues with DNS lookup that I don't understand yet. This release includes the IRP_* packets, but won't currently allow you to connect to the relay server. Sorry, my bad.

[tmehlinger]

Oh crap, I forgot I actually compiled this release without the Relay connection code. I do have working relay code, but I forgot I still need to fix a couple of issues with DNS lookup that I don't understand yet. This release includes the IRP_* packets, but won't currently allow you to connect to the relay server. Sorry, my bad.

you son of a bitch :tilt:

[DarkTimes]

Yeah, sorry. I have three different version of DarkInSim, at least two versions of InSimSniffer, four versions of pyinsim, plus a new version of LFSPoints on the go. Sometimes I get confused at to what features are available in which version.

Anyway my cool tip of the day, if you use InSimSniffer a lot, is to recompile the source with Visual Studio 2010 beta. The whole programs runs even better on C# 4.0. Everything feels much more responsive and the whole library feels much more optimised.

[Dygear]

you son of a bitch :tilt:

Haha, Awesome.

Yeah, sorry. I have three different version of DarkInSim, at least two versions of InSimSniffer, four versions of pyinsim, plus a new version of LFSPoints on the go. Sometimes I get confused at to what features are available which version.

Excuses!

Anyway my cool tip of the day, if you use InSimSniffer a lot, is to recompile the source with Visual Studio 2010 beta. The whole programs runs even better on C# 4.0. Everything feels much more responsive and the whole library feels much more optimised.

I was thinking about grabbing the Visual Studio C++ 2010 Beta, but I don't know how I feel about writing code in a beta environment.

[DarkTimes]

I was thinking about grabbing the Visual Studio C++ 2010 Beta, but I don't know how I feel about writing code in a beta environment.
I've not tried Visual C++ 2010, but C# has been plagued by bugs and performance issues. Apparently the new RC1 release has fixed almost all of those problems however, and the new WPF code editor seems to be working very well. To be honest though, unless you are going to be using the new features of .NET 4.0, I wouldn't bother upgrading right now. That said the new .NET 4.0 is absolutely awesome, as with support for Python and Ruby it's completely first class.

[Dygear]

That said the new .NET 4.0 is absolutely awesome, as with support for Python and Ruby it's completely first class.

That's pretty cool! Must be making your life easier.

[DarkTimes]

I uploaded a version of InSimSniffer 1.1 compiled for the brand new .NET Framework 4.0 (http://www.microsoft.com/NET/) to the first post (http://www.lfsforum.net/showthread.php?p=1235887#post1235887). I also fixed a very small bug that caused some packet info to be processed twice.

[Dygear]

I uploaded a version of InSimSniffer 1.1 compiled for the brand new .NET Framework 4.0 (http://www.microsoft.com/NET/) to the first post (http://www.lfsforum.net/showthread.php?p=1235887#post1235887). I also fixed a very small bug that caused some packet info to be processed twice.

Did you feel any change, does it feel faster?

[DarkTimes]

InSimSniffer already ran pretty fast, I put a lot of effort into optimising it a while back, so it's hard to tell without doing actual tests. The bug fix will have improved performance quite a bit, as it was a dumb error where at one point in the logic I was doing:

Info info = GetInfo();
ProcessInfo(GetInfo());

And processing everything twice. Which means a lot of performance was being thrown away anyway...

[DarkTimes]

Uploaded 1.1.1 to the first post (http://www.lfsforum.net/showthread.php?p=1235887#post1235887).

Changes

Now detects location of LFS.exe automatically

I realised that as LFS now uses a proper installer I can grab the location of LFS.exe from the registry instead of requiring the user to configure it. That said, you can still set the location manually if you want/need to.

Note: I have depreciated the old version of this program, I will only support .NET 4.0 from now on.

[DarkTimes]

Uploaded 1.1.2 to the first post (http://www.lfsforum.net/showthread.php?p=1235887#post1235887). Only a single change:

Changes


Export now only exports the filtered packets list instead of the full packet list.


There is an option to renable the old functionality (export all packets no matter what) in the options dialog. That is all.

[wsinda]

This is a great tool, thanks! It really helped me to figure out the InSim traffic, before taking the plunge into InSim programming.

One minor bug: after I moved the location of the LFS installation, InSimSniffer stopped working. It exited with a null pointer exception at startup. (Can send you the details if you want.) Apparently, InSimSniffer assumes that when it finds an LFS registry key, it will also find the LFS install at that location.

Improvement suggestion: Put the filter settings in a different sidebar, so the user doesn't have to switch tabs between filter settings and message list. (Even nicer: apply filter changes immediately, without needing to click "Apply".)

[Whiskey]

Open InsimSniffer->Options->General->Location of LFS.exe

Can you do that or it crashes before?

[wsinda]

Open InsimSniffer->Options->General->Location of LFS.exe

Can you do that or it crashes before?It crashes immediately. I don't even get to see the main screen.

[DarkTimes]

One minor bug: after I moved the location of the LFS installation, InSimSniffer stopped working. It exited with a null pointer exception at startup. (Can send you the details if you want.) Apparently, InSimSniffer assumes that when it finds an LFS registry key, it will also find the LFS install at that location.

I cannot reproduce this bug, so I would appreciate it if you could send a crash report, if one was generated. Otherwise I need step-by-step instructions on how to reproduce it. I have looked through the code and tried moving the LFS location but I can't see anything that would allow this bug to happen.

[wsinda]

This is the crash report:
Version: 1.1.2.0
Date: 6-12-2010 19:09:30
OS: Microsoft Windows NT 6.0.6002 Service Pack 2
Culture: en-US
Exception: NullReferenceException
Message: Object reference not set to an instance of an object.
Source: InSimSniffer
Target: Void GetLfsPathFromRegistry()
Stack Trace: at InSimSniffer.Program.GetLfsPathFromRegistry()
at InSimSniffer.Program.Main(String[] args)
Inner Exception:

Might be worth adding that LFS was installed under a different user account than the account that I used when I got the crash.
Running MS Vista, BTW.

[DarkTimes]

OK - I looked at the code harder and saw the bug, which I've now fixed.

Thanks!

[DarkTimes]

I uploaded 1.1.3 with the bug fix.

Note: I also updated the screenshot to show Windows 7 instead of Fisher-Price era XP. :)

[wsinda]

Version 1.1.3 works fine. Bug solved.

[DarkTimes]

I set about to add some new features to this, but I was embarrassed by how poor the code was, so before I started working on it I decided to refactor the existing codebase to bring it up to a much higher standard.

There are no new features in this version, so to speak, but everything has been improved and brought up to date and many things run better. The code is also easier to follow and less-complex to understand (which is a benefit to me above all else). Other things such as security and compatibility have also been improved.

Anyway, it will have a few bugs here and there, and I still plan to refactor the actual packet sniffer quite a lot, but I decided to release it now in beta form so as to get feedback on any problems there are with the current code revision.

You can download 1.2 later in this thread (http://www.lfsforum.net/showthread.php?p=1527328#post1527328). Please note that it will have bugs, but then every program has bugs, so meh.

[DarkTimes]

Dear Microsoft,

Please fix the bugs in the Visual Studio forms designer.

KTHXBYE

I've uploaded a new version where the status bar actually works. Seriously every time I edit the application resources things mysteriously go missing from the form.

[RenvoN]

My LFS is not installed, it's just a copy that I have been keeping for so many years now, so it's not in registry and maybe that's why InSimSniffer doesn't detect it.

Alright, when I try to set the path manually, I get this:

Version: 1.2.0.0
Date: 09/12/2010 19:01:33
OS: Microsoft Windows NT 6.1.7600.0
Culture: pt-BR
Exception: ArgumentException
Message: The path is not of a legal form.
Source: mscorlib
Target: System.String NormalizePath(System.String, Boolean, Int32)
Stack Trace: at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength)
at System.IO.Path.GetDirectoryName(String path)
at InSimSniffer.OptionsDialog.OnLfsExeButtonClick(Obj ect sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventAr gs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.O nMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.W ndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


Since I wanted to use it asap and I can't expect you (and you don't have to) to be here 24/7, I tried to solve it by my own workarounding that problem.

On OnLfsExeButtonClick(), I changed:
dlg.InitialDirectory = Path.GetDirectoryName(lfsExeTextBox.Text);

to

if (lfsExeTextBox.Text != "")
{
dlg.InitialDirectory = Path.GetDirectoryName(lfsExeTextBox.Text);
}


Now I can select the path manually without any problem, it even launches LFS correctly. BUT, I still can't connect to my LFS. :(

It says:
"Make sure LFS is running and configured to accept connections on the correct port."

I tried connecting after launching LFS by my own and setting insim to 29999, tried 127.0.0.1, tried 192.168.1.2, nothing works.

Have you got any idea to help me? :(

Thanks,
Lucas

[NotAnIllusion]

Version: 1.2.0.0
Date: 10.12.2010 0:16:58
OS: Microsoft Windows NT 6.0.6002 Service Pack 2
Culture: en-US
Exception: InSimException
Message: Did not receive VER
Source: InSimSniffer.InSim
Target: InSimSniffer.InSim.Packets.IS_VER ReceiveVersion()
Stack Trace: at InSimSniffer.InSim.InSimClient.ReceiveVersion()
at InSimSniffer.InSim.InSimClient.EndInitialize(IAsyn cResult asyncResult)
at InSimSniffer.MainForm.ConnectCallback(IAsyncResult r)
at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
at System.Net.ContextAwareResult.CompleteCallback(Obj ect state)
at System.Threading.ExecutionContext.runTryCode(Objec t userData)
at System.Runtime.CompilerServices.RuntimeHelpers.Exe cuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.ExecutionContext.RunInternal(Exec utionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ExecutionContext.Run(ExecutionCon text executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionCon text executionContext, ContextCallback callback, Object state)
at System.Net.ContextAwareResult.Complete(IntPtr userToken)
at System.Net.LazyAsyncResult.ProtectedInvokeCallback (Object result, IntPtr userToken)
at System.Net.Sockets.Socket.MultipleAddressConnectCa llback(IAsyncResult result)
at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
at System.Net.ContextAwareResult.Complete(IntPtr userToken)
at System.Net.LazyAsyncResult.ProtectedInvokeCallback (Object result, IntPtr userToken)
at System.Net.Sockets.Socket.ConnectCallback()
at System.Net.Sockets.Socket.RegisteredWaitCallback(O bject state, Boolean timedOut)
at System.Threading._ThreadPoolWaitOrTimerCallback.Pe rformWaitOrTimerCallback(Object state, Boolean timedOut)
Inner Exception:

I clicked connect without changing any connection settings (password doesn't match), InSim was enabled on port 29999.

[DarkTimes]

OK - I have fixed the password miss-match bug and the illegal path bug and uploaded a new version to the beta post (http://www.lfsforum.net/showthread.php?p=1526191#post1526191). The illegal path bug was introduced by a change I made to make the LFS.exe browse dialog work better on Windows 7, the admin password bug was in code unchanged from the old version but had just never been reported before.

Now I can select the path manually without any problem, it even launches LFS correctly. BUT, I still can't connect to my LFS. :(

It says:
"Make sure LFS is running and configured to accept connections on the correct port."

I tried connecting after launching LFS by my own and setting insim to 29999, tried 127.0.0.1, tried 192.168.1.2, nothing works.

Have you got any idea to help me? :(

Thanks,
Lucas

I can't say for certain what the problem is, but that message is ConnectionRefused, which means that either LFS is not running or the host/port information your provided is incorrect.

Do you get this error with the old/stable (http://www.lfsforum.net/showthread.php?p=1235887#post1235887) version of InSimSniffer?

[RenvoN]

I can't say for certain what the problem is, but that message is ConnectionRefused, which means that either LFS is not running or the host/port information your provided is incorrect.

Do you get this error on the old/stable (http://www.lfsforum.net/showthread.php?p=1235887#post1235887) version of InSimSniffer?

Just tested it and same thing happens.

I took an screenshot of my configs:

http://img254.imageshack.us/img254/2366/configs.png

Everything seems to be set up correctly :(

[DarkTimes]

Edit: Ignore, it turns out it was my bug. :)

[RenvoN]

I found the problem.

At least on the stable version, it's not passing the IP correctly. I type 192.168.1.2 (which is correct to connect to my LFS) and it's shown as 127.0.0.1 on BeginInitialise().

Since I don't know how to fix that, and I needed to know if it was the real problem, so I putted:

settings.Host = "192.168.1.2";

And it connects perfectly now, so it must be a problem with getting the IP from the field.

Hope I have helped somehow!

[DarkTimes]

I found the problem.

At least on the stable version, it's not passing the IP correctly. I type 192.168.1.2 (which is correct to connect to my LFS) and it's shown as 127.0.0.1 on BeginInitialise().

Since I don't know how to fix that, and I needed to know if it was the real problem, so I putted:

settings.Host = "192.168.1.2";

And it connects perfectly now, so it must be a problem with getting the IP from the field.

Hope I have helped somehow!

OK I understand the bug now and I have fixed it. I have uploaded a fixed version to the beta post (http://www.lfsforum.net/showthread.php?p=1526191#post1526191).

Thanks for the help, it's great to get these issues sorted, so often people don't even bother to report them. :)

Edit:Reporting bugs is like voting in an election. If you don't report bugs, you don't get to complain about errors. :D

[Dygear]

Edit:Reporting bugs is like voting in an election. If you don't report bugs, you don't get to complain about errors. :D

Broken, I've found your next signature quote.

[broken]

Broken, I've found your next signature quote.

I still like the current one better.
(Sorry DarkTimes)

[wsinda]

No problems so far, except for 2 oddities that already existed:
- When launching LFS, InSimSniffer is a bit too impatient. On my (admittedly slow) system, it signals failure to connect before LFS has fully started up.
- Tab order of fields in the InSim tab of the options dialog is messed up. Or should we blame MS VS Forms Designer?
- Pining for the fjords!? :D (OK, after clicking that button the app has indeed ceased to be. But WTH is it for?)

[DarkTimes]

OK, thanks for those reports. I just haven't checked the tab stop order for a while, so I guess it must have gotten mixed up.

I can try adding a call to Process.WaitForInputIdle() to the LFS launch code, which will cause InSimSniffer to wait until LFS has finished creating its main window and the message pump goes into an idle state. Hopefully by then the socket code should be ready for it to connect.

The exception thing was something I put in to allow me to test the unhandled exception code and I decided to leave it. It lets people see what happens when an error occurs. I don't remember where the Monty Python references came from. :p

[wsinda]

Ouch. The Export function doesn't work anymore. It causes a crash as soon as I select "Export" from the menu. Here is the crash report:
Version: 1.2.0.0
Date: 12-12-2010 0:21:32
OS: Microsoft Windows NT 5.1.2600 Service Pack 3
Culture: nl-NL
Exception: InvalidOperationException
Message: Bestand InSimSniffer Export 12-12-2010 00:21 is een ongeldige bestandsnaam.
Source: System.Windows.Forms
Target: Boolean RunFileDialog(OPENFILENAME_I)
Stack Trace: bij System.Windows.Forms.SaveFileDialog.RunFileDialog( OPENFILENAME_I ofn)
bij System.Windows.Forms.FileDialog.RunDialogOld(IntPt r hWndOwner)
bij System.Windows.Forms.FileDialog.RunDialog(IntPtr hWndOwner)
bij System.Windows.Forms.CommonDialog.ShowDialog(IWin3 2Window owner)
bij System.Windows.Forms.CommonDialog.ShowDialog()
bij InSimSniffer.MainForm.OnFileExportMenuItemClick(Ob ject sender, EventArgs e)
bij System.Windows.Forms.ToolStripItem.RaiseEvent(Obje ct key, EventArgs e)
bij System.Windows.Forms.ToolStripMenuItem.OnClick(Eve ntArgs e)
bij System.Windows.Forms.ToolStripItem.HandleClick(Eve ntArgs e)
bij System.Windows.Forms.ToolStripItem.HandleMouseUp(M ouseEventArgs e)
bij System.Windows.Forms.ToolStripItem.FireEventIntera ctive(EventArgs e, ToolStripItemEventType met)
bij System.Windows.Forms.ToolStripItem.FireEvent(Event Args e, ToolStripItemEventType met)
bij System.Windows.Forms.ToolStrip.OnMouseUp(MouseEven tArgs mea)
bij System.Windows.Forms.ToolStripDropDown.OnMouseUp(M ouseEventArgs mea)
bij System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
bij System.Windows.Forms.Control.WndProc(Message& m)
bij System.Windows.Forms.ScrollableControl.WndProc(Mes sage& m)
bij System.Windows.Forms.ToolStrip.WndProc(Message& m)
bij System.Windows.Forms.ToolStripDropDown.WndProc(Mes sage& m)
bij System.Windows.Forms.Control.ControlNativeWindow.O nMessage(Message& m)
bij System.Windows.Forms.Control.ControlNativeWindow.W ndProc(Message& m)
bij System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Inner Exception:
Note for non-Dutch speakers: "Bestand [...] is een ongeldige bestandsnaam" means that the file name is invalid.

[DarkTimes]

Hmm quite a few errors in this beta it seems. :)

I had added some stuff that generates a default filename for you when you click export, and while it works on this PC, that doesn't seem to be the case for you. I think it may be an internationalization issue, as the filename in that error report is slightly different from how I intended it to look. Anyway, I've simplified all that stuff now which should get rid of it.

I was't planning on releasing a new version until I had finished the new sniffer code, but I have uploaded BETA 3 which is just BETA 2 with a few bug fixes.

In addition to confirming the export now works (hopefully), I'd also appreciate it if you could report back on whether the Launch LFS code is any better.

Thanks!

[wsinda]

Yep, both issues fixed.
Amazing turnaround time, BTW!

[DarkTimes]

I have uploaded a new version to CodePlex (http://insimsniffer.codeplex.com/releases/view/57495).

It has all new sniffer code, so again it may have one or two bugs. I also rewrote the options dialog to make it easier to use.

Please report any bugs or issues you may have.

[DarkTimes]

I added a release for InSimSniffer 1.2 to CodePlex and added some screenshots and documentation.

http://insimsniffer.codeplex.com/

[wsinda]

Hate to be the bringer of bad news, but there is another crash-causing bug. When trying to send a TINY_RIP message, InSimSniffer crashes immediately after selecting the menu item, with this exception:
Version: 1.2.0.0
Date: 19-12-2010 20:37:06
OS: Microsoft Windows NT 5.1.2600 Service Pack 3
Culture: nl-NL
Exception: InvalidCastException
Message: De opgegeven conversie is ongeldig.
Source: InSimSniffer.Library
Target: System.String LookupMpr(System.Object)
Stack Trace: bij InSimSniffer.Library.SnifferService.LookupMpr(Obje ct value)
bij InSimSniffer.Library.SnifferService.LookupInformat ion(String name, Object value)
bij InSimSniffer.Library.SnifferService.SniffValues(Ob ject packet)
bij InSimSniffer.Library.SnifferService.SniffPacket(IP acket packet)
bij InSimSniffer.Library.SnifferClient.HandlePacket(By te[] buffer)
bij InSimSniffer.Library.SnifferClient.OnTcpSocketRece iveCompleted(Object sender, ReceiveCompletedEventArgs e)
bij InSimSniffer.Library.TcpSocket.OnReceiveCompleted( ReceiveCompletedEventArgs e)
bij InSimSniffer.Library.TcpSocket.ReceiveCallback(IAs yncResult asyncResult)
bij System.Net.LazyAsyncResult.Complete(IntPtr userToken)
bij System.Net.ContextAwareResult.CompleteCallback(Obj ect state)
bij System.Threading.ExecutionContext.runTryCode(Objec t userData)
bij System.Runtime.CompilerServices.RuntimeHelpers.Exe cuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
bij System.Threading.ExecutionContext.RunInternal(Exec utionContext executionContext, ContextCallback callback, Object state)
bij System.Threading.ExecutionContext.Run(ExecutionCon text executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
bij System.Threading.ExecutionContext.Run(ExecutionCon text executionContext, ContextCallback callback, Object state)
bij System.Net.ContextAwareResult.Complete(IntPtr userToken)
bij System.Net.LazyAsyncResult.ProtectedInvokeCallback (Object result, IntPtr userToken)
bij System.Net.Sockets.BaseOverlappedAsyncResult.Compl etionPortCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
bij System.Threading._IOCompletionCallback.PerformIOCo mpletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)
Inner Exception:

[DarkTimes]

OK thanks, I had already fixed that error in my version, I just hadn't pushed the changes out to release.

I've uploaded a new version to CodePlex (http://insimsniffer.codeplex.com/releases/view/57812).

This update, with the major-refactorings, does seem to have caused a lot of bugs, sorry.

[DarkTimes]

I hadn't really thought about it up until now, but the way I was figuring out the elapsed time was kinda low-tech and not very accurate. I've updated it to use a high-performance timer which gives much more accurate readings.

As ever it's on CodePlex (http://insimsniffer.codeplex.com/).

[DarkTimes]

Uploaded version 1.2.4 to CodePlex (http://insimsniffer.codeplex.com/releases/):

Changes


String encoding support for double-byte charsets (e.g. shift-jis, trad chinese etc..)
Can restore app from notification tray by left-clicking notify icon and balloon tooltip
Improvements to the way menus are shown
Fixed several issues with dialog boxes when main window is in always on top mode
Fixed bug with disconnecting from InSim while sniffer is paused

Note: The new string encoding stuff is a little experimental, but hopefully it shouldn't explode. Adding it to InSimSniffer seems as good a way as any to test it. :)

[DarkTimes]

Uploaded 1.2.5 to CodePlex (http://insimsniffer.codeplex.com/releases/).

Changes

Added new text-based filter
Optimized string encoding code

I've replaced the old CheckedListBox filter tab with a new text-based one. The old filter tab has been removed and there is now a new TextBox at the top of the packet list that allows you type a packet name and filter the list on the fly.

I'm happy to receive feedback on the new filter, if you hate it or whatever. I think it's better overall but may need some tweaking. One issue is it might not scale well to having thousandths and thousandths of packets. I do maintain that InSimSniffer is a bad tool to use if you just want to do general logging, but the idea of having a standalone InSim event logging tool has been bought up before and perhaps it's time for someone to write one. :)

[boothy]

Got an issue connecting this to Z32 - gives me an error message of "the given key was not present in the directory" :shrug:

[DarkTimes]

OK, thanks for the report, but I will need more information to be able to understand what's causing your error.


Which version of InSimSniffer?
Is the message a popup dialog box or the big unhandled exception dialog? (if the later please post the stacktrace)
Are you connecting to a dedi server or a local client?
Are you connecting to an empty host or to one with a race already in progress?
Does this happen with the old version of LFS or just Z32?


I have tested InSimSniffer 1.2.6 against LFS Z32 and it works fine (there is no reason it should not), so I would imagine this error must be caused by something else.

[boothy]

OK, thanks for the report, but I will need more information to be able to understand what's causing your error.


Which version of InSimSniffer?
Is the message a popup dialog box or the big unhandled exception dialog? (if the later please post the stacktrace)
Are you connecting to a dedi server or a local client?
Are you connecting to an empty host or to one with a race already in progress?
Does this happen with the old version of LFS or just Z32?

I have tested InSimSniffer 1.2.6 against LFS Z32 and it works fine (there is no reason it should not), so I would imagine this error must be caused by something else.


The latest one from codeplex
popup with an ok button
local client, but i'm online in a server
yes, a race (open config) is in progress
haven't checked, don't have time right now but will check soon.

:tilt:

[DarkTimes]

local client, but i'm online in a server
yes, a race (open config) is in progress


OK this is a scenario where I can imagine an error like that might be thrown. Can I ask is it only against an open config host that this occurs, or does it occur on a 'closed' config host as well? I'm thinking this error might be an open config issue as I haven't tested that yet.

It might be a bit late to start debugging tonight, but I'll try and check it out tomorrow.

Incidentally don't worry about testing it against old LFS versions, I'm pretty sure that's not the problem.

[DarkTimes]

It should be fixed now.

http://insimsniffer.codeplex.com/releases/

[boothy]

tis indeed, cheers :thumbsup:

[DarkTimes]

Pushed release for LFS 0.6B to CodePlex. I added the new InSim packets and also reworked the options dialog so you can turn the new packets on/off. You can download the new release from CodePlex. As always please tell me of any bugs you find, or improvements you can suggest.

http://insimsniffer.codeplex.com/releases/

[DarkTimes]

I've been wanting to add an auto-update feature to this, but I'm stuck trying to figure out a way to get the version number of the latest release from CodePlex. It seems CodePlex has an API that allows you to create and update releases, but nothing that allows you to simply get some info about what the most recent release actually is. Seems a bit of an oversight, to be honest. Obviously there are other options, for instance I could parse the releases page and read the release info from there, but that seems like complete overkill. I guess the best route will be just to upload some text file somewhere that contains the latest version number and download URL, and then use that to update the app. Still this would require me to either upload the file manually using FTP, or to write some kind of build script that uploaded it for me. It would be much nicer if CodePlex offered an API that you allowed to get the URL and version number of the latest release of the project.

[DarkTimes]

This is the simplest way I can think to do it. Upload a text file somewhere with two lines, the version and the download URL.

1.2.3.4
http://www.website.com/downloadpage

Then you could read it like this (without any error checking). This checks if there is a new version, then launches your default browser to the download page.

void UpdateApp() {
var versionFile = new WebClient().DownloadString(VersionFileUrl); // Download file.
var tokens = versionFile.Split(Environment.NewLine);
var version = new Version(tokens[0]); // .NET has a handy version class.
var url = tokens[1]; // Download page URL.

if (version > Assembly.GetExecutingAssembly().GetName().Version) {
if (MessageBox.Show("A new version is available, do you want to download it?", "Download Update", MessageBoxButtons.YesNo, MessageBoxIcon.Question) == DialogResult.Yes) {
Process.Start(url); // Launch browser
}
}
else {
MessageBox.Show("The current version is up to date");
}
}