| 14 Jul 2025 |
toonn | In the IPv6 future sharing your IP publically is intended, no? | 13:40:14 |
matthewcroughan - nix.zone | bittorrent is more like a real broadcast (radio spectrum broadcast), because it doesn't require more bandwidth from the transmitter, to serve it to 1000 people | 13:40:40 |
matthewcroughan - nix.zone | A real radio station doesn't require more bandwidth to reach more listeners (unless you count distance, which I don't) | 13:41:13 |
n4ch723hr3r | if you have a VPS or some other public device you could forward your port over that | 13:41:16 |
matthewcroughan - nix.zone | Ah, not true, you can't proxy icecast neatly because it uses a combination of http and tcp | 13:41:38 |
matthewcroughan - nix.zone | it runs http bits on port 8000, and tcp bits on 8000 | 13:41:50 |
matthewcroughan - nix.zone | when the user hits it, nginx proxies to the http bits, and then fails on the tcp bits | 13:42:03 |
n4ch723hr3r | as far as i know you can do that over ssh | 13:42:05 |
matthewcroughan - nix.zone | when you do services.icecast.enable = true and give it a stream, you can go to http://localhost:8000/stream and then you'll get binary data, not http | 13:42:40 |
matthewcroughan - nix.zone | if you try to proxy to localhost:8000/stream on the public internet, with nginx, it doesn't work | 13:42:54 |
n4ch723hr3r | that sounds complicated. why doesnt icecast just do m3u8 or something like that? | 13:43:44 |
matthewcroughan - nix.zone | [error] 57885#57885: *14 upstream sent invalid header: "\x20..." while reading response header from upstream, client: 192.168.5.222, server: icecast.example.com, request: "GET /radio HTTP/1.1", upstream: "http://192.168.5.196:8001/radio.ogg", host: "icecast.example.com" | 13:44:24 |
matthewcroughan - nix.zone | that's what you'll get if you try to use nginx to proxy to icecast on port 8000 | 13:44:34 |
matthewcroughan - nix.zone | because the webpage and other bits surrounding icecast are http, but the stream is tcp | 13:44:49 |
toonn | I've run into similar difficulty trying to proxy Ente. It has hardcoded-ish references in the code sharing backend addresses and such and it expects the host to be the same, only got part of the way through patching the behavior before I ran out of time to spend on it. | 13:44:57 |
n4ch723hr3r | i've proxied DNS (for DoH & DoT) with only bind9 and nginx before so i know that you can use nginx to forward TCP streams | 13:45:47 |
jappie | ^ look for stream config in the documentation | 13:46:06 |
matthewcroughan - nix.zone | Yes, it's just quite different and I haven't found a way yet | 13:46:18 |
matthewcroughan - nix.zone | This doesn't work either. Because it's using TCP and HTTP on the same port (8000) | 13:46:41 |
matthewcroughan - nix.zone | and when you visit in the browser on http://foo.com:8000 it proxies http, not tcp | 13:46:55 |
matthewcroughan - nix.zone | so the tcp stream proxy doesn't even get hit | 13:47:07 |
jappie | is this even allowed? | 13:47:19 |
n4ch723hr3r | cant you change one of the ports in the icecast config? | 13:47:20 |
matthewcroughan - nix.zone | No, if you make a new listen socket it seems to just create another http endpoint you can hit that has the same problem of combining tcp and http | 13:47:51 |
matthewcroughan - nix.zone | You can't bifurcate it | 13:48:05 |
matthewcroughan - nix.zone | * You can't bifurcate/split it | 13:48:11 |
n4ch723hr3r | "is that legal?" | 13:48:28 |
jappie | it just sounds so cursed lol - HTTP is what, layer 7? | 13:49:32 |
n4ch723hr3r | https://gist.github.com/virtadpt/94eb781cba3ec9c56a4f39ef6bf760f3
i found this 🤡 | 13:49:36 |
n4ch723hr3r | subs_filter_types application/xspf+xml audio/x-mpegurl audio/x-vclt text/css text/html text/xml;
subs_filter ':8000/' '/' gi;
subs_filter '@localhost' '@example.com' gi;
subs_filter 'localhost' $host gi;
subs_filter 'Mount Point ' $host gi;
| 13:49:57 |