I have seen a similar thing - whilst it doesn't impact me to the same extent as your scenario, it is still annoying. TL;DR - found it was related to conntrack (although not sure my understanding of the entire packet processing model is sufficient to say this is the root cause) - flushing the conntra...

Looked everywhere but in the Beta release notes

Many thanks for the heads-up Emils - that was steadily driving me nuts!

Cheers!

Strangely, this appears to get worse with time - just ended up with eighteen SANs!

Fresh install of RouterOS CHR, no clue as to what's causing this...

I was going to suggest checking "/system health print" for the bad block counter as it sounds like the flash is trash, but my CCR1016 is lacking that...

Certificate shenanigans again, RouterOS 6.44.2 CHR. I start off with a completely empty certificate system: [me@myendpoint] /certificate> print Flags: K - private-key, D - dsa, L - crl, C - smart-card-key, A - authority, I - issued, R - revoked, E - expired, T - trusted # NAME COMMON-NAME SUBJECT-AL...

Thank you for this - it's proven to be a very helpful chunk of code!

This gels with something I found when I was doing some testing last night. I suspect the problem is that the various processes in RouterOS struggle to malloc() memory for various tasks, and it makes for a very painful experience. That description of malloc() after high memory pressure agrees with m...

So what firmware do we need to install on what routers to prevent this ?

As of right now, 6.45beta23 AFAIK.

People above you in this thread are saying that there should be separate terminology between denial of service (CPU high, out of memory, crash etc) and something that allows attacker to gain access to devices, steal credentials, install malware and read private data. You are shoving them both under...

/ipv6 export file=hahahanoipv6foryou.rsc /system package disable [find name=ipv6] /system reboot Thankfully I'm in the position to do the above (and just have on my edge routers, in fact). I am nothing short of apoplectic that I've had to, however. Secretly hoping that either 6.44.1 was a fix for t...

Hello, Typically when setting up a router I add the standard bunch of non-internet-routable RFC1918 / documentation range / "reserved for future use" address ranges as blackhole, prohibited or unreachable routes so that packets can't escape in an uncontrolled manner. It also means (in the case of pr...

Awesome - cheers!

Hello, May be missing something obvious here, but when issuing a certificate on 6.44, I can no longer import them to a device running the 6.42.12 long-term branch. I notice the changelog does show that some things have changed with certificates in 6.44, but nothing that looked like it would break ba...

Sorry for reviving an old thread, but again +1 for ACME / LetsEncrypt support. There is at least one router that's already supporting this approach, namely A&A's firebrick:

https://www.firebrick.co.uk/fb2900/

Hello, I have a CRS-317-1G-16S+ and have been trying out compatibility between various SFP+ modules. We've got a handful of Finisar's FTLX8574D3BCV, but I can only get them to function at 1Gbit by forcing autonegotiation off on both ends. With autonegotiation on, I get: name: s13 status: no-link aut...

You need to :put $userinput, not :put $read

If you have any kind of feedback channel to HPE, I think they'd appreciate to learn this, it simply cannot be an intended behaviour. At least one of the switches involved has a valid support contract, so I'll stuff it in as a support ticket tomorrow. Given previous experience with HPE, I shall not ...

Try adding the bridge w/o RSTP: Good call - that prevented the bridge pulling the switch over. Often the protective mechanism consists in shuting down a port if a BPDU (xSTP message) comes in through it when unexpected, i.e. if that port is deemed an edge one. What you describe (everything works un...

I'm going to prefix this with "may have missed something obvious" and "I might be a complete idiot" as this all feels way to weird to be real, but here goes (it's a bit wordy - apoligies)... I've recently had some strange occurrences with HP switches and MT APs, specifically the cAP Lite and the wAP...

Hello, Also seeing this on a wAP-2nD-r2 that was working just fine on 6.40.4, upgraded to 6.40.5 and now have this: 14:37:04 wireless,info 90:3A:E6:15:AE:C7@wlan: connected 14:37:09 wireless,info 90:3A:E6:15:AE:C7@wlan: disconnected, unicast key exchange timeout 14:40:11 wireless,info 90:3A:E6:15:AE...

Not at all scientific, but I've had IPSec running on the bench between an RB1100AHx2 and an RB3011UiAS-RM using the following IPSec proposal: auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=strongish pfs-group=modp4096 When traffic is passing with the RB3011 doing most of the encrypting, I se...

Regarding the PPPoE breakage between 6.33 and 6.33.1, setting the max-mtu and max-mru to "auto" fixed it for me...

Same issues with PPPoE client on CRS-1xx - can't test downgrading yet as need to go home to fix it

Hello, As mentioned in this post for v6.5 , it would appear SSH out from a v6.7 RouterBoard to an SSH host with "ChallengeResponseAuthentication yes" (i.e. most default installs of SSH on any Linux host) still fails - it just times out. RouterOS to RouterOS is fine, just not to other SSH servers wit...

masquerade is only shorter way to tell router what to do.

Many thanks for the pointer - all working now Had it in my head the two were discrete functions rather than one being a shortcut to the other...

Cheers,
Harry

Cheers - I'll give that a go

Thanks,
Harry

Well, the lack of responses here kind of mirrors my own attempts to get this to work: it would appear nigh on impossible to do what I've illustrated above. Is this so or am I missing something vital?

Cheers,
Harry

Hello, I have an RB750 running RouterOS 4.6 and I have a question regarding Masquerading a couple of networks... My current setup is as follows: http://photos.disgruntledgoat.com/static/mtk/001.png I have a PPPoE connection to my ISP with a public address as my end point (illustrated as 253.12.13.14...