Community discussions

 
User avatar
docmarius
Forum Guru
Forum Guru
Posts: 1196
Joined: Sat Nov 06, 2010 12:04 pm
Location: Timisoara, Romania
Contact:

Re: v6.44beta [testing] is released!

Fri Oct 12, 2018 6:08 pm

Yes, you are right. It has nothing to do with ROS. As Sob said, it's probably a preparation for later actions. Sorry for the bump in.
But an actual PE release for Winbox could be a nice step :-)
Torturing CCR1009-7G-1C-1S+, RB450G, RB750GL, RB951G-2HnD, RB960PGS, RB260GSP, OmniTIK 5HnD and NetMetal 922UAGS-5HPacD + R11e-5HnD in my home network.
 
pakud
just joined
Posts: 3
Joined: Sat Oct 13, 2018 9:59 pm

Re: v6.44beta [testing] is released!

Sat Oct 13, 2018 10:07 pm

the recent betas [ eg 6.44beta20 ] allow for upgrade of the lte card's firmware in RBwAPR-2nD&R11e-LTE, yet it's not possible in the RBwAPR-2nD&R11e-LTE-US

do you plan for allowing lte firmware upgrade on the US version?

thanks!
 
raffav
Member Candidate
Member Candidate
Posts: 249
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.44beta [testing] is released!

Sat Oct 13, 2018 11:22 pm

Test on the current/stable channel
I was also trying to do that without success.
I think I'm running into a config bug in 6.44 Beta 20

I've upgraded my testing router and saw the L2TP/IPSec unsafe config notice. So I was playing around with configs to fix that.

Once the L2TP peer is initially added, any attempt to edit the peer config errors out with "Couldn't change IPSec Peer <::/0> - certificate chain is supported only in IKEv2 (6)"
This seems to affect both manually and dynamically added peers.

Any truly valid peer config commits successfully when initially configured, but any attempt to change them results in the same error.

Also, since Mikrotik is warning against L2TP/IPSec PSK, is there any plans to expand the L2TP setup in PPP to be more secure?
Sent from my XT1580 using Tapatalk

 
notToNew
Member Candidate
Member Candidate
Posts: 135
Joined: Fri Feb 19, 2016 3:15 pm

Re: v6.44beta [testing] is released!

Sun Oct 14, 2018 4:03 am

the recent betas [ eg 6.44beta20 ] allow for upgrade of the lte card's firmware in RBwAPR-2nD&R11e-LTE,
Is 008 still the current firmware?
--------------------------------------------------------------------------------------------
CCR1036-12G-4S, several 952Ui-5ac2nD, ...
 
pakud
just joined
Posts: 3
Joined: Sat Oct 13, 2018 9:59 pm

Re: v6.44beta [testing] is released!

Sun Oct 14, 2018 9:05 am

the recent betas [ eg 6.44beta20 ] allow for upgrade of the lte card's firmware in RBwAPR-2nD&R11e-LTE,
Is 008 still the current firmware?
after an upgrade on RBwAPR-2nD&R11e-LTE /interface lte info lte1 shows "MikroTik_CP_2.160.000_v008", while RBwAPR-2nD&R11e-LTE-US - MPSS: R11eL_v12.09.171931 APSS: R11eL_v02.14.173531 CUSTAPP

running /interface lte firmware-upgrade upgrade=y lte1 on the US device gives: failure: Device does not support this feature!
 
mkx
Forum Guru
Forum Guru
Posts: 1021
Joined: Thu Mar 03, 2016 10:23 pm

Re: v6.44beta [testing] is released!

Sun Oct 14, 2018 10:42 am

Change log for this beta clearly states that R11e firmware upgrade is available only for international version of devices .... can't you read?
BR,
Metod
 
pakud
just joined
Posts: 3
Joined: Sat Oct 13, 2018 9:59 pm

Re: v6.44beta [testing] is released!

Sun Oct 14, 2018 7:06 pm

Change log for this beta clearly states that R11e firmware upgrade is available only for international version of devices .... can't you read?
actually i can - that's why i stated my question: do you plan for allowing lte firmware upgrade on the US version?
 
mkx
Forum Guru
Forum Guru
Posts: 1021
Joined: Thu Mar 03, 2016 10:23 pm

Re: v6.44beta [testing] is released!

Sun Oct 14, 2018 10:16 pm

Change log for this beta clearly states that R11e firmware upgrade is available only for international version of devices .... can't you read?
actually i can - that's why i stated my question: do you plan for allowing lte firmware upgrade on the US version?
Sorry, didn't see the question in your previous post.
BR,
Metod
 
