Community discussions

MikroTik App
 
MikeKulls
Member Candidate
Member Candidate
Topic Author
Posts: 130
Joined: Thu Dec 22, 2016 4:31 am

When answering questions

Thu Jun 23, 2022 10:45 am

Hi All,

Could I please make a suggestion? I've been trying to find an answer to a problem for several days and the number of posts I've come across with vague answers is really frustrating, eg
- "once I applied the fix mentioned in post xyz then it solved my problem", but post xyz lists about 10 possible fixes
- "I got this solved by changing the MSS." Where do I change it????
- "just decrease the MTU a bit" How much and where???
etc etc

I got to thinking with Mikrotik it's so easy to give a very direct answer
1) Start winbox
2) Click "New Terminal" on menu down the left hand side
3) type /export
4) Copy/Paste the relevant parts of the config into the post, making sure to remove any possibly sensitive info
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11982
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: When answering questions

Thu Jun 23, 2022 11:22 am

And?
 
MikeKulls
Member Candidate
Member Candidate
Topic Author
Posts: 130
Joined: Thu Dec 22, 2016 4:31 am

Re: When answering questions

Thu Jun 23, 2022 3:15 pm

And?
????
 
User avatar
StubArea51
Trainer
Trainer
Posts: 1739
Joined: Fri Aug 10, 2012 6:46 am
Location: stubarea51.net
Contact:

Re: When answering questions

Thu Jun 23, 2022 4:41 pm

User forums have always varied widely in content and quality since the early days of the Internet. We should always strive to improve but the variance will always be there.

Your thought process is a little hard to follow though as the first part of your post relates to the specificity of answers given while the second part seems to be related to asking for information in a structured way - neither are bad things but it came across a little disjointed.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: When answering questions

Thu Jun 23, 2022 4:53 pm

What does MTU and MSS have to do with answering questions?
I could think of TCP problems but the post seems to be forum oriented.
The forum doesn't have currently any MTU or MSS problems.
Open another topic describing your issue with as much details as possible, describe the network topology and attach a redacted config from all the devices implicated if required.
Cheers!
 
User avatar
Buckeye
Forum Veteran
Forum Veteran
Posts: 890
Joined: Tue Sep 11, 2018 2:03 am
Location: Ohio, USA

Re: When answering questions

Fri Jun 24, 2022 3:11 am

This topic reminds me of a story about Paul DIrac.
After he presented a lecture at a conference, one colleague raised his hand and said: "I don't understand the equation on the top-right-hand corner of the blackboard". After a long silence, the moderator asked Dirac if he wanted to answer the question, to which Dirac replied: "That was not a question, it was a comment."
 
MikeKulls
Member Candidate
Member Candidate
Topic Author
Posts: 130
Joined: Thu Dec 22, 2016 4:31 am

Re: When answering questions

Fri Jun 24, 2022 10:56 am

Thanks everyone for the replies. I didn't expect everyone to like my post, I was a bit frustrated when I wrote it.
User forums have always varied widely in content and quality since the early days of the Internet. We should always strive to improve but the variance will always be there.

Your thought process is a little hard to follow though as the first part of your post relates to the specificity of answers given while the second part seems to be related to asking for information in a structured way - neither are bad things but it came across a little disjointed.
In both cases I was talking about answering posts. What I'm saying is that posting the exact config that you used to solve a problem answers a lot of questions that might otherwise be left open to the reader to find out. I guess it applies equally to asking questions but I was specifically talking about answering them. For example, here's 2 ways to answer the same question

"Change mss to 1328"

vs

"Here's the config I used to solve the problem
/ip firewall mangle
add action=change-mss chain=forward new-mss=1328 passthrough=yes protocol=tcp tcp-flags=syn"
 
pe1chl
Forum Guru
Forum Guru
Posts: 10197
Joined: Mon Jun 08, 2015 12:09 pm

Re: When answering questions

Fri Jun 24, 2022 11:18 am

You should understand that questions on the forum are not answered by a computer running some knowledge base and AI system to parse your questions, but by actual people typing them at their keyboard.
When the same question comes up again and again, you cannot expect a complete course in RouterOS administration as a response every time.
When you get a short answer, you could try "search" on that again, to see if it has been in another forum topic where some more explanation is given, or search it in the RouterOS documentation at https://help.mikrotik.com/docs/ or the old one at http://wiki.mikrotik.com/wiki/Main_Page

