How to use Wireshark to get IP camera RTSP URL

November 10, 2017 on 12:57 pm | In Hacks | No Comments

I have bought a simple IP camera. Manta SRV201HD. Nice, small, with a decent built and superb cost-effectiveness. Manual describes the configuration over an Androind/iOS app. I’ve tired and run away from the store seeing the permissions it needed to install:

Screenshot_20171110-121748 (002)

I want the other way around. I’ve connected to the camera WIFI using my laptop (it spreads a technical wireless network with some cryptic SSID) and went to the web interface (to check the camera IP you will have to go to the router DHCP table or use some WIFI sniffing tool). The configuration was seamless. Enter local WIFI SSID and password and reset.

Now back to my local WIFI. And back to the camera web interface. To see the stream I had to install some OCX component. I did it on some disposable VM because I did not wanted to litter my system (it is enough that the camera is probably calling China to feed the image to the mobile app). It worked perfectly but that was not the way I intended to use it. I needed the stream to embed it for example into my own app. I needed the RTSP URL. RTSP stands for Real Time Streaming Protocol and it is the standard way the IP cameras stream their image. There was not URL in the manual. So I needed to get it from the live stream in the web interface. I have used the Wireshark.


Filter with ip.proto==RTP and scroll around.There should be URL beginning with rtsp:// somewhere in the info column. That’s your stream address.

My stream URL for the Manta SRV201HD was rtsp:// together with the authentication credentials it was rtsp://admin:admin@

And it worked perfectly:


.NET Versioning Riddle

September 1, 2017 on 10:10 am | In Uncategorized | No Comments

We have a .NET application compiled with .NET Framework 4.5 as a target.

The riddle is: why does this application work on Windows 7 with only .NET Framework 4.0 installed but not on Windows Server 2003 with the same .NET Framework 4.0 installed?

The answer it twofold. The first part is easy:

1. Why does the application compiled with .NET Framework 4.5 as a target even works with .NET Framework 4.0?

It is because the CLR is still the same. It is 4.0. Have a look with ildasm at a simple exe or dll targeted for .NET Fraemwork 4.5 and you will see:


So the app will work but, as Microsoft puts it in “We do not recommend running apps that target a later version of the .NET Framework on the an earlier version of the .NET Framework.” So it will work up until the time where you access some specific .NET 4.5 functionality where it will crash.

So I guess if you want your app to be specific about the minimal .NET Framework Version it needs, you will have to check it yourself. For example as suggested in here:

2. The second part of the question is more tricky. Why does it work with .NET Framework 4.0 in Windows 7 but not with the same .NET Framework 4.0 in Windows Server 2003?

