hAP ac2 model DHCP Client difference from mipsbe models

Hardware MikroTik hardware general
1

We managed problem with ac2 model compatibility with some fiber media converters. There is problem with dhcp client packets. Ac2 router can’t receive ip from dchp server. DHCP Broadcast discover and offer passes, but no more. All mipsbe routers works fine. I found that mipsbe routers sends broadcast flag (Bootp flags: 0x8000, Broadcast flag (Broadcast)) and it works. Ac2 (arm) router sends unicast flag (Bootp flags: 0x0000 (Unicast)) and it fails. How to solve this problem from Mikrotik side? And why simple fiber converters can fail to pass hdcp packets?

2

What version of ROS are you running? There has been a problem with DHCP client sending unicast renew request to wrong mac address.

https://mikrotik.com/download/changelogs

What’s new in 6.42.2 (2018-May-17 09:20):
*) dhcpv4-client - fixed DHCP client stuck in renewing state;

3

I’ve tried few versions 6.41.3, 6.42.3 and newest 6.42.5, same result. Mipsbe routers like rb951g, rb952ui, rb951ui works fine. Possible arm package has different dhcp setup, but how to change it.

4

There should be no difference in functionality between platforms, except for some extra packages (dude/userman) and MetaROUTER.

Could you update firmware as well? Are you sure the offer is received by the hAP AC^2? Could you share a pcap of the incomplete conversation on the hAP AC^2 side?

5

Firmware update makes no difference. dhcp server was cisco router, I was testing here with mikrotik rb952ui as dhcp server. Discover and offer could be seen here (no request and act appears):

Frame 335: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: cc:2d:e0:a3:73:40 (cc:2d:e0:a3:73:40), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0xeb6730af
    Seconds elapsed: 51
    Bootp flags: 0x0000 (Unicast)
        0... .... .... .... = Broadcast flag: Unicast
        .000 0000 0000 0000 = Reserved flags: 0x0000
    Client IP address: 0.0.0.0
    Your (client) IP address: 0.0.0.0
    Next server IP address: 0.0.0.0
    Relay agent IP address: 0.0.0.0
    Client MAC address: cc:2d:e0:a3:73:40 (cc:2d:e0:a3:73:40)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Discover)
        Length: 1
        DHCP: Discover (1)
    Option: (55) Parameter Request List
        Length: 8
        Parameter Request List Item: (1) Subnet Mask
        Parameter Request List Item: (121) Classless Static Route
        Parameter Request List Item: (3) Router
        Parameter Request List Item: (33) Static Route
        Parameter Request List Item: (6) Domain Name Server
        Parameter Request List Item: (42) Network Time Protocol Servers
        Parameter Request List Item: (138) CAPWAP Access Controllers
        Parameter Request List Item: (43) Vendor-Specific Information
    Option: (12) Host Name
        Length: 9
        Host Name: MTik_7340
    Option: (61) Client identifier
        Length: 7
        Hardware type: Ethernet (0x01)
        Client MAC address: cc:2d:e0:a3:73:40 (cc:2d:e0:a3:73:40)
    Option: (255) End
        Option End: 255
    Padding: 000000000000000000000000000000000000000000000000...

Frame 336: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Routerbo_60:d7:97 (6c:3b:6b:60:d7:97), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 192.168.10.1, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 67, Dst Port: 68
Bootstrap Protocol (Offer)
    Message type: Boot Reply (2)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0xeb6730af
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
        0... .... .... .... = Broadcast flag: Unicast
        .000 0000 0000 0000 = Reserved flags: 0x0000
    Client IP address: 0.0.0.0
    Your (client) IP address: 192.168.10.236
    Next server IP address: 192.168.10.1
    Relay agent IP address: 0.0.0.0
    Client MAC address: cc:2d:e0:a3:73:40 (cc:2d:e0:a3:73:40)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Offer)
        Length: 1
        DHCP: Offer (2)
    Option: (54) DHCP Server Identifier
        Length: 4
        DHCP Server Identifier: 192.168.10.1
    Option: (51) IP Address Lease Time
        Length: 4
        IP Address Lease Time: (7200s) 2 hours
    Option: (1) Subnet Mask
        Length: 4
        Subnet Mask: 255.255.255.0
    Option: (3) Router
        Length: 4
        Router: 192.168.10.1
    Option: (6) Domain Name Server
        Length: 4
        Domain Name Server: 192.168.10.1
    Option: (42) Network Time Protocol Servers
        Length: 4
        Network Time Protocol Server: 86.100.0.8
    Option: (255) End
        Option End: 255
    Padding: 0000000000000000000000000000000000000000
6

“Seconds elapsed: 51” indicates that you have captured not the first packet in the dhcp discovery process.

The unicast flagged discover after a while is to be expected: http://forum.mikrotik.com/t/dhcp-client-problem-with-broadcast-flag/44690/1

However we could add a workaround, when DHCP client will switch off broadcast after 15 sec of not getting the address;

  • 15sec broadcast;
  • 15sec without broadcast, when broadcast messages fail.

Can you redo capture on an ‘IP release’ action on DHCP client?

7

We collected these strange fiber converters and will try to replace, because problem seems there. I can’t test now what packets pass and fail. And I guess it is not hardware topic for this, but found that only this arm device model ac2 tries to send unicast flag. Is it possible to change this dchp client flag to: Bootp flags: 0x8000, Broadcast flag (Broadcast) ?

8

The first few DHCP Discovers contain a broadcast flag. Then, after 15 seconds without a succesful negotiation, MT will send DHCP Discovery without broadcast flag.

This is why i suggested to re-do the capture on the beginnen of the discovery process (e.g. after disable/enable dhcp-client).

DHCP Request #4:

Bootstrap Protocol (Discover)
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x209b6eb3
    Seconds elapsed: 15
    Bootp flags: 0x8000, Broadcast flag (Broadcast)
    Client IP address: 0.0.0.0
    Your (client) IP address: 0.0.0.0
    Next server IP address: 0.0.0.0
    Relay agent IP address: 0.0.0.0
    Client MAC address: MS-NLB-PhysServer-20_3f:49:4c:2d (02:14:3f:49:4c:2d)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Discover)
    Option: (55) Parameter Request List
    Option: (255) End
    Padding: 000000000000000000000000000000000000000000000000...

DHCP Request #5:

Bootstrap Protocol (Discover)
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x209b6eb3
    Seconds elapsed: 20
    Bootp flags: 0x0000 (Unicast)
    Client IP address: 0.0.0.0
    Your (client) IP address: 0.0.0.0
    Next server IP address: 0.0.0.0
    Relay agent IP address: 0.0.0.0
    Client MAC address: MS-NLB-PhysServer-20_3f:49:4c:2d (02:14:3f:49:4c:2d)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Discover)
    Option: (55) Parameter Request List
    Option: (255) End
    Padding: 000000000000000000000000000000000000000000000000...