Unfortunately the search systems of both the forum and the documentation really suck. It would help a lot when they were even a little more intelligent.
 
holvoetn
Forum Guru
Forum Guru
Posts: 5413
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

Re: When answering questions

Fri Jun 24, 2022 5:58 pm

Use Google magic

Search
<search terms> site:forum.mikrotik.com
Or alike.

Works pretty well.
 
User avatar
StubArea51
Trainer
Trainer
Posts: 1739
Joined: Fri Aug 10, 2012 6:46 am
Location: stubarea51.net
Contact:

Re: When answering questions

Fri Jun 24, 2022 6:58 pm

Use Google magic

Search
<search terms> site:forum.mikrotik.com
Or alike.

Works pretty well.
Yup, that's exactly what I do - I use this every day.
 
User avatar
Buckeye
Forum Veteran
Forum Veteran
Posts: 890
Joined: Tue Sep 11, 2018 2:03 am
Location: Ohio, USA

Re: When answering questions

Fri Jun 24, 2022 11:38 pm

For example, here's 2 ways to answer the same question

"Change mss to 1328"

vs

"Here's the config I used to solve the problem
/ip firewall mangle
add action=change-mss chain=forward new-mss=1328 passthrough=yes protocol=tcp tcp-flags=syn"
Several things:
Remember that this is a forum of volunteer users that are not getting paid to provide answers. And providing the second answer takes significantly longer than providing the first.
I also think it depends a lot on the personality of the person answering the question, and whether the question has been answered many times in the past.

If the person answering is coming from a "teach a man to fish" point of view instead of "give a man a fish", it is less likely to be a direct answer to the specific question, because a specific answer is not very useful to learning, or to the next person asking the same question. A direct answer isn't helpful to learning for at least two reasons:
  • The answer by itself gives no indication of how it was determined to be the solution, or how it solves the problem, perhaps even giving cases where the solution won't apply.
  • The person receiving the answer puts no effort into solving the problem, and without effort, most people won't remember. That's why "practice problems" are assigned for homework.
Then there is also the issue of "type 1" thinking that can lead to confirmation bias. See this for Derek Muller's (Veritasium) view.

In the specific example you gave, consider what happens if there is a link between you and some site that has an mtu below 1368 (and therefore needs an mss < 1328). Also assume that the remote end is clamping mss to 1200. The rule you provided (assuming I understand it), will unconditionally change (increase in this case) the mss on the syn-ack coming back from the remote site, so the local host establishing the tcp connection will think it is ok to send tcp packets with size 1368 (mss 1328) even though it should have only sent packets with mss of 1200 (1240 with ip and tcp headers).

So in my opinion, neither of the above answers is "great", but if I had to choose, I think the first is perhaps better (but it should have been "clamp mss to 1328" instead of "change mss to 1328") just because it will force the "student" to do some further investigation, and when they do that investigation, they would be more likely to find out why mss makes a difference, and some better options to use.

I prefer to provide links to other material that covers the subject than to just provide a "raw" answer. For example, a link to something that explains why I think the problem is related to mss, as well as a link to a possible solution, and also to reference material. Then the answer can be referred to in the future for similar questions.

For example, for the (poorly stated) problem in this thread. Perhaps there should be a thread with the title "When Asking Questions"
TCP MSS Clamping – What Is It and Why Do We Need It?
PMTU and MSS Discovery Issues Resolved with MikroTik
MikroTik Mangle Documentation
Last edited by Buckeye on Mon Aug 22, 2022 10:03 pm, edited 1 time in total.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10197
Joined: Mon Jun 08, 2015 12:09 pm

Re: When answering questions

Sat Jun 25, 2022 12:52 am

In the specific example you gave, consider what happens if there is a link between you and some site that has an mtu below 1368 (and therefore needs an mss < 1328). Also assume that the remote end is clamping mss to 1200. The rule you provided (assuming I understand it), will unconditionally change (increase in this case) the mss on the syn-ack coming back from the remote site, so the local host establishing the tcp connection will think it is ok to send tcp packets with size 1368 (mss 1328) even though it should have only sent packets with mss of 1200 (1240 with ip and tcp headers).
I think any implementation of router code that has a "change MSS" feature actually implements a "clamp" function. That is, it never increases the MSS, it always clamps it to the specified value, decreasing it when it is higher but never increasing it.
This has become so obvious that some people refer to it as "set MSS" instead of "clamp MSS".

