Community discussions

MikroTik App
 
RackKing
Member
Member
Posts: 380
Joined: Wed Oct 09, 2013 1:59 pm

Re: Feature request for v7.x

Tue Dec 04, 2018 2:23 pm

mDNS server for Chromecast/Bonjour/ZeroConfig across VLANs.

WiFi networks are too big to have all the available devices all bridged to the LAN.

Would be nice to then firewall what devices are discoverable.
m2
 
lygstate
just joined
Posts: 5
Joined: Wed May 01, 2019 4:02 pm

Re: Feature request for v7.x

Wed May 01, 2019 9:13 pm

I hope full SwOS function are merged into RouterOS
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11629
Joined: Thu Mar 03, 2016 10:23 pm

Re: Feature request for v7.x

Thu May 02, 2019 10:42 am

I hope full SwOS function are merged into RouterOS
Which functionality can you enable/configure in SwOS that can not be done in ROS?
 
mada3k
Long time Member
Long time Member
Posts: 698
Joined: Mon Jul 13, 2015 10:53 am
Location: Sweden

Re: Feature request for v7.x

Mon May 06, 2019 8:15 pm

mDNS proxy is very useful, both home and medium-enterprise.
 
arily
just joined
Posts: 1
Joined: Sat Jun 16, 2018 3:12 pm

Re: Feature request for v7.x

Fri May 17, 2019 1:47 pm

IPv6 policy routing
IPv6 multiple routing table
IPv6 accounting
Address list subscription
 
eliemacho
just joined
Posts: 22
Joined: Thu May 02, 2019 12:20 pm

Re: Feature request for v7.x

Wed Jun 12, 2019 2:28 am

cant really understand why does PCC require us to mark the connection of the incoming WAN interfaces with the same mark of the incoming LOCAL interface
knowing that the routing mark will take the decision at the where to route the packets to the outside world
like using the "WAN1" & "WAN2" for example as connection mark names for the incoming WANs and using the same connection mark names for the incoming LOCAL and then mark the route for each WAN interface
whats the reason behind having the same cnx mark name of the in WAN and in LOCAL

any clarification whats the relation between them and how does this feature work, CZ as for me i could mark the in LOCAL with a routing mark (using of course the pcc feature 2/0';2/1 for ex) and route every connection being made from the LOCAL to the outside with the specific gateway associated with that routing mark WITHOUT going into routing the output traffic of the router interfaces with a cnx mark of there each WAN etc...
 
Sob
Forum Guru
Forum Guru
Posts: 9121
Joined: Mon Apr 20, 2009 9:11 pm

Re: Feature request for v7.x

Fri Jun 14, 2019 2:55 am

1) You posted in wrong thread

2) I'm not sure if I'm getting the part about same names, but no such requirement exists. In some cases, it should be possible to skip connection marking completely, but it would only work if you'd have outgoing connections only, no incoming. And even then marking connections first should be more efficient, because connection tracking happens anyway and just checking mark should take less work than doing PCC computing for each packet.
 
rene72
just joined
Posts: 15
Joined: Fri Jun 14, 2019 11:35 am

Re: Feature request for v7.x

Tue Jun 18, 2019 8:29 pm

A solution like ha proxy in router os v7 would be usefull I like to run multiple ssl sites behind my mikrotik router on 1 public ip and lets encrypt support to automaticly secure them with ssl
 
rupeshkafle
just joined
Posts: 3
Joined: Sun Feb 11, 2018 10:44 pm

Re: Feature request for v7.x

Wed Jul 24, 2019 1:24 pm

Is there any timeline for IPv6 route marking? or Is it still impossible to implement on routeros6 due to kernel limitations?
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11629
Joined: Thu Mar 03, 2016 10:23 pm

Re: Feature request for v7.x

Wed Jul 24, 2019 2:07 pm