schrotn
just joined
Posts: 13
Joined: Sat Sep 13, 2014 8:23 am

Re: v6.44beta [testing] is released!

Mon Oct 15, 2018 6:52 am

I previously had 6.44 b(~6 or 8, can't recall) and it didn't warn about either l2tp/ipsec psk nor ipsec certificates.
I'm fairly certain it's a recent addition to the testing channel only.
Test on the current/stable channel
I was also trying to do that without success.

Sent from my XT1580 using Tapatalk
 
fredcom
just joined
Posts: 9
Joined: Thu Jan 18, 2018 7:55 pm

Re: v6.44beta [testing] is released!

Mon Oct 15, 2018 10:53 am

Hey guys,

I have a sort of offtopic question, but since we have the ability to upgrade the firmware now - where does one get the new firmware for R11e-LTE?
 
User avatar
juliokato
Member Candidate
Member Candidate
Posts: 223
Joined: Mon Oct 26, 2015 4:27 pm
Location: Brazil

Re: v6.44beta [testing] is released!

Mon Oct 15, 2018 2:46 pm

I apologize my grammatical errors, my english not so good, I am not a native speaker.
Wiki is maintained in English. I use Google translator. 8)
 
raffav
Member Candidate
Member Candidate
Posts: 249
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.44beta [testing] is released!

Mon Oct 15, 2018 3:44 pm

