Jump to content











Photo

replicating dnsmasq


  • Please log in to reply
27 replies to this topic

#1 iainf

iainf

    Newbie

  • Members
  • 14 posts
  •  
    United Kingdom

Posted 11 February 2015 - 12:31 AM

Hi everyone,

 

Thanks for your hard work. I'm trying to use tftpd32 or "tiny pxe server" to boot over Ethernet a Mirotik RB951G-2hnd. Normally I use dnsmasq, however I'd like to try do it on windows.

 

However on tftpd32 it seems like the router ignores the DHCP response. The log file continually prints request from 0.0.0.0 with MAC address xyz. Then the next line is the correct lease. This just repeats all the time. I've used a hub to confirm that the packets are going back and forth.

 

The only significant difference I can see with dnsmasq & tfpd32 is that your destination field with the DHCP response is the broadcast address 255.255.255.255 where as dnsmasq uses the new leased IP as the destination field. Could this be it?

 

When I try it with tiny PXE server all I see in the log dialog is a long list of:

 

DHCPd:unrecognised bootp packet, MAC:4C-5E-0C-BA-D6-A6
 
I was going to try write a quick patch but I got loads of Visual Studio errors, most likely incorrect vcproj/Makefile problems so I thought I'd ask here before I began.
 
Thanks
Iain
 


#2 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 11 February 2015 - 11:11 AM

Hi Iain,

 

I can only talk for TinyPXE Server.

The packet being unrecognized (malformed?), TPS will not process it further.

If you capture it in wireshark and send it to me I could may be fix TPS to handle such packet.

 

"Unrecognized" in TPS means it starts with the right byte(01 or 02) but i could not match one of the below types : 

DHCP_DISCOVER,DHCP_offer,DHCP_REQUEST,DHCP_DECLINE,DHCP_ACK,DHCP_NACK,DHCP_RELEASE,DHCP_INFORM.

 

In dhcp mode, you can only answer (offer and ack) back to 255.255.255.255 since the client does not have an IP until the very last stage.

 

Regards,

Erwan

 

Edit : you meant mikrotic right (instead of mirotik) ?

if so, I am bit lost : mikrotic is a router/ap/dhcpd, why do you need another dhcp server?



#3 iainf

iainf

    Newbie

  • Members
  • 14 posts
  •  
    United Kingdom

Posted 11 February 2015 - 12:00 PM

Hi Erwan,

 

Thanks for replying. I need it to boot a new RAM kernel onto the router :)

 

Below is a screenshot of the DHCP packet, is that enough info?

 

Thanks!

 

RMwbamH.png

 



#4 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 11 February 2015 - 02:19 PM

Oki I believe this is a bootp request (rfc951) not a dhcp request (rfc2142) since option 53 is missing.

I have done a quick fix in TinyPXE Server. Download latest version
Edit config.ini, add rfc951=1 under [dhcp].

You should no longer read "unrecognized packet" and the boot request should be handled as a dhcp request.
This is a blind patch : I cannot test over here.

Give it a try and let me know : further adjustements may be needed.

Regards,
Erwan

EDIT : to be discussed later, you may have to update opt60 in TPS to match your hardware.

#5 iainf

iainf

    Newbie

  • Members
  • 14 posts
  •  
    United Kingdom

Posted 11 February 2015 - 02:58 PM

Thanks so much for patching for me.

 

Now I'm not getting errors but its behaving like tftpd32, it sends a response but the router seems to ignore it and continually send requests. I've attached a pic of TPS and also the response packet which I've split into two images.

 

I'm very interested in the opt60, image you mentioned above. 

 

dKdeTEj.png

 

QQ5SuWL.png

DzT1i7E.png



#6 iainf

iainf

    Newbie

  • Members
  • 14 posts
  •  
    United Kingdom

Posted 11 February 2015 - 03:04 PM

I'll show you the response that dnsmasq does on Linux that the router accepts, maybe it will help you :)

 

GsSFh4n.png

y4VbjaH.png



#7 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 11 February 2015 - 03:44 PM

i'll have a look at these screenshots and will report back.

would you be able to mail/pm me a capture from wireshark?

 

and opt60, see in TPS in the lower part of the form (click on the arrow) and make sure it matches your classid (mips_boot).



#8 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 11 February 2015 - 03:56 PM

The issue could be with the servername filled.

I have the feeling it should be empty in your case.

See here : https://tools.ietf.org/html/rfc951 .

The BOOTREQUEST/BOOTREPLY is explained.

 

Either that or the bootp client does not like the extra DHCP options.



#9 iainf

iainf

    Newbie

  • Members
  • 14 posts
  •  
    United Kingdom

Posted 11 February 2015 - 04:00 PM

Hi Erwan,

 

Sure I can send you the wireshark, although all DHCP files look like that. How can I send it to you?

 

How could I remove the servername and other DHCP options. Is it possible via the config file?


Edited by iainf, 11 February 2015 - 04:00 PM.


#10 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 11 February 2015 - 05:33 PM

Hi Erwan,

 

Sure I can send you the wireshark, although all DHCP files look like that. How can I send it to you?

 

How could I remove the servername and other DHCP options. Is it possible via the config file?

 

I would not worry too much about your servername : it does not put you at risk.

I alreayd know you internal mac and ip so ...

If really a matter for you, edit the pcap file with an hex editor (like hxd).



#11 iainf

iainf

    Newbie

  • Members
  • 14 posts
  •  
    United Kingdom

