SuSE has been doing USB for three versions now.
SuSE 6.3, SuSE 6.4, SuSE 7.0. In fact, SuSE
developers contributed greatly in backporting the
2.4 usb stuff into the stable 2.2 kernel. See
For a long time in my office, I put the computer in the closet. Put a blanket behind the closet door, and ran 30 foot cables to the desk for the mouse, keyboard, and monitor. After that I could not even hear my hardrive array spinning.
here are some files from the mailing list which address your concerns.
-- boletus ================================================ First mail in thread ----------------------------------------------- The SpeakFreely for Linux Mailing List
Hi!
I'm glad that my friend contributed his setup for two machines, one running Linux 2.2 and connected to the internet with a regular IP address. The other (on the local network) is being masqueraded having a private IP address.
The trick is to _masquerade_ outgoing packets and to _forward_ incoming packets. However, you'll need kernel 2.2 for this to work, AFAIK.
Questions should be posted to the Speakfreely for Linux mailing list .
Regards, Walter
-- Walter Haidinger For further information, such as address or PGP public key, please refer to: http://members.kstp.at/wh/index.html ================================================ = foo script ------------------------------------------------ - #!/bin/bash
# # Linux kernel 2.2 masquerading/forwarding rules for Speakfreely # # Required tools: # * ipchains (http://www.rustcorp.com/linux/ipchains) # * ipmasqadm (http://juanjox.linuxhq.com) # # Notes: # * The man page of ipmasqadm tells which kernel options are needed # * There is a IPCHAINS-HOWTO available at the ipchains webpage. #
alias ipchains=echo alias ipmasqadm=echo set -v; set -x # uncommend to debug
# # Accept connections to local from anywhere # ipchains -A input -s 0/0 -d 0/0 $SF_PORT:$SF_NEXT_PORT \ -p udp -j ACCEPT
# # Masquerade packets from local to remote # ipchains -A forward -s $SF_MASQ_HOSTIP -d 0/0 $SF_PORT:$SF_NEXT_PORT \ -p udp -i $INTERFACE -j MASQ
# # Allow connections to remote sfspeaker from anywhere # ipchains -A output -s 0/0 -d 0/0 $SF_PORT:$SF_NEXT_PORT \ -p udp -j ACCEPT
# # Forward ports to the masqueraded network # ipmasqadm portfw -a -P udp -L $SF_REAL_HOSTIP $SF_PORT \ -R $SF_MASQ_NET $SF_PORT
ipmasqadm portfw -a -P udp -L $SF_REAL_HOSTIP $SF_NEXT_PORT \ -R $SF_MASQ_NET $SF_NEXT_PORT ================================================ replies to first item in thread: first reply: ------------------------------------------------ The SpeakFreely for Linux Mailing List
F***! Please remove or comment the following three lines in the previously attached script:
alias ipchains=echo alias ipmasqadm=echo set -v; set -x # uncommend to debug
Just left over from debugging... Sorry.
Walter
================================================ = second reply ------------------------------------------------ - Walter Haidinger wrote: > [SNIP] > > SF_PORT=2076 > SF_MASQ_NET=192.168.10.20 [SNIP]
This is a really reply to: Walter Haidinger, Brian Winters, Dave McCracken, and Ivan Kocher.
Given the current situation, Speak Freely can't be used behind masq without special setup on the masq gateway, and even with special setup it can be only fully used by one machine behind the masq. (Walter's solution above isn't functional for outgoing calls, as the new port number is never received by the remote copy, which sends to 2074.) I see three possible solutions for this, none of them perfect.
First: Making Speak Freely a connection-based UDP program like ICQ, which sends to the port it received data from, instead of a fixed port. This solution is the best IMHO for the long term. Multiple users could use speak freely from behind the masq, even conversing with the same person! The single problem with this is that it would break communication with older versions of Speak Freely. A call couldn't be made directly to any specific machine behind the masq without a port forward, but that is the case with all masq applications. Incoming calls would come to port 2074, and would be handled by either a local sfspeaker, or be forwarded to a default host as any other service would be. This is Ivan's Suggestion.
Second: A userspace proxy that runs on port 2074 on the gateway, reads the packet's host, and based on that sends the packet to the appropriate host based on the contents of/proc/net/ip_masq/udp. Such a proxy would be trivial to write, and would allow multiple machines behind the masq to use Speak Freely at a time, if they are conversing with different hosts. Another disadvantage is that the incoming audio will appear as a separate incoming connection from the gateway machine to the calling machine, but that is an aesthetic issue only. The proxy would have to have some caching logic to operate efficiently, as reading and parsing /proc/net/ip_masq/udp for each packet would have quite a bit of overhead. Incoming calls would be sent to a default host specified in the configuration, or to a sfspeaker running on another port on the gateway. This is my suggestion, inspired by the "sfproxy" that used TCP and required a modification to Speak Freely itself.
Third: A proxy as mentioned above done in a kernel masq module. This would have direct access to the raw masquerade tables, so it could cut back the overhead mentioned above, and simplify the code a bit. The incoming audio could also be made to look as if it was coming directly from the host, not the gateway. The "different host" rule of above applies, as there is no easy way to distinguish packets for different internal computers aside from hostname. In addition, writing a kernelspace module is more difficult than a userspace proxy because of the rules, e.g.: no floating point math, subtle locking issues on SMP, etc. This is Dave's Suggestion.
If you can think of any better ideas, feel free to toss them onto the list.
--RZG
(OBSpeakFreelyBug: Sometimes when one party tries to close a connection, he is unable to since the keepalives from the other side reopen it. It there a close command sent down the line? Should Speak Freely for Windows ignore keepalives from a specific host for a set time after it closes a connection to that host? Or am I missing something?)
================================================ == third reply ------------------------------------------------ -- The SpeakFreely for Linux Mailing List
On Fri, 3 Sep 1999, Reuven Gevaryahu wrote:
> it can be only fully used by one machine behind the masq. (Walter's > solution above isn't functional for outgoing calls, as the new port > number is never received by the remote copy, which sends to 2074.) I see > three possible solutions for this, none of them perfect.
The remote machine has know that port x is forwarded to machine y on the local network. That is, both participants have to know exactly which port to use. Of course, this _is_ very inconvenient but it is suitable for at least a small set of machines until there's a transparent solution.
This may have been asked before, but does somebody care/like/desire to write a masq module/proxy for speakfreely?;-)
-- Walter Haidinger For further information, such as address or PGP public key, please refer to: http://members.kstp.at/wh/index.html
Just ommiting the U.C. Regents from the license doesn't change much. AFAIK, the main point of the license is that you can take code and not release it with your modifications. That's what makes it different than GPL.
Slashdot Mirror
Sony did developed the play station on linux. I am not sure what the native OS is but it might be linux
SuSE has been doing USB for three versions now.
SuSE 6.3, SuSE 6.4, SuSE 7.0. In fact, SuSE
developers contributed greatly in backporting the
2.4 usb stuff into the stable 2.2 kernel. See
http://www.suse.cz/development
for more details.
For a long time in my office, I put the computer in the closet. Put a blanket behind the closet door, and ran 30 foot cables to the desk for the mouse, keyboard, and monitor. After that I could not even hear my hardrive array spinning.
http://www.rme-audio.com/english/linux/alsa/alsa.h tm
Some of the professional audio cards by RME are supported by alsa. Alsa site is:
http://www.alsa-project.org
I have not tried the RME cards yet, but supposedly they are the first professional audio cards to be supported in linux!
ok you convinced me to go to a matinee show today. Much cheaper :)
has the gpl ever been tested in court?
here are some files from the mailing list which
=
= = - -
- ------------------
- ------------------
= -
= = - -
/proc/net/ip_masq/udp. Such a proxy would
= == - --
;-)
address your concerns.
-- boletus
===============================================
First mail in thread
-----------------------------------------------
The SpeakFreely for Linux Mailing List
Hi!
I'm glad that my friend contributed his setup for two machines, one
running Linux 2.2 and connected to the internet with a regular IP address.
The other (on the local network) is being masqueraded having a private IP
address.
The trick is to _masquerade_ outgoing packets and to _forward_ incoming
packets. However, you'll need kernel 2.2 for this to work, AFAIK.
Questions should be posted to the Speakfreely for Linux mailing list
.
Regards, Walter
--
Walter Haidinger
For further information, such as address or PGP public key,
please refer to: http://members.kstp.at/wh/index.html
===============================================
foo script
-----------------------------------------------
#!/bin/bash
#
# Linux kernel 2.2 masquerading/forwarding rules for Speakfreely
#
# Required tools:
# * ipchains (http://www.rustcorp.com/linux/ipchains)
# * ipmasqadm (http://juanjox.linuxhq.com)
#
# Notes:
# * The man page of ipmasqadm tells which kernel options are needed
# * There is a IPCHAINS-HOWTO available at the ipchains webpage.
#
alias ipchains=echo
alias ipmasqadm=echo
set -v; set -x # uncommend to debug
# -------------------------------------------------
#
# Ports used (speakfreely requires 2 ports for data
# and control packets, udp only)
#
# LWL uses 2076/tcp and isn't supported here.
#
SF_PORT=2074
SF_NEXT_PORT=$((SF_PORT+1)) # 2075
#
# The IP address of the local (i.e. masqueraded) host.
# Usually a private address.
#
SF_MASQ_HOSTIP=192.168.10.11
#
# The local network of which host $SF_MASQ_HOSTIP is a member of
#
SF_MASQ_NET=192.168.10.0
#
# The IP address of the _masquerading_ host. Usually _not_
# a private address.
#
SF_REAL_HOSTIP=123.012.321.210
#
# Name of the interface that connects to the internet
#
INTERFACE=eth0
# -------------------------------------------------
#
# Accept connections to local from anywhere
#
ipchains -A input -s 0/0 -d 0/0 $SF_PORT:$SF_NEXT_PORT \
-p udp -j ACCEPT
#
# Masquerade packets from local to remote
#
ipchains -A forward -s $SF_MASQ_HOSTIP -d 0/0 $SF_PORT:$SF_NEXT_PORT \
-p udp -i $INTERFACE -j MASQ
#
# Allow connections to remote sfspeaker from anywhere
#
ipchains -A output -s 0/0 -d 0/0 $SF_PORT:$SF_NEXT_PORT \
-p udp -j ACCEPT
#
# Forward ports to the masqueraded network
#
ipmasqadm portfw -a -P udp -L $SF_REAL_HOSTIP $SF_PORT \
-R $SF_MASQ_NET $SF_PORT
ipmasqadm portfw -a -P udp -L $SF_REAL_HOSTIP $SF_NEXT_PORT \
-R $SF_MASQ_NET $SF_NEXT_PORT
===============================================
replies to first item in thread:
first reply:
-----------------------------------------------
The SpeakFreely for Linux Mailing List
F***!
Please remove or comment the following three lines in the previously
attached script:
alias ipchains=echo
alias ipmasqadm=echo
set -v; set -x # uncommend to debug
Just left over from debugging...
Sorry.
Walter
===============================================
second reply
-----------------------------------------------
Walter Haidinger wrote:
>
[SNIP]
>
> SF_PORT=2076
> SF_MASQ_NET=192.168.10.20
[SNIP]
This is a really reply to: Walter Haidinger, Brian Winters, Dave
McCracken, and Ivan Kocher.
Given the current situation, Speak Freely can't be used behind masq
without special setup on the masq gateway, and even with special setup
it can be only fully used by one machine behind the masq. (Walter's
solution above isn't functional for outgoing calls, as the new port
number is never received by the remote copy, which sends to 2074.) I see
three possible solutions for this, none of them perfect.
First: Making Speak Freely a connection-based UDP program like ICQ,
which sends to the port it received data from, instead of a fixed port.
This solution is the best IMHO for the long term. Multiple users could
use speak freely from behind the masq, even conversing with the same
person! The single problem with this is that it would break
communication with older versions of Speak Freely. A call couldn't be
made directly to any specific machine behind the masq without a port
forward, but that is the case with all masq applications. Incoming calls
would come to port 2074, and would be handled by either a local
sfspeaker, or be forwarded to a default host as any other service would
be. This is Ivan's Suggestion.
Second: A userspace proxy that runs on port 2074 on the gateway, reads
the packet's host, and based on that sends the packet to the appropriate
host based on the contents of
be trivial to write, and would allow multiple machines behind the masq
to use Speak Freely at a time, if they are conversing with different
hosts. Another disadvantage is that the incoming audio will appear as a
separate incoming connection from the gateway machine to the calling
machine, but that is an aesthetic issue only. The proxy would have to
have some caching logic to operate efficiently, as reading and parsing
/proc/net/ip_masq/udp for each packet would have quite a bit of
overhead. Incoming calls would be sent to a default host specified in
the configuration, or to a sfspeaker running on another port on the
gateway. This is my suggestion, inspired by the "sfproxy" that used TCP
and required a modification to Speak Freely itself.
Third: A proxy as mentioned above done in a kernel masq module. This
would have direct access to the raw masquerade tables, so it could cut
back the overhead mentioned above, and simplify the code a bit. The
incoming audio could also be made to look as if it was coming directly
from the host, not the gateway. The "different host" rule of above
applies, as there is no easy way to distinguish packets for different
internal computers aside from hostname. In addition, writing a
kernelspace module is more difficult than a userspace proxy because of
the rules, e.g.: no floating point math, subtle locking issues on SMP,
etc. This is Dave's Suggestion.
If you can think of any better ideas, feel free to toss them onto the
list.
--RZG
(OBSpeakFreelyBug: Sometimes when one party tries to close a connection,
he is unable to since the keepalives from the other side reopen it. It
there a close command sent down the line? Should Speak Freely for
Windows ignore keepalives from a specific host for a set time after it
closes a connection to that host? Or am I missing something?)
===============================================
third reply
-----------------------------------------------
The SpeakFreely for Linux Mailing List
On Fri, 3 Sep 1999, Reuven Gevaryahu wrote:
> it can be only fully used by one machine behind the masq. (Walter's
> solution above isn't functional for outgoing calls, as the new port
> number is never received by the remote copy, which sends to 2074.) I see
> three possible solutions for this, none of them perfect.
The remote machine has know that port x is forwarded to machine y on the
local network. That is, both participants have to know exactly which port
to use. Of course, this _is_ very inconvenient but it is suitable for at
least a small set of machines until there's a transparent solution.
This may have been asked before, but does somebody care/like/desire to
write a masq module/proxy for speakfreely?
--
Walter Haidinger
For further information, such as address or PGP public key,
please refer to: http://members.kstp.at/wh/index.html
Just ommiting the U.C. Regents from the license doesn't change much. AFAIK, the main point of the license is that you can take code and not release it with your modifications. That's what makes it different than GPL.