April 2014 - Public - talk.mikrotik.com.au

Re: [MT-AU Public] Problems with multiple RBMetal2SHPn devices failing at one site
by Karl Auer 01 Jun '14

01 Jun '14

On Tue, 2014-04-29 at 23:37 +1000, Steve at Digitronics wrote: > Typically, a device works ok for a while (up to a month) but then > starts logging kernel faults and exhibiting other weird symptoms such > as script failures, and vanishing scripts. Sometimes only a reboot or > a power cycle will get a failed unit going again. > The chances of their being actual faulty devices is now so vanishing > small as to be discounted, so we are trying to figure out what it is > at this site that could be causing the same persistent failures on the > series of devices. Radiation - is the unit in the path of somebody else's microwave or similar? Heat: Could the unit be above or near an intermittent heat source? Or an "accidental lens" focusing heat on the unit, such as a concave metal or glass panel? Vibration: Is the unit mounted on something that could be subject to intermittent vibration, such as a poorly mounted aircon unit? Vandalism: Is the unit anywhere where an aggrieved person might be playing silly buggers with it? Some people are really touchy about wireless devices nearby. Non-human pest activity: Rats, mice, insects etc. You'd expect visible damage if they were attacking the unit directly, but perhaps they are somehow causing vibration or overheating. If not to the unit, then possibly to the POE injector, the PSU or some other component. Swap the PSU on the suspect end to with the PSU on the other end. Does the problem follow the PSU? Swap the units at the two ends. Does the problem follow the unit, or does the previously good unit that has "never had a failure of any kind" start exhibiting the same symptoms? Is the POE source rated to provide enough power for the aggregate load of this device and any others it is supplying? Long shot, but is there any chance that the method of attaching the unit is in some way penetrating or deforming the unit in some way? Try mounting it differently just for a week or two to see if it makes a difference. Has the CAT5 cable been checked *for POE use*? Some equipment checks only that the cable is good for data... In situations like this, I also I recommend my two debugging mantras: Ain't no such thing as magic. When you have eliminated the impossible, whatever remains, *however improbable*, must be the truth. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer(a)nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: 231A B066 CF91 1216 4F0F F2AC CE25 B8AA 46DC CC4F Old fingerprint: 1DB8 0599 13F0 E774 3811 6CA6 D6D0 AFA9 D91A 004C

4 7

API Wildcard search
by Mike Everest 15 May '14

15 May '14

Hi folks, Anyone have some experience using routerOS API? I've been extending the configuration group functionality of our DuxTel Commander, and come up against a challenge in filtering API query (http://wiki.mikrotik.com/wiki/API#Queries) The deal is that I use 'comment' field as a way to cross-reference router configuration entries with the configuration database items. For example, a firewall rule might look like: ip firewall filter add chain=forward src-address-list=blocked action=drop comment='Managed by DuxAdmin SetID:443 ItemID:27' So when I want to find all the firewall rules with SetID:443, I can do this: /ip/firewall/filter/find ?>comment=Managed by DuxAdmin SetID:443 Which seems to work OK, but I can't work out how to return just those entries that include 'ItemID:27' I'll put the question to MT support and post a solution (if there is one) if/when they respond, but if anyone has some suggestions, I'm 'all ears'! ;-) Cheers, Mike.

4 7

'announcements' list?
by Mike Everest 30 Apr '14

30 Apr '14

Hi folks, A couple of people have asked me about submitting commercial news to this list, but since the original intent was to always keep this one free of commercial content, marketing material and general advertising, I continue to advise that we should avoid that kind of post to this list. The next question, then, is whether anyone considers some value in a new list just for that kind of material. We already have jobs@talk.mikrotik.com.au for employment opportunity posts, would it be worth also creating a list like announcements@talk.mikrotik.com.au for posts like when new products are available or training programs are planning? Perhaps revision of the rules (and name) for jobs list to /include/ announcements? We have about ½ dozen subscribers to jobs at the moment, would anyone consider subscribing to announce? Suggestions/comments? Cheers! Mike.

6 6

Problems with multiple RBMetal2SHPn devices failing at one site
by Steve at Digitronics 30 Apr '14

30 Apr '14

