-1

Yesterday I asked this question.

Basically all I wanted to find out was the debug solutions to diagnose problems with tcp resubmission. For example if we want to find out about possible routes we use traceroute tool.

The moderator closed the question in just a few seconds after it was posted. In the comments he mentioned " It is obvious that the problem lies in your applications because it works with websockets or HTTP, which use TCP, but your use of raw TCP sockets seems to be flawed". This proves the quick reaction, because I had mentioned that my application works with VPN and other operators. When in the comments I told the moderator about this, he then gave up on the application logic and said: "questions about networks not under your direct control, such as the public Internet, are off-topic here, and you need to discuss that with your ISP."

I called my ISP, interestingly they told the same: We don't support networks we don't have access to. (Meaning the servers my application was tested on).

I strongly disagree with calling this question off-topic. In a community of Network Engineering, I'm sure there are people who could lead me to find out about troubleshooting this case.

At least they can help me persuade my ISP with technical reasoning, or even if this is something about the application itself, they can point out about possible reasons of the application working on some networks and not on others.

Closing the question in just a few seconds after it was published is not a nice way to welcome a new contributer.

2

There's nothing we can do here. There's very little information about what exactly is being done. (custom application, and "raw tcp")

As the problem doesn't happen through other ISPs, a VPN, or other transport mechanisms, it would, on the surface, appear to be an issue with that ISP. But we aren't the ISP, so we can't even begin to guess what might be going on. (It could be a circuit error that your exact bit pattern is triggereing. I.e. the "can't download JPEGs" ticket that was eventually track down to a "3 wire T1" -- TX+/- RX+/-, one of the wires was broken in the crimp. Or the infamous "D4/B8ZS" linecard incident. [no one uses T1's anymore, but those are my go-to examples.])

To begin to troubleshoot any issue you assume is beyond the borders of your network, capture the traffic at BOTH ends. You can't tell if traffic is being lost in the middle by looking at only one end. Once it's left your network, you can't do anything about it. And neither can we.

7
  • Thanks. I did capture the traffic on my server as well, it really was not receiving the packets. I tested my server on an Iranian ip, it seems that they allow unknown traffic to reach anywhere inside the country but not outside. This is definitely related to censorship, Telegram is filtered in Iran, they use their custom protocol, the government has decided any custom protocols are illegal. Because the majority of applications use http and, websockets and other known protocols like SSH, FTP, SMTP, etc..
    – Ali Padida
    Nov 7 '20 at 15:26
  • My point was that the mod blindly closed my question and said the issue is definitely about my application, clearly he goes against any custom TCP protocol because my question was closed seconds after it was asked! Idk maybe he thinks only a university professor can write a custom proto, if it's written by students, then it will definitely have problems. Then when I reminded him that this was tested on other situations and worked, he changed the discussion mentioning networks not in our direct control.
    – Ali Padida
    Nov 7 '20 at 15:30
  • If Network was my expertise and someone from a country with heavy censorship had asked the question, I would've done my best to help them prove the case was because of the censorship by mentioning methods to track, debug and test with different scenarios. We're here to learn about Network, and this is Network, if it's out of my control, I want to know where does it get out of my control and how do I get close to find out what happens in the area that is out of my control.
    – Ali Padida
    Nov 7 '20 at 15:38
  • 1
    It was closed because it's off-topic. It doesn't matter who wrote the custom protocol, the whole subject is off-topic. As the issue is beyond the border of your own network, again, it's off-topic -- you can't fix someone else's network.
    – Ricky
    Nov 7 '20 at 23:10
  • I never wanted to fix someone else's network, I wanted to be aware of the problem, or as I said get as closer as I can to know about the nature of the problem so that I can call my ISP and inform them technically about the case. You are being ignorant, and I'm failing to see why. I don't ask you to show me how to fix my ISP's problem. It was closed because of the misunderstandings that was the result of the quick judgment of the mod, who acted seconds after "not" reading the question and only because of the few words that caught his eyes: custom protocol, ISP, programming language.
    – Ali Padida
    Nov 7 '20 at 23:29
  • 1
    I'm being ignorant? You know exactly what's wrong [traffic is being dropped], and where it's going wrong [upstream ISP]. There's NOTHING we can do to help you. And you know that. (or should) It would appear you don't grasp how SE works: people ask questions that can be answered with authoritative solutions. No guesses, no opinions, no discussions. Each site has a list of "on-topic" / "off-topic" areas. For NE, a network that is not under your direct control (i.e. you can provide a complete picture, and implement our solution) is off-topic. Your issue is outside your network, thus O-T.
    – Ricky
    Nov 8 '20 at 1:47
  • "people ask questions that can be answered with authoritative solutions". I can see that in this answer of yours: "There are bugs in every piece of software. The longer it runs, the more likely one is going to setup shop in your network". "the more likely" doesn't fall into the category of "No guesses, no opinions, no discussions". It's funny that having authority and power has the same effect on people even in a scientific community. I guess it's the nature of it and less people can avoid their nature. Have fun closing more questions.
    – Ali Padida
    Nov 8 '20 at 5:04
0

Your problem is that your hosts/servers are off-topic here, as is a network you do not directly control (the Internet). You have not given us any on-topic information, such as a good network description or diagram, the network device models, the network device configurations, and network device debugs logs, etc. You can review the Network Engineering Question Checklist for guidance on the type of information we need.

Just because it relates to a network does not mean it is network engineering or is on-topic here. Questions about hosts/servers are off-topic here, but on-topic at Server Fault for a business network (the same requirement as here). The OS implementation of TCP in your hosts/server is off-topic here. We can help you with the protocol theory, but if your hosts/servers OSes implementation is different than the theory, then we cannot help you with that.

Applications and programming are also off-topic here, so we cannot help you with your applications that you created. You could ask about that on Stack Overflow.

I really do not see anything in the question that is on-topic for Network Engineering. You can review the checklist I linked above and edit your question to try to include the necessary information, but it really does not sound like a problem with a network you directly control.

2
  • The same mod closes the question, rejects the flag and is the judge. I'm desperate here I guess. Already posted my question on Server Fault, thank you.
    – Ali Padida
    Nov 1 '20 at 16:03
  • I was not the first person to vote to close the question, and you have not received any reopen votes. Please read and understand what I wrote in my answer here. We do not have any information necessary to help troubleshoot your network.
    – Ron Maupin Mod
    Nov 1 '20 at 16:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .