DNSRessourceRecord

May 12, 2012 at 5:39 PM

Hi Emi,

I made a simple program that answers to DNS request by sending always the same answer!
I'm having a little issue since the answer.Name is one byte too long and so the answer.Type, answer.Class and so on, are shifted.

Here a picture that shows the problem (my explaination isn't very clear I know ;) :
http://img831.imageshack.us/img831/2923/201205121827.png

And here is my code to create the DNSFrame and adding the answer to it.

//Exctracting the DNS request from the input frame
DNSFrame fDNSFrame = (DNSFrame)GetFrameByType(fInputFrame, FrameTypes.DNS);	

DNSFrame newDNSFrame = new DNSFrame();
//copy the DNS request into my new DNS frame
newDNSFrame = fDNSFrame;
//this frame is a Query
newDNSFrame.QRFlag = true;
//the answer is not Authoritative
newDNSFrame.AAFlag = false;
//no error = 0000
newDNSFrame.ResponseCode = 0000;

//Create a new answer block
DNSResourceRecord reponse = new DNSResourceRecord();
reponse.Name = "hello.world";
//Type 1 : A
reponse.Type = (DNSResourceType)Convert.ToInt32(1);
//Class 1 : INTERNET
reponse.Class = (DNSResourceClass) Convert.ToInt32(1);
reponse.TTL = 5;

//The answered address will be 192.168.11.1
reponse.ResourceData = new byte[4] {0xC0, 0xA8, 0x0B, 0x01};                

//Add the Answer to the DNS frame
newDNSFrame.AddAnswer(reponse);

The transport datagram, the IP packet and Ethernet frame are good.

Thank you for your help,
Nicolas

May 12, 2012 at 6:58 PM

In fact it's more likely that the reponse.Name is too short in my case ! This string must finish by '00' which is a delimiter since the name is of variable length.
In my capture, we can see that the first '00' of DnsType are wrongly mistaken for the DnsName delimiter :s

Coordinator
May 17, 2012 at 1:43 PM

Thank you for this detailed bug report.

It should be fixed in the current revision I just checked into the repository.


Would you kindly get the code from source control and try if the problem persists?

 

with best regards,

Emi

May 17, 2012 at 3:30 PM

I've got a "VerificationException was unhandled : operation coud destabilize the runtime" from the eExNetworkLibrary.Threading.InvocationHelper class.

Here a sreenshot of the problem :

http://img577.imageshack.us/img577/5553/verificationexception.png

The sender is eExNetworkLibrary.Routing.Router

 

I was working with the network Library 2.9 before (the one from the home page).
I will check each version of network library to tell you which one causes this for me.

Once again, thank you for your help.

May 17, 2012 at 4:18 PM

Almost there !
The answer seems correct but the query has an extra \0 at the end of the query.Name.

Here a capture of a DNS answer with bugfix applied:

http://img708.imageshack.us/img708/705/201205171705.png

May 18, 2012 at 9:45 AM

Hi Emi !

I made progress regardind this issue ! In fact there is no need for a bugfix !!
The name attribute must finish with the final dot representing the root domain.

I just modify this line from :

reponse.Name = "hello.world";

to :

reponse.Name = "hello.world.";

and now it is working perfectly !

 

But I can't use network Library with the InvocationHelper class because of the "VerificationException" :(
I can make other test if needed to help resolve this issue.

Best regards,
Nicolas

Coordinator
May 28, 2012 at 7:47 PM

I'm glad you found a way to work around the DNS issue.
I made a change to the DNSNameEncoder class, which fixes this bug by the same approach (adding a trailing dot, if none was there).

Sadly, I am currently not capable of reproducing the threading issue, I will further try to fix this error.

Could you describe what traffic handlers you are using in your program and how they are linked together?
Which router event is exactly fired when the verification exception happens?

Thanks for your help,

regards, Emi

Coordinator
May 28, 2012 at 7:55 PM

I just checked in a new version of the InvocationHelper class, which handles the case in which the invocation target is null.

Could you check whether this fixes the issues?

 

with best regards,

Emi

May 29, 2012 at 1:42 PM

Thank you for your response! I'm returning home tomorrow and I will try the new InvocationHelper class.

If it's not successful I will post my handlers definition and links for you to see what is going on.

 

Best regards,
Nicolas 

May 30, 2012 at 8:13 PM

I checked the last version of the class and I'm now able to use the last revision of the library :)

Best regards,
Nicolas

Coordinator
May 31, 2012 at 9:01 PM

Thank you. :)