3 ms·

Show HN: Mmar – open-source, zero-dependancy, cross-platform HTTP tunneling

15 points by ymusleh 2y ago

Hey HN! For the past couple of months, I've been working on and off on a cool project I'm excited to share. mmar (pronounced "ma-mar") is an open-source, zero dependency, cross platform and self-hostable HTTP tunnel built in Go. It allows you to easily expose your localhost to the world on a public URL. You can easily create an HTTP tunnel right away for free on a randomly generated subdomain on "*.mmar.dev" if you don't feel like self-hosting. This isn't something new, in fact there's quite a few of alternative HTTP tunneling tools out there. mmar is my attempt to optimize for a super easy developer experience and simplified implementation. None the less, I had a blast building it and I think developers could find it pretty useful. Additionally, I documented the whole process of building mmar through devlogs. You can read about the thought process and implementation details here (https://ymusleh.com/tags/mmar.html https://ymusleh.com/tags/mmar.html). If I would suggest one devlog to read, I highly recommend devlog 5 (https://ymusleh.com/mmar-devlog-005.html https://ymusleh.com/mmar-devlog-005.html). I describe how I built a (very) basic DNS server just to run simulation tests for mmar (a bit of an overkill, but a fantastic learning experience). I dive deep into the DNS protocol and explain why I needed to implement it. Finally, I would love to hear your thoughts and feedback. If you try mmar out, let me know!

fuzzfactor 2y ago
I like the looks of this, maybe I will be able to try it out. Edit: Would be good if there was a 32-bit x86 binary for Windows.
- ymusleh 2y ago
  Hey, thanks for checking it out! I'm looking into adding the 32 bit binary for Windows, stayed tuned. Meanwhile, if you have docker installed you could also try it out using the docker instructions if you'd like.
- ymusleh 2y ago
  I just created a new release that has a 32-bit x86 binary for Windows. Feel free to check it out: https://github.com/yusuf-musleh/mmar/releases/tag/v0.2.4 https://github.com/yusuf-musleh/mmar/releases/tag/v0.2.4
  - fuzzfactor 2y ago
    You're amazing. Just have been trying it out on bare metal on Windows 10, using VLC as a local media server. PCs on the LAN can play the (server VLC's http) stream like normal to begin with, by opening their audio player to a Network Stream or URL, without any browser. On my own fully accessible & controllable router/modem, port-forwarding 8080 alone for only TCP allows PCs on the web to access the stream from the modem's WAN IP address:8080/streamname. This is extremely reliable. But without port-forwarding on the router, running mmar on the server PC I can see the tunnel to port 8080 on your subdomain, but have not had any luck reaching the VLC media from that address on the web. From what I understand, VLC may only support http and not https, maybe that is the problem? Also the (simple audio) media stream from VLC has a :portnumber/streamname of :8080/mmarRadio without any file extension. There is no index.html or anything else exposed. Then tried a low-resolution MPG2 stream with a .MPG file extension which also streams normally when port-forwarded, the mediaplayer on the remote PC acts more like it wants to connect but then fails and reports it can not open the file. Much more significant buffering on the video stream though. When it's my own router, I port-forward a range from 8080 - 8083, to a single mediaserver PC to provide 4 streams simultaneously from that one PC. So streams appear on the single WAN IP address of my modem, accessible from the web, with a choice of 4 ports, acting logically as 4 different Network URLs. All raw numerical IP addresses, no DNS or anything. It really does look nominal from the Windows command line, I'll leave 8080 in its "apparently tunneling" condition, going to get some rest for a while.
    - ymusleh 2y ago
      > You're amazing. Thanks, I appreciate you taking the time to check out mmar. > But without port-forwarding on the router, running mmar on the server PC I can see the tunnel to port 8080 on your subdomain, but have not had any luck reaching the VLC media from that address on the web. I haven't tested HTTP streaming using mmar, however taking a look at the logs, I can see a bunch of i/o timeouts, so it's likely the case the HTTP streaming doesn't work properly with mmar currently. Do you have any suggestions off the top of your head for a small project that has HTTP streaming that I can run locally to test? If not, that's fine, I can figure something out to reproduce the issue.

15 points by ymusleh 2y ago

fuzzfactor 2y ago

I like the looks of this, maybe I will be able to try it out. Edit: Would be good if there was a 32-bit x86 binary for Windows.

ymusleh 2y ago
Hey, thanks for checking it out! I'm looking into adding the 32 bit binary for Windows, stayed tuned. Meanwhile, if you have docker installed you could also try it out using the docker instructions if you'd like.
ymusleh 2y ago
I just created a new release that has a 32-bit x86 binary for Windows. Feel free to check it out: https://github.com/yusuf-musleh/mmar/releases/tag/v0.2.4 https://github.com/yusuf-musleh/mmar/releases/tag/v0.2.4
- fuzzfactor 2y ago
  You're amazing. Just have been trying it out on bare metal on Windows 10, using VLC as a local media server. PCs on the LAN can play the (server VLC's http) stream like normal to begin with, by opening their audio player to a Network Stream or URL, without any browser. On my own fully accessible & controllable router/modem, port-forwarding 8080 alone for only TCP allows PCs on the web to access the stream from the modem's WAN IP address:8080/streamname. This is extremely reliable. But without port-forwarding on the router, running mmar on the server PC I can see the tunnel to port 8080 on your subdomain, but have not had any luck reaching the VLC media from that address on the web. From what I understand, VLC may only support http and not https, maybe that is the problem? Also the (simple audio) media stream from VLC has a :portnumber/streamname of :8080/mmarRadio without any file extension. There is no index.html or anything else exposed. Then tried a low-resolution MPG2 stream with a .MPG file extension which also streams normally when port-forwarded, the mediaplayer on the remote PC acts more like it wants to connect but then fails and reports it can not open the file. Much more significant buffering on the video stream though. When it's my own router, I port-forward a range from 8080 - 8083, to a single mediaserver PC to provide 4 streams simultaneously from that one PC. So streams appear on the single WAN IP address of my modem, accessible from the web, with a choice of 4 ports, acting logically as 4 different Network URLs. All raw numerical IP addresses, no DNS or anything. It really does look nominal from the Windows command line, I'll leave 8080 in its "apparently tunneling" condition, going to get some rest for a while.
  - ymusleh 2y ago
    > You're amazing. Thanks, I appreciate you taking the time to check out mmar. > But without port-forwarding on the router, running mmar on the server PC I can see the tunnel to port 8080 on your subdomain, but have not had any luck reaching the VLC media from that address on the web. I haven't tested HTTP streaming using mmar, however taking a look at the logs, I can see a bunch of i/o timeouts, so it's likely the case the HTTP streaming doesn't work properly with mmar currently. Do you have any suggestions off the top of your head for a small project that has HTTP streaming that I can run locally to test? If not, that's fine, I can figure something out to reproduce the issue.