I previously had 6.44 b(~6 or 8, can't recall) and it didn't warn about either l2tp/ipsec psk nor ipsec certificates.
I'm fairly certain it's a recent addition to the testing channel only.
Test on the current/stable channel
I was also trying to do that without success.

Sent from my XT1580 using Tapatalk
On the 43rc was also get the sames errors
I sent a email to support they told me that I had to use the cli for that. maybe they still doesn't have fixed yet.

Sent from my XT1580 using Tapatalk

 
fredcom
just joined
Posts: 9
Joined: Thu Jan 18, 2018 7:55 pm

Re: v6.44beta [testing] is released!

Mon Oct 15, 2018 10:09 pm

Thanks for heads up. I think I will eventually end up with this new board, as it seems I've became addicted to Mikrotik tech :)

But anyway, no one has knowledge on where to get new firmware?
 
netispguy
newbie
Posts: 35
Joined: Sun Feb 25, 2018 4:29 am

Re: v6.44beta [testing] is released!

Tue Oct 16, 2018 12:12 am

I really hope that the new iPhone Xs/XsMax 5GHz AC problem is resolved before the 6.44 production release.

viewtopic.php?f=7&t=139608&sid=c8121250 ... cae5c96b71
 
andriys
Forum Guru
Forum Guru
Posts: 1051
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

Re: v6.44beta [testing] is released!

Tue Oct 16, 2018 11:00 am

I really hope that the new iPhone Xs/XsMax 5GHz AC problem is resolved before the 6.44 production release.

viewtopic.php?f=7&t=139608&sid=c8121250 ... cae5c96b71

Reading through the topic you've linked to makes me think it is an iPhone's problem, not Mikrotik's one.
 
netispguy
newbie
Posts: 35
Joined: Sun Feb 25, 2018 4:29 am

Re: v6.44beta [testing] is released!

Tue Oct 16, 2018 2:14 pm

I really hope that the new iPhone Xs/XsMax 5GHz AC problem is resolved before the 6.44 production release.

viewtopic.php?f=7&t=139608&sid=c8121250 ... cae5c96b71

Reading through the topic you've linked to makes me think it is an iPhone's problem, not Mikrotik's one.
Hmm... I respectfully disagree that reading the topic leads to your assumption; however, I am also willing to believe this is an Apple problem.

The problem is that we (and other reports) have confirmed that the new Apple Xs devices appear to be working without any problem across a broad spectrum of Wi-Fi ecosystems. This includes commercial environments (such as Ubiquiti and Cisco), consumer environments (such as NetGear, Linksys, Google, ASUS etc.) and whatever Comcast and Xfinity are using for their deployments. Maybe these platforms are having issues (although unnoticeable), but the problem we are seeing on the Mikrotik framework is extremely severe.

I personally went out and purchased an iPhone XsMax to see for myself. I travel a lot and move through a large number of wifi environments and can confirm that I saw the problem at our office in Silicon Valley (as reported by my users) and at my home (which is fully Mikrotik). I did NOT see any issue whatsoever last week connecting to wifi at SFO, for 6 hours connected to Gogo on a United flight to Boston, at a Marriott hotel or at a coffee shop. Once I walked into my Boston office (Mikrotik), I immediately saw the problem return...

If this is an Apple problem, it appears to be impacting our Mikrotik frameworks more than others...
 
kalamaja
just joined
Posts: 7
Joined: Wed May 23, 2018 3:13 pm

Re: v6.44beta [testing] is released!

Tue Oct 16, 2018 2:20 pm

I really hope that the new iPhone Xs/XsMax 5GHz AC problem is resolved before the 6.44 production release.

viewtopic.php?f=7&t=139608&sid=c8121250 ... cae5c96b71
Reading through the topic you've linked to makes me think it is an iPhone's problem, not Mikrotik's one.
From iOS 12.0.1 release notes:
Resolves an issue that could cause iPhone XS devices to rejoin a Wi-Fi network at 2.4GHz instead of 5GHz
 
netispguy
newbie
Posts: 35
Joined: Sun Feb 25, 2018 4:29 am

Re: v6.44beta [testing] is released!

Tue Oct 16, 2018 2:48 pm

I really hope that the new iPhone Xs/XsMax 5GHz AC problem is resolved before the 6.44 production release.

viewtopic.php?f=7&t=139608&sid=c8121250 ... cae5c96b71
Reading through the topic you've linked to makes me think it is an iPhone's problem, not Mikrotik's one.
From iOS 12.0.1 release notes:
Resolves an issue that could cause iPhone XS devices to rejoin a Wi-Fi network at 2.4GHz instead of 5GHz
12.0.1 does not resolve what we are seeing. I can confirm it did fix the issue you mentioned above when both 2.4GHz and 5GHz radios are broadcasting the same SSID, and was impacting all environments. The issue I am discussing makes these new iPhones almost totally dysfunctional within the Mikrotik framework using any 5GHz AC 80MHz XXXX channel width. If you configure your radio to 5GHz A/N 40MHz XX, the problem goes away. It's an "AC" issue...different problem than what was fixed in 12.0.1
 
kramer
just joined
Posts: 6
Joined: Mon Jun 18, 2018 1:21 am

Re: v6.44beta [testing] is released!

Wed Oct 17, 2018 6:57 pm

Hi,

In the beginning just to say I'm not IT pro when comes to Mikrotik. However on beta soft I did create ipv6 tunnel from HE - it working fine on my CCR 1009. I can ping outside ipv6 addr without problem.
But what I cannot ping Miktrotik ipv6 addres from LAN, same subnet, same VLAN. Maybe someone have similar issue ?

Brgds
D
 
pe1chl
Forum Guru
Forum Guru
Posts: 4867
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.44beta [testing] is released!

Wed Oct 17, 2018 8:37 pm

But what I cannot ping Miktrotik ipv6 addres from LAN, same subnet, same VLAN. Maybe someone have similar issue ?
Please do not use the release topic for other things than reporting issues with the release.
Make a new topic in the General or Beginners section describing your issue and include a /export of your configuration (no screenshots!).
 
kramer
just joined
Posts: 6
Joined: Mon Jun 18, 2018 1:21 am

Re: v6.44beta [testing] is released!

Wed Oct 17, 2018 10:25 pm

But what I cannot ping Miktrotik ipv6 addres from LAN, same subnet, same VLAN. Maybe someone have similar issue ?
Please do not use the release topic for other things than reporting issues with the release.
Make a new topic in the General or Beginners section describing your issue and include a /export of your configuration (no screenshots!).
sorry... I fixed this by using Router/48: from HE instead /64:
 
User avatar
emils
MikroTik Support
MikroTik Support
Topic Author
Posts: 278
Joined: Thu Dec 11, 2014 8:53 am

Re: v6.44beta [testing] is released!

Mon Oct 29, 2018 11:31 am

Version 6.44beta28 has been released.

Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

What's new in 6.44beta28 (2018-Oct-29 07:58):

MAJOR CHANGES IN v6.44:
----------------------
!) cloud - added command "/system backup cloud" for backup storing on cloud (CLI only);
!) upgrade - release channels renamed - "bugfix" to "long-term", "current" to "stable" and "release candidate" to "testing";
!) upgrade - "testing" release channel now can contain "beta" together with "release-candidate" versions;
----------------------

Changes in this release:

!) radius - initial implementation of RadSec (Radius communication over TLS);
*) bridge - added option to monitor fast-forward status;
*) bridge - disable fast-forward when using SlowPath features;
*) bridge - fixed DHCP Option 82 parsing when using DHCP Snooping;
*) certificate - fixed time zone adjustment for SCEP requests;
*) crs328 - fixed SFP+ interface linking on CRS328-24P-4S+RM (introduced in v6.44beta17);
*) crs328 - fixed SFP ports not reporting auto-negotiation status;
*) crs328 - improved link status update on disabled SFP and SFP+ interfaces;
*) defconf - automatically accept default configuration if reset done by holding button;
*) defconf - fixed configuration not generating properly on upgrade;
*) ethernet - fixed linking issues on wAP ac, RB750Gr2 and Metal 52 ac (introduced in v6.43rc52);
*) fetch - fixed fetching with "as-value" creating an empty file (introduced in v6.44beta20);
*) fetch - fixed "without-paging" option;
*) health - fixed bad voltage readings on RB493G;
*) ike2 - added option to specify certificate chain;
*) ike2 - send split networks over DHCP (option 249) to Windows initiators if DHCP Inform is received;
*) ike2 - show weak pre-shared-key warning;
*) ipsec - added basic pre-shared-key strength checks;
*) ipsec - fixed hw-aead (H) flag presence under Installed SAs on startup;
*) ipsec - improved stability when uninstalling multiple SAs at once;
*) ipsec - made peers autosort themselves based on reachability status;
*) ipsec - properly update warnings under peer menu;
*) lte - added support for JioFi JMR1040 modem;
*) lte - fixed IPv6 activation for R11e-LTE-US modems;
*) lte - fixed LTE interface not working properly after reboot on RBSXTLTE3-7;
*) lte - fixed missing running (R) flag for Jaton LTE modems;
*) ospf - improved stability while handling type-5 LSAs;
*) port - improved "remote-serial" TCP performance in RAW mode;
*) rb3011 - implemented multiple engine IPsec hardware acceleration support;
*) rbm33g - improved stability when used with some USB devices;
*) routerboard - require at least 10 second interval between "reformat-hold-button" and "max-reformat-hold-button";
*) routerboard - show "boot-os" and "force-backup-booter" option only on devices that have such feature;
*) snmp - added "dot1qPortVlanTable" and "dot1dBasePortTable" OIDs;
*) ssh - added error log message when key exchange fails;
*) ssh - fixed non-interactive shell not returning all output (introduced in v6.44);
*) tr069-client - fixed HTTP cookie getting duplicated with the same key;
*) tunnel - made "ipsec-secret" parameter sensitive;
*) upgrade - made security package depend on DHCP package;
*) wireless - removed G/N support for 2484MHz in "japan" regulatory domain;
*) w60g - fixed scan in bridge mode;
*) w60g - improved PtMP performance;
*) w60g - renamed "frequency-list" to "scan-list";
*) w60g - renamed disconnection message when license level did not allow more connected clients;
*) w60g - added align mode "/interface w60g align" (CLI only);

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as expected or after crash.
 
User avatar
eworm
Member Candidate
Member Candidate
Posts: 184
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v6.44beta [testing] is released!

Mon Oct 29, 2018 1:30 pm

Starting with 6.44beta28 the security package requires the dhcp package to be installed? I think that is something to be noted in changelog. What's the reason?
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
User avatar
emils
MikroTik Support
MikroTik Support
Topic Author
Posts: 278
Joined: Thu Dec 11, 2014 8:53 am

Re: v6.44beta [testing] is released!

Mon Oct 29, 2018 2:11 pm

Nice catch. It is because of the new IKEv2 feature which works with DHCP. I will update the changelog.
 
huntah
Member Candidate
Member Candidate
Posts: 259
Joined: Tue Sep 09, 2008 3:24 pm

Re: v6.44beta [testing] is released!

Mon Oct 29, 2018 4:33 pm

ike2 - send split networks over DHCP (option 249) to Windows initiators if DHCP Inform is received;
Any Examples?

If I am not mistanken this means that split tunneling will now work!
 
User avatar
emils
MikroTik Support
MikroTik Support
Topic Author
Posts: 278
Joined: Thu Dec 11, 2014 8:53 am

Re: v6.44beta [testing] is released!

Mon Oct 29, 2018 4:48 pm

There is no special configuration needed. RouterOS will automatically convert split-network parameter to use with DHCP option.
 
huntah
Member Candidate
Member Candidate
Posts: 259
Joined: Tue Sep 09, 2008 3:24 pm

