July 2018 - Public - talk.mikrotik.com.au

Axiom Cyber Shield
by Philip Loenneker 27 Jan '21

27 Jan '21

Hi all, After seeing their presentation at the Melbourne MUM, we've been having a look at Axiom Cyber Shield. Is anyone on here using it and happy to provide some feedback, on-list or off-list? It certainly sounds like a good product, but I only seem to be able to find sales pitch information, not unbiased reviews. Regards, Philip Loenneker | Network Engineer | TasmaNet 40-50 Innovation Drive, Dowsing Point, Tas 7010, Australia P: 1300 792 711 philip.loenneker(a)tasmanet.com.au<mailto:philip.loenneker@tasmanet.com.au> www.tasmanet.com.au<http://www.tasmanet.com.au/>

3 7

Re: [MT-AU Public] Radar detection Chaos Since 6.40.4
by Mike Everest 31 May '19

31 May '19

Hi Harry, thanks for the comments! (have you tried subscribing to the public list? What happens when you try to add a subscription?) That is only the LIPD class license document but it does not list the relevant standards. The standards list some of the ETSI specifications which according to MT include radar detect operation. From MT perspective, they claim that DFS implies Radar Detect in the relevant standards. I have no doubt that it DOES make that link in the EU specification, but since our AU compliance requirements also refer to some ETSI standard then it is possible that our rules are also affected by the recent updates to relevant ETSI standards simply by association and since ACMA have not explicitly excluded that revision... This is what I am attempting to ascertain ;) So far, I have not been able to find the direct relationships and have been doing the rounds of some compliance folks to try to get to the bottom of it all. It may take some time :-1 Cheers, Mike. ---------------------------------------------------------------------------- -------- Why Choose DuxTel for all your MikroTik needs? 10 good reasons: http://duxtel.com/why_duxtel ---------------------------------------------------------------------------- -------- Follow our tweets for news and updates: http://twitter.com/duxtel > -----Original Message----- > From: Harry Fiotakis [mailto:Harry.Fiotakis@tasmanet.com.au] > Sent: Monday, 23 October 2017 10:39 AM > To: Mike Everest (mike(a)duxtel.com) <mike(a)duxtel.com> > Cc: Philip Loenneker <Philip.Loenneker(a)tasmanet.com.au> > Subject: RE: [MT-AU Public] Radar detection Chaos Since 6.40.4 > > Morning Mike, Phil forwarded me the latest correspondence as I still have not > been approved on the mailing list :( > > https://www.legislation.gov.au/Details/F2015L01438 (Radiocommunications > (Low Interference Potential Devices) Class Licence 2015) > > 5250-5350 Must use DFS > 5470-5600 Must use DFS > 5650-5725 Must use DFS > > No Radar Detect required (it is not implied) > > We will have to seek official clarification on that if Mikrotik require it, but > with it forced on we are downgrading Mikrotik radios or simply not using > them. > > > Regards, > > Harry Fiotakis | TasmaNet > 40-50 Innovation Drive, Tas 7010, Australia > M: 0418 540 806 P: 1300 792 711 > Email: harry.fiotakis(a)tasmanet.com.au > > > -----Original Message----- > From: Philip Loenneker > Sent: Monday, October 23, 2017 10:30 AM > To: Harry Fiotakis <Harry.Fiotakis(a)tasmanet.com.au> > Subject: FW: [MT-AU Public] Radar detection Chaos Since 6.40.4 > > > -----Original Message----- > From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of > Mike Everest > Sent: Monday, 23 October 2017 9:50 AM > To: 'MikroTik Australia Public List' <public(a)talk.mikrotik.com.au> > Subject: Re: [MT-AU Public] Radar detection Chaos Since 6.40.4 > > Further update on this issue, > > I've had a bit of correspondence with them, but they are 'fighting' it. Latest > comment from them is that "ETSI standard mentions when you use DFS and > those ranges you need to use the Radar-detect. Radar detect is happening > only for 1 minute." > > The line they are taking is that since our LIPD class license specification says > that DFS must be enabled for the sub 5785 channels, then radar detect must > also be enabled. I've been trying to pore through all the relevant ACMA > documentation so that I can find some definitive paragraph that clarifies the > situation, but so far have drawn a blank. > > I need someone who has some specific familiarity with the relevant rules and > standard that can find something that will convince them to turn it off - any > takers? :-} > > Cheers, Mike. > > > > _______________________________________________ > Public mailing list > Public(a)talk.mikrotik.com.au > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au

