Would you care to paste appropriate command to implement that workaround here? Thank you!The workaround is to add TCP MSS rule to your firewall rules
Would you care to paste appropriate command to implement that workaround here? Thank you!The workaround is to add TCP MSS rule to your firewall rules
As I already wrote, my VLAN-infested RBs are still on 6.40.5, so things might have changed. However, my setup is something like this:I'll appreciate much if someone can explain to me all that stuff...
/interface ethernet switch port
set 0 vlan-mode=secure
set 1 vlan-mode=secure
set 2 default-vlan-id=42 vlan-header=add-if-missing vlan-mode=secure
set 3 vlan-mode=secure
set 4 default-vlan-id=2 vlan-header=add-if-missing vlan-mode=secure
set 5 vlan-header=add-if-missing vlan-mode=fallback
/interface ethernet switch vlan
# .. I guess this is the old style of defining which ethernet port is member of which VLAN
add independent-learning=no ports=switch1-cpu,ether1,ether2,ether3,ether4 switch=switch1 vlan-id=42
add independent-learning=no ports=ether1,ether2,ether5,ether4 switch=switch1 vlan-id=3999
add independent-learning=no ports=switch1-cpu,ether1,ether2 switch=switch1 vlan-id=41
add independent-learning=no ports=switch1-cpu,ether1,ether2 switch=switch1 vlan-id=40
add independent-learning=no ports=switch1-cpu,ether1,ether2,ether5,ether4 switch=switch1 vlan-id=2
/interface vlan
add interface=bridge name=vlan-2 vlan-id=2
add interface=bridge name=vlan-40 vlan-id=40
add interface=bridge name=vlan-41 vlan-id=41
add interface=bridge name=vlan-42 vlan-id=42
/interface bridge port
add bridge=bridge interface=ether1
/ip address
add address=192.168.42.1/23 interface=vlan-42 network=192.168.42.0
add address=192.168.41.1/24 interface=vlan-41 network=192.168.41.0
add address=192.168.40.1/24 interface=vlan-40 network=192.168.40.0
add address=192.168.1.240/24 interface=vlan-2 network=192.168.1.0
adding tcp mss to my firewall doesn't work router os 6.41The problem is already fixed in 6.42rc.
The workaround is to add TCP MSS rule to your firewall rules
Neither works for me. Did anybody succeed to fix this with a firewall rule?adding tcp mss to my firewall doesn't work router os 6.41The problem is already fixed in 6.42rc.
The workaround is to add TCP MSS rule to your firewall rules
Witch will disable fastpath on your router yes!?The problem is already fixed in 6.42rc.
The workaround is to add TCP MSS rule to your firewall rules
It won't. TCP MSS has to be adjusted only in the first two packets of each session, and the fasttracking rule only applies on the following ones anyway (TCP state established is reached after the SYN,ACK has been processed).Which will disable fastpath on your router, yes!?
I wasn't talking about fast track this is for firewall state tracking but more optimisted.It won't. TCP MSS has to be adjusted only in the first two packets of each session, and the fasttracking rule only applies on the following ones anyway (TCP state established is reached after the SYN,ACK has been processed).Which will disable fastpath on your router, yes!?
If it's critical for you - just stay with 6.40 or earlierWitch will disable fastpath on your router yes!?
Am doing just that, was just stating the obvious.If it's critical for you - just stay with 6.40 or earlier
I have the same problem but not only SSTP affected, PPtP is not working too. Even more strange that if remote ip is from another network, it will work...After upgrading smoothly SSTP VPN is working fine but there is no route to internal LAN.
Until this upgrade everything was running OK, is there any issue or extra configuration to be done with SSTP interface?
As an update, seems that changing that it will break another sites.. so isn't a viable solution.Hello, same problem with some sites not accesible on all devices with 6.41.. changed tcp mss without any luck so.. please advice.
L.E: So as a quick fix, edit the ppp profile and modify 'Change TCP MSS' from default/yes to no. This should fix the issue.
do you have a vlan filtering ability and hw-offload in your bridge configurations? 'cause if no - yep, things are changed and, if my memory serves me, in 6.40.5 brigde had no vlan filtering ability yet and master-port functionality is still present there.my VLAN-infested RBs are still on 6.40.5, so things might have changed
I think, you should re-read my post more precisely:in your case, the problem of no management access is probably due to the fact that management computer, connecting to eth5, does not use VLAN-tagged packets and consequently gets tagged with VLAN ID 1 (PVID setting). You either need to configure your management computer to use VLANs or configure eth5 with PVID=110 (and make sure also that VLAN segement gets routed/NATed to internet if so desired).
/interface ethernet switch port
# ether5 port
set 3 default-vlan-id=110 vlan-header=always-strip vlan-mode=check
# switch1-cpu port
set 4 default-vlan-id=1 vlan-mode=check
Maybe because it is new for everybody so no one feels competent enough yet to advise in this high-profile topic? This was at least my reason to wait for someone more competent to answer.you're the only one person here who tried to help!
/interface bridge
add fast-forward=no name=bridge1 protocol-mode=none vlan-filtering=no pvid=1
/interface bridge port
add bridge=bridge1 interface=ether2-uplink pvid=1
add bridge=bridge1 interface=ether3 pvid=1
add bridge=bridge1 interface=ether4 pvid=300
add bridge=bridge1 interface=ether5 pvid=110
/interface vlan
add interface=bridge1 name=vlan110 vlan-id=110
/ip address
add address=192.168.110.211/24 interface=vlan110 network=192.168.110.0
/interface bridge vlan
add bridge=bridge1 vlan-ids=110 tagged=bridge1,ether2-uplink untagged=ether5
add bridge=bridge1 vlan-ids=200 tagged=ether2-uplink,ether3
add bridge=bridge1 vlan-ids=300 tagged=ether2-uplink,ether3 untagged=ether4
/interface bridge set bridge1 vlan-filtering=yes
Same thing here.I have similar (bad) experience with the new bridge and VLAN tagging. The first attempt to convert my initial multi-bridge setup to a single bridge with VLAN tags failed.
I reverted to my pre-6.41 configuration (separate bridge for each VLAN and switch configured for the VLANs and tagged/untagged ports) and have to try again some time.
Hello, same problem with some sites not accesible on all devices with 6.41.. changed tcp mss(iptables firewall) without any luck so.. please advice.
We have same problems with PPP server/router with http://fl.yantarenergosbyt.ru/ and https://www.verbojuridico.com.br/default.aspxSame problem with http://fl.yantarenergosbyt.ru/We are seeing a strange problem with 6.41 in the fact that it prevents one particular HTTPS website from being accessable. This is the case if either 6.41 is running on the PPP server/router or indeed if 6.41 is running on the client's Mikrotik router.
The website in question is https://safeseas.ie/ssi/login.jsp and we have replicated the problem on many iterations of 6.41 across multiple sites. In each case rolling back fixes the issue.
Feedback would be welcome
On 6.39.3 all good, on 6.41 and newer - cant open site.
I see this problem if MT set like pppoe-client. If internet from dhcp-client - site available.
please team MK new relese
Yes, now fixed in rc11.The problem is already fixed in 6.42rc.
The workaround is to add TCP MSS rule to your firewall rules
/ppp profile
set [ find default ] change-tcp-mss=no
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu out-interface=all-ppp protocol=tcp tcp-flags=syn
......................................I have the same experience. After the upgrade, no connection via ethernet or wifi works. Wifi is off. Winbox cannot show it. I asked another RB on the LAN which properly upgraded to show its neighbours, and the dead RB is listed with a MAC address of 00:00:00:00:00:00. The dead device is up in the air, been operating for a few years, and properly installed to protect it from rain and weather. It will not be fun to replace. It will not be fun to hit a reset button. Any ideas will be appreciated.
I upgraded my RB750Gr3 from 6.40.5 to 6.41, and now I cannot connect to it via wire or wireless. Did I miss anything here?
Thanks.
Please read this post and if it does not help, create a new topic and place here a link to it, I'll try to guide you.but, with this, my bridge is not working...
I have seen this once, but could not reproduce since. No idea what happened and why.Now I get errors like 'port received packet with own address as source address' and a packet storm. Network is down.
When you type the command to take the supout, begin the file name with flash/.Can you please explain, when Mikrotik will amend the CRS3xx releases, so that the supout.rif not gets written to volatile memory, but onto flash instead ?
+1 .. absolutely, and keep 6.40.x on bugfix for long timeCould we expect that 6.40.5 will become "bugfix" or 6.40.6 with fixes from 6.41?
6.40.5 is the last with "old-known-bridge-implementation" technology and not all want to upgrade to "new-better-but-not-too-familiarized" one.
+1001Could we expect that 6.40.5 will become "bugfix" or 6.40.6 with fixes from 6.41?
6.40.5 is the last with "old-known-bridge-implementation" technology and not all want to upgrade to "new-better-but-not-too-familiarized" one.
Could we expect that 6.40.5 will become "bugfix" or 6.40.6 with fixes from 6.41?
6.40.5 is the last with "old-known-bridge-implementation" technology and not all want to upgrade to "new-better-but-not-too-familiarized" one.
+1 .. absolutely, and keep 6.40.x on bugfix for long time
Quite agree. Or make all that stuff with new bridge-to-L2 behaviour and features more transparent and understandable. 'Cause before 6.41 you made master port and then went to Switch in winbox and did all the stuff for L2, including VLANs, there. And now the things are not as clear.+1001
It's invalid from 6.41, but earlier it was workingdistance can only be 0 for "directly connected" routes (the automatically generated routes that correspond to the address/net of an interface), all other routes including your default route have a distance of at least 1. So distance=0 is invalid.
What do you mean with "working"? In 6.40.5 I cannot add a static route with distance=0.It's invalid from 6.41, but earlier it was working
[admin@MikroTik] > /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-ALT-NAME FINGERPRINT
0 K L T wildcard.test.com *.test.com DNS:*.test.com 09133...
1 T AddTrustExternalCARoot AddTrust External CA Root 687fa...
2 L T COMODORSAAddTrustCA COMODO RSA Certification Authority 4f32d...
3 L T COMODORSADomainValidationSecureServerCA COMODO RSA Domain Validation Secure Server CA 02ab5...
[admin@MikroTik] > /ip service print detail
Flags: X - disabled, I - invalid
0 XI name="telnet" port=23 address=""
1 XI name="ftp" port=21 address=""
2 name="www" port=80 address=192.168.1.0/24
3 name="ssh" port=22 address=""
4 I name="www-ssl" port=443 address=192.168.1.0/24 certificate=wildcard.test.com
5 XI name="api" port=8728 address=""
6 name="winbox" port=8291 address=""
7 name="api-ssl" port=8729 address="" certificate=*C
Yep, that's exactly what happened. And that change could introduce some other bug, for exampleYou mean a DHCP client with default-route-distance=0 was adding a route with distance=0?
That must have been a bug that has been fixed...
What is that "other bug"? I still don't get why you would want to have a default route with distance=0Yep, that's exactly what happened. And that change could introduce some other bug, for exampleYou mean a DHCP client with default-route-distance=0 was adding a route with distance=0?
That must have been a bug that has been fixed...
For example, I had an initialization script for a class of routers that was initially generated two years ago from an export of a working hand configuration. The export process created a DHCP client with default-route-distance=0 specified (something I would not have specified by hand, but was present in the export). I went to use it yesterday, and it failed to import, because MikroTik made this fix. So, bug.What is that "other bug"? I still don't get why you would want to have a default route with distance=0Yep, that's exactly what happened. And that change could introduce some other bug, for exampleYou mean a DHCP client with default-route-distance=0 was adding a route with distance=0?
That must have been a bug that has been fixed...
It should probably just ignore the distance=0 in the input and use the default distance=1it failed to import, because MikroTik made this fix. So, bug.
Well, the "other bug" I thought of was "the remote clients no longer have a DHCP default-route" %)What is that "other bug"? I still don't get why you would want to have a default route with distance=0
Read the changes log before postinghi everybody
My opinion is too bad over version 6.41 , i didnt find master port.........
best regards
I cannot find that option. Can someone please give some hints?*) capsman - use "adaptive-noise-immunity" value from CAP local configuration;
/interface wireless cap set enabled=no
/interface wireless set adaptive-noise-immunity=ap-and-client-mode wlan2
/interface wireless set adaptive-noise-immunity=ap-and-client-mode wlan1
/interface wireless cap set enabled=yes