Hacker News Reader

Comment by sofaofthedamned | Hacker News Reader

Had a similar thing a while ago. Very complicated IPSEC tunnels, routers switches firewalls and whatnot between us and our customer. Customers techs were - not great - so needed to make sure port 443 worked through the tunnel. Our side mainly Linux, theirs was mainly Windows 10.

Asked a programmer our side (.net) who said it'd take a couple of hours to write a simple webserver, package it up into an .msi and give it us. I got annoyed, did it in Golang in about 10 lines of code.

I then realised i'd compiled a Linux executable on Linux, remembered it did cross-compiling, 10 seconds later I had a Windows .exe. All for a simple webserver that printed "cock", not useful but it proved the tunnels worked.

Sometimes we overcomplicate the simplest shit.

EDIT: As it wasn't clear (my fault) - we were trying to get to port 443 at their end - they were on Windows, we mainly Linux but the guys I asked were .net programmers..

View on HN

> Sometimes we overcomplicate the simplest shit.

Indeed. Why not use nc and telnet on port 443 to test? Linux already has nc and Windows already has telnet.

Indeed writing a _webserver_ to test connectivity sounds a bit non-simple.

The endpoint at their end was Windows. No nc. Apologies if that wasn't clear. I was testing our end reaching their endpoint at port 443.

nc is the client, if you could host a webserver surely you could have run nc...

Actually I misunderstood and thought the server was Linux.

You could of course use nc as the client too, but it would be an additional install on Windows. [0]

And nc wouldn't help if the firewall was stateful and actually expected to see HTTPS traffic on port 443, so I do see their logic of putting an actual webserver there.

But without sufficient detail, it does seem at first glance to be overkill ;-)

[0] https://joncraton.org/blog/46/netcat-for-windows/

Good point, but the dudes at the other end had no idea. I had to give them an .exe, which was better than a .msi.

Bear in mind the server was at the Windows end, so no good with telnet over that side...

It might also be possible that we don't know the simplest methods of doing something. I'm not sure if there is a simpler way to do it from the Windows side of things than what this person told you.

I wouldn't know how to do it in Golang because I don't use it. I would default to my most comfortable language, which is almost guaranteed to not be the most efficient method to do anything.

    python -m SimpleHTTPServer 443

Quite. And you tell the Windows admin at the other end, who doesn't know Python from the hole in his arse, that it's an option.

Remember - the server end is Windows, and the guys at that end didn't know what to do if it wasn't an .msi or .exe.

Whatever time it took you to write that program, it could have been saved by letting the other guy do it, even if it would take much more of his time.

Yeah but by doing it oneself, one knows that it will work, or at least that if it doesn't work one won't have to sit through interminable conference calls on the topic of Why the Fact that It Won't Work Isn't Actually that Other Dude's Fault.

That was pretty much it. Guys at the end were evasive, lazy and not capable and the project was dragging on. Best to give them an .exe with no dependencies, get them to click on it and verify the tunnels that way.

You could write a web server that echoes a word in around 10 lines of C# fwiw

Sometimes, I take 10% of the time writing what is needed and 90% of the time getting it to be testable and then writing the actual unit tests.

And people wonder why there's ever resistance to "everything has to have automated tests" style directives...

You asked a .Net dev for a solution and he specced you one...

The right solution would've been a powershell script.

Reply on news.ycombinator.com