The card has latest firmware (version 5.300.8 from 2017) and when it tries to configure itself with DHCP from a MT router, it fails with a message that it didn't get a gateway from the DHCP server (the message can only be seen on the serial port of the card). The lease appears on the MT DHCP server correctly, the DHCP server actually provides the gateway, but the card remains without an IP address and unreachable. The same card when connected to a random cheap Chinese router (Tenda) in default config, can get its IP with no problem. Many other devices (except this UPS card) can get its IP (and gateway too) from the same MT router just fine, it's really the first time I see such a strange device. Tried two such cards (to rule out bad hardware) both running the same latest firmware and factory default configuration. And the firmware from 2017 even includes IPv6 support, so one might think any IPv4 bugs have long been fixed.
Before I build a setup to sniff traffic between the card and the Tenda router that gives working DHCP for this card - any suggestions what the missing DHCP option in the MT DHCP server could be? Has anyone seen similar issues with some hardware (the card seems to be running some kind of proprietary embedded OS). Building the setup is a bit of a challenge because the UPS is at a remote location, and the card needs to be rebooted to try DHCP again, ethernet link down/up doesn't do it, easiest ways without powering down the UPS (and its connected loads) is to reboot by serial console menu on the card, or power-cycle the card (physically remove from UPS and then re-insert).
Re: Liebert IS-WEBCARD HID9 (UPS monitoring card) DHCP compatibility issue
If you can, try to sniff DHCP traffic (a wireshark running on a PC, UPS' port mirrored) and then compare DHCP offer as sent out by Mikrotik against offer which that Liebert card likes.
I seem to remember issue in MT's DHCP server, introduced a couple of years ago (which was then resolved). It was about order in which DHCP options are present in DHCP lease offer (and not the lack of any). It seems that there are (buggy!!) DHVP clients which expect certain options in a particular order. If DHCP lease offer uses different order, then clients refuse to use that lease. This behaviour is clearly not according to relevant RFCs, they don't specify DHCP option order. MT then "fixed" DHCP server so that it sends DHVP options in certain order which made most clients happy again.
As suggested above, coparision of DHCP lease offers, sent out by different servers, may point out the problem (and you may be able to persuade MT devs to do something about it).
I seem to remember issue in MT's DHCP server, introduced a couple of years ago (which was then resolved). It was about order in which DHCP options are present in DHCP lease offer (and not the lack of any). It seems that there are (buggy!!) DHVP clients which expect certain options in a particular order. If DHCP lease offer uses different order, then clients refuse to use that lease. This behaviour is clearly not according to relevant RFCs, they don't specify DHCP option order. MT then "fixed" DHCP server so that it sends DHVP options in certain order which made most clients happy again.
As suggested above, coparision of DHCP lease offers, sent out by different servers, may point out the problem (and you may be able to persuade MT devs to do something about it).
Re: Liebert IS-WEBCARD HID9 (UPS monitoring card) DHCP compatibility issue
OK, found a way to power up the card without the UPS (luckily found Liebert GXT2 series UPS schematics, and found connector pinout where to apply +12V DC to the connector) and sniffed something. Both of the two different cheap working Chinese routers I've tried (Phicomm, Tenda - both generally crappy otherwise) sent the following sets of DHCP options, in the same order, differing only in default IPs and amount of padding at the end:
while the MT routers (similar for 6.49.10 and 7.12.1) send fewer options:
The router option is there but the subnet mask and broadcast address are missing. I'm surprised it works with most clients anyway, as if they assumed /24 based on the 192.168.x.x prefix (called C-class, obsolete long long ago, I thought only dinosaurs like me still remember that). I suspect the card doesn't make such assumption and requires the options. But I'm not sure how to test it, as trying to add the option manually doesn't seem to have any effect (it doesn't appear in captured DHCP packets):
Code: Select all
Dynamic Host Configuration Protocol (Offer)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x0000794b
Seconds elapsed: 0
Bootp flags: 0x8000, Broadcast flag (Broadcast)
Client IP address: 0.0.0.0
Your (client) IP address: 192.168.2.166
Next server IP address: 192.168.2.1
Relay agent IP address: 0.0.0.0
Client MAC address: 00:02:99:10:e1:2d
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Offer)
Option: (54) DHCP Server Identifier (192.168.2.1)
Option: (51) IP Address Lease Time
Option: (58) Renewal Time Value
Option: (59) Rebinding Time Value
Option: (1) Subnet Mask (255.255.255.0)
Option: (28) Broadcast Address (192.168.2.255)
Option: (3) Router
Option: (6) Domain Name Server
Option: (255) End
Padding: 0000000000000000
Code: Select all
Dynamic Host Configuration Protocol (Offer)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x0000794b
Seconds elapsed: 0
Bootp flags: 0x8000, Broadcast flag (Broadcast)
Client IP address: 0.0.0.0
Your (client) IP address: 192.168.88.254
Next server IP address: 192.168.88.1
Relay agent IP address: 0.0.0.0
Client MAC address: 00:02:99:10:e1:2d
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Offer)
Option: (54) DHCP Server Identifier (192.168.88.1)
Option: (51) IP Address Lease Time
Option: (3) Router
Option: (6) Domain Name Server
Option: (255) End
Padding: 0000000000000000000000000000000000000000000000000000000000000000
Code: Select all
/ip dhcp-server option
add code=1 name=option1 value="'255.255.255.0'"
Re: Liebert IS-WEBCARD HID9 (UPS monitoring card) DHCP compatibility issue
Maybe you need to add the (newish 7.1rc5):
force=yes
https://help.mikrotik.com/docs/display/ROS/DHCP
force=yes
https://help.mikrotik.com/docs/display/ROS/DHCP
Re: Liebert IS-WEBCARD HID9 (UPS monitoring card) DHCP compatibility issue
Thanks! Now tested with 7.12.1 and adding these options helps:
The netmask option (1) is required for the card to configure properly without the confusing "no gateway" error message.
The broadcast option (28) is not strictly required but makes the card report proper broadcast address instead of 0.0.0.0.
The request from the card asks (option 55) for broadcast (28) but not netmask (1):
MT DHCP server needs to be specifically configured to send the broadcast option (not sent by default even though requested), and the netmask option (with force=1 for clients that don't request it, like this UPS card). This is in a mostly default configuration.
For comparison, the Chinese routers (Phicomm, Tenda) do send both: broadcast, netmask (the latter even if not requested by client). Out of curiosity I've just tested another one, very old (2011) TP-Link TL-WR340G - only difference is that its broadcast is 255.255.255.255 (not subnet broadcast 192.168.x.255 as in the newer ones), but it also does send netmask even if not requested and this UPS card works properly. So this (DHCP server sending netmask option even if not requested by DHCP client, and sending broadcast option) seems to be common practice, and MT probably should follow that. Values of these options depend on specific IP configurations so it would be error-prone to set them manually (separately for each DHCP network, especially on routers that have many interfaces with possibly different netmasks).
Hope this helps someone, for those searching for solutions to the error messages from the card I include the messages below. With default MT DHCP server config (no netmask, no broadcast), not working:
With netmask (force=yes) and broadcast options added, working:
MT, please consider changing the DHCP server defaults so these options don't have to be set manually (or at least, set them in the default router configuration to match most other SOHO routers) - it may affect other IoT devices which happen to be based on the same embedded OS (unknown one for now, but Google finds FNS_IF_EVENT_ADDRESS_READY in log messages from some VoIP phones).
Code: Select all
/ip dhcp-server option
add code=1 force=yes name=option1 value="'255.255.255.0'"
add code=28 name=option2 value="'192.168.88.255'"
The broadcast option (28) is not strictly required but makes the card report proper broadcast address instead of 0.0.0.0.
The request from the card asks (option 55) for broadcast (28) but not netmask (1):
Code: Select all
Dynamic Host Configuration Protocol (Request)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x0000794b
Seconds elapsed: 0
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: 00:02:99:10:e1:2d
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Request)
Length: 1
DHCP: Request (3)
Option: (57) Maximum DHCP Message Size
Length: 2
Maximum DHCP Message Size: 548
Option: (50) Requested IP Address (192.168.1.100)
Length: 4
Requested IP Address: 192.168.1.100
Option: (54) DHCP Server Identifier (192.168.1.1)
Length: 4
DHCP Server Identifier: 192.168.1.1
Option: (55) Parameter Request List
Length: 8
Parameter Request List Item: (3) Router
Parameter Request List Item: (6) Domain Name Server
Parameter Request List Item: (28) Broadcast Address
Parameter Request List Item: (54) DHCP Server Identifier
Parameter Request List Item: (2) Time Offset
Parameter Request List Item: (23) Default IP Time-to-Live
Parameter Request List Item: (0) Padding
Parameter Request List Item: (255) End
Option: (255) End
Option End: 255
Padding: 000000000000000000000000000000000000000000000000000000000000000000000000…
For comparison, the Chinese routers (Phicomm, Tenda) do send both: broadcast, netmask (the latter even if not requested by client). Out of curiosity I've just tested another one, very old (2011) TP-Link TL-WR340G - only difference is that its broadcast is 255.255.255.255 (not subnet broadcast 192.168.x.255 as in the newer ones), but it also does send netmask even if not requested and this UPS card works properly. So this (DHCP server sending netmask option even if not requested by DHCP client, and sending broadcast option) seems to be common practice, and MT probably should follow that. Values of these options depend on specific IP configurations so it would be error-prone to set them manually (separately for each DHCP network, especially on routers that have many interfaces with possibly different netmasks).
Hope this helps someone, for those searching for solutions to the error messages from the card I include the messages below. With default MT DHCP server config (no netmask, no broadcast), not working:
Code: Select all
Interface callback: FNS_IF_EVENT_ADDRESS_READY for 192.168.88.249.
DhcpCallback: DHCP_LEASE_IS_BOUND, IP 192.168.88.249
Error: Could not set DHCP Data!
IPv4 DHCP Address returned
No gateway is provided by DHCP server!
IP Address: 0.0.0.0
Netmask: 0.0.0.0
Broadcast Address: 0.0.0.0
DHCP/BootP Server: 0.0.0.0
Code: Select all
Interface callback: FNS_IF_EVENT_ADDRESS_READY for 192.168.88.249.
DhcpCallback: DHCP_LEASE_IS_BOUND, IP 192.168.88.249
Received DHCPv4 DNS Address: 192.168.88.1
IPv4 DHCP Address returned
IP Address: 192.168.88.249
Netmask: 255.255.255.0
Gateway: 192.168.88.1
Broadcast Address: 192.168.88.255
DHCP/BootP Server: 192.168.88.1
IPv4 DNS Server: "192.168.88.1"
Re: Liebert IS-WEBCARD HID9 (UPS monitoring card) DHCP compatibility issue
As always I may be wrong, but it seems to me a (yet another) case of different companies/programmers reading and implementing standards in different ways, it doesn't really matter who is right and who is wrong (in this case specifically Mikrotik seems half right and half wrong), what I find preoccupying is the lack of documentation about the matter.
It is simply incredible that a potentially serious issue (something that could well drive customers away from the company products) is resolved by the competence and persistence of one user and the intuition of another one on the forum (by sheer coincidence, I was looking for a completely different topic and happened to see the thread about the force=yes feature, it took years to have the option added):
viewtopic.php?t=92799
I don't think that Mikrotik should "mimic" what other manufacturer do (out of standards) but since it is possible to use the existing features to do that in case of need, they could well document properly the matter, judging from the given thread you are not the first one (nor will be the last one) with this kind of problems.
It is simply incredible that a potentially serious issue (something that could well drive customers away from the company products) is resolved by the competence and persistence of one user and the intuition of another one on the forum (by sheer coincidence, I was looking for a completely different topic and happened to see the thread about the force=yes feature, it took years to have the option added):
viewtopic.php?t=92799
I don't think that Mikrotik should "mimic" what other manufacturer do (out of standards) but since it is possible to use the existing features to do that in case of need, they could well document properly the matter, judging from the given thread you are not the first one (nor will be the last one) with this kind of problems.
Re: Liebert IS-WEBCARD HID9 (UPS monitoring card) DHCP compatibility issue
In this case it's not just "mimic what other manufacturer does" as probably almost everyone else (except MT) does that, that's probably why the bug may have gone unnoticed for so long in a mature product like that UPS card (which comes with DHCP as factory default, so if DHCP fails the only way to access it is to set static IP via serial console).
Is there any way to "force" the netmask option without changing its value? If not, there should be - this would match common practice what typical home routers do (send netmask option even if not requested by client) and make some buggy clients like this UPS card work, while using the correct netmask from the defined DHCP network without need to specify it separately in the option (different options for routers that have more interfaces with different netmasks). There are some predefined variables that can be used in DHCP options, such as NETWORK_GATEWAY but not netmask (or at least not documented). It would be useful to be able to write DHCP options like this, independent from specific IP addresses/netmasks, and make it part of default router configuration (to match what everyone else does, for better compatibility with different clients including buggy ones):
Is there any way to "force" the netmask option without changing its value? If not, there should be - this would match common practice what typical home routers do (send netmask option even if not requested by client) and make some buggy clients like this UPS card work, while using the correct netmask from the defined DHCP network without need to specify it separately in the option (different options for routers that have more interfaces with different netmasks). There are some predefined variables that can be used in DHCP options, such as NETWORK_GATEWAY but not netmask (or at least not documented). It would be useful to be able to write DHCP options like this, independent from specific IP addresses/netmasks, and make it part of default router configuration (to match what everyone else does, for better compatibility with different clients including buggy ones):
Code: Select all
/ip dhcp-server option
add code=1 force=yes name=option1 value="$(NETWORK_MASK)"
add code=28 name=option28 value="$(NETWORK_BROADCAST)"Re: Liebert IS-WEBCARD HID9 (UPS monitoring card) DHCP compatibility issue
Yep, still the manufacturer of a (I presume) high-end device is clearly not respecting the standard.
Mikrotik evidently does not respect the standard in a different way.
The el-cheapo Chinese manufacturer while also not respecting the standard, at least manage to have more devices (very likely there are lots of devices in the wild that behave badly) working without making their customers go mad or needing to become DHCP investigators.
You tell me which one is not respecting the standard in the smartest way.
Seriously, your proposal seems to me a very logical one that could be implemented with very little effort by Mikrotik and (if properly documented) could solve the incompatibility with (I believe) a number of devices, you should try to propose it officially as a feature request.
Mikrotik evidently does not respect the standard in a different way.
The el-cheapo Chinese manufacturer while also not respecting the standard, at least manage to have more devices (very likely there are lots of devices in the wild that behave badly) working without making their customers go mad or needing to become DHCP investigators.
You tell me which one is not respecting the standard in the smartest way.
Seriously, your proposal seems to me a very logical one that could be implemented with very little effort by Mikrotik and (if properly documented) could solve the incompatibility with (I believe) a number of devices, you should try to propose it officially as a feature request.