Re: v6.44beta [testing] is released!

Mon Oct 29, 2018 8:25 pm

I just installed beta28 on brand new HapLite (default Settings).
added Certificates and ipsec ike2 RSA setup:
/certificate
add common-name=TESTCA name=TESTCA days-valid=3650
sign TESTCA ca-crl-host=192.168.3.124
add common-name=192.168.3.124 subject-alt-name=DNS:192.168.3.124 key-usage=tls-server name=TestVPN days-valid=3600
sign TestVPN ca=TESTCA
add common-name=hunter key-usage=tls-client name=hunter days-valid=3600
sign hunter ca=TESTCA

/ip pool
add name=VPN-Pool ranges=192.168.222.100-192.168.222.150

/ip ipsec mode-config
add address-pool=VPN-Pool address-prefix-length=32 name=RW-cfg split-include=192.168.88.0/24
/ip ipsec peer profile
set [ find default=yes ] enc-algorithm=aes-128
/ip ipsec policy group
add name=RoadWarrior
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-256-cbc,aes-128-cbc
add auth-algorithms=sha256,sha1 enc-algorithms=aes-256-cbc,aes-128-cbc name=proposal1 pfs-group=none
/ip ipsec peer
add auth-method=rsa-signature certificate=TestVPN exchange-mode=ike2 generate-policy=port-strict mode-config=RW-cfg passive=yes policy-template-group=RoadWarrior
/ip ipsec policy
add comment=IKEv2 dst-address=192.168.222.0/24 group=RoadWarrior proposal=proposal1 src-address=0.0.0.0/0 template=yes
Win10 client connects OK but split-include does not work. The Win10 1803 client does not get routes..
Also tried address-prefix-length=24.. still noting.

In log I can see mikrotik detect Windows Machine but split-include is not pushed to the client..
I have attached the ipsec debug log. Connect and disconnect from win10 test machine

@emils: Am I doing something wrong? Please advise.. thx
You do not have the required permissions to view the files attached to this post.
Last edited by huntah on Mon Oct 29, 2018 11:06 pm, edited 1 time in total.
 
sindy
Forum Guru
Forum Guru
Posts: 2581
Joined: Mon Dec 04, 2017 9:19 pm

Re: v6.44beta [testing] is released!

Mon Oct 29, 2018 9:32 pm

I'm not Emils, however can you try to run packet sniffer before clicking "connect" on the Windows machine with the following settings (assuming that etherX is the name of the interface through which it connects)?

/tool sniffer set only-headers=no memory-limit=100 memory-scroll=yes file-name="" file-limit=8000 streaming-enabled=no filter-stream=no filter-interface=etherX filter-mac-address="" filter-mac-protocol="" filter-ip-address="" filter-ipv6-address="" filter-ip-protocol=udp filter-port=53 filter-cpu="" filter-direction=any filter-operator-between-entries=and

Then, do the following:

/tool sniffer start
/tool sniffer packet print interval=1s


And then start the client on Windows.

If you see a packet in the list, chances are high that it is the DHCPINFORM which is needed for the feature to work; however, another necessary condition may be to have more than one split-subnet, as one destination subnet is normally a mandatory part of the mode-config so there is no point in sending it using DHCP.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
huntah
Member Candidate
Member Candidate
Posts: 259
Joined: Tue Sep 09, 2008 3:24 pm

Re: v6.44beta [testing] is released!

Mon Oct 29, 2018 11:03 pm

I tried with ether1 (my wan on test router)
but nothing is catcing in the sniffer when I connect or disconnect.
I dont really understand what DNS (udp/53) has to do with DHCP (udp/67-68)
If I change it to correct ports I get:
0   14.46 ether1                         192.168.222.146:68 (bootpc)                                 255.255.255.255:67 (bootps)                                 udp           342   0 no 
 1  19.212 ether1                         192.168.222.146:68 (bootpc)                                 255.255.255.255:67 (bootps)                                 udp           342   0 no 
 2   24.21 ether1                         192.168.222.146:68 (bootpc)                                 255.255.255.255:67 (bootps)                                 udp           342   0 no 
I have also tried multiple subnets in split-include.. With no luck.

If I set user remote gateway on Win10 Client VPN connecton works.. But for all networks (split-include set 0.0.0.0/0, havent tried with includes...).
 
sindy
Forum Guru
Forum Guru
Posts: 2581
Joined: Mon Dec 04, 2017 9:19 pm

Re: v6.44beta [testing] is released!