A solution like ha proxy in router os v7 would be usefull I like to run multiple ssl sites behind my mikrotik router on 1 public ip and lets encrypt support to automaticly secure them with ssl
The only sensible part of this wish is "letsencrypt support for SSL certificates" ...

If you're running multiple (SSL) sites behind your mikrotik, you can easily use one of those servers to run reverse proxy (haproxy functionality you requested above is essentially this) on it ... PC hardware is much better suited to run such service than average xMIPS/ARM deployed in RBs. Not to mention additional RAM needed by this functionality (it needs to keep list of active connections if load-ballancing functionality of haproxy is used). Plus all encryption/decryption (not sure if that can/will be offloaded to HW on units that have such hardware).
 
pe1chl
Forum Guru
Forum Guru
Posts: 10240
Joined: Mon Jun 08, 2015 12:09 pm

Re: Feature request for v7.x

Wed Jul 24, 2019 2:33 pm

PC hardware is much better suited to run such service than average xMIPS/ARM deployed in RBs. Not to mention additional RAM needed by this functionality (it needs to keep list of active connections if load-ballancing functionality of haproxy is used). Plus all encryption/decryption (not sure if that can/will be offloaded to HW on units that have such hardware).
While I did not make this request and do not need such functions, I would say that my CCR routers have so much CPU, crypto accel and RAM capacity that is sitting unused that it would certainly be worth it to load them with something like this, e.g. when the webserver itself gets a little overloaded by the crypto.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11629
Joined: Thu Mar 03, 2016 10:23 pm

Re: Feature request for v7.x

Wed Jul 24, 2019 4:46 pm

I'd say that such an expensive hardware (as CCRs are) sitting idle at some cheap enterprise, is a rare species which doesn't warrant developing new functionality. I mean ... having idle CCR costing anywhere between 425€ and 3000€, but saving some 1000€ by not buying a modest x86_64 server which would handle things much better ...

I think devs' time would be better used when implementing full feature set for IPv6 ... for example.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10240
Joined: Mon Jun 08, 2015 12:09 pm

Re: Feature request for v7.x

Wed Jul 24, 2019 5:33 pm

I'd say that such an expensive hardware (as CCRs are)
Apparently we have different definition of expensive... I think our CCR1009's are quite cheap.
I think devs' time would be better used when implementing full feature set for IPv6 ... for example.
I agree with that! But talking to MikroTIk staff it became clear to me that nothing is to be expected in that department.
Apparently most of their customers are not interested in IPv6.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11629
Joined: Thu Mar 03, 2016 10:23 pm

Re: Feature request for v7.x

Wed Jul 24, 2019 10:06 pm

I'd say that such an expensive hardware (as CCRs are)
Apparently we have different definition of expensive... I think our CCR1009's are quite cheap.
Perhaps not ... but we might have different perspectives. Me, for example, I associate CCRs with decent LAN size which deserves some dedicated boxes to do some things ... such as dedicated server for http/https and in this case CCR should do routing and firewalling. On the other hand I expect to see budget hardware (hEX/hAP) to do stuff where it is sensible to join different tasks on small number of devices.

OTOH I'm quite used to use ICT gear vith price tags ranging from 0 to a few million €uros. (I'm not saying that's their value :wink:)
 
pe1chl
Forum Guru
Forum Guru
Posts: 10240
Joined: Mon Jun 08, 2015 12:09 pm

Re: Feature request for v7.x

Thu Jul 25, 2019 12:04 am

I was thinking more in terms of an inexpensive SSL accellerator/loadbalancer that could also perform some other functions like routing and firewalling.
Not that I need one, but maybe some people do.
 
User avatar
ingdaka
Trainer
Trainer
Posts: 452
Joined: Thu Aug 30, 2012 3:06 pm
Location: Albania
Contact:

Re: Feature request for v7.x

Thu Jul 25, 2019 12:45 am

+1 for BGP4-MIB (RFC 4273)
 