We have lots of groove type devices out there, plastic and metal, but there is one installation where we are having consistent problems, and it is the only place we have had any problems. Over the last 6 months or so we have had kernel failures and script errors logged on four different devices at the same site, the last three being RBMetal2SHPns. The four devices have been installed at the same site with the last three as subsequent replacements for the prior unit because it was playing up. Typically, a device works ok for a while (up to a month) but then starts logging kernel faults and exhibiting other weird symptoms such as script failures, and vanishing scripts. Sometimes only a reboot or a power cycle will get a failed unit going again. The chances of their being actual faulty devices is now so vanishing small as to be discounted, so we are trying to figure out what it is at this site that could be causing the same persistent failures on the series of devices. The device mounting and sealing has been checked. The antenna VSWR has been checked. The antenna cabling has been checked. The CAT5 cabling has been checked. The PSU and POE injector have both been changed at different times. The PSU is on a UPS. The site is not subject to lightning strikes or subsequent voltage gradients. The device is only 15m from the POE injector. When it is working the wireless data throughput is as expected. The device is on a private CAN so cannot be publicly hacked. The times and frequency of failures do not follow any obvious throughput, temperature, humidity or time of day patterns. The unit at the other end of the link has never had a failure of any kind. We are struggling to think of any other possible site specific environmental or equipment influence(s) that could be causing these failures, and I am really hoping that someone on the list can give us some fresh ideas or can share the resolution to similar circumstances they have experienced. TIA. Steve.

5 6

heartbleed and routerOS
by Mike Everest 29 Apr '14

29 Apr '14

Responding to some questions about this topic, the official word is that routerOS is not affected: http://forum.mikrotik.com/viewtopic.php?f=2 <http://forum.mikrotik.com/viewtopic.php?f=2&t=83815> &t=83815 according to the posts, routerOS prior to 6.11 used an older version of openSSL that did not have the reported vulnerability, and 6.12 onward has a newer version of openSSL that has the vulnerability fixed. Thus it seems that due to a lack of attention in keeping public maintained libraries up to date has been counted as a win for routerOS users this time around ;) Cheers! Mike.

1 0

Cloud Core Router Bargains!
by Mike Everest 14 Apr '14

14 Apr '14

Hi All, Take a search on bay.com.au - rackcentral have 'outgrown' some CCR 1036+ (10 gig SFP models), and offloading them at bargain basement prices. They can't be more than a couple of months old, and will still carry their original warranty (from DuxTel ;) Even if you don't need one right now, maybe it's a price too good to let it go! :) Cheers, Mike.

2 1

CCR Tips and Tricks
by Andrew Cox 11 Apr '14

11 Apr '14

This presentation by Janis has a lot of detailed info about the current status of routing functions in v6 and the best way to fully utilise the performance of them; also what will be changed in v7! Thought you might all find it useful: http://mum.mikrotik.com/presentations/RU14/megis.pdf Cheers, Andrew Cox

3 6

Interfaces on CCR's not disabling
by Paul Julian 11 Apr '14

11 Apr '14

Hi all, we have had some experiences on ROS v6.x (still on 6.11) of Ethernet interfaces on CCR's not actually disabling when you disable them in winbox, disabling from the terminal seems to work fine. These Ethernet interfaces are slaves in a bonded interface setup, however we can't really identify whether it is this setup which is causing the problem. Even though the interface shows as disabled (greyed out), you can still see the counters going up and down as it is still seeing traffic. Just wondering if anybody else has experienced this phenomenon before as Mikrotik don't seem to know about it. Regards Paul

2 1

Re: [MT-AU Public] Public Digest, Vol 2, Issue 5
by Greg Sowell 08 Apr '14

08 Apr '14