Mon Oct 29, 2018 11:16 pm

I dont really understand what DNS (udp/53) has to do with DHCP (udp/67-68)
I'm a bit sleepy so I've mixed them up, that's all. Good you've found out yourself.

Now if 192.168.222.146 is the address from the /ip pool assigned to /ip ipsec mode-config, so it is the one assigned to the Win PC using mode-config, you can double-check that it is a DHCPINFORM packet by sniffing into file and opening the file using Wireshark (update: just checked it myself on a W2012 system connected to 6.43.2, so yes, it is a DHCPINFORM)

So until Emils comes tomorrow, I'd try to attach a DHCP server to ether1, and that's my last idea given that he's already stated that the ipsec plant itself takes care about converting the split-include data into Option 249.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
huntah
Member Candidate
Member Candidate
Posts: 259
Joined: Tue Sep 09, 2008 3:24 pm

Re: v6.44beta [testing] is released!

Mon Oct 29, 2018 11:51 pm

I dont get any DHCPInform..
Attached is the wireshark and then connect to VPN..
I cant put DHCP Server on WAN port ...

guess we will wait for Mktik guys to wake up :)
Night all and thnx for tips and help sindy!
You do not have the required permissions to view the files attached to this post.
 
sindy
Forum Guru
Forum Guru
Posts: 2581
Joined: Mon Dec 04, 2017 9:19 pm

Re: v6.44beta [testing] is released!

Tue Oct 30, 2018 12:02 am

You most likely do get the DHCPINFORM :-) But to see it, you cannot capture on the PC as you did, you have to use /tool sniffer on Mikrotik and set file-name=something.pcap. When you capture on the PC, the DHCPINFORM is only seen there encrypted in the ESP so you cannot recognize it. The Mikrotik sniffer shows you both the IPsec transport packets (ESP in this case) and the plaintext packets extracted from them. This is not true in the opposite direction, i.e. you cannot see plaintext packets before they got encrypted on the same interface through which they are sent out encrypted.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
huntah
Member Candidate
Member Candidate
Posts: 259
Joined: Tue Sep 09, 2008 3:24 pm

Re: v6.44beta [testing] is released!

Tue Oct 30, 2018 12:45 am

OK my bad :)

Here is the Wireshark capture from Mikrotik..
There are DHCP Inform messages but I am not able to interpret them :/
You do not have the required permissions to view the files attached to this post.
 
User avatar
emils
MikroTik Support
MikroTik Support
Topic Author
Posts: 278
Joined: Thu Dec 11, 2014 8:53 am

Re: v6.44beta [testing] is released!

Tue Oct 30, 2018 9:04 am

That is interesting. Are there really no other logs in ipsec topic after the IPsec-SA has been established? From what I can tell, DHCP inform is received on the router, but IPsec does not see the packet. What other configuration do you have on the router? Is there a DHCP server or client configured? Do you see any logs in dhcp topic when establishing the tunnel?
 
huntah
Member Candidate
Member Candidate
Posts: 259
Joined: Tue Sep 09, 2008 3:24 pm

Re: v6.44beta [testing] is released!

Tue Oct 30, 2018 9:46 am

I have default configuration (eth1 -> DHCLient to my private network)
All drop rules disabled
DHCPServer on Bridge (Default with IP pool 192.168.88.0)
VPN Pool is 192.168.222.0/24
I have attached the full config export compact
You do not have the required permissions to view the files attached to this post.
 
User avatar
emils
MikroTik Support
MikroTik Support
Topic Author
Posts: 278
Joined: Thu Dec 11, 2014 8:53 am

Re: v6.44beta [testing] is released!

Tue Oct 30, 2018 10:39 am

Weird, it works for me with exact your configuration and 1803 (Pro). Did you change any of the advanced ipv4 configuration on Windows side except for disabling EAP authentication? Note that it might take a few seconds for routes to be installed. How are you checking the route presence? Can you do 'route print -4' in cmd.exe? If that does not yield any results, please enable IPsec debug logs (topics=ipsec) and generate a supout.rif file after a few seconds when connection is established and send it to support@mikrotik.com.
 
huntah
Member Candidate
Member Candidate
Posts: 259
Joined: Tue Sep 09, 2008 3:24 pm

Re: v6.44beta [testing] is released!

Tue Oct 30, 2018 11:24 am