Fun fact: I think I actually invented MSS clamping. Unfortunately I never patented it, else I could be rich :-)
I implemented this as one of my many patches to the KA9Q TCP/IP package back in august 1995. Cisco introduced it in IOS in 2001.
When looking at the use of TCP/IP on amateur packet radio, which operated over 1200 bps links and you could easily watch a trace of a session on your screen in real time, it occurred to me that many packets of the default MTU of 256 on the network were fragmented because a layer 2.5 protocol called NET/ROM had an MTU of 236. Similar situation as we today still encounter with tunnels. As fragmenting the packets meant additional headers, which already were such a large portion of the small MTU, I figured that it would be more efficient when I could convince the endpoints to send smaller packets in the first place. Then I thought of this MSS clamping trick and implemented it in the code. It is in the change history for NET version PE1CHL.950819.
At that time, it was difficult to work together on a single software package as there were no convenient sites to host source versioning, and my patched version became a fork long before that. This change never made it into the more commonly used JNOS version.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11982
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: When answering questions

Sat Jun 25, 2022 1:49 am

Thanks everyone for the replies. I didn't expect everyone to like my post, I was a bit frustrated when I wrote it.

In both cases I was talking about answering posts. What I'm saying is that posting the exact config that you used to solve a problem answers a lot of questions that might otherwise be left open to the reader to find out. I guess it applies equally to asking questions but I was specifically talking about answering them.
Very often, if not always, users are not even able to formulate a question, I do not say correct, but that at least specify what they are talking about,
because as usual, therefore always, they assume that you already know what routerboard they have, what routeros they use,
and, it is not known how, you also know how they are configured, just from a two-line question...

And much more often, instead of explaining what they want to achieve in the end, specifying what to start with, they ask some intermediate question
(XY problem: https://xyproblem.info ) which doesn't actually lead to the solution but just wastes everyone's time,
and only after several questions do we discover what the user really wanted to do...

A fresh example:
viewtopic.php?t=187091
is there any solution to get the same 100 MB from Mikrotik on distance 50 meters ?
and the problem at the end is one "dlink dap 1360".......
 
User avatar
Buckeye
Forum Veteran
Forum Veteran
Posts: 890
Joined: Tue Sep 11, 2018 2:03 am
Location: Ohio, USA

Re: When answering questions

Sat Jun 25, 2022 5:17 am

Fun fact: I think I actually invented MSS clamping. Unfortunately I never patented it, else I could be rich :-)
I implemented this as one of my many patches to the KA9Q TCP/IP package back in august 1995. Cisco introduced it in IOS in 2001.
Interesting. I wonder if it was reinvented independently or if someone at Cisco saw your patch (perhaps without even remembering they saw it).

I found pe1ch.nl/NET but didn't download the source.lzh file.

Just curious, did you implement bi-directional mss clamping, or only unidirectional?

After you see how it works, it seems "obvious", but seeing the possibility the first time isn't obvious; i.e. once you see how a puzzle is solved, it often seems obvious in hindsite. Same with IEEE 802.1Q vlan tags, once you see how they are implemented (by using a new ethertype), it seems obvious, and is clearly more backward compatible than the ISL vlans Cisco used to use, one reason they have disappeared from new switches.

This old thread suggests that it didn't used to work correctly. Dynamic TCP MSS rule breaks stuff I am new to ROS, and I haven't done any wireshark captures to see what happens. But there is the tcp-mss that can be used as a filter to only modify mss when the tcp-mss is greater than some value, so it can be made to "ratchet" mss only in the downward direction as shown in this post. Plus the new-mss=clamp-to-pmtu
Last edited by Buckeye on Sat Jun 25, 2022 11:40 am, edited 1 time in total.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10197
Joined: Mon Jun 08, 2015 12:09 pm

Re: When answering questions

Sat Jun 25, 2022 11:12 am