Gesuino
just joined
Posts: 14
Joined: Mon Jan 21, 2019 5:28 pm

Re: Feature request for v7.x

Fri Jul 26, 2019 9:11 pm

Hi please improve dude settings from cli, i love routeros scripting language. I need some instrument for auto adding devices to graphical map, in routeros style like: /dude network-maps rescan "home" that can be triggered by scripts;
/dude device add name=" " ip-address=" " type=" .... to-map="home" <-And device added can be showed in dude graphical client relative map.

Thanks :)
 
aneroid
just joined
Posts: 9
Joined: Fri Dec 30, 2016 1:07 pm

Re: Feature request for v7.x

Tue Sep 10, 2019 3:40 pm

mDNS server for Chromecast/Bonjour/ZeroConfig across VLANs.

WiFi networks are too big to have all the available devices all bridged to the LAN.

Would be nice to then firewall what devices are discoverable.
m2
also here ... for securing IoT over VLANs, etc.
 
User avatar
kiler129
Member
Member
Posts: 354
Joined: Tue Mar 31, 2015 4:32 pm
Location: IL, USA
Contact:

Re: Feature request for v7.x

Mon Sep 23, 2019 3:22 am

I hit the mDNS problem again in an enterprise setting. You know how funny it is to explain that we need a small VM just to run Avahi reflector? It got even more awkward when someone in the meeting mentioned that both Cisco and Ubiquity can do that.

Really, the mDNS/Zeroconf/Bonjour is really needed. While originally it was just merely a helpful gadget in the Apple ecosystem it's no longer the case. Back in the days there was always a manual option to connect to a device - nowadays it's simply not possible in many scenarios. Chromecasts and AppleTVs are used across the industry in conference rooms and currently it's not possible to put them into isolation since mDNS will not cross the subnets.
 
User avatar
nithinkumar2000
Member Candidate
Member Candidate
Posts: 160
Joined: Wed Sep 11, 2019 7:42 am
Location: Coimbatore
Contact:

Re: Feature request for v7.x

Mon Sep 23, 2019 7:58 am

It would be really great if Mikrotik v7.x can include walled-garden like feature for PPPOE also just Like Cisco's.
Because PPPOE with radius create lots of hits when user is suspended of Terminated....

Thanks :)
 
User avatar
nithinkumar2000
Member Candidate
Member Candidate
Posts: 160
Joined: Wed Sep 11, 2019 7:42 am
Location: Coimbatore
Contact:

Re: Feature request for v7.x

Mon Oct 28, 2019 7:16 pm

Dear Mikrotik Team,

Please Include the following features in Mikrotik ROS v7.x

