Custom query (1019 matches)

Filters
 
or
 
  
 
Columns

Show under each result:


Results (172 - 174 of 1019)

Ticket Resolution Summary Owner Reporter
#257 wontfix Fwd: IPv6 routing issue in nordunet zhzhy@… anonymous
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


smime.p7s

#370 fixed Fwd: MultiPath TCP - Live-CD odonoghue@… lars.eggert@…
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
> --


smime.p7s

#627 fixed Fwd: Nagasaki's icecast server is serving the wrong content-type joelja@… pusateri@…
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.