My implementation was always doing "clamp to pmtu", it did not have a configurable fixed MSS value.
In the IP router code, packets were examined to see if they are TCP SYN and if so the MSS was extracted, 40 added for the TCP/IP header overhead, and then compared with the MTU of both the incoming and outgoing interface, and when higher than those the value was adjusted down to MTU - 40.
So I guess you could call that bidirectional, it takes into account both MTU values known at that site. Note that a TCP SYN with MSS field travels from the source to destination of the connect and the (possibly lowered) MSS is stored at the destination end to use as maximum for the data it will send back, then the destination will reply with a TCP SYN ACK also with an MSS that comes back to the source of the connection and locally stored for maximum size of outgoing segments. So indeed it will clamp in both directions when you view it that way.
        /* Check for something that appears to be a TCP SYN */
        /* When it is, trim the MSS to fit MTU of incoming and */
        /* outgoing interfaces */

        if(ip->protocol == TCP_PTCL &&
           length >= (TCPLEN + 4) && length <= (TCPLEN + 16))
        {
                struct tcp tcph;
                struct pseudo_header ph;
                int16 mtu;

                ph.source = ip->source;
                ph.dest = ip->dest;
                ph.protocol = TCP_PTCL;
                ph.length = TCPLEN + 4;

                if (cksum(&ph,bp,TCPLEN + 4) == 0 && ntohtcp(&tcph,&bp) >= 0)
                {
                    if ((tcph.flags & SYN) && tcph.mss != 0)
                    {
                        mtu = tcph.mss + IPLEN + TCPLEN;

                        if (i_iface != NULLIF && mtu > i_iface->mtu)
                            mtu = i_iface->mtu;

                        if (mtu > iface->mtu)
                            mtu = iface->mtu;

                        tcph.mss = mtu - IPLEN - TCPLEN;
                    }

                    bp = htontcp(&tcph,bp,&ph);
                }
        }
W.r.t. the mentioned bug: in Linux there is the "firewall mangle" feature to adjust the MSS and I think that has always worked correctly. But MikroTik added their own hack in the interface I/O routines for PPP to have a "more efficient" handling of MSS clamping for this special case that hit a lot of users (usually with PPPoE). Both more efficient in processing (as it would not have to look at traffic not going to the PPP interface at all) and in terms of configuration (as it is just a checkmark, no need to craft a firewall mangle rule that does exactly what you need).
But indeed it looks like they initially goofed up on that. MSS should never be increased as it will cause problems when an even lower MTU link exists further down the path, or the user has some other reason for using a smaller MSS (e.g. it is a tiny device which has only a 256 byte buffer, and sets MSS to 256 for that reason).

And also this solution does not work properly when you are using some form of tunneling (e.g. GRE tunnel), so I never use that and always have just:
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes \
    protocol=tcp tcp-flags=syn
That works every time.
 
sindy
Forum Guru
Forum Guru
Posts: 10206
Joined: Mon Dec 04, 2017 9:19 pm

Re: When answering questions

Wed Jun 29, 2022 4:45 pm

I never use that and always have just:
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes \
protocol=tcp tcp-flags=syn

That works every time.
@pe1chl, can you please explain what this new-mss=clamp-to-pmtu thing actually does? For all what I know about it, it can only help if there is a difference in MTU between in-interface and out-interface (i.e. Ethernet on LAN and PPPoE on WAN) on the router where this rule is used. So if there is an even smaller MTU somewhere else on the path between the client and the server, forcing MSS to a manually chosen value is necessary to work around a broken PMTUD.

To be even more pessimistic, I've even seen cases in the wild where no new-mss setting helped because either some other router has increased it again or the remote server was ignoring it. And it wasn't set just back to 1460, packets carrying 2000+ byte segments were coming, incredible.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10197
Joined: Mon Jun 08, 2015 12:09 pm

Re: When answering questions

Wed Jun 29, 2022 6:04 pm

Is that an issue that you saw in a MikroTik environment? Or was there other equipment involved that increases the MSS?
I have not observed that in a MikroTik-based network at least.

