So I just installed an RB1100Ah at a client’s site today. Everything worked according to plan except for the DHCP server setup.
The DHCP server was successfully setup to respond to DHCP requests, however, the option configuration which is used by the Avaya IP Phones didn’t exactly work.
I replicated the same config on one of the Windows server and it worked like a charm.
After battling for some hours and there seemed to be no headway, i setup that windows server as the DHCP server while I try to find what may be wrong with my DHCP server config.
Below is the option config I have on the router:
name: avaya
code: 242
value: MCIPADD=192.168.0.241,MCPORT=1719,HTTPSRVR=192.168.0.202,VLANTEST=60,L2QAUD=5,L2QSIG=3,L2QVLAN=0
Please recall I have this same setting on my windows dhcp server and it works well.
in RouterOS you have to set dhcp-server option value in HEX. you can try to sniff the traffic that your ucrrent dhcp-server is sending to client and get the hex string out of it. Then put this in as value. At least this works for options that are described in various RFC.
other options described in this way:
code, length, value - in routeros you only have to enter value, as length of the option usually is calculated from the value you have entered.
Or, you can convert whole string to HEX, most probably IP addresses should be 4 bytes. as example: 10.10.10.10 would become 0a0a0a0a.
Thanks for the feedback. If I understand you correctly, you are saying that I convert this option string value (MCIPADD=192.168.0.241,MCPORT=1719,HTTPSRVR=192.168.0.202,VLANTEST=60,L2QAUD=5,L2QSIG=3,L2QVLAN=0) into HEX?
How possible can this be considering the length of the string itself and its content?
Can you possibly help with the HEX version?
Regards,
Femi
UPDATE
I just checked online and came up with a website where I can do online conversion into HEX and it seems to have done it nicely. I’ll go ahead and try this and update this post.
Here’s the website’s url by the way: http://www.string-functions.com/string-hex.aspx
Cheers.
I am not too familiar with packet sniffers and how to decode the capture. How did you arrive with the code you are referring to as the correct one? Can you just help me with the code meant for the entire string:
MCIPADD=192.168.0.241,MCPORT=1719,HTTPSRVR=192.168.0.202,VLANTEST=60,L2QAUD=5,L2QSIG=3,L2QVLAN=0
when you send option it is encoded in ASCII, so you have to send ASCII symbol code. IP address is simply 4bytes integer that for ease of use is written in a way it is(fancy dots and decimal)
I can’t tell you how nice it would have been to just find an answer here instead of cryptic crap from MT support. I’m not sure if its actual arrogance or if mr. wonderful up there maybe thinks his english is more polished than it is.
I really wouldn’t expect anyone that writes with an accent to just leave snippy, short, dismissive answers. You are support. Support your users.
Anyway, here’s what I found after wasting 25 minutes figuring this out because MT’s support person couldn’t be bothered to explain:
Conversions came out like this:
First url, Ascii to Hex: MCIPADD= ----> 4d:43:49:50:41:44:44:3d
2nd url, IP to Hex: 192.168.0.241 ----> c0a800f1
Remove the colons ( and concatenate the two strings:
step 1 yields: 4d:43:49:50:41:44:44:3d c0a800f1
step 2 yields: 4d4349504144443dc0a800f1
I gues what you will have to do is convert each param/value pair by itself, using the multi steps above and concat that string into the 'Tik DHCP..
hth, let me know how it worked.
I’m on my own mission but I think this was a piece of what I need so be good to hear confirm back if I had it all correct or not.
Thanks for the comments. I also found it quite appalling that the Jansik fellow couldn’t render much support on this matter. Instead of being helpful, I think he ended up complicating matters.
I had actually tried out the steps you stated below and after about an hour or so converting strings and decimals to hex, I came up with the following:
4d4349504144443dc0a800f12c4d43504f52543d6b72c48545450535256523dc0a800ca2c564c414e544553543d3c2c4c32514155443d52c4c32515349473d32c4c3251564c414e3d0
which unfortunately still didn’t work. Since I wasn’t getting any response from this forum, I didn’t bother to post any comments back about that outcome.
I am really disappointed with the support here, this can never happen at Cisco and if the folks at Mikrotik dont already know that product support will go a long way to win them market share, then they should probably go back to MBA class
and concatenate the two strings:
