I have been finding Neighbour discovery on Winbox very unreliable with CHR VMs.
I started looking with Wireshark at the MNDP protocol packets and made the following observation.
On a Real Routerboard, the first 4 bytes of the UDP payload are (per packet) like this:
00 00 2d 02
00 00 2d 03
00 00 2d 04
00 00 2d 05
etc.
On a CHR, the equivalent bytes are:
8d 05 00 00
8e 05 00 00
8f 05 00 00
90 05 00 00
Winbox does eventually discover the CHR, but it takes a random (long) amount of time to do so.
This looks like a classic big-endian/little-endian problem with CHR in what it puts into the MNDP header - the rest of the data in the packet is OK.
If I log into the routers themselves, then CHRs never show up on a real router’s neighbour list, and other CHRs never show up a a CHR’s neighbour list.
I suspect this is also the same problem.
Almost needless to say, support have not done anything about this.
You might have thought they could have tried this on any CHR and hardware unit out of the box.
But no, they demanded Supouts for this trivial, perfectly repeatable case. Sometimes you just wanna cry. I gave up. Why should I waste my time?
I suggest you all write to Mikrotik support, seeing as they clearly don’t believe me - based on the fact that they have done NOTHING about this bug in the last 9 months.
Posting here is essentially pointless.
MikroTik support have so far been very responsive however the implication is currently that the issue is with my computers L2 connectivity.
My desktop and 2 laptops can’t discover it (cabled and 2 wireless) however the 'Tik App on my phone on the same wireless AP as the laptops CAN discover the CHR.
This leads me (personally) to think the problem MUST simply be with how Winbox is written? Why would the 'Tik App get the CHR and not Winbox from the same AP? It can’t be L2.