5 26

Fwd: xDSL SFPs
by Jason Hecker (Up & Running Tech) 27 Aug '18

27 Aug '18

That's flat out wrong. Have a look at the PDF on http://www.acma.gov.au/ Industry/Suppliers/Regulatory-arrangements/EMC- Electromagnetic-compatibility/emc-standards-list and see page 5. All IT equipment - no exceptions - must be tested (by an approved tester) to and comply with CISPR-32 and get a C-Tick for use in Australia. Upshot is don't import and use or sell the SPF modules unless the supplier has ensure it's complied. Duxtel know all about this - they supply all their Mikrotik gear (including boring old routers with no Wifi) with pretty little compliance stickers. On 9 August 2017 at 17:05, Paul Julian <paul(a)oxygennetworks.com.au> wrote: > Agreed, the VC-231's are Tick approved, PSU and Bridge, we use a lot of > them when deployed as a NTU for a VDSL2 DSLAM Implementation or as a point > to point VDSL2 link. > > C tick or A tick approval is only required when connecting > telecommunication devices to public communication networks, C tick or A > tick approval is required for radio communications devices, so if it's a > telecommunications device connected to a private wire you don't need > approval, if it's a radio communications device you need approval no matter > what. > > The ACMA make it pretty clear on their website if you aren't sure. > > http://www.acma.gov.au/theACMA/bringing-communications- > equipment-into-australia > > Regards > paul > > -----Original Message----- > From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of > Jason Hecker (Up & Running Tech) > Sent: Wednesday, 9 August 2017 4:52 PM > To: MikroTik Australia Public List > Subject: Re: [MT-AU Public] xDSL SFPs > > That's partly true. As it's an active device it still needs C-Tick > approval for electromagnetic compatibility and susceptibility reasons. > There are likely even considerations for electrical isolation as it can > connect two sites on different AC phases and potentials. Considering it's > pumping HF energy into a long wire it's like a radio transmitter anyway so > it definitely needs to comply. > > On 9 August 2017 at 16:45, Paul Julian <paul(a)oxygennetworks.com.au> wrote: > > > If it's a private CAT3 cable there are no approvals required as it's > > just a private link. > > > > We use the Planet VC-231 bridges for that sort of thing, they are > > pretty good and will do 100/100 over a couple of hundred metres with > good cable. > > > > Regards > > Paul > > > > -----Original Message----- > > From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of > > Jason Hecker (Up & Running Tech) > > Sent: Wednesday, 9 August 2017 4:41 PM > > To: MikroTik Australia Public List > > Subject: Re: [MT-AU Public] xDSL SFPs > > > > Yes the belt and braces and correct way is to find a version that > > someone has had approved for use in Australia. I don't think anyone > > has done that yet! It'd be nice if the manufacturer did the legwork > > but they only do FCC and CE. > > > > On 9 August 2017 at 16:33, Russell Hurren > > <russell(a)zeropointnetworks.com> > > wrote: > > > > > I've just had a client call me and ask for a WiFi repeater to go in > > > the house next to their motel. There's already CAT3 running between > > > the buildings, so something like that would be a good option for me. > > > I'd be willing to order a pair and give it a try, but I'm not sure > > > about the legality - I presume it'd need an A-Tick approval? > > > > > > I've got a CRS125 in the main building and I could put a hAP ac in > > > the house and it'd be a nice clean option, compared to using > > > something like a Planet VC-231. > > > > > > -----Original Message----- > > > From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf > > > Of Jason Hecker (Up & Running Tech) > > > Sent: Wednesday, 26 July 2017 8:37 > > > To: MikroTik Australia Public List <public(a)talk.mikrotik.com.au> > > > Subject: Re: [MT-AU Public] xDSL SFPs > > > > > > That said, the http://www.proscend.com/en-gb/product/sfp/180cr.html > > > looks interesting for linking buildings that have old CAT3 cabling > > > in between. I reckon I could have used that sort of thing in a few > > > places instead of wireless. Has anyone tried these sort of VDSL2 > > bridges? > > > > > > On 26 July 2017 at 10:20, Philip Loenneker <Philip.Loenneker@tasmanet. > > > com.au > > > > wrote: > > > > > > > If anyone would care to donate a unit, I have a service I can test > > > > it > > on. > > > > And as an RSP, we have direct access to the NBN portal to request > > > > reactivation if it gets blocked :) > > > > > > > > -----Original Message----- > > > > From: Public [mailto:public-bounces@talk.mikrotik.com.au] On > > > > Behalf Of Jason Hecker (Up & Running Tech) > > > > Sent: Wednesday, 26 July 2017 10:17 AM > > > > To: MikroTik Australia Public List <public(a)talk.mikrotik.com.au> > > > > Subject: Re: [MT-AU Public] xDSL SFPs > > > > > > > > I think we're all pretty excited about the prospects of those > > > > VDSL2 and G.Fast SFP modules (I am getting FTTC so G.Fast is > > > > probably on the cards one day). I guess you can be the guinea pig > > > > and be the one to risk explaining to your ISP why your port should > be unlocked. > > > > ;) > > > > > > > > On 26 July 2017 at 10:09, Damien Gardner Jnr <rendrag(a)rendrag.net> > > > wrote: > > > > > > > > > If you plug in a modem which does not support G.vector, the port > > > > > will get shut down within ~10 minutes, and requires a support > > > > > request from your > > > > RSP > > > > > to NBNco to have the port re-enabled. They don't specifically > > > > > detect > > > > modem > > > > > model and shut down if they don't know the model though, as far > > > > > as I > > > > know. > > > > > > > > > > IPOE on ADSL is an interesting one, that'd make setup very easy! > > > > > > > > > > On 26 July 2017 at 10:05, Jason Hecker (Up & Running Tech) < > > > > > jason(a)upandrunningtech.com.au> wrote: > > > > > > > > > >> Be careful, I remember reading that modems not tested and > > > > >> authorised for NBN use can cause the port to be locked. Until > > > > >> someone goes to the expense of having them tested and approved > > > > >> for use in Australia (cough .. Mike?) you may not get much joy. > > > > >> They might work on a bog standard ADSL line. > > > > >> > > > > >> Speaking of which, I might be late to the party but I noticed > > > > >> that > > > > Telstra > > > > >> ADSL now supports IPoE as well as PPPoE/A. I reset an old > > > > >> cheapie/dodgy TPLink modem the other day for someone and > > > > >> without doing anything the PC connected did a DHCP request and > > > > >> got a public IP/DNS! When I set the modem up to do IPoE it > > > > >> picked all that up as well but for some reason wouldn't NAT or > > > > >> proxy the DNS. Wrote the modem off and we proceeded to order an > NBN service. > > > > >> > > > > >> On 26 July 2017 at 09:57, Damien Gardner Jnr > > > > >> <rendrag(a)rendrag.net> > > > > wrote: > > > > >> > > > > >> > Anyone else ordered one of the 180-T's yet? innet24.de are > > > > >> > now > > > > selling > > > > >> > them, but are waiting on a firmware update (due out next > > > > >> > week) before they're shipping more units. Looking forward to > > > > >> > getting one and > > > > seeing > > > > >> how > > > > >> > they go on NBN, if I can remove one device from the network > > > > >> > at home, > > > > >> I'll > > > > >> > be very happy! > > > > >> > > > > > >> > On 19 May 2017 at 08:08, Thomas Jackson > > > > >> > <thomas(a)thomax.com.au> > > > wrote: > > > > >> > > > > > >> > > Thanks for the responses everyone > > > > >> > > > > > > >> > > Looks like we're using the double-sided tape again this > > > > >> > > time around > > > > :) > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > Sent from mobile > > > > >> > > > > > > >> > > Thomas Jackson > > > > >> > > Managing Director > > > > >> > > +61 2 8378 5555 > > > > >> > > > > > > >> > > > On 18 May 2017, at 12:54 pm, Mike Everest > > > > >> > > > <mike(a)duxtel.com> > > > > wrote: > > > > >> > > > > > > > >> > > > Hi Everyone, > > > > >> > > > > > > > >> > > > I thought I'd chip in some commentary here since there is > > > > obviously > > > > >> > > plenty > > > > >> > > > of interest :-} > > > > >> > > > > > > > >> > > > There are at least two products around that implement > > > > >> > > > some form of > > > > >> vDSL > > > > >> > > in > > > > >> > > > an SFP module, but there are lots of hurdles preventing > > > > >> > > > release to > > > > >> AU > > > > >> > > market > > > > >> > > > which are partly commercial (vendor requests significant > > > > >> > > > - circi > > > > >> > USD100K > > > > >> > > - > > > > >> > > > commitment prior to even proving viable operation on any > > > > >> > > > given > > > > >> network) > > > > >> > > and > > > > >> > > > partly technical (vDSL definition is somewhat 'loose' in > > > > >> implementation > > > > >> > > such > > > > >> > > > that there is no guarantee that something that works well > > > > >> > > > with one > > > > >> > vendor > > > > >> > > > DSLAM will also work with every other) > > > > >> > > > > > > > >> > > > At DuxTel, we've been trying to work out a solution for > > > > >> > > > many > > > > months, > > > > >> > and > > > > >> > > > although we are closing on a potential outcome, there is > > > > >> > > > no firm > > > > >> date > > > > >> > for > > > > >> > > > market readiness. > > > > >> > > > > > > > >> > > > One thing that we know of thus far: > > > > >> > > > - devices are real, and actually exist ;) > > > > >> > > > - devices work with MikroTik RouterOS to the extent that > > > > >> > > > they are > > > > >> > > recognised > > > > >> > > > by SFP drivers and 'inserted module' parameters are > > > > >> > > > reported > > > > >> correctly > > > > >> > > > - MikroTik are 'on board' to develop further support to > > > > >> > > > implement > > > > >> some > > > > >> > > form > > > > >> > > > of configuration interface for routerOS and this type of > > > > >> > > > device > > > > >> > > > > > > > >> > > > Here is what we don't have yet: > > > > >> > > > - commercial agreement with manufacturing vendor/s to > > > > >> > > > support > > > > >> > > development of > > > > >> > > > solution to work with any given vDSL service (read: NBN) > > > > >> > > > - compliance testing documentation to support RCM > > > > >> > > > eligbility for > > > > AU > > > > >> > > > environment > > > > >> > > > > > > > >> > > > What needs to happen before they are made available to > > > > >> > > > the AU > > > > >> market: > > > > >> > > > - compliance testing and certification > > > > >> > > > - testing (and probably some driver/firmware development) > > > > >> > > > to work > > > > >> with > > > > >> > > NBNCo > > > > >> > > > DSLAMs and other DSLAM vendors > > > > >> > > > > > > > >> > > > The big hurdle to the above is in coming to some > > > > >> > > > commercial > > > > >> agreement > > > > >> > > with > > > > >> > > > one or more vendors that satisfies their need to cover > > > > >> > > > costs of > > > > >> final > > > > >> > > stages > > > > >> > > > of development and compliance testing. > > > > >> > > > > > > > >> > > > My assessment of where this is all at is that the > > > > >> > > > manufacturer/s > > > > >> have > > > > >> > > > developed some 'proof of concept' hardware that seems to > > > > implement a > > > > >> > > general > > > > >> > > > form of vDSL (with ADSL fallback) BUT (and that's a big > > > > >> > > > BUT) there > > > > >> is a > > > > >> > > lot > > > > >> > > > of technical work to be done to deliver sufficient > > > > >> > > > confidence that > > > > >> they > > > > >> > > will > > > > >> > > > work reliably over any particular or general vDSL network. > > > > >> > > > That > > > > is > > > > >> not > > > > >> > > even > > > > >> > > > beginning to consider whether they are likely to meet any > > > > particular > > > > >> > > > regulatory compliance requirements for AU or any other > > > > jurisdiction > > > > >> ;) > > > > >> > > > > > > > >> > > > So short story is: they are coming, perhaps, but probably > > > > >> > > > not any > > > > >> time > > > > >> > > soon > > > > >> > > > :-J > > > > >> > > > > > > > >> > > > Questions (on or off list) are welcome! > > > > >> > > > > > > > >> > > > Cheers, Mike. > > > > >> > > > > > > > >> > > > > > > > >> > > > _______________________________________________ > > > > >> > > > Public mailing list > > > > >> > > > Public(a)talk.mikrotik.com.au > > > > >> > > > http://talk.mikrotik.com.au/mailman/listinfo/public_talk. > > > > >> > mikrotik.com.au > > > > >> > > > > > > >> > > _______________________________________________ > > > > >> > > Public mailing list > > > > >> > > Public(a)talk.mikrotik.com.au > > > > >> > > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mi > > > > >> > > k > > > > >> rotik.com.au > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > > >> > -- > > > > >> > > > > > >> > Damien Gardner Jnr > > > > >> > VK2TDG. Dip EE. GradIEAust > > > > >> > rendrag(a)rendrag.net - http://www.rendrag.net/ > > > > >> > -- > > > > >> > We rode on the winds of the rising storm, We ran to the > > > > >> > sounds of thunder. > > > > >> > We danced among the lightning bolts, and tore the world > > > > >> > asunder _______________________________________________ > > > > >> > Public mailing list > > > > >> > Public(a)talk.mikrotik.com.au > > > > >> > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mik > > > > >> rotik.com.au > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> -- > > > > >> <https://www.upandrunningtech.com.au> > > > > >> _______________________________________________ > > > > >> Public mailing list > > > > >> Public(a)talk.mikrotik.com.au > > > > >> http://talk.mikrotik.com.au/mailman/listinfo/public_talk. > > > > mikrotik.com.au > > > > >> > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Damien Gardner Jnr > > > > > VK2TDG. Dip EE. GradIEAust > > > > > rendrag(a)rendrag.net - http://www.rendrag.net/ > > > > > -- > > > > > We rode on the winds of the rising storm, We ran to the sounds > > > > > of thunder. > > > > > We danced among the lightning bolts, and tore the world asunder > > > > > > > > > > > > > > > > > > > > > -- > > > > <https://www.upandrunningtech.com.au> > > > > _______________________________________________ > > > > Public mailing list > > > > Public(a)talk.mikrotik.com.au > > > > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mik > rotik.com. > > > > au > > > > > > > > > > > > > > > > -- > > > <https://www.upandrunningtech.com.au> > > > _______________________________________________ > > > Public mailing list > > > Public(a)talk.mikrotik.com.au > > > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. > > > au > > > > > > _______________________________________________ > > > Public mailing list > > > Public(a)talk.mikrotik.com.au > > > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. > > > au > > > > > > > > > > > -- > > <https://www.upandrunningtech.com.au> > > _______________________________________________ > > Public mailing list > > Public(a)talk.mikrotik.com.au > > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. > > au > > > > > > > -- > <https://www.upandrunningtech.com.au> > _______________________________________________ > Public mailing list > Public(a)talk.mikrotik.com.au > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au > > -- <https://www.upandrunningtech.com.au> -- <https://www.upandrunningtech.com.au>