1. DHCPv6 Server
2. Accounting for IPv6 and Radius Parameters (Most Important Requirement for ISP's)
3. Walled Garden Service for PPPOE to prevent unnecessary hits from users. (Just like feature in Cisco Routers).
4. IPv6 Hotspot Service (Optional).
5. IPv6 NAT Service

Looking forward to your valuable response.

Regards
Nithin Kumar
 
deanMKD1
Member
Member
Posts: 366
Joined: Fri Dec 12, 2014 12:06 am
Location: Macedonia
Contact:

Re: Feature request for v7.x

Mon Oct 28, 2019 8:18 pm

Monthly traffic per interface. Dont tell me about graphing. Its not fine for me.
 
User avatar
nithinkumar2000
Member Candidate
Member Candidate
Posts: 160
Joined: Wed Sep 11, 2019 7:42 am
Location: Coimbatore
Contact:

Re: Feature request for v7.x

Mon Nov 18, 2019 11:42 am

Please Include Traget= interface-list in Simple Queues.

Thanks in Advance
 
User avatar
BartoszP
Forum Guru
Forum Guru
Posts: 2880
Joined: Mon Jun 16, 2014 1:13 pm
Location: Poland

Re: Feature request for v7.x

Mon Nov 18, 2019 1:24 pm

MAC list ...
 
User avatar
nithinkumar2000
Member Candidate
Member Candidate
Posts: 160
Joined: Wed Sep 11, 2019 7:42 am
Location: Coimbatore
Contact:

Re: Feature request for v7.x

Sun Jul 05, 2020 9:07 pm

Please add the IPv6 Radius accounting. All ISP are looking for the same from very long time.

ISP's are unable to deploy the IPv6 due to No Radius Accounting for IPv6 and it is really SAD:( that Mikrotik team is not taking any actions towards this issue.

Mikrotik is being used by Many ISP's across the world and yes we love ROS and Features but it feels bad that other brands like CISCO, Huwai, Juniper are IPv6 Ready but Majorities who are using Mikrotik are still not ready to deploy IPv6 because it still lags features.

Expecting the Feature at the earliest.
 
anuser
Long time Member
Long time Member
Posts: 601
Joined: Sat Nov 29, 2014 7:27 pm

Re: Feature request for v7.x

Mon Jul 06, 2020 5:11 pm

Feature request for wireless: "airtime fairness": fair-accese / To allocate Airtime evenly across all the clients.
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 3300
Joined: Sat Dec 24, 2016 11:17 am
Location: Magrathean

Re: Feature request for v7.x

Tue Jul 07, 2020 12:50 pm

Monthly traffic per interface. Dont tell me about graphing. Its not fine for me.
Log interface traffic counter to a syslog server. There you can see it number or you can graph it if you like.
See link in my signature on how to set up Splunk (syslog server) to log MikroTik Routers.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10240
Joined: Mon Jun 08, 2015 12:09 pm

Re: Feature request for v7.x

Tue Jul 07, 2020 12:57 pm

Monthly traffic per interface. Dont tell me about graphing. Its not fine for me.
Log interface traffic counter to a syslog server. There you can see it number or you can graph it if you like.
See link in my signature on how to set up Splunk (syslog server) to log MikroTik Routers.
It may be that he has one of those ISPs that have "limited bundle of traffic". Some other routers offer an option
to set a "day of the month when bundle starts" and it will count traffic and reset it on that date. It may also offer
an alert when the accumulated traffic exceeds some set limit.
It is a feature in the "detect internet" and "kid control" class: people want this because others offer it, and it
is convenient in their home setting. They do not want to setup a syslog analyzer for that.
 
buraglio
Frequent Visitor
Frequent Visitor
Posts: 70
Joined: Mon Aug 10, 2015 5:59 pm
Location: +1 (217)
Contact:

Re: Feature request for v7.x

Wed Jul 08, 2020 2:55 am

I'd say that such an expensive hardware (as CCRs are)
Apparently we have different definition of expensive... I think our CCR1009's are quite cheap.
I think devs' time would be better used when implementing full feature set for IPv6 ... for example.
I agree with that! But talking to MikroTIk staff it became clear to me that nothing is to be expected in that department.
Apparently most of their customers are not interested in IPv6.
This is the conundrum of IPv6 - the "no one is asking for it" line is the weakest excuse for not deploying IPv6. 99.999% of customers won't ask for it, nor should they. If it is done correctly they'll never even notice they are using it. Operators don't deploy it because vendor implementations are incomplete. IPv6 deployment is quite profound in mobile and smartgrid networks, and (at least in the US), nearly all major providers offer it (Comcast, ATT, Spectrum, etc.) and the content has been there for years. If Mikrotik would implement feature parity with IPv4 then the bar is further lowered.
If we put even 1/8 of the effort into doing v6 as we did painting over the rusty carcas of ipv4 we would have been done a decade ago. Come on, Mikrotik, this is fundamental stuff.


nb
 
User avatar
nithinkumar2000
Member Candidate
Member Candidate
Posts: 160
Joined: Wed Sep 11, 2019 7:42 am
Location: Coimbatore
Contact:

Re: Feature request for v7.x

Wed Jul 08, 2020 7:01 am

I'd say that such an expensive hardware (as CCRs are)
Apparently we have different definition of expensive... I think our CCR1009's are quite cheap.
I think devs' time would be better used when implementing full feature set for IPv6 ... for example.
I agree with that! But talking to MikroTIk staff it became clear to me that nothing is to be expected in that department.
Apparently most of their customers are not interested in IPv6.
This is the conundrum of IPv6 - the "no one is asking for it" line is the weakest excuse for not deploying IPv6. 99.999% of customers won't ask for it, nor should they. If it is done correctly they'll never even notice they are using it. Operators don't deploy it because vendor implementations are incomplete. IPv6 deployment is quite profound in mobile and smartgrid networks, and (at least in the US), nearly all major providers offer it (Comcast, ATT, Spectrum, etc.) and the content has been there for years. If Mikrotik would implement feature parity with IPv4 then the bar is further lowered.
If we put even 1/8 of the effort into doing v6 as we did painting over the rusty carcas of ipv4 we would have been done a decade ago. Come on, Mikrotik, this is fundamental stuff.


nb
Yes i agree with you. There is no major concentration to IPv6 Modules from Mikrotik Team.

Come On Mikroitk Team Please add the support for Delegated IPv6 Prefix when using PPPOE Auth for RADIUS CLIENT

Atleast this much we can expect from Team Mikrotik right!
 
pe1chl
Forum Guru
Forum Guru
Posts: 10240
Joined: Mon Jun 08, 2015 12:09 pm

Re: Feature request for v7.x

Wed Jul 08, 2020 12:14 pm

This is the conundrum of IPv6 - the "no one is asking for it" line is the weakest excuse for not deploying IPv6. 99.999% of customers won't ask for it, nor should they. If it is done correctly they'll never even notice they are using it.
That is probably the biggest problem in IPv6 adaptation! When you do it correctly, nobody notices it. When you make a mistake, people complain that things that
were working before now are no longer working. So the pre-calculated impact on the network is: "it can only cause problems".

With that situation, it is not so surprising that so many ISPs postpone it over and over again, and most of them are not asking for IPv6 features at MikroTik.
And of course, the major sales of MikroTik routers is triggered by what ISPs do and buy, not the end-user who has bought a single router and tries to config it.
With RouterOS v6, IPv6 is not even enabled by default. So people who do not explicitly try to use it, will never notice it is there.

Fortunately that has changed in v7, but now we still see a large disparity of functionality between IPv4 and IPv6 in RouterOS. Hopefully sometime people will wake
up and align that.
 
sep
newbie
Posts: 25
Joined: Thu Nov 28, 2013 2:34 pm

Re: Feature request for v7.x

Tue Nov 10, 2020 11:31 am

pre covid. when going to a conference, I counted more then 15 people asking a unnamed firewall vendor about ipv6... and every one of them got the answer that "nobody is asking about ipv6"... ; "Nobody is asking about ipv6" is just a silly excuse, many vendors simply do not want to hear the question.

of course, when the users are asking about ipv6, it is a bit late to start thinking about it from the vendor's side. most vendors are on the ipfv6 ball for years already. And mikrotik have rudimentary support. but they are so far behind the ball at this point that working with the quirks is not funny any more.

I have been a mikrotik and routeros user since the the first version 3.x And I really would want to continue using routeros in the future. But that means that mikrotik must have plans to be relevant in the future.

And the (my?) future consists mostly of ipv6-only networks. With some ipv4 bubbles connected with ipv6 tunnels or ipv4 as a service solutions.

We are migrating networks as quick as we can, and unfortunatly in each case that usually means replacing mikrotik. Running dual-stack is a last resort option, since it is more then 2x the work.

Mikrotik as an CPE desperately need RFC8585 support, it contains the common CPE solutions. most importantly NAT64, since that is so widespread already.
All of these have FOSS tools available, so they do not need to reinvent anything. But they do need to integrate them. with TR069 support, DNS64+NAT64 and CLATD mikrotik could be a CPE of choice for many isp's

Mikrotik as a DC/ISP use Need tools such as SIIT-DC and NAT64.
SIIT-DC allow you to provice services to ipv4 internet from an ipv6 only datasenter. DNS64+NAT64 allow ipv6 only hosts to reach ipv4 only services online.
integrating something like JOOL would solve this. ( https://www.jool.mx )

Those are my personal itches. but ipv6 feature parity should be mikrotik's endgoal.

NPTv6 is useful for a small niche as well. But if you have a network so important it need 2x isp's, you could probably send that email and ask one of the isp's for a PI space as well. with ipv6 PI space, announced by the isp's or announced via a privateAS bgp should be the default solution for a small multihomed network, since the address space is so abundant, getting PI space is an email or 2 away. and not the problem it was on ipv4.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10240
Joined: Mon Jun 08, 2015 12:09 pm

Re: Feature request for v7.x

Tue Nov 10, 2020 2:23 pm

But if you have a network so important it need 2x isp's, you could probably send that email and ask one of the isp's for a PI space as well. with ipv6 PI space, announced by the isp's or announced via a privateAS bgp should be the default solution for a small multihomed network, since the address space is so abundant, getting PI space is an email or 2 away. and not the problem it was on ipv4.
Do you have any experience with that in practice, or is it only a proposal?
Here we have two different ISPs connected, each with IPv4 and IPv6, we use load-balancing/failover techniques to distribute the traffic over the two lines for IPv4, but for IPv6 that
is not possible due to the lack of NAT/route marking.
Of course even when we had BGP announcement of a PI space, and had the providers advertise only default routes, we would still have no loadbalancing for outbound traffic,
but maybe some for inbound. It could be a solution.
But I think the ISPs would act quite surprised when I propose setting up such a thing. It would be nice when you have some RFC that describes the scenario and practices.
(this does not appear to be in the scope of RFC 8585)
 
magnavox
Member
Member
Posts: 357
Joined: Thu Jun 14, 2007 1:03 pm

Re: Feature request for v7.x

Tue Jun 15, 2021 6:47 pm

There is this small, not-well-known but very useful tool called "etckeeper" for Linux, which automatically commits all changes you do on your configuration to the version-control-system of your choice (git, svn...). An implementation of that for MikroTik would be interesting
I suggest you look at RANCID, it does what you've described. Works for me, as well as with much other network equipment.
Very interesting, can you share some details about Rancid and Mikrotik backup?
 
troffasky
Member
Member
Posts: 431
Joined: Wed Mar 26, 2014 4:37 pm

Re: Feature request for v7.x

Sat Jun 26, 2021 12:05 pm

RANCID is a heap of scripts, with different collector plugins for different target platforms. It logs in on a schedule, executes whatever the native equivalent of "/export compact", "show run", etc, is and stores the output in a version control backend. It can email you a diff of the config.

The "mtlogin" RANCID component takes ROS commands or scripts as an argument, so you can use this from your own scripts for making bulk changes, for example.
 
emunt6
Member Candidate
Member Candidate
Posts: 103
Joined: Fri Feb 02, 2018 7:00 pm

Re: Feature request for v7.x

Sun Jun 27, 2021 3:28 am

1., High Availability (HA) (example: two or more router devices)
Stacking / Clustering - features:
> control-plane states sync ( example: NAT );
> configuration sync ( filesystem );
> upgrade/downgrade firmware ( cluster all members );
> all devices like a "single logical device" ( example: cisco VSS; hpe IRF );
> load-balancing / load-sharing ( master-master; master-slave; other )
2., Linux Namespaces for VRF (virtual routing and forwarding)
3., VRF route leaking with MP-BGP
 
User avatar
nithinkumar2000
Member Candidate
Member Candidate
Posts: 160
Joined: Wed Sep 11, 2019 7:42 am
Location: Coimbatore
Contact:

Re: Feature request for v7.x BGP advertise-inactive

Sat Jul 03, 2021 8:51 am

BGP option like Juniper "advertise-inactive".
+1
 
User avatar
BartoszP
Forum Guru
Forum Guru
Posts: 2880
Joined: Mon Jun 16, 2014 1:13 pm
Location: Poland

Re: Feature request for v7.x

Sun Jul 18, 2021 4:00 pm

port list
mac-address list
 
altayr
just joined
Posts: 2
Joined: Tue Feb 15, 2022 9:11 pm

Re: Feature request for v7.x

Wed Feb 16, 2022 8:23 am

A solution like ha proxy in router os v7 would be usefull I like to run multiple ssl sites behind my mikrotik router on 1 public ip and lets encrypt support to automaticly secure them with ssl
+1

And I would mention that it would be enough to have port sense ability, like port forward port 80 to ip list, and use first available of them, and fail over to next available in case health check fails.
This time no need for full ha proxy implementation but only “smart” or “ha port forward” which requires only health check and dynamic port forward rule change.
 
digit
just joined
Posts: 22
Joined: Thu Apr 01, 2010 7:07 pm

Re: Feature request for v7.x

Fri Feb 18, 2022 4:20 pm

WIFI multiple PSK ACL with wildcard MAC.

Here Engenius description on that. Ruckus also have something similar and I think Meraki also do so...
https://www.engeniustech.com/mypsk-a-ne ... porations/

Here discussion about the issue on the forum
viewtopic.php?p=913911&hilit=dpsk#p913911

Basic idea is to have a single SSID and allow multiple PSK and assigned VLAN based on PSK used. That is use in hotel or nursing home application where device does not always play well with WPA2-Enterprise (RADIUS). Basic idea, each room have it's own PSK on a single SSID and VLAN are assign based on PSK used, so device on same "room" can communicate with each other. Alexa, ChromeCast, Tablet...

Right now wifi ACL allow for (almost) that, but MAC need to be know. Also a "wildcard" MAC is allowed, but only the first one is evaluated. Need to have multiple wildcard, if first failed, check the next...

This is working
/interface wireless access-list
add mac-address=01:01:01:01:01:01 private-pre-shared-key=testvlan1
add mac-address=02:02:02:02:02:02 private-pre-shared-key=testvlan105 vlan-id=105 vlan-mode=use-tag
This is also working
/interface wireless access-list
add mac-address=00:00:00:00:00:00 private-pre-shared-key=testvlan1
add mac-address=02:02:02:02:02:02 private-pre-shared-key=testvlan105 vlan-id=105 vlan-mode=use-tag
But this is not, and that is requiered
/interface wireless access-list
add mac-address=00:00:00:00:00:00 private-pre-shared-key=testvlan1
add mac-address=00:00:00:00:00:00 private-pre-shared-key=testvlan105 vlan-id=105 vlan-mode=use-tag
/code]
Last edited by digit on Fri Feb 18, 2022 6:07 pm, edited 3 times in total.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10240
Joined: Mon Jun 08, 2015 12:09 pm

Re: Feature request for v7.x

Fri Feb 18, 2022 4:40 pm

You are aware that this feature is patented by Ruckus?
 
digit
just joined
Posts: 22
Joined: Thu Apr 01, 2010 7:07 pm

Re: Feature request for v7.x

Fri Feb 18, 2022 5:10 pm

You are aware that this feature is patented by Ruckus?
Damn... patent... that's why you can't have a toilet that flush properly or a saw that can saw without being over complicated these days...

EDIT:

Found that RUCKUS patent, I don't think it apply
This describe a connection to an open network first, then a PSK is dynamically generated and use for later communication.

https://patents.google.com/patent/US9226146B2/en

Proposed solution is to have multiple STATIC psk on a non open SSID where all PSK are evaluated and if one match, grant access.

Explain why current implementation where first wildcard is allowed is correct and check multiple wildcard infringe Ruckus patent ? Also note that Engenius, Cambium, Aerohive and Meraki have similar solution.

https://www.engeniustech.com/mypsk-a-ne ... porations/
https://community.cambiumnetworks.com/t ... keys/62609
Last edited by digit on Fri Feb 18, 2022 8:54 pm, edited 2 times in total.
 
excession
Frequent Visitor
Frequent Visitor
Posts: 95
Joined: Mon May 11, 2015 8:16 pm

Re: Feature request for v7.x

Fri Feb 18, 2022 7:45 pm

Other vendors have this feature.
Doesn’t seem like a patent issue if you don’t try and call it DPSK.
 
tx6376
just joined
Posts: 10
Joined: Tue Feb 02, 2021 8:35 pm

Re: Feature request for v7.x

Sat Feb 19, 2022 2:40 pm

RTSP helper (alg)
Thanks.
 
digit
just joined
Posts: 22
Joined: Thu Apr 01, 2010 7:07 pm

Re: Feature request for v7.x

Thu Feb 24, 2022 12:09 am

route based ipsec vs policy based

ipsec with an interface, so we can do OSPF / BGP / Static routing on Interface without the need of L2 tunneling like GRE when connected to other brand router / Azure.

VTI or XFRM interfaces.
 
CTSsean
Frequent Visitor
Frequent Visitor
Posts: 61
Joined: Fri Sep 15, 2017 12:56 pm

Re: Feature request for v7.x

Tue Jul 04, 2023 5:22 pm

Plus 1 for this!
WIFI multiple PSK ACL with wildcard MAC.

Here Engenius description on that. Ruckus also have something similar and I think Meraki also do so...
https://www.engeniustech.com/mypsk-a-ne ... porations/

Here discussion about the issue on the forum
viewtopic.php?p=913911&hilit=dpsk#p913911

Basic idea is to have a single SSID and allow multiple PSK and assigned VLAN based on PSK used. That is use in hotel or nursing home application where device does not always play well with WPA2-Enterprise (RADIUS). Basic idea, each room have it's own PSK on a single SSID and VLAN are assign based on PSK used, so device on same "room" can communicate with each other. Alexa, ChromeCast, Tablet...

Right now wifi ACL allow for (almost) that, but MAC need to be know. Also a "wildcard" MAC is allowed, but only the first one is evaluated. Need to have multiple wildcard, if first failed, check the next...

This is working
/interface wireless access-list
add mac-address=01:01:01:01:01:01 private-pre-shared-key=testvlan1
add mac-address=02:02:02:02:02:02 private-pre-shared-key=testvlan105 vlan-id=105 vlan-mode=use-tag
This is also working
/interface wireless access-list
add mac-address=00:00:00:00:00:00 private-pre-shared-key=testvlan1
add mac-address=02:02:02:02:02:02 private-pre-shared-key=testvlan105 vlan-id=105 vlan-mode=use-tag
But this is not, and that is requiered
/interface wireless access-list
add mac-address=00:00:00:00:00:00 private-pre-shared-key=testvlan1
add mac-address=00:00:00:00:00:00 private-pre-shared-key=testvlan105 vlan-id=105 vlan-mode=use-tag
/code]
[/quote]
 
LaZyLion
newbie
Posts: 32
Joined: Fri May 09, 2014 10:27 am

Re: Feature request for v7.x

Wed Jul 05, 2023 8:49 pm

Hi all

The Zerotier client allows adding static routes but only to the main routing table.
It would be nice to specify a different routing table on the Zerotier interface tab.

This would make handling marked routing-table traffic much easier as one could update routes en-mass from the Zerotier portal, rather than having to update routes manually in each router.


Thanks all.
Keep up the great work.

Who is online

Users browsing this forum: adimihaix, sebi099 and 153 guests