Problem with link (WDS slave & Bridge)

Hey

If its possible, please help me with this problem.

The setup as follows (someone else set it up previously)

2 x Mikrotik Router with RB133

One is setup as bridge, and the other as WDS-slave.
So, we did get a connection between the two on a 5Ghz frequency (5180mhz), and it was created as a LAN network, with internet access through ADSL line.

All settings are setup the same for both routers (except WDS-slave mode for the one with ADSL line near it, and the other one as bridge [NOT AP bridge]).

Suddenly, from Sunday the link STOPPED working. WE have climbed up, and aligned again to LOS for each other (maybe it moved, which is not really possible).

WHy would they not see each other anymore when scanning in the Wireless Scan option?

NOTE: The one router CAN see other APs on the 5ghz frequency, as well as on the 2Ghz frequency (Setup as WDS slave). The OTHER (that is setup as the Bridge) one is unconfirmed if it can still receive / transmit in the 5ghz frequency, but dropping down to 2ghz, it ALSO sees lots of others APs.
NOTE: the routers are about 1.75km from each other.

So, is it possible that the one router (bridge mode) the 5ghz frequency part is damaged>?
How can it be tested>?
Also, what is the difference between 5ghz and 2ghz frequency ranges? IE. can we drop to the 2ghz range?

PLEASE excuse me, I am NOT clued up with this, but wish to sort out the link again,… WHICH did work , until unexpectedly stopped on Sunday.

Thanks

Could be damage I suppose. You do what you’ve been doing to figure it out. If one radio can scan and get results, then it can receive. Go to the other side and see if it can receive as well. Likely one of them seems to not be transmitting anymore, or to be receiving so little signal as to be useless.

You can drop to the 2ghz range depending on the laws in your area and all the various hardware factors that would enable 2ghz usage.

This is about the best I can say. Good luck. Wish I could be more help. But you just need to go through the normal troubleshooting process.