Custom query (1019 matches)
Results (172 - 174 of 1019)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#257 | wontfix | Fwd: IPv6 routing issue in nordunet | ||
Description |
Begin forwarded message: > From: Pekka Savola <pekkas@netcore.fi> > Date: November 7, 2010 15:06:48 GMT+08:00 > To: "Eggert Lars (Nokia-NRC/Espoo)" <lars.eggert@nokia.com> > Cc: "noc@nordu.net" <noc@nordu.net> > Subject: Re: IPv6 routing issue in nordunet > > Hello, > > This happens in Funet. The folks are advertising only 2001:df8::/34 > and we reject advertisements that exceed allocation boundaries so > there is no return path. They should advertise a /32 in addition or > instead. > > You can see this from > http://www.nordu.net/connectivity/looking-glass/lg.cgi > http://www.csc.fi/funet/status/tools/lg > > On Sat, 6 Nov 2010, Lars Eggert wrote: >> it looks like the prefix used at IETF-79 isn't being routed correctly in NorduNet. Could you forward this to someone who can do something about it? >> >> [eggert@dhcp-6306: ~/Stuff/codesprint/lars/ietf] traceroute6 fit.nokia.com >> traceroute6 to fit.nokia.com (2001:708:40:fff1::1) from 2001:df8::96:225:ff:fe45:eccf, 64 hops max, 12 byte packets >> 1 2001:df8:0:96::3 1.199 ms 0.796 ms 0.734 ms >> 2 2001:250:0:46::253 1.178 ms 1.202 ms 1.398 ms >> 3 2001:252:0:290::1 1.294 ms 2.310 ms 1.089 ms >> 4 bj-ge-03-v6.bb.tein3.net 1.250 ms 1.525 ms 1.389 ms >> 5 eu-cop-pr-v6.bb.tein3.net 180.270 ms 180.284 ms 280.658 ms >> 6 nordunet-gw.rt2.cop.dk.geant2.net 180.413 ms 180.195 ms 180.328 ms >> 7 dk-ore.nordu.net 189.751 ms 189.511 ms 189.742 ms >> 8 * * * >> 9 * * * >> 10 * * * >> 11 * * * >> ... >> >> Thanks, >> Lars |
|||
#370 | fixed | Fwd: MultiPath TCP - Live-CD | ||
Description |
Below is the link to the Live CD Begin forwarded message: > From: Christoph Paasch <christoph.paasch@uclouvain.be> > Date: March 27, 2011 9:44:51 GMT+02:00 > To: <chelliot@pobox.com>, <karen.odonoghue@navy.mil> > Cc: Lars Eggert <lars.eggert@nokia.com>, Sébastien Barré <Sebastien.Barre@uclouvain.be> > Subject: MultiPath TCP - Live-CD > Reply-To: <christoph.paasch@uclouvain.be> > > Hello, > > as requested by Lars, we would like you to host our MPTCP Live-CD. > The final version is now available at: > http://192.135.168.249/data/ubuntu-10.10-mptcp-amd64.iso > > Could you please send me the link to it, as soon as it is ready? > > Thanks a lot. > > Regards, > Christoph Paasch > > -- > Christoph Paasch > PhD Student > > IP Networking Lab --- http://inl.info.ucl.ac.be > MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp > Université Catholique de Louvain > > www.rollerbulls.be > -- |
|||
#627 | fixed | Fwd: Nagasaki's icecast server is serving the wrong content-type | ||
Description |
It seems like the mime type of the remote audio stream is wrong again. It is serving audio/mpegurl instead of audio/mpeg. This was fixed last IETF. Note from Bill Fenner detecting it below. This is causing the iPhone/iPad clients not to work. Thanks, Tom Begin forwarded message: > From: Bill Fenner <fenner@fenron.com> > Subject: Re: Nagasaki's icecast server is serving the wrong content-type > Date: March 12, 2013 11:47:51 AM EDT > To: joel jaeggli <joelja@bogus.com> > Cc: Tom Pusateri <pusateri@bangj.com>, Nick Kukich <nkukich@verilan.com> > > On Tue, Mar 12, 2013 at 9:49 AM, joel jaeggli <joelja@bogus.com> wrote: > running icecast 2.3 looking at the config I'm not sure I see an knob for this... > > I can upgrade but I'll have to kick all the users off. > > I also created a .pls file with the appropriate format which is more expressive but doesn't appear to help. > > http://nagasaki.bogus.com/ietf/ > > So it turns out that the streamer itself is supplying the "audio/mpegurl" content type. I talked to Nick and he is reconfiguring them all to use "audio/mpeg", so starting with the 1:00 sessions streaming to iOS should work right. The server was just reporting to the client what the streamer was reporting to icecast. > > Bill > > > > > joel > > > On 3/12/13 9:17 AM, Bill Fenner wrote: > So I tried an IOS "icecast player". It came with some presets, like http://pub4.sky.fm/sky_classical, which it successfully streams and uses "Content-Type: audio/mpeg". nagasaki uses "Content-Type: audio/mpegurl" (which I thought was the content-type for m3u, not for the stream itself). > > > Sample curl output: > > forbin:tmp fenner$ curl -v http://nagasaki.bogus.com:8000/stream01 > /dev/null > * About to connect() to nagasaki.bogus.com <http://nagasaki.bogus.com> port 8000 (#0) > > * Trying 147.28.0.81... % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0connected > * Connected to nagasaki.bogus.com <http://nagasaki.bogus.com> (147.28.0.81) port 8000 (#0) > > > GET /stream01 HTTP/1.1 > > User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5 > > Host: nagasaki.bogus.com:8000 <http://nagasaki.bogus.com:8000> > > > Accept: */* > > > * HTTP 1.0, assume close after body > < HTTP/1.0 200 OK > < Content-Type: audio/mpegurl > < icy-br:64 > < ice-audio-info: bitrate=64;samplerate=22050;channels=2 > < icy-description:ietf86 - Boca1 - am1Orlando > < icy-genre:misc > < icy-name:ietf86 - Orlando - Boca1 - am1 - 64Kbps > < icy-pub:0 > < icy-url:http://nagasaki.bogus.com:8000/stream01 > < Server: Icecast 2.3.2 > < Cache-Control: no-cache > < > { [data not shown] > > For the one that works: > > forbin:tmp fenner$ curl -v http://pub4.sky.fm/sky_classical > /dev/null > * About to connect() to pub4.sky.fm <http://pub4.sky.fm> port 80 (#0) > > * Trying 72.26.204.77... % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0connected > * Connected to pub4.sky.fm <http://pub4.sky.fm> (72.26.204.77) port 80 (#0) > > > GET /sky_classical HTTP/1.1 > > User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5 > > Host: pub4.sky.fm <http://pub4.sky.fm> > > > Accept: */* > > > * HTTP 1.0, assume close after body > < HTTP/1.0 200 OK > < Content-Type: audio/mpeg > < icy-br:96 > < icy-genre:classical easy symphonic > < icy-name:Mostly Classical - SKY.FM <http://SKY.FM> - Listen and Relax, it's good for you! www.sky.fm <http://www.sky.fm> > > < icy-notice1:<BR>This stream requires <a href="http://www.winamp.com/">Winamp</a><BR> > < icy-notice2:SHOUTcast Distributed Network Audio Server/Linux v1.9.8<BR> > < icy-pub:0 > < icy-url:http://www.sky.fm/classical/ > < Server: Icecast 2.3.3-kh5 > < Cache-Control: no-cache > < Pragma: no-cache > < Expires: Mon, 26 Jul 1997 05:00:00 GMT > > There's a fair bit of evidence that "audio/mpegurl" is actually the content-type for the m3u file, not for the stream itself. > > Joel, is there a configuration you can tweak for this, or is this a bug in the server version you're running? > > Thanks, > Bill > > > |
Note: See TracQuery for help on using queries.