if this is true (i am not using beta), then MT played this in silence, leaving users in doubt with broken network to chase ghosts with unwanted RA
ipv6,ra - correctly process RAs advertising previously expired prefix;
ipv6,ra - fixed prefix invalidation;
beta changelog does not mention anything about default ND/RA
I think it's a regression caused by a fix in 7.23... But yes MikroTik should publish an update asap.
Good evening all. I have noticed an issue with LTE passthrough not working correctly in 7.23.1. I have had to install stable 7.21.4 to get it back working.
To expand - this is quite a vague comment as I don’t actually know the root of the issue. I have an SXT-R11e-LTE which passes through an LTE connection as a failover to my RB5009. Since the update, the failover connection doesn’t work. I can’t seem to understand why as everything looks identical, routes look fine, DHCP client is getting an address, etc.
Hi,
Recently I have upgraded my router and switch (RB1100AHx4 and CRS354-48G-4S+-2Q+).
On switch I have enabled dhcp snooping with default configuration. After uprade on router in /ip dhcp server print entries i see "garbage" (numbers). Before upgrade i saw there interface on the switch from the dhcp request was p
Those are in hexadecimal format. It's a documented change in 7.23:
It's still functionally garbage.
Does your response address the DHCP Option 82 format change? If yes, then your statement is wrong, and the change is a welcomed one. The values of Circuit ID and Remote ID as specified by RFC 3046 are opaque string of bytes, there is no requirement for them to be only ASCII text. In fact, many (non MikroTik) devices encode the port / slot etc... information as raw binary number in Circuit ID for example, and the fact that RouterOS previously presented them as text make matching / viewing difficult. If you use Wireshark, you'll also see that it presents the Agent Circuit ID and Agent Remote ID as hexadecimal in the tree.
Don't believe both claims? See this screenshot in this article:
Notice the 0x01, 0x06 bytes in the values? Now let's see how previous RouterOS versions display them.
For previous versions it was presented as text and it was very usefull to debug/check where this device is physically connected.
Still i would see that there is an option to switch this back to interpret this as a text.
If you just need to quickly identify the port number (for example etherXX) without having to use one of the hundreds available hex decoder tools, you can look for occurrences of the 30, 31, ... 39 hex pairs. They correspond to the 0, 1, ... 9 ASCII characters. And 20 is whitespace.
Huh... try to find this where you have 4 switches and on everyone there is a different setup (8/12/24/48 ports), also if there are ether, sfp/sfp-plus/sfp28, qsfpplus, bonding. That is a little frustrating.
Maybe a reasonable function would be for Winbox to show a text representation for the hex bytes, either alongside or as a "hover" box when hovering over the hex string?
It looks as a begining of a kind of "flame war" if MT should obey/implement/use RFC standards or not?
Ones want following RFCs, ones want "convinient aproach" and "the rest" do not care.
No way to satisfy ALL.
This is not an XOR thing. Why not just:
Costs nothing. Does not require users to "think in HEX" or "convert HEX to ASCII in brain".
In my opinion, RFCs must be respected exactly as presented, and if one or two older gentlemen don't want to work with standards, they should stick to older versions and let those of us who applaud when a company adheres to the RFCs to the letter move forward.
If every time MikroTik or another manufacturer makes a modification while respecting the standards, a few people come along and make a fuss without even understanding, we're in serious trouble.
MikroTik shouldn't have to pay any attention to those comments.
Costs implementing it. And other "hover" in another place, and another, and another ... there are tools for such things and the list of reported "disabilities in ergonomics" for WinBox is long enough to not open the new "bells&whistles" winbox.
Winbox should settle as "managing tool", not the "Latvian router knife".
I think that option in CLI "convert to text" will solve the issue. Anyway it was suprising to me that since dhcp snooping was introduced such BIG change was implemented in minor release update. First when I have saw this "hex garbage" I thought that my router/switch is broken.
And maybe DHCP options editor that could convert those to hex (and back to text for display)...
And as a management GUI fur humans it should make things user readable.
I have two main use-cases for Circuit-ID:
The first is as a standalone tool for small-medium business setups:
Think a CCR2004 managing 4-6 CRS3xx switches, for a total of 100~200 ports
To be able to quickly, at a glance, tell "where is this device customer is complaining about"
In this scenario, the other way is to go dig into every switchs' "/bridge/hosts" table for the one mac:port tuple
The second scenario, is IPoE / Broadband Access:
Be it Mikrotik's "GPEN" concept, or some {}PON deployment, the OLT injects Option82 in the DHCP Headers, that make their way to the BRAS / L3 "Concentrator".
This scenario universally works with ASCII-encoded strings: The OLT/Switch salts the DHCP packet with the AccessNodeID + LogicalPort + CPE-DSN.
This is decoded by the L3 "Concentrator", sent to RADIUS for authorization and accounting, and matched against the CircuitID authorized by the ERP.
Obviously, this has to be debuggable... Good luck convincing your "common joe" sellers that "read in HEX like in the Matrix" is a reasonable (let alone attainable) training requirement for the job.
Dealing with RAW hex in intermediary devices basically negates the possibility of using Mikrotik in this scenarios:
in the small Business case, something that should be "instantly glanceable" , becomes :
-- "now i have to copy paste each and every one of this 100 entries into this translator tool, to make it readable. Hope i don't skip a line
In the ISP/Access scenario:
Technician installs CPE device in OLT-X, PORT-Y, SERIAL-Z
(alternativelly Mikrotik has the GPEN line, so: SWITCH-X, PORT-Y, MAC-Z)
Another technician registers this in the RADIUS database: Client 123456789 exists at Circuit-ID: {OLT::PORT::SERIAL}
If the switches work in HEX instead of ASCII, then whomever is going to enter this data into radius has to hex-encode the ASCII/Human {NAME::PORT::SERIAL}
If the BRAS/CCR's work in HEX, then this kills any hopes one might have of being able to debug something ( good luck finding your lease/CircuitID in the 2000+ lease-table + unreadable HEX)
if BOTH Access-Switches + DHCP-Server/BRAS hex-encode everything, then maybe in the future of agentic-workers the AI's can manage that...
