Is it possible to auto block MAC in mikrotik for IP conflict? And what does video surveillance have to do with it?

Question

Mikrotik

Can Mikrotik block devices by MAC addresses if 4 devices were on the network with the same IP at once?
At one object, friends asked to register IP cameras on the video recorder, while they said that all the cameras were already connected to the network, but they were not assigned IP. The matter did not seem to be dusty, to find the cameras. Set IP addresses to them and register an registrar. My friends managed to detect and register only one camera out of 5 on their own. Thus, all the other 4 cameras were on the network with one standard factory IP. It seemed that everything should have been simple, but as it turned out, none of the 4 cameras is detected on the network by the factory software from the cameras and in other ways. There was an idea that I was in conflict with IP and it was necessary to connect cameras to the switch one at a time - but this did not help. Cameras on the network are not discovered in this way either. As a result, through the POE, the injector tried to connect the cameras past the switch directly to the laptop - in turn, and all 4 cameras in turn were successfully determined by the factory IP. As a result, in this way I registered a free static IP of the internal target network in all 4 cameras and returned the whole thing back to the switch. But even after that, the cameras in the target network are not detected in any way. Could Mikrotik block the MAC addresses of these cameras, for example, for an IP address conflict initially? And where in the Mikrotik interface can I check this? Could Mikrotik block the MAC addresses of these cameras, for example, for an IP address conflict initially? And where in the Mikrotik interface can I check this? Could Mikrotik block the MAC addresses of these cameras, for example, for an IP address conflict initially? And where in the Mikrotik interface can I check this?
The network itself looks like this. There are two buildings.
In the control room of the 1st building, there is a Mikrotik and an unmanaged POE switch to expand the number of Mikrotik ports and power the cameras via POE. The registrar and cameras of the first building are stuck there. Also from this switch there is a cable to the second building with a total length of more than 100 meters, but in the middle of the entire route there is a device that acts as a repeater. In the second building, there is also an unmanaged POE switch, into which these 5 cameras are plugged, 4 of which are not detected on the network.
And there is one more thing, all the ends of the twisted-pair cable by some smart guy, who actually apparently mounted all this with his friends, are not crimped according to the standard. Instead of crimping according to B scheme. All ends from the cable going from the first building to the second are crimped in the following order:
1. white-orange,
2. orange,
3. white-blue,
4. blue
5. white-green
6. green
7. white-brown
8.
brown crookedly crimped in the same way. Therefore, there are no crosshairs. But contacts 3 and 6 do not go through paired wires. Could this be the reason for everything? We have not yet tried to re-compress as it should be, tk. these 4 cameras are not at an easily accessible height above the ground from the street.
The network indicators in the switch light up / blink when these cameras are turned on.

Answer 1

> Maybe this is the reason for everything?
it could easily be. the standard did not appear out of the blue, you can easily not have a connection. recompress.

Answer 2

I did an experiment on your case.
Fluke DTX-1200 cable tester with DTX-CHA002 adapters was used.
A wire of about 25 meters was taken.
Here is the result with normal crimping:
And this is the result when crimping is approximately the same as yours (I read it inattentively and the order turned out to be slightly different, but also direct):
A pair of 3-6 does not meet the standard at all (the red line on the charts is the limit of compliance with the standard).

Answer 3

And what prevented to compress at once as it is necessary? and assign IP via DHCP, and what does Mikrotik have to do with it?

Answer 4

The problem, in my opinion, is not in a different park - this will only affect the maximum length of the wire, but in the fact that for the receiver-transmitter pair to work, the third contact of the Eth connector must come to the sixth and vice versa. In your configuration, it is possible to work only at a speed of 10 Mbps half duplex (one transmitter-receiver pair works). Not all switches are capable of this mode. In this regard, you can either make an adapter from the side of the switch so that the second pair of receiver-transmitter works, albeit in a different park (remember the length), or (which is correct) correct the network wiring.

Answer 5

Theoretically, it should be do not care about crimping. But practically smart switches and Mikrotik should try to detect MDI / MDIX - and they may well blunt it. Well, either a banal underpressure, or, for example, there is a multi-core and an inappropriate connector, or a stupid wire inside the cable has broken off ... Firstly, you
need to clamp it to a standard circuit, and secondly, test all the wires.