Awesome detective work Mike...inspector Everest! On Mon, Apr 7, 2014 at 9:00 PM, <public-request(a)talk.mikrotik.com.au> wrote: > Send Public mailing list submissions to > public(a)talk.mikrotik.com.au > > To subscribe or unsubscribe via the World Wide Web, visit > > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au > > or, via email, send a message with subject or body 'help' to > public-request(a)talk.mikrotik.com.au > > You can reach the person managing the list at > public-owner(a)talk.mikrotik.com.au > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Public digest..." > > > Today's Topics: > > 1. Re: DHCP bug rOSv6.10 (at least) (Mike Everest) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 8 Apr 2014 09:02:44 +1000 > From: "Mike Everest" <mike(a)duxtel.com> > To: "'MikroTik Australia Public List'" <public(a)talk.mikrotik.com.au> > Subject: Re: [MT-AU Public] DHCP bug rOSv6.10 (at least) > Message-ID: <087201cf52b5$7cb57a20$76206e60$(a)duxtel.com> > Content-Type: text/plain; charset="us-ascii" > > Hi Folks, > > Latest news regarding this issue, MT have confirmed that it is a routerOS > bug, and is addressed in v6.12 - Quoting one of the Janises: > > > Yes, exactly that problem is fixed in that build i linked. > > It was our mistake, we forget that Option 82 must be at the end of option > list, > > cause those switches remove all options after option 82. > > Now it is back in place and there should be no problem and no need to > change > > switch configurations. > > Cheers, Mike. > > > > -----Original Message----- > > From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of > Mike > > Everest > > Sent: Wednesday, 2 April 2014 2:58 PM > > To: public(a)talk.mikrotik.com.au > > Subject: [MT-AU Public] DHCP bug rOSv6.10 (at least) > > > > Hi Folks, > > > > > > > > I have received report of this bug behaviour before, but never seen it > happen > > myself, or been able to get any diagnostic at all until this afternoon. > Thought I > > would post in case it is useful info! > > > > > > > > This has been reported to us previously as "when customer gets DHCP > lease, > no > > access to anything is possible. When customer enters static lease, > everything is > > good. Reboot router, everything fine again for a while. Then stops > working" > > > > > > > > Today, I discovered the reason. After some number of leases has been > issued > > by DHCP server, some number in the vicinity of about 200 leases, new > leases > > are issued with bad subnet mask, no gateway and no DNS. End result, of > > course, is no connectivity. > > > > > > > > This is apparently just related to number of leases, not actual dhcp > server > > - i.e. the problem happens after the same number of leases are formed > even > > when there are 3 DHCP servers on 4 different subnetworks, or just one > DHCP > > server for all clients. > > > > > > > > Today, I had a chance to work with a fellow who had done some much better > > diagnostic work on a network experiencing essentially the same behaviour > - > he > > discovered that DHCP becomes broken after some time (or some number of > > leases) in that clients no longer receive netmask, gateway or DNS detail. > > Thus the client picks up IP address only, and a default mask (assume > based > on > > address 'class') and blank gateway and DNS. > > > > > > > > The routerOS version in place omn that network is 6.10 - we have upgraded > to > > 6.11 and see if it happens again. > > > > > > > > If so, we'll grab some pcaps of DHCP traffic and report to MT - in the > > meantime, if anyone has experience with this issue too, please post it! > ;) > > > > > > > > Cheers, Mike. > > > > > > > > > > > > _______________________________________________ > > Public mailing list > > Public(a)talk.mikrotik.com.au > > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Public mailing list > Public(a)talk.mikrotik.com.au > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au > > > ------------------------------ > > End of Public Digest, Vol 2, Issue 5 > ************************************ > -- GregSowell.com TheBrothersWISP.com

1 0

DHCP bug rOSv6.10 (at least)
by Mike Everest 08 Apr '14

08 Apr '14

Hi Folks, I have received report of this bug behaviour before, but never seen it happen myself, or been able to get any diagnostic at all until this afternoon. Thought I would post in case it is useful info! This has been reported to us previously as "when customer gets DHCP lease, no access to anything is possible. When customer enters static lease, everything is good. Reboot router, everything fine again for a while. Then stops working" Today, I discovered the reason. After some number of leases has been issued by DHCP server, some number in the vicinity of about 200 leases, new leases are issued with bad subnet mask, no gateway and no DNS. End result, of course, is no connectivity. This is apparently just related to number of leases, not actual dhcp server - i.e. the problem happens after the same number of leases are formed even when there are 3 DHCP servers on 4 different subnetworks, or just one DHCP server for all clients. Today, I had a chance to work with a fellow who had done some much better diagnostic work on a network experiencing essentially the same behaviour - he discovered that DHCP becomes broken after some time (or some number of leases) in that clients no longer receive netmask, gateway or DNS detail. Thus the client picks up IP address only, and a default mask (assume based on address 'class') and blank gateway and DNS. The routerOS version in place omn that network is 6.10 - we have upgraded to 6.11 and see if it happens again. If so, we'll grab some pcaps of DHCP traffic and report to MT - in the meantime, if anyone has experience with this issue too, please post it! ;) Cheers, Mike.

1 1