As it turnes out (I have not found the answer at Microsoft but on StackOverflow: the compiler for the app targeting .NET Framework 4.5 sets the file header ( to be compatible with Windows Version 6.0 (Vista and up – or newer. You can check it out by using dumpbin /headers from VS command line:


4.00 operating system version
0.00 image version
4.00 subsystem version

If you compile the app with .NET Framework 4.0 as a target the file header looks like this:


4.00 operating system version
0.00 image version
6.00 subsystem version

So the minimal Windows version is 4.0 being Windows 95 and up.

Certificate of Basic BPMN Competence

June 21, 2017 on 11:00 am | In BPMN | No Comments

imageOn April 28th 2017 I’ve passed the Polish state examination of the basic competence in Business Process Model and Noatation (BPMN). The exam is carried out by the System Research Institute at the Polish Academy of Sciences. It is an exam in accordance with the requirements of the standard ISO / IEC 19510:2013.





The scope of the certificate contains:

1. Basic terms of business processes

  • Process and sub-process
  • Process goal and purpose of process modeling
  • Map of processes
  • Process model
  • Process vs. procedure
  • Process measures
  • Participant (business role, position)

2. Basic terms related to process modeling in BPMN notation

  • Objects in process diagrams
    • Pools and lanes
    • Flow objects
    • Connecting objects
    • Data
    • Artifacts
  • Proper and improper diagrams
    • Sequence flow and message flow
    • Representation of participants and business roles
    • Forking and joining of sequence flow
    • Exception flow

3. Individual skill in process modeling

  • Developing a BPMN diagram on the basis of tabular or narrative description

My certificate number is 0070/2017 and can be looked up at the System Research Institute web page.

Machine Learning 4 Continuous Defect Prediction

March 16, 2017 on 2:05 pm | In Article, Conference, Continuous Integration | No Comments

Defect prediction is a set of techniques used to identify a likely buggy software change (eg. a commit). Various measurements from previous changes are taken into consideration to predict weather a new change is likely to contain a bug or not. Commit messages or bug tracking system entries are usually examined to gather the measurements. Machine learning is often used to classify the buggy/clean changes. We are working now on adding a continuous notion to defect prediction. On one side by building on top the idea of continuous defect prediction in the IDE (Integrated Development Environment). On the other side by perfecting the prediction by using the unambiguous results of continuous integration builds of the software project.

The technique was described in a paper I coauthored under the title “Continuous Defect Prediction: The Idea and a Related Dataset”. I will present the paper at the 14th International Conference on Mining Software Repositories 2017 (MSR) in Buenos Aires, Argentina in May this year. MSR is colocated with 39th International Conference on Software Engineering (ICSE) which I will attend.

What is IL – practical example

July 21, 2016 on 1:40 pm | In DotNet | No Comments

I’m sure you know your C# code is not directly compiled into machine code and ran. It is first converted into IL. CIL to be precise. Its stands for Common Intermediate Language. This CIL is then assembled into bytecode and compiled by JIT (Just-in-time compiler) into executable machine code. So much for the theory, but have you ever tried to mess with IL yourself? Not? Lets try it.

Run the Visual Studio Command Prompt from the start menu. Find yourself suitable directory to tinker around. Create a program, compile it and run:

C:\Dev\ilmagic>copy con p.cs
public class p {
  public static void Main() {
    System.Console.WriteLine("Hello console!");
        1 file(s) copied.

C:\Dev\ilmagic>csc p.cs
Microsoft (R) Visual C# Compiler version
Copyright (C) Microsoft Corporation. All rights reserved.

Hello console!

Now lets see inside the IL. You can use the ildasm decompiler you have on your machine. It can not only show you the decompiled code but also save it to the file. In order to do it issue the following command:

C:\Dev\ilmagic>ildasm p.exe /

Now take a look inside the il file with any txt editor you like. Inside its intermediate code. It’s still readable and similar to assembler. Lets mess around. Look for the class definition:

.class public auto ansi beforefieldinit p
       extends [mscorlib]System.Object
  .method public hidebysig static void  Main() cil managed
    // Code size       13 (0xd)
    .maxstack  8
    IL_0000:  nop
    IL_0001:  ldstr      "Hello CIL!"
    IL_0006:  call       void [mscorlib]System.Console::WriteLine(string)
    IL_000b:  nop
    IL_000c:  ret
  } // end of method p::Main

  .method public hidebysig specialname rtspecialname
          instance void  .ctor() cil managed
    // Code size       8 (0x8)
    .maxstack  8
    IL_0000:  ldarg.0
    IL_0001:  call       instance void [mscorlib]System.Object::.ctor()
    IL_0006:  nop
    IL_0007:  ret
  } // end of method p::.ctor

} // end of class p

Looks vaguely familiar? You can even see the text that will be beamed into console. It is in line:

IL_0001:  ldstr      "Hello console!"

Lets change it to:

IL_0001:  ldstr      "Hello CIL!"

and save the file.

Assemble the IL back to the bytecode with ilasm.exe (it’s a part of .NET SDK – that’s why we are in VS command prompt):

C:\Dev\ilmagic>ilasm /OUTPUT=p2.exe /EXE

Microsoft (R) .NET Framework IL Assembler.  Version 4.6.1038.0
Copyright (c) Microsoft Corporation.  All rights reserved.
Assembling ''  to EXE --> 'p2.exe'
Source file is ANSI

Assembled method p::Main
Assembled method p::.ctor
Creating PE file

Emitting classes:
Class 1:        p

Emitting fields and methods:
Class 1 Methods: 2;

Emitting events and properties:
Class 1
Writing PE file
Operation completed successfully

Voila and now lets run the exe (that’s the time where the JIT comes into play and creates machine code out of the CIL assembly).

Hello CIL!

Nice! He?

XVIII KKIO Software Engineering Conference

May 26, 2016 on 8:24 pm | In CODEFUSION, Conference | No Comments

imageI will be speaking at the XVIII KKIO Software Engineering Conference in Wrocław, Poland. The conference will take place between 15th and 17th September, 2016. It is a conference “covering all topics of software engineering research and practice”. This years motto is: “Better software = more efficient enterprise: challenges and solutions”. I will be speaking about “Agile Experimentation” (more to it soon). I will also cover the Visual Studio extension we developed at CODEFUSION called NActivitySensor. Let’s meet in Wrocław!

I will be speaking at CIDC 2015 in Orlando, Florida

August 31, 2015 on 1:29 pm | In Clarion, DotNet | No Comments

hostI was invited to give a talk at the CIDC 2015 in Orlando, USA. CIDC is annual Clarion International Developers Conference. I will be speaking about the Microsoft .NET and Clarion integration. The talk is prepared together with the C.I.C. Software GmbH and my company (CODEFUSION). The Clarion part is supervised by Andrzej Skolniak from the C.I.C. We will be giving the speech together. We will be talking about various interoperability solution between .NET and Clarion tried out in one of the projects my company I co-developing with C.I.C. Software. The interoperability solution that is based on unmanaged exports – modified .NET libraries that are accessible form Clarion. The managed methods are not exposed as such. Instead, inverse P/Invoke thunks, automatically created by the common language runtime, are exported. These thunks provide the same marshaling functions as “conventional” P/Invoke thunks, but in the opposite direction. Using this method we were able not only to connect a full blown .NET based BPMN Engine to Clarion but we are able to inject Microsoft WPF based controls to Clarion created windows. With this and a set of callback functions (for .NET to talk back to Clarion – to do the evaluates for example), we built in .NET and C# a production grade extension to Clarion based software.

Join us at the CIDC 2015 between September 30th and October 2nd in Orlando, Florida, USA.

Developer Week 2015

February 17, 2015 on 12:30 pm | In DotNet, Windows | No Comments

DWX2015_Banner_200x120_Speaker_statischThird time in a row I will be speaking at Developer Week 2015 in Nuremberg, Germany. This year I will not do it solo. I’m going with the CODEFUSIONs Head Developer Marcin Słowik and we will be speaking about creating professional style user controls in WPF like the guys at Telerik or Infragistics do it. Please joins as between 15th and 18th of June 2015 in Nuremberg!

Scaling CI–switching poll to push

October 21, 2014 on 10:13 pm | In Continuous Integration, DotNet, SVN, TFS, Windows | No Comments

Scaling CI has many flavors. For example:


  • Code base / test no. increases -> build time increases,
  • Teams grow,
  • No. of projects grows.


  • Create targeted builds (dev build, qa build),
  • Write fast unit tests,
  • Smaller teams with local integration servers,
  • Modularize the code base:
    • Scale hardware,
    • Add more build agents,
    • Parallelize.

and last but not least:

  • Ease the source control system.

Let me show you how to make Subversion and (TFS) Git pro actively inform Jenkins CI about changes in source control.

The most straight forward way to let the CI server know that something changed in the repository is to configure polling. What it means is that the CI server periodically asks the source control system “do you have changes for me”. In Jenkins CI you are configuring it under “Build Triggers” and “Poll SCM”. Jenkins uses Cron style notation like this:


Five stars “* * * * *” means: poll every minute. Ovary minute is as close to continuous as you can get. More often is not possible. Most of the times it is not a problem. Once a minute is quite enough. But what if you have many repositories under CI. The single Jenkins CI requests cost not so much, but if there are many repositories to check it can mean a significant delay.

There is a way to change it. Switching from poll to push. How about letting source control system inform the CI server “I have something new for you”. The mechanism that makes it possible is called hooks (at least its hooks in Subversion and Git). Hooks are scripts that are executed in different situations. On the client before or after commit in (pre-commit, post-commit). Before or after update (pre-update, post-update) and so on. Or on the server before or after receive (pre-commit, post-commit). What is interesting for us are post-commit hook in Subversion (look for hooks subdirectory on the server) or post-receive in Git (look in .git\hooks). Because Git is distributed you have it in every repo but, the one that is interesting for us is of course the repo destined for the CI server, and from its point of view it is the post-receive hooks that needs to be executed. In those hooks you can do basically everything you want. We will get back to it soon.

On the the Jenkins CI side you change to change the trigger to “Trigger build remotely”. This option is only visible if your installation of Jenkins is not secured with long and password.


In this case you can always trigger the build by simply calling the URL:


If your installation is secured you have to flag the “Trigger build remotely” and you can set the security token for the build. Only with this token the build will be triggered.


The URL that needs to be called in this case is


If you have the repository viewable without authentication it will be possible to trigger the build. But sometimes the Jenkins CI will be secured that way that nothing is viewable without log in. How to trigger a build in this case? Well there is a plug-in for that. It is called “Build Authorization Token Root Plugin” and it is available under In this case the URL will be


We are ready on the Jenkins CI side. Lets make it ready on the source control system side. Since we are Microsoft minded at CODEFUSION (my company). We have Subversion on our own Windows Server and Git on Microsoft Visual Studio Cloud.

In Subversion go to the server and look for the repositories. Go to repository you want to trigger and to hooks subdirectory. Create a file called post-commit.cmd. Subversion will run this script every time something comes in. We want to simply call an URL. Under Linux you would use the curl command. Here you can do it also but you will have to download the curl for Windows and place it somewhere on the server. But there is a better way. You can use PowerShell do call the URL. So create a post-commit.ps1 file (the name does not matter actually but lets keep it “in ordnung”). Inside write the script:

[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
(New-Object System.Net.WebClient).DownloadString("$url");

The first line is only if you have Jenkins running over SSL with self issued certificate (like we have). In the second line please fill the gaps with to form correct URL. The third line calls this URL. Nice thing about it you have most likely PowerShell installed if you are on modern Windows Server.

Now call the PowerShell script from the post-commit.cmd like this:

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& '%~dp0post-commit.ps1'"

The NoProfile and ExecutionPolicy switches are to make it possible to call a script from command line. In Command switch pay attention to the syntax. The %~dp0 switch means current directory (of course).

Now check something in and watch the build being triggered (if it’s not – check it once again – it worked on my machine).

Now Git. We were using TFS Git from There is no access to hooks under TFS. But Microsoft was kind enough to make it possible in other way. Log into Go to your project and look for “Service Hooks”.


It lets you integrate with various 3rd party services. One of them is Jenkins CI.


I would like Microsoft to let me make simple URL call among those “Services”. Please. But since it is not possible let’s choose Jenkins.


Decided to trigger the build after every code push. You can set the filers to get it triggered only for certain repos or branches. Then choose to trigger generic build and provide all the necessary information like Jenkins URL, user name, API token (more to it later), build (it is job name provided automatically) and build token (as in case of SVN – provided by Jenkins when you configure “Trigger build remotely”). To get the API token on Jenkins CI go to “People”, search for the configured user and choose “Configure”


Look for API token and use it on

Test it and check it the build was triggered. It should. It worked on my machines.

I hope it was useful!

Vanilla build server and a little NuGet gem

October 6, 2014 on 7:37 pm | In ASP.NET MVC, Continuous Integration, DotNet, MSBuild | No Comments

Vanilla build server is a concept that says that the build server should have as few dependencies as possible. It should be like vanilla ice cream without any raisins (I have raisins in ice cream). Let me cite the classic (from: Continuous Integration in .NET):

“It’s strongly suggested that you dedicate a separate machine to act as the CI server. Why? Because a correctly created CI process should have as few dependencies as possible. This means your machine should be as vanilla as possible. For a .NET setup, it’s best to have only the operating system, the .NET framework, and probably the source control client. Some CI servers also need IIS or SharePoint Services to extend their functionality. We recommend that you not install any additional applications on the build server unless they’re taking part in the build process.”

I was recently preparing a talk for a conference and setting up a brand new CI server on Windows Server 2012. My ASP.NET MVC project build ended up of course with following error:

error MSB4019: The imported project "C:\Program Files 
was not found. Confirm that the path in the <Import> 
declaration is correct, and that the file exists on disk.

Well of course. I have a vanilla machine without any MSBuild targets for ASP.NET MVC. I was going to solve it like usual. Create a tools directory, copy the needed targets into the repository and configure the MSBuild paths to take the targets provided with the repository. It worked like a charm in the past and it would work now. But something (call it intuition) made check over at NuGet and to my joy I found this little gem:

“MSBuild targets for Web and WebApplications that come with Visual Studio. Useful for build servers that do not have Visual Studio installed.” Exactly!

I quickly installed it. Configured the MSBuild on the build server to use it like this:


It is a command line parameter I’ve added to the build arguments.

An voila!

Next Page »

Powered by WordPress with Pool theme design by Borja Fernandez.
Text © Marcin Kawalerowicz. Hosting CODEFUSION.