For me solution was easy and I’ve made this complicate because I’ve followed all instructions in thread, reset RMPro remote control (now need to spend at least 2 hour to configure all devices again), changed all DHCP settings, etc etc etc …
Well, final solution for me was :
get back from 6.44.3 to 6.42.6 and everything is working fine.
btw.
Spent additinal 30 minutes by trying to reset password on THIS site, I know old email but don’t remember username :
when I am trying to reset password this is asking for username which I don’t remember
when I am trying to register new account this say email is already used (yes, I know, but HOW to use this email …)
and yeah, I am upset with my “let’s upgrade this” right now
I found the issue that may be due to compatibility between the latest ROS DHCP driver and ethernet hardware/driver. In my setup of x86 hardware, I used to use routerOS KVM to create a virtural network interface for my linux client. The default network interface is based on redhat virtio.
Under the latest firmware, it can get network ip when boot up but somehow it loses its ip upon renewal. That means the client is not connecting to network or internet.
When I look back the KVM wiki, it found that the virtual network interface can be created to emulate e1000. When I re create a separate virtual network interface with hardware emulation to intel e1000, IP address renewed was successful. I did not make any setting changed under routeros DHCP server nor downgrade the firmware to a lower version as described above by other users.
But I have to monitor the situation for a longer period of time.
Same problem with Android TV and v 6.47, moreover, when TV is conneted, it jams other hosts somehow (no network access). “DHCP offered without success”
Nothing to to with bootp or authoritative options, that’s a bs**t.
Hello guys, after a lot of research on this problem that is taking the peace of thousands of people here on the forum regarding the DHCP Bug mikrotik (offering lease without success), I decided to speak up and carry out this outburst. From what I understand this bug affects all versions above 6.38.7 and it seems that there is nothing, nothing that can be done to solve this problem; with regard to the mikrotik people, it is absurd that no engineer or programmer is going to speak publicly about it.
Well, let’s go to the resolution of the facts, let’s go to the origin of this problem, which seems to be the masking of MAC ADDRESS.
Here I use a DD-WRT router in AP BRIDGE mode (ROUTED), in this mode this equipment is absolutely unable to pass the true mac address of the clients that are dependent on it, this generates a MAC duplication for the DHCP service to which it understands how to were it an attempt to duplicate or clone or attempt to breach because of this mikrotik displays the following error message:
defconf offering lease 192.168.10.xxx for 00: 30: 18: xx: xx: xx to 10: FE: ED: xx: xx: xx without success
So far so good, but this is a problem for those who use the MAC masking system, and in my view it seems that there is no minimum interest from mikrotik in solving this problem, or that at least it could create a LEGACY DHCP option that could handle MAC masking. I sincerely hope that mikrotik can help us, because as well as the other colleagues we are already discouraged from these bugs and these errors.
Same here, many hours to finally find this out, this is nuts. I can see in logs the request. Is MikroTik at least looking at this?
What gets me is I have a wAP ac connected to a Cisco switch and a Hex router connected to same switch for internet. The wAP ac unit has the default vlan (1) and a second vlan (20). On my Cellphone via wi-fi I can get an IP address from dhcp server on Hex when I connect to ssid that is mapped to vlan1 but when I associate with other ssid mapped on vlan 20, I never get the address. All is configured correctly and I can see the request in the logs of the Hex.
Has anyone gotten a wAP ac to work with multiple ssid’s mapped to multiple vlans?
No sympathy for anyone that uses vlan1 and further no sympathy for anyone using vlans and has the bridge providing DHCP services. Associate the DHCP services to the vlans and leave the poor bridge alone (so it can focus on bridge ports and bridge vlan filtering)
Recently encountered 2 cases of this problem in my network. Both of them were unrelated to RouterOS.
In one case, it was unconfigured tagged port for VLAN on an intermediate switch.
In another one it was broken LAN card driver on end PC due to damaged HDD.
Please check your end devices before suspecting bugs in RouterOS
