DHCP

RouterOS General
1

I’m having a probem with DHCP on 2.94. On the debug on the Mikrotik it says received discover from (Mac address of client) unknown giaddr 192.168.10.202 The 192.168.10.202 is the address of the Wireless interface on my tropos unit. Is their a way to turn off the giaddr event and get the DHCP server to go ahead and issue an address?

Thanks for the help

2

What version of ROS are you using?

3

2.9.4? update to 2.9.51 and check again

4

I’m having the same problem and I am on 3.9
Isn’t there some way to make the Mikrotik DHCP ignore the giaddr?

5

Updated to 3.9 still same problem. Noticed in other devices there is a command to turn off giaddr is their such a command for ROS

Frank

6

ATT Mikrotik guys-

Many DHCP servers have an option to ignore the giaddr, as frankw also notes.
My application is going to require this and I can’t find anything in the MT docs as to how to accomplish this.
Please let us know what (other than going away from MT) we can do to cause the router to give addresses and not care about the giaddr.

Thanks Very Much!

7

Here is a bit more info on the problem after observing more and spending a couple more hours time trying to get it working.

I look at the log (debug on).
I see that I

receive requests, discovers, informs from (client MAC) with unknown giaddr 192.168.10.194 (for example)

If I go to the DHCP server and fill in the “relay” section with the address quoted, then the server assigns an IP to the request.
I don’t know if the client can do anything with it, but at least it goes into the list of leases.

Anyone have any ideas? All my stuff is on the same subnet- relay should never have to even enter in to it.


Thanks

8

I have more information on this problem.

The devices I am using behind the hotspot are Tropos mesh nodes. These are expensive radios. Upon discussing this with the manufacturer, I found that they require that a DHCP server be 100% ISC compliant. It must be that the MT DHCP is not. Not to feel bad, but it seems that Dlink, Netgear, DDWRT, OPENWRT and lots of others are not either. They all don’t know what to do with the giaddr.

Reading up on ISC, I see that DHCPD is compliant, and I also know that many Enterprise class DHCP are also. Even the IOS DHCP server in Cisco routers is compliant.

One thing I read about MT was that disabling Universal Client might help this, that Universal Client “breaks” DHCP a bit. It looks like in older versions you could disable it, but here I sit with 3.9 (recommended to upgrade right here in the forum) and I don’t see how to do that.

So I’d like to hear from MT on how to solve this, or any suggestion about integrating a properly working DHCP server into the hotspot (not possible, I’m afraid).

9

from RFC 2131
giaddr Relay agent IP address, used in booting via a
relay agent.


so this is has to be relay address

10

Thanks for that answer, but I'm not sure what you are telling me here.
Let me give you some information from Tropos that may help you understand what I am asking for.
With this information maybe you can better see what is happening.
A Tropos mesh radio is actually a router as well, so the DHCP requests are coming to you from a downstream router.

\

Why do some DHCP servers not work with Tropos routers?

Tropos Metro Mesh routers are Layer 3 devices and as such, we do not forward broadcast packets. This includes DHCP broadcasts.

Whenever a client associates to a Tropos router, the client will send out a DHCP broadcast Discovery packet. The Tropos Router will then forward this Discovery packet as a DHCP Relay Unicast request to its upstream Tropos Gateway, the Gateway will forward the unicast request to the DHCP server. The problem arises if 1) the DHCP server responds to this DHCP Discovery with a broadcast offer, or 2) the DHCP server responds to the Tropos gateway that forwarded the request rather than the giaddr (the IP of the node where the client is associated)

What is a relay agent?

A relay agent acts on behalf of a client and ensures that clients can be served with IP addresses in a routed environment.

The way this process happens is by using a field called giaddr (Relay Agent Addr) in all DHCP packets relayed to the DHCP server. An RFC 2131 (and RFC1532) compliant server SHOULD always unicast the DHCP Reply messages (OFFER & ACK) back to the giaddr if present. Please refer to the above two RFCs for precise details.

Some servers send a unicast reply back to the Gateway (Note: not to the giaddr). We don't like those packets too as the giaddr in the corresponding request packet is typically the wlan0 address of the node that has the client association. Although the relay agent at the gateway sees such packets it does not forward the packet to the node.

Here's an excerpt from RFC 1532 which describes how the DHCP server should respond.

"The server SHOULD next check the 'giaddr' field. If this field is non-zero, the server SHOULD send the BOOTREPLY as an IP unicast to the IP address identified in the 'giaddr' field."

The DHCP RFCs specify that the DHCP server SHOULD respond in a specific way. However, the RFCs do not say MUST, so technically, the DHCP servers are not breaking the RFC. But, we only support DHCP servers that respond with Unicast packets to the IP in the giaddr field

11

What they are saying is that Tropos router acts as a dhcp relay, so you have to set relay address on mikrotik router.
If you set 255.255.255.255 as a relay address on Mikrotik router then DHCP server will process incomming request from any DHCP relay. I think it should solve your problem.

Another DHCP question
12

Aha! We can try that.
We did notice one thing.
When looking at the MT log and seeing the giaddr errors, we noticed the different IP addresses of the Tropos units.
If we picked one of the addresses showing errors, and set its address in the RELAY, then the Tropos with that address did allow the client behind it to obtain an address.
But of course errors began coming in from the others.
SO if your suggestion works, it could be like changing it for each one when needed, I guess.

Thanks and will give that a try.

13

Thanks to mrz, that last suggestion seems to have fixed it!

For Tropos mesh radios (Tropos calls them routers) behind MT hotspot, just set the “relay” in the DHCP server of the MT to 255.255.255.255.
The Tropos routers and customers behind them are now able to get IP addresses properly and use the network.
(I did get a couple of responses from the support folks at MT as well, in which they finally suggested the same thing.)

Now on to my next problem: ssl enablement and authorize.net, which will be in another thread.

Ralph