I check exactly like that..
but there arent any routes from split-include..
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.3.1    192.168.3.122     55
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
      192.168.3.0    255.255.255.0         On-link     192.168.3.122    311
    192.168.3.122  255.255.255.255         On-link     192.168.3.122    311
    192.168.3.124  255.255.255.255         On-link     192.168.3.122     56
    192.168.3.255  255.255.255.255         On-link     192.168.3.122    311
    192.168.222.0    255.255.255.0         On-link   192.168.222.148     46
  192.168.222.148  255.255.255.255         On-link   192.168.222.148    301
  192.168.222.255  255.255.255.255         On-link   192.168.222.148    301
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link     192.168.3.122    311
        224.0.0.0        240.0.0.0         On-link   192.168.222.148    301
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link     192.168.3.122    311
  255.255.255.255  255.255.255.255         On-link   192.168.222.148    301
===========================================================================
Suppout.rif sent to support..
If anyone else can try it would be super..
Maybe just my Win10 machine wont work as it should :)
I will test in the eventing with another..
 
msatter
Forum Veteran
Forum Veteran
Posts: 965
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: v6.44beta [testing] is released!

Tue Oct 30, 2018 1:16 pm

Why can't device-specific stuff like MAC-addresses simply be removed from the backup files?
Because it is whole system backup.
Proposal: choice, to omit not on backup but on restore. So you will have allways a full backup and can select on restore if certain values should not be restored.

Workings could be, enter the password if needed, that you can selected direct restore or making a selection containing options, which by omitting them not lead to bricking the device.

After deselecting data not to be restored a new backup file is written (with a different name), not containing the omitted data. This file is used for the restore and deleted after restoring, so one time usage.

The original full backup file will be untouched.
RB760iGS (hEX S) with the SFP being cooled.
Running:
RouterOS 6.44Beta40 / Winbox 3.18 / MikroTik APP 1.0.13
Cooling a SFP module: viewtopic.php?f=3&t=132258&p=671105#p671105
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8142
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.44beta [testing] is released!

Tue Oct 30, 2018 1:48 pm

Proposal: choice, to omit not on backup but on restore. So you will have allways a full backup and can select on restore if certain values should not be restored.
Let's imagine the internals of this restoration process. There's a database table with the list of interfaces, their parameters, their MAC addresses, etc. Now you restore it from backup leaving MAC address fields empty (?). So there's no connection between entries in the table and real interfaces. Configuration is in inconsistent state.

Don't think about backup like about an /export file. It's a bit different and more low-level thing.
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
5nik
Frequent Visitor
Frequent Visitor
Posts: 71
Joined: Thu Dec 08, 2011 3:15 am
Location: Czech Republic

Re: v6.44beta [testing] is released!

Tue Oct 30, 2018 1:49 pm

*) ike2 - send split networks over DHCP (option 249) to Windows initiators if DHCP Inform is received;
It will be greate to add this feature for PPP tunels too (SSTP, L2TP). Now I'm using forwarding DHCP Info packets to external DHCP server for DHCP option 249 (and another DHCP options for Windows clients).
Generally, I apologise for my weak english.
 
msatter
Forum Veteran
Forum Veteran
Posts: 965
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: v6.44beta [testing] is released!

Tue Oct 30, 2018 5:36 pm

Proposal: choice, to omit not on backup but on restore. So you will have allways a full backup and can select on restore if certain values should not be restored.
Let's imagine the internals of this restoration process. There's a database table with the list of interfaces, their parameters, their MAC addresses, etc. Now you restore it from backup leaving MAC address fields empty (?). So there's no connection between entries in the table and real interfaces. Configuration is in inconsistent state.

Don't think about backup like about an /export file. It's a bit different and more low-level thing.
Then maybe a RSC script that does manual work after a restore. I can Reset MAC on a interface so I get the MAC of the restored to device and not the MAC from the backup.

Changing the tables that use MAC is something you always have to do when use the hard MAC's of a different device.
RB760iGS (hEX S) with the SFP being cooled.
Running:
RouterOS 6.44Beta40 / Winbox 3.18 / MikroTik APP 1.0.13
Cooling a SFP module: viewtopic.php?f=3&t=132258&p=671105#p671105
 
huntah
Member Candidate
Member Candidate
Posts: 259
Joined: Tue Sep 09, 2008 3:24 pm

Re: v6.44beta [testing] is released!

Tue Oct 30, 2018 7:19 pm

HI,
ike2 - send split networks over DHCP (option 249) to Windows initiators if DHCP Inform is received;
just got word back from support. They have found the problem with split-include and it will be fixes in next beta..
Will test then again and post back the results!
 
