Hello all,
I’m relatively new to RouterOS, and I’ve got a problem with some 951G RouterBOARDS that I can’t solve.
My DrayTek 2710 ADSL router is operating as an AP and has a DHCP Server offering IP addresses over WiFi. I want to connect an RB (RouterBOARD 951G 2HnD) to this over the WLAN so I can plug in some wired ethernet devices in another part of the house.
I have put a DHCP Client on the RB WLAN (station mode) and I cannot pick up an IP address. The RB WLAN connects to ess, but the DHCP Client is stuck in ‘searching’. If I configure the WLAN to have a manual IP address it works OK, so I think that proves that there is nothing wrong with Layer 1/2. My other RB has identical problems. All other WiFi devices in the house have no problems (HP laptops, iPad, Android phones, etc.).
I tried setting up an AP on one of my RouterBOARDs and then I could use DHCP Client on the other one to get an IP address. So, I’m thinking I have an incompatibility between my DrayTek AP DHCP Server and RouterBOARD Station DHCP Client, - over the WLAN only. If I connect the DrayTek and RouterBOARD using wired connections, then it works OK.
To see if the problem is DrayTek or MikroTik, I ran a sniffer on another PC to see what broadcast packets were exchanged. I get:
Time Source Destination Port Protocol Length Info
27.458693 0.0.0.0 255.255.255.255 67 DHCP 342 DHCP Discover - Transaction ID 0xc2fe3c0f
27.561175 192.168.1.1 255.255.255.255 68 DHCP 342 DHCP Offer - Transaction ID 0xc2fe3c0f
28.484052 0.0.0.0 255.255.255.255 67 DHCP 342 DHCP Discover - Transaction ID 0xc2fe3c0f
28.487481 192.168.1.1 255.255.255.255 68 DHCP 342 DHCP Offer - Transaction ID 0xc2fe3c0f
31.042734 0.0.0.0 255.255.255.255 67 DHCP 342 DHCP Discover - Transaction ID 0xc2fe3c0f
31.046145 192.168.1.1 255.255.255.255 68 DHCP 342 DHCP Offer - Transaction ID 0xc2fe3c0f
32.273626 0.0.0.0 255.255.255.255 67 DHCP 342 DHCP Discover - Transaction ID 0xc2fe3c0f
32.277059 192.168.1.1 255.255.255.255 68 DHCP 342 DHCP Offer - Transaction ID 0xc2fe3c0f
34.216854 0.0.0.0 255.255.255.255 67 DHCP 342 DHCP Discover - Transaction ID 0xc2fe3c0f
34.220197 192.168.1.1 255.255.255.255 68 DHCP 342 DHCP Offer - Transaction ID 0xc2fe3c0f
40.053550 0.0.0.0 255.255.255.255 67 DHCP 342 DHCP Discover - Transaction ID 0xc2fe3c0f
40.056889 192.168.1.1 255.255.255.255 68 DHCP 342 DHCP Offer - Transaction ID 0xc2fe3c0f
44.354222 0.0.0.0 255.255.255.255 67 DHCP 342 DHCP Discover - Transaction ID 0xc2fe3c0f
44.357576 192.168.1.1 255.255.255.255 68 DHCP 342 DHCP Offer - Transaction ID 0xc2fe3c0f
46.709244 0.0.0.0 255.255.255.255 67 DHCP 342 DHCP Discover - Transaction ID 0xc2fe3c0f
46.712898 192.168.1.1 255.255.255.255 68 DHCP 342 DHCP Offer - Transaction ID 0xc2fe3c0f
52.750600 0.0.0.0 255.255.255.255 67 DHCP 342 DHCP Discover - Transaction ID 0xc2fe3c0f
52.753866 192.168.1.1 255.255.255.255 68 DHCP 342 DHCP Offer - Transaction ID 0xc2fe3c0f
Why do the RouterBOARDs not send out a ‘DHCP Request’ - the normal response to a ‘DHCP Offer’?
By the way, I did try running the ROS sniffer on the WLAN port on the RB, but it was useless - didn’t see any DHCP packets at all - just lots of Beacons and a tiny number of Data packets with MAC addresses I didn’t recognise - sorry, I’m pretty clueless about WLAN sniffing.
Here is the normal response I expect (got by getting one RB to connect to the AP of the other one - with similar security, etc., compared with the DrayTek AP):
Time Source Destination Port Protocol Length Info
0.000000 0.0.0.0 255.255.255.255 67 DHCP 342 DHCP Discover - Transaction ID 0x37cb4889
0.538204 192.168.1.1 255.255.255.255 68 DHCP 342 DHCP Offer - Transaction ID 0x37cb4889
0.542769 0.0.0.0 255.255.255.255 67 DHCP 342 DHCP Request - Transaction ID 0x37cb4889
0.546100 192.168.1.1 255.255.255.255 68 DHCP 342 DHCP ACK - Transaction ID 0x37cb4889
So, the usual RB DHCP Client operation is to send out a ‘DHCP Request’ 4 ms after the ‘DHCP Offer’ broadcast. Why is this not happening when the DrayTek broadcasts the ‘DHCP Offer’? I’ve looked at every bit in the header of a RB-issued ‘DHCP Offer’ and compared it with the header of the DrayTek-issued ‘DHCP Offer’. They are identical (apart from obvious things like Source MAC Addresses, Transaction IDs, and slightly different Parameter Request Lists).
So how does the RB recognise that one of the offers is from a DrayTek and then refuse to proceed any further in the transaction?
I’ve done the usual diagnostic things - rebooted DrayTek and RBs several times, put the latest firmware on everything, set both RBs back to factory settings (with no config) and just configured the minimum number of settings on the RBs to isolate the problem. I’ve spent half a day on this now, and don’t think I’ll make any more progress without some assistance from a grown up!
Help!
Paul.