Posted 11 February 2015 - 05:57 PM

Hi Erwan,

 

I meant how can I stop TPS not send the server name or the other options. Because I also think that could be the issue :)



#12 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 11 February 2015 - 06:09 PM

Hi Erwan,

 

I meant how can I stop TPS not send the server name or the other options. Because I also think that could be the issue :)

 

 

Download the exe again.

Put no_hostname=1 under [dhcp] .

 

Lets see what it gives :)

 

Edit :

1/Note that opt6 and opt28 differs between your dnsmasq and tps setup.

2/You also seem to have a specific opt43.

I dont think this this will prevent the dhcp lease to happen but worth mentionning.



#13 iainf

iainf

    Newbie

  • Members
  • 14 posts
  •  
    United Kingdom

Posted 11 February 2015 - 06:24 PM

Thanks again but I tried and checked wireshark but it didn't work. I think I know what it could be with the working version wireshark recognizes the file response as "Boot Reply" with TPS it comes up as "DHCP ACK".

 

Can I remove option 53 from the response with TPS please? If its possible it could be cool have something in the config file like the following

 

IgnoreOpt=53

IgnoreOpt=100

 

Then when its building the file if it sees the Opt 53 or Opt 100 it skips it and doesn't include in the file. I made up opt 100 just to show the example.

 

Thanks again you're help is very much appreciated !



#14 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 11 February 2015 - 06:27 PM

you mean that even with the hostname field empty, it does not work?

or do you mean the no_hostname option did not work as expected (i.e null the information) ?

 

in theory (per the rfc) the extra option should not be an issue but this is the last difference with your dnsmasq capture so indeed ...



#15 iainf

iainf

    Newbie

  • Members
  • 14 posts
  •  
    United Kingdom

Posted 11 February 2015 - 06:30 PM

I mean that the new option worked, I could see it using wireshark :)

 

However it did not fix the problem, the router continued to ignore it :(

 

I think ignring options has to be it, also would be great addition to your TPS making it very flexible so it can handle badly coded DHCP clients like the routers one :)



#16 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 11 February 2015 - 06:32 PM

I mean that the new option worked, I could see it using wireshark :)

 

However it did not fix the problem, the router continued to ignore it :(

 

I think ignring options has to be it, also would be great addition to your TPS making it very flexible so it can handle badly coded DHCP clients like the routers one :)

 

I did not test but inputing 0.0.0.0 for every field when an IP is required might skip it then.

I'll review my code on my side but you may want to try it already.

 

EDIT :

1/

discard the above. wont help.

2/

let me implement a ignoreopt53 as a test.

is that the only option that should be skipped?



#17 iainf

iainf

    Newbie

  • Members
  • 14 posts
  •  
    United Kingdom

Posted 11 February 2015 - 07:04 PM

53,54 and 13 ignored would replicate it thanks :)



#18 iainf

iainf

    Newbie

  • Members
  • 14 posts
  •  
    United Kingdom

Posted 12 February 2015 - 01:44 PM

HI Erwan,

 

Just wondering how its going, don't mean to rush just interested. I'm a coder too so if I can help let me know please :)



#19 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 12 February 2015 - 02:09 PM

HI Erwan,

 

Just wondering how its going, don't mean to rush just interested. I'm a coder too so if I can help let me know please :)

 

actually working on it :)

 

i am trying to find a bootp client at home (no luck so far).

i tried with a wrt54gl (linksys) with dd-wrt but no bootp there.

now trying with an old network card.

 

once i find a bootp client, i will be able to support it very quickly.

 

easier than blind patching.

 

EDIT : send me some wireshark captures. it will help. both working and non working.



#20 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 12 February 2015 - 02:35 PM

new version uploaded. give it another try.

 

sum up :

-add rfc951=1

-add no_hostname=1 (although i am not sure this is needed, we'll see later)

-add no_opt13=1

 

new version will not fill in opt53 (dhcp message) if it detects a bootp request (i.e not a dhcp request).

 

opt54 is still there for now.

and the vendor buffer size differs from bootp (64 bytes) to dhcp (254 bytes).



#21 iainf

iainf

    Newbie

  • Members
  • 14 posts
  •  
    United Kingdom

Posted 12 February 2015 - 03:02 PM

Ok great thanks man, if there is anything I can do let me know please :) 



#22 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 12 February 2015 - 03:03 PM

Ok great thanks man, if there is anything I can do let me know please :)

 

Hi Iain,

 

See my latest post above.

Give a try to latest version.

 

Regards,

Erwan



#23 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 12 February 2015 - 03:24 PM

Oki latest version (uploaded a few secs ago), now sends correct "BOOTP Reply" frames.

By correct I mean recognized as such by wireshark.

The trick was indeed to strip out option 53 (dhcp message).

 

It "might" now works for you :)

 

rvExB3D.png


  • iainf likes this

#24 iainf

iainf

    Newbie

  • Members
  • 14 posts
  •  
    United Kingdom

Posted 12 February 2015 - 03:32 PM

It works yaaaaaaaay thanks so much man



#25 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 12 February 2015 - 03:34 PM

It works yaaaaaaaay thanks so much man

 

Nice :)

So now Tiny PXE Server is compatible with bootp requests (next to dhcp requests) : thanks for your help in achieving that.

 

Would you care to do one last test?

Remove no_hostname=1 and no_opt13=1 and leave only rfc951=1.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users