8 19

LtAP Mini Kit
by Dave Browning 02 Aug '18

02 Aug '18

Hi All, Looking for anyone with an LtAP mini kit who can check if they have the same problem as I. If I power from USB port, the lte interface doesn't come up when WiFi is enabled - If I power from PoE or AC, works fine. Cheers, Dave Browning | Network Engineer P 1300 791 678 Level 1, 12 Railway Tce, Milton QLD 4064

3 3

Re: [MT-AU Public] SIP Identification issue in mangle and queues
by Nick Pratley | Servers Australia 25 Jul '18

25 Jul '18

Hey Paul, How are you talking to MyNetPhone? Do you have dedicated cross connects to them, or are you just talking over the internet? If it's over the internet, its the general consensus is that DSCP gets remarked to 0 through all providers - so it'd only be used within your network toward the upstream and down to your customer. Probably also why you won't see any markings from MyNetPhone inbound on your transit links. If you're just trying to QOS your last mile circuits so large downloads etc don't break SIP - can you move that to customer access device? Not sure what phones you are using but Polycom/Cisco/Yealink can all mark their RTP / Signal traffic with different markings. You could match these markings from your customer on your LNS and add those addresses to an address list with a ~15 minute timeout. You could then match that address list on your inbound interfaces from the internet and remark internally before routing to your customer site over last mile access. Obviously that'd mark everything for those IPs down to the customer and not just RTP - however if the provider only uses them for RTP, I don't really see the issue. Regards, Nick (p.s. Sorry for signature in advanced - it's enforced outbound on our MTA, just subbed personal email to this list so next reply won't have it - I promise) --- original message --- On Wed, Jul 25, 2018 at 04:53 pm, <paul(a)buildingconnect.com.au> Paul Julian wrote: Well I found the problem I think, I am still working out how to get around it though. It seems that mynetfone use different servers for their signalling and RTP, which means if you use the sip service type in Mikrotik, or port 5060/5061 to mark your packets then you will miss the RTP traffic which is really what you need to get. Somehow I need to mark packets that are related to the SIP connection, not just the SIP connection itself. I will have to have a think about this one..... Regards Paul -----Original Message----- From: Public <public-bounces(a)talk.mikrotik.com.au> On Behalf Of Philip Loenneker Sent: Wednesday, 25 July 2018 2:41 PM To: MikroTik Australia Public List <public(a)talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SIP Identification issue in mangle and queues Fair call :) Are your mangle rules not matching, or only the queue not matching? -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Wednesday, 25 July 2018 2:18 PM To: 'MikroTik Australia Public List' <public(a)talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SIP Identification issue in mangle and queues Hi Philip, Quite honestly we wouldn't trust any provider with DSCP values, they just don't get it, we mark everything based on connection type and/or ports and also pickup SIP servers dynamically based on those other criteria. The problem comes when we mark the packets they seem to get marked but the way we see them treated in queues is strange, they seem to have a bursty nature rather than having a consistent 80kbit/s sort of situation. There is something strange going on but it is only affecting this one customer who uses mynetfone, so I am trying to think outside the box and wondering what on earth could be happening to cause this. Regards Paul -----Original Message----- From: Public <public-bounces(a)talk.mikrotik.com.au> On Behalf Of Philip Loenneker Sent: Wednesday, 25 July 2018 2:14 PM To: MikroTik Australia Public List <public(a)talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SIP Identification issue in mangle and queues Hi Paul, We have noticed that MyNetFone do NOT mark their packets with DSCP values, even if the handsets/softphones at the customer end do. You can see this clearly in torch and packet captures. We have asked them about it in the past, and didn't manage to get them to understand what DSCP was and why it was important. You may have more luck if you reach out to them, as it's been a while since we tried. If you do have some luck, please let me know so I can check our customers again :) Regards, Philip Loenneker | Network Engineer | TasmaNet 40-50 Innovation Drive, Dowsing Point, Tas 7010, Australia P: 1300 792 711 philip.loenneker(a)tasmanet.com.au www.tasmanet.com.au -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Wednesday, 25 July 2018 1:33 PM To: 'MikroTik Australia Public List' <public(a)talk.mikrotik.com.au> Subject: [MT-AU Public] SIP Identification issue in mangle and queues Hi All, Just wondering if anybody has seen this anomaly before. We use Mikrotik routers as LNS’s in many locations, we prioritise VOIP traffic outbound to our customers and it works very well. We do this using a mix of mangle rules and reconstruct the customer facing queues during login, this also works very well and allows us to prioritise any voice provider not just ourselves. Just recently we had a customer advise that they were having voice issues and were wondering if they needed to increase their capacity, upon looking at their usage history we could see that they were spiking a bit but also noticed that their VOIP queue was not matching any packets. Other customers were matching just fine with the same rules in place, however we totally went through everything and couldn’t find any issues. As a precaution we upgraded the ROS to the latest bugfix version and also upgraded firmware. After that the other customers VOIP queues were still matching just fine so we thought perhaps Mynetfone were doing something a bit weird with the voice traffic to this customer, so we even setup a dedicated queue for this customer with everything needed to match the traffic, but still nothing. It’s a really weird problem, it’s only this one customer, all other customers are working correctly, so I’m not sure whether it’s a mynetfone problem or maybe the customers router, but we only prioritise the outbound traffic TO the customer and across our network but in this case it’s the traffic from mynetfone to the customer which isn’t matching, as such I wouldn’t think that their CPE could impact what we are doing in any way. Any thoughts would be appreciated, I am fast running out of my remaining hair on this one ૘ෞ਀ ഀ਀吀栀愀渀欀猀ഀ਀倀愀甀氀 _______________________________________________ Public mailing list Public(a)talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public(a)talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public(a)talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public(a)talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public(a)talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au --- end of original message ---

