The Release Notes say "Fix problems with realaudio masquerading". Looked
promising, since with 2.2.17 one masqueraded system (but not another) was
having occassional problems with realaudio at some (but not all) sites.
Compiled 2.2.19 with 'make oldconfig,' no to new options. Otherwise running
with the same firewall and masquerading settings (and yes I built and
installed ip_masq_raudio.o). Masquerading is otherwise working, but now
neither masqueraded system can connect with realaudio - the realplay routine
to find a way to make a connection automatically fails for both.
Please cc me, not subscribed.
Thanks,
Whit
[email protected]
I've been running masquerading unchanged from 2.2.13, currently 2.2.19 as:
real IP +
masq. 192.168.1.NNN
DSL <-> gateway <-> switch <-> client 1
server <-> client 2
...
<-> client n
There was some general slowness over the last few days (Bay Area, California
<-> US East Coast) including realaudio being unable to locate servers and/or
content. This one is working right now:
RealPlayer v 7.0.3.338
abit:~ > cat On24ram.asp
rtsp://rm.on24.com/media/news/04192001/palumbo_ted6.rm
--stop--
http://rm.on24.com/media/news/04192001/palumbo_ted6.rm
Try '# strace /usr/bin/X11/realplay On24ram.asp > log' and see where the
connect fails if you aren't getting specific error messages.
rgds,
tim.
Whit Blauvelt wrote:
>
> The Release Notes say "Fix problems with realaudio masquerading". Looked
> promising, since with 2.2.17 one masqueraded system (but not another) was
> having occassional problems with realaudio at some (but not all) sites.
>
> Compiled 2.2.19 with 'make oldconfig,' no to new options. Otherwise running
> with the same firewall and masquerading settings (and yes I built and
> installed ip_masq_raudio.o). Masquerading is otherwise working, but now
> neither masqueraded system can connect with realaudio - the realplay routine
> to find a way to make a connection automatically fails for both.
rgds,
tim.
--
On Tue, Apr 24, 2001 at 06:01:05PM -0700, Tim Moore wrote:
> rtsp://rm.on24.com/media/news/04192001/palumbo_ted6.rm
> --stop--
> http://rm.on24.com/media/news/04192001/palumbo_ted6.rm
Hmm, the rtsp: fails while the http: works for that one. But then a tcp
connection doesn't depend on the realaudio masq module.
> Try '# strace /usr/bin/X11/realplay On24ram.asp > log' and see where the
> connect fails if you aren't getting specific error messages.
Unfortunately this spits out a bunch of stuff and then totally freezes up my
KDE 2.1.1 desktop. Probably totally unrelated, but that's what happens - the
part of the log that ends up in the frozen display doesn't tell me much, and
have to go to shell and kill strace to unfreeze things.
Could the problem be that I have realplay 8.0.3.412 on the systems here and
they've introduced some bug or incompatibility?
Whit
[quoted lines by Whit Blauvelt on April 25, 2001, at 13:38]
>On Tue, Apr 24, 2001 at 06:01:05PM -0700, Tim Moore wrote:
>> Try '# strace /usr/bin/X11/realplay On24ram.asp > log' and see where the
>> connect fails if you aren't getting specific error messages.
>
>Unfortunately this spits out a bunch of stuff and then totally freezes up my
>KDE 2.1.1 desktop.
strace writes to standard error, not standard output, by default. Better yet,
though, use the -o option of strace to direct its output to a file, which
leaves the standard output streams alone for the aplication being traced.
--
Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the
Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me
EMail: [email protected] | Canada K2A 1H7 | if you're concerned about Hell.
Le 25 Apr 2001 14:52:56 -0400, Dave Mielke a ?crit :
> [quoted lines by Whit Blauvelt on April 25, 2001, at 13:38]
>
> >On Tue, Apr 24, 2001 at 06:01:05PM -0700, Tim Moore wrote:
> >> Try '# strace /usr/bin/X11/realplay On24ram.asp > log' and see where the
> >> connect fails if you aren't getting specific error messages.
> >
> >Unfortunately this spits out a bunch of stuff and then totally freezes up my
> >KDE 2.1.1 desktop.
>
> strace writes to standard error, not standard output, by default. Better yet,
> though, use the -o option of strace to direct its output to a file, which
> leaves the standard output streams alone for the aplication being traced.
I didn't follow this thread at all (just caught this last mail), but I
use realplayer8 here, and I actually had to *rmmod* the realaudio
masquerading module to make it stream audio from the internet on a
masqueraded machine. The server is a debian with kernel 2.2.19, does
NAT.
Xav
On Wed, Apr 25, 2001 at 10:56:11PM +0200, Xavier Bestel wrote:
> Le 25 Apr 2001 14:52:56 -0400, Dave Mielke a ?crit :
> > strace writes to standard error, not standard output, by default. Better yet,
> > though, use the -o option of strace to direct its output to a file, which
> > leaves the standard output streams alone for the aplication being traced.
Okay, so being unfamiliar with strace, I should be able to invoke something
like "strace -o log realplay some-realaudio-url"? And this should mean
something to me?
> I didn't follow this thread at all (just caught this last mail), but I
> use realplayer8 here, and I actually had to *rmmod* the realaudio
> masquerading module to make it stream audio from the internet on a
> masqueraded machine. The server is a debian with kernel 2.2.19, does
> NAT.
Thanks for reasuring me there's something broken in the module. Xavier, do
you happen to know what transport mode your realplay is using then? That
would show under View | Preferences | Transport. And if you hit the
Autoconfigure button therer, does it succeed? It doesn't for me either with
or without the module loaded, and it used to with a 2.2.17 kernel plus
realplay 7 rather than 8.
Of course, the masq module is only to handle udp - if real goes to tcp it
doesn't need it, so I suspect what Xavier's seeing is it working via tcp -
but perhaps some servers today refuse to do anything but udp connections?
Whit
PS: Please cc me, I'm not on the list.
Le 25 Apr 2001 18:12:38 -0500, Whit Blauvelt a ?crit :
> On Wed, Apr 25, 2001 at 10:56:11PM +0200, Xavier Bestel wrote:
> > Le 25 Apr 2001 14:52:56 -0400, Dave Mielke a ?crit :
>
> > > strace writes to standard error, not standard output, by default. Better yet,
> > > though, use the -o option of strace to direct its output to a file, which
> > > leaves the standard output streams alone for the aplication being traced.
>
> Okay, so being unfamiliar with strace, I should be able to invoke something
> like "strace -o log realplay some-realaudio-url"? And this should mean
> something to me?
>
> > I didn't follow this thread at all (just caught this last mail), but I
> > use realplayer8 here, and I actually had to *rmmod* the realaudio
> > masquerading module to make it stream audio from the internet on a
> > masqueraded machine. The server is a debian with kernel 2.2.19, does
> > NAT.
>
> Thanks for reasuring me there's something broken in the module. Xavier, do
> you happen to know what transport mode your realplay is using then? That
> would show under View | Preferences | Transport. And if you hit the
> Autoconfigure button therer, does it succeed? It doesn't for me either with
> or without the module loaded, and it used to with a 2.2.17 kernel plus
> realplay 7 rather than 8.
Well, it says 'Automatically select best transport', and Autoconfigure
doesn't succeed. With or without ip_masq_raudio.
> Of course, the masq module is only to handle udp - if real goes to tcp it
> doesn't need it, so I suspect what Xavier's seeing is it working via tcp -
> but perhaps some servers today refuse to do anything but udp connections?
I confirm it uses TCP for streaming (I just looked with ethereal). The
problem is that when insmoding ip_masq_raudio on the firewall,
realplayer just hangs when buffering - if the server only supported UDP,
I suspect it would negociate TCP or something like that.
Xav