ksteink
just joined
Posts: 23
Joined: Thu Mar 31, 2016 6:54 pm

Re: v6.44beta [testing] is released!

Tue Oct 30, 2018 7:22 pm

I want to see HW Off-load enabled in all bridge interfaces, not just one. Specially knowing that you need 1 Bridge per VLAN having this limitation is a killer as I will limit the traffic throughput without unable to get wired speed only in just 1 VLAN. Really?? Seriously??
 
User avatar
xvo
Member
Member
Posts: 321
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

Re: v6.44beta [testing] is released!

Tue Oct 30, 2018 7:36 pm

I want to see HW Off-load enabled in all bridge interfaces, not just one. Specially knowing that you need 1 Bridge per VLAN having this limitation is a killer as I will limit the traffic throughput without unable to get wired speed only in just 1 VLAN. Really?? Seriously??
After implementing vlan-aware bridges with hw-offload you no longer need 1 bridge per vlan.
 
pe1chl
Forum Guru
Forum Guru
Posts: 4867
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.44beta [testing] is released!

Tue Oct 30, 2018 8:15 pm

After implementing vlan-aware bridges with hw-offload you no longer need 1 bridge per vlan.
But with VLAN-aware bridges you have no hw-offload at all!
 
User avatar
xvo
Member
Member
Posts: 321
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

Re: v6.44beta [testing] is released!

Tue Oct 30, 2018 8:51 pm

After implementing vlan-aware bridges with hw-offload you no longer need 1 bridge per vlan.
But with VLAN-aware bridges you have no hw-offload at all!
The config mentioned above - with multiple bridges - was always purely software, and it was the only way for devices without switch chip.
No point to think of it in any other way.

But now, devices without switch chip can do it in much easier way.
Some switches can even do it both easy and in hardware.
And all others - still can do it in the switch menu, just like before.

Anyway, all this is completely unrelated to this ROS version.
 
dgrififth
just joined
Posts: 7
Joined: Sat Oct 15, 2016 10:35 am

Re: v6.44beta [testing] is released!

Wed Oct 31, 2018 1:08 am

*) ethernet - fixed linking issues on wAP ac, RB750Gr2 and Metal 52 ac (introduced in v6.43rc52);

So what was the bug here? I have a bunch of RB750Gr2 units on 6.43.2 that sometimes lose traffic on ethernet ports until the port is cycled on/off. Link remains up, and it *appears* that data is sent out the port (although maybe it is just presented to the port hardware by ROS and the hardware fails to send it), just nothing comes back in.

Disable/enable the link, all works again for 5-15 minutes. Turning on "Proxy-arp" for that ethernet interface appears to fix it or at least make it work for hours instead of minutes, although there is no reason to have proxy-arp.
 
pe1chl
Forum Guru
Forum Guru
Posts: 4867
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.44beta [testing] is released!

Wed Oct 31, 2018 11:20 am

Turning on "Proxy-arp" for that ethernet interface appears to fix it or at least make it work for hours instead of minutes, although there is no reason to have proxy-arp.
That depends. It can be a bug in your client device too. E.g. Ubiquiti access points sometimes lose the default route (or it becomes ineffective) and then you need tricks
like proxy-arp or SNAT to still access the management interface of the device from the network (while it continues to bridge traffic between the routers).
Reboot of the Ubiquiti fixes that, for a few weeks or months. Then it randomly returns.
 
dgrififth
just joined
Posts: 7
Joined: Sat Oct 15, 2016 10:35 am

Re: v6.44beta [testing] is released!

Wed Oct 31, 2018 11:58 am

It can be a bug in your client device too.
Yeah I was hoping that proxy arp would have a slightly different processing path, and it appears to work. It's a WinCE end device (that is, no routing, just a single IP address) that appeared to work ok with 6.39 across 15 or so units, so I'll probably revert to that and see if it makes a difference. But I've been trawling the changelogs looking for recent ROS ethernet changes, and this is the first one I've come across.
 
pe1chl
Forum Guru
Forum Guru
Posts: 4867
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.44beta [testing] is released!

Wed Oct 31, 2018 2:12 pm

You could check the ARP table of the client to see if it has any strange entries (other IP addresses than the router, with the router's MAC address).
If so you need to debug the client.
I would not know a legitimate reason why proxy-arp would work and normal arp would not, when the client is correctly configured.
(correct subnet on the LAN interface and a default route via the router's IP address)

Who is online

Users browsing this forum: No registered users and 5 guests