2 1

SIP Identification issue in mangle and queues
by Paul Julian 25 Jul '18

25 Jul '18

Hi All, Just wondering if anybody has seen this anomaly before. We use Mikrotik routers as LNS’s in many locations, we prioritise VOIP traffic outbound to our customers and it works very well. We do this using a mix of mangle rules and reconstruct the customer facing queues during login, this also works very well and allows us to prioritise any voice provider not just ourselves. Just recently we had a customer advise that they were having voice issues and were wondering if they needed to increase their capacity, upon looking at their usage history we could see that they were spiking a bit but also noticed that their VOIP queue was not matching any packets. Other customers were matching just fine with the same rules in place, however we totally went through everything and couldn’t find any issues. As a precaution we upgraded the ROS to the latest bugfix version and also upgraded firmware. After that the other customers VOIP queues were still matching just fine so we thought perhaps Mynetfone were doing something a bit weird with the voice traffic to this customer, so we even setup a dedicated queue for this customer with everything needed to match the traffic, but still nothing. It’s a really weird problem, it’s only this one customer, all other customers are working correctly, so I’m not sure whether it’s a mynetfone problem or maybe the customers router, but we only prioritise the outbound traffic TO the customer and across our network but in this case it’s the traffic from mynetfone to the customer which isn’t matching, as such I wouldn’t think that their CPE could impact what we are doing in any way. Any thoughts would be appreciated, I am fast running out of my remaining hair on this one ૘ෞ਀ ഀ਀吀栀愀渀欀猀ഀ਀倀愀甀氀