Of course the new-mss=clamp-to-pmtu is just a convenience to be used when the MTU bottleneck is local, as usually is the case for the typical home user.
They are confronted with PPPoE withotu RFC4638, or they make a VPN (because that is hip). And then they come here with "why do some sites not work while others do?". They need a quick fix.
When you know how to calculate MSS of course you can consider to manually set it. Or, for example, in our hamnet VPN router, where all kinds of different VPN tunnels are routed, each of which can be over PPPoE connection or not, I just simply clamp the MSS to 1280 which usually works OK.

Another potential issue is that some routers may fragment IP datagrams (even when DF is set), and then some other routers may re-assemble them in order to implement firewall or CGNAT. They will then have to be re-fragmented when forwarding them further down the path.
But increasing MSS in the router I have not observed. Maybe some routers do that in an attempt to fight a specific attack: to send (or maybe clamp) ridiculously small MSS values. I have a firewall rule to drop TCP SYN packets with very small MSS (like < 160), maybe others change the MSS to 1460 in such cases?
 
sindy
Forum Guru
Forum Guru
Posts: 10206
Joined: Mon Dec 04, 2017 9:19 pm

Re: When answering questions

Wed Jun 29, 2022 6:15 pm

Is that an issue that you saw in a MikroTik environment?
...
Maybe some routers do that in an attempt to fight a specific attack: to send (or maybe clamp) ridiculously small MSS values. I have a firewall rule to drop TCP SYN packets with very small MSS (like < 160), maybe others change the MSS to 1460 in such cases?
I've got no clue whatsoever what exacly was happening and where. I could only see I was sending out MSS of 1400 (cloud environment with vxlan-based private networks with MTU of 1450) and was getting back 2200 or so large packets.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19114
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: When answering questions

Wed Jun 29, 2022 7:32 pm

What you are missing mike, is that there are many ways to solve an issue but there is one common denominator and that is understanding the requirements.
You want an answer to a specific question but that is not necessarily the path to the most efficient or elegant solution. Often attempts to fix a config by an op amount to nothing but a horrible work-around to a messy approach to requirements ( and thats assuming the OP went through an organized approach to requirements identification).

Take this comment.........
"4) Copy/Paste the relevant parts of the config into the post, making sure to remove any possibly sensitive info"

That is the wrong thinking, and arrogant, as if the person with the problem knows where the problem lies............... in MT configs, many items are interrelated and uncertainty in one area often means uncertainty in other parts of the config....................

viewtopic.php?p=908118

++++++++++++++
as to the sideline on mss mtu etc.................... I still owe a thesis to sindy on that one LOL, but my only experience is you change numbers randomly until the traffic you are trying to achieve works, in other words still a complete mystery to me, one day I will broach the subject,,,,,,,,,,,, hopefully before being six feet under.
 
User avatar
Buckeye
Forum Veteran
Forum Veteran
Posts: 890
Joined: Tue Sep 11, 2018 2:03 am
Location: Ohio, USA

Re: When answering questions

Wed Jun 29, 2022 10:14 pm

What you are missing mike, is that there are many ways to solve an issue but there is one common denominator and that is understanding the requirements.
You want an answer to a specific question but that is not necessarily the path to the most efficient or elegant solution. Often attempts to fix a config by an op amount to nothing but a horrible work-around to a messy approach to requirements ( and thats assuming the OP went through an organized approach to requirements identification).
@anav Hopefully you had a nice vacation/holiday.

Good points,

Understanding the problem is the first step in G. Polya, How to Solve It which is a formalized problem solving approach that is very useful in troubleshooting (of any kind).
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19114
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: When answering questions

Wed Jun 29, 2022 10:28 pm

Too short, so yes very good! I prefer not to couch a config as a problem it should be looked at as simply a desire (expressed in a series of user based set of requirements be they devices or users) given the constraints of existing equipment/connectivity. Through a process, the desire is teased out into factual statements (that express what users can and cannot do), that form the basis of the config.

The process of eliciting requirements can best be done by a thorough approach that includes questionnaires, surveys, interviews and reading any existing documentation about what what the work or desire entails. In that sense its very much in step with writing software code based on requirements, except here we are limited by existing equipment and the code available in MT (and the imagination of script writers).

Who is online

Users browsing this forum: Amazon [Bot], chrisk, GoogleOther [Bot], muona, pajapatak, Sampsonfarms0, uxertxo, ywlhlp and 75 guests