2 5

Forward Chain firewall rules
by Paul Julian 20 Jul '18

20 Jul '18

Hi All, Just wondering what others do when it comes to jumping to new chains from the forward chain for protecting services running behind your Mikrotik running as a firewall. We typically jump to a new chain for stuff like SMTP servers or Web servers and then filter based on protocol and port within that new chain to protect boxes, then drop anything that doesn't match. Some people add an accept rule at the top of each of those chains for related and established connections, some people add one at the beginning of the default forward chain, what are peoples thoughts on the pros and cons of doing this in any way mentioned ?, are there any risks doing one way or another or should you just stick to allowing only the trusted ports and protocols through in each relevant chain rather than anything that's already been allowed previously ? I'm interested in peoples thoughts on this Thanks Paul

2 1

ccr1072 power supply
by Alex Samad 20 Jul '18

20 Jul '18

Hi Is there any way from the command line to detect the health of the power supplies ? I looked at /system health but couldn't find anything related to health of each power supply A

2 2

Mikrotik 60Ghz Gear
by Paul Julian 20 Jul '18

20 Jul '18

Hi, according to Duxtel some 60Ghz kit has already flown out the door, who is using it and what's it like ? I am looking for some real world experience on the new LHG 60 Ghz gear. What is it like in the real world ? What distance are you comfortably seeing from it ? What about colocation on the same mast ? Thanks Paul

2 2

Maxxwave Rack Mount Adapter
by Russell Hurren 18 Jul '18

18 Jul '18

Does anyone know where I could get a rackmount adapter for a hex-s like this one or similar? https://www.balticnetworks.com/mikrotik-rackmount-adapter-for-routerboard-2… Shipping from the US is several times more expensive than the adapter itself. Wouldn't mind buying 2-3 so I've got some spares on hand, but I only need one at the moment. Regards Russell Hurren

3 2