filtering .mp3 packets

filtering .mp3 packets

[William Stanard]

We've been having some difficulty finding the vocabulary to describe
filtering content (for example .mp3 files) over TCP-IP. We would like to
set up our Linux server to do some "trapping" of packets containing .mp3
files with an eye toward using Linux enabled routing to clean our campus
of an overwhelming dose of music downloads and trading. To do this
exploration, I need to know what I should call the process I'm trying to
perform. Any vocabulary that you can suggest?

Bill Stanard
Academic Computing
Palmer Trinity School
305.969.4239



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: filtering .mp3 packets

[Ray Olszewski]

William Stanard wrote:
> We've been having some difficulty finding the vocabulary to describe
> filtering content (for example .mp3 files) over TCP-IP. We would like to
> set up our Linux server to do some "trapping" of packets containing .mp3
> files with an eye toward using Linux enabled routing to clean our campus
> of an overwhelming dose of music downloads and trading. To do this
> exploration, I need to know what I should call the process I'm trying to
> perform. Any vocabulary that you can suggest?

What you are seeking to do is application-level (or content-based) 
packet filtering, and the stock Linux routing capabilities are not 
really the way to go about it.

What you can do at the conventional level of iptables rules is block 
specific ports and IP addresses. This capability might, when combined 
with some traffic analysis, allow you to interfere with the downloads in 
question ... but P2P apps these days are pretty smart about working 
around firewalls, often opting to use port 80 (www) to disguise their 
nature.

To do content-based filtering, you need to do one of the following things.

1. Force LAN hosts to go through a proxy server to access the standard 
services (smtp, www, and the like), while blocking ALL direct access to 
the Internet. Then configure the proxy server to analyze and filter 
content. Offhand, I don't know of an Open Source proxy server that will 
do the sort of filtering you want ... partly because I don't *quite* 
know what you want, beyond your example ... but you might want to see if 
either "filterproxy" or "middleman" can be adapted to your needs.

2. Add application-level filtering to the iptables capability, probably 
by dropping in some sort of userspace module that the router uses to 
process all packets. Take a look at FireFlier 
(http://fireflier.sourceforge.net/index.html) for some help here. Its 
documentation is a bit sketchy, but it does support app-level filtering 
in userspace, so it might be adaptable to your needs.

(BTW, please remember that app-level filtering in userspace is a bit 
more demanding of CPU time thansimple kernel-level filtering ... if your 
router is an old, slow Linux host like mine is, you may need to upgrade it.)

Even if you do something like either of these things, remember that 
there willl be workarounds (using password-protected zip'd files, or 
using https, for example) that will interfere with app-level filtering. 
And also remember that a server can only filter what it sees ... so 
controls at your router can restrict downloads from, and uploads to, the 
Internet, but not LAN-to-LAN exchanges ... which may be what you meant 
by "trading". (I suspect there are ways to do this too, but they are not 
immediately obvious to me and they probably impose significant LAN 
overhead.)

If you move ahead on this project, please don't hesitate to pose more 
specific questions. I'd be curious to read what you come up with as a 
solution here ... this sort of filtering seems to be an underaddressed 
issue in Linux development.


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: filtering .mp3 packets

[John T. Williams]

Bill Stanard,

There are many ways to attack the mp3 problem, but the one you trying for is
probably the most problematic.  You would not only need to check packets for
mp3's, but you would also have to understand the various protocols used by
file sharing software.   My university tracks the amount of bytes uploaded
by a user and limits bandwidth of users who upload too much. (indicating
that the user is doing something of which the school wouldn't approve).
There are very few uses for massive uploads which would not violate the
average university's Internet use agreement, and those cases could be
addressed on a user by user bases.


However the only way to truly limit the behavior will be to convince the
students not to do it.  Otherwise there will always be a work around.
Packet sniffing is questionable ethical and in some states may violate the
rights of the users, however you can probably do ports scans to protect the
network security and find people running servers on ports which are commonly
used for file sharing.  If someone is running a publicly open server, I
cannot see any problem with finding out what content is being served.  You
could probably write a robot of some sort that could search the file sharing
ports, and raise a flag if it finds contents with *.avi or *.mp3 on it, but
I would check with your legal department before doing so.



----- Original Message ----- 
From: "William Stanard" <wstanard@palmertrinity.org>
To: <linux-newbie@vger.kernel.org>
Sent: Monday, April 25, 2005 7:27 AM
Subject: filtering .mp3 packets


> We've been having some difficulty finding the vocabulary to describe
> filtering content (for example .mp3 files) over TCP-IP. We would like to
> set up our Linux server to do some "trapping" of packets containing .mp3
> files with an eye toward using Linux enabled routing to clean our campus
> of an overwhelming dose of music downloads and trading. To do this
> exploration, I need to know what I should call the process I'm trying to
> perform. Any vocabulary that you can suggest?
>
> Bill Stanard
> Academic Computing
> Palmer Trinity School
> 305.969.4239
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: filtering .mp3 packets

[J.]

On Tue, 26 Apr 2005, John T. Williams wrote:

> From: "William Stanard" <wstanard@palmertrinity.org>
> To: <linux-newbie@vger.kernel.org>
> Sent: Monday, April 25, 2005 7:27 AM
> Subject: filtering .mp3 packets
> 
> > We've been having some difficulty finding the vocabulary to describe
> > filtering content (for example .mp3 files) over TCP-IP. We would like to
> > set up our Linux server to do some "trapping" of packets containing .mp3
> > files with an eye toward using Linux enabled routing to clean our campus
> > of an overwhelming dose of music downloads and trading. To do this
> > exploration, I need to know what I should call the process I'm trying to
> > perform. Any vocabulary that you can suggest?
> >
> > Bill Stanard
> > Academic Computing
> > Palmer Trinity School
> > 305.969.4239

> Bill Stanard,
> 
> There are many ways to attack the mp3 problem, but the one you trying for is
> probably the most problematic.  You would not only need to check packets for
> mp3's, but you would also have to understand the various protocols used by
> file sharing software.   My university tracks the amount of bytes uploaded
> by a user and limits bandwidth of users who upload too much. (indicating
> that the user is doing something of which the school wouldn't approve).
> There are very few uses for massive uploads which would not violate the
> average university's Internet use agreement, and those cases could be
> addressed on a user by user bases.
> 
> However the only way to truly limit the behavior will be to convince the
> students not to do it.  Otherwise there will always be a work around.
> Packet sniffing is questionable ethical and in some states may violate the
> rights of the users, however you can probably do ports scans to protect the
> network security and find people running servers on ports which are commonly
> used for file sharing.  If someone is running a publicly open server, I
> cannot see any problem with finding out what content is being served.  You
> could probably write a robot of some sort that could search the file sharing
> ports, and raise a flag if it finds contents with *.avi or *.mp3 on it, but
> I would check with your legal department before doing so.

I have to agree with that. Especially the legal part. From a
legal point [europe, dont know 'bout the states] filtering in itself is 
not so much of a legal problem if you have informed all the clients of 
your network in a proper legal way and made sure they understood it;
and they did agree with it. 

It's what you do with the results and what your intentions are. You can
filter what you want on your own network but it's no use if your not
allowed to use it. 

From a pratical point what you can do is detect the biggest traffic
generators and isolate them from the rest of the pack. Small script that
analyzes stats from the firewall etc..

Here we run several OpenBSD firewalls [sorry] and analyze all trafic on a
weekly basis, protocol by protocol, port, quantity. We know what to expect
and what's reasonable in terms of traffic amount, what protocols etc..

Excessive uploaders and downloaders are put into a special watch queue
for some specific amount of time. When they cross a certain boundry the
case is presented and analyzed by a small group of people consisting out
of several non-techno's, dean etc. And they decide what to do with that
knowledge. It doesn't so much matter what the content is in most cases.

The solution is in the combination of different tools, education of the
students, good user legal contract and a simple but robust admin plan that
keeps itself intact.

Filtering on specific content can be done, but is costly very costly in
usertime, in admin time, hardware spec's e.g. money... 

Filtering in user space is praticly undo'able after a certain amount of
traffic. Try to run an app. like driftnet for 30min's on a sniffer
machine that listens to a network with 100/200 users. ;-) And that can
easily be bypassed by clients.

In the early days picking out for example napster with pcap was easy.
((ip[2:2] - ((ip[0]&0x0f)<<2) - (tcp[12]>>2)) = 4 && \
 tcp[(tcp[12]>>2):4] = 0x53454e44) || \
 ((ip[2:2] - ((ip[0]&0x0f)<<2) - (tcp[12]>>2)) = 3 && \
 tcp[(tcp[12]>>2):2] = 0x4745 && tcp[(tcp[12]>>2)+2]=0x54)

Or later by using something like `ngrep' .

Easy because the amount of traffic was reasonable low, and the p2p hadn't
hit the scene that hard. P2p has also a quirck, like the 90/10 rule
or 80/20 rule, where 80 percent of the users are often sharing constantly 
20 percent of the total content.

If you analyze your traffic carefully and you notice that only one or two
protocols are being used you could make a tcpdump filter like the one
listed above and save a number of push packets for each
connection. After that run a program over it trying to guess what data it
may or may not contains but you will always be behind.

There are commercial systems for gov. and large companies available
some tux based. Most of them require either special hardware and/or a
big budget. While the results are variable. Afterall we are all subject to
the same limitations.

Filtering on just .mp3 files is hel .

J.

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: filtering .mp3 packets

[simon]

hello Bill

>>We've been having some difficulty finding the vocabulary to describe
>>filtering content (for example .mp3 files) over TCP-IP. We would like to
>>set up our Linux server to do some "trapping" of packets containing .mp3
>>files with an eye toward using Linux enabled routing to clean our campus
>>of an overwhelming dose of music downloads and trading. To do this
>>exploration, I need to know what I should call the process I'm trying to
>>perform. Any vocabulary that you can suggest?
>>
>>Bill Stanard

may be you can write a kernel module using the netfilter to perform that...
netfilter is a very powerful way to build every kind of filter.
you can find some informations here : 
http://www.ouah.org/p61-0x0d_Hacking_the_Linux_Kernel_Network_Stack.txt

regards

simon
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: filtering .mp3 packets

[J.]

On Wed, 27 Apr 2005, simon wrote:
> hello Bill
> 
> >>We've been having some difficulty finding the vocabulary to describe
> >>filtering content (for example .mp3 files) over TCP-IP. We would like to
> >>set up our Linux server to do some "trapping" of packets containing .mp3
> >>files with an eye toward using Linux enabled routing to clean our campus
> >>of an overwhelming dose of music downloads and trading. To do this
> >>exploration, I need to know what I should call the process I'm trying to
> >>perform. Any vocabulary that you can suggest?
> >>
> >>Bill Stanard
> 
> may be you can write a kernel module using the netfilter to perform that...
> netfilter is a very powerful way to build every kind of filter.
> you can find some informations here : 
> http://www.ouah.org/p61-0x0d_Hacking_the_Linux_Kernel_Network_Stack.txt
> 
> regards
> 
> simon
Wednesday, April 27 21:36:30

Problem is not catching the actual TCP packets, but classifying them like: 
This TCP packet is 100% sure, a packet that contains a piece of mp3 data .

Try to encode a mp3 file, split it into very tiny chunks, remove all but
one, and see if you can guess if it's a mp3 file.. 

There is also encryption to deal with, terrible implemented TCP stacks in
cheap modems and routers when trying to reassemble a whole stream,
disecting, guessing different protocols and levels.. It's definitively
a challenge so to speak..

J.

-- 
Don't worry Ma'am. We're university students, - we know what we're doing.

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: filtering .mp3 packets

[John T. Williams]

I don't know mp3 format, but surely they all have a header that is
identifiable?  I mean where they store information about the mp3 such as
speed and title and such.  Surely you could id an mp3 from that information.
and terminate the stream.


----- Original Message ----- 
From: "J." <mailing-lists@xs4all.nl>
To: <linux-newbie@vger.kernel.org>
Sent: Wednesday, April 27, 2005 3:51 PM
Subject: Re: filtering .mp3 packets


> On Wed, 27 Apr 2005, simon wrote:
> > hello Bill
> >
> > >>We've been having some difficulty finding the vocabulary to describe
> > >>filtering content (for example .mp3 files) over TCP-IP. We would like
to
> > >>set up our Linux server to do some "trapping" of packets containing
.mp3
> > >>files with an eye toward using Linux enabled routing to clean our
campus
> > >>of an overwhelming dose of music downloads and trading. To do this
> > >>exploration, I need to know what I should call the process I'm trying
to
> > >>perform. Any vocabulary that you can suggest?
> > >>
> > >>Bill Stanard
> >
> > may be you can write a kernel module using the netfilter to perform
that...
> > netfilter is a very powerful way to build every kind of filter.
> > you can find some informations here :
> > http://www.ouah.org/p61-0x0d_Hacking_the_Linux_Kernel_Network_Stack.txt
> >
> > regards
> >
> > simon
> Wednesday, April 27 21:36:30
>
> Problem is not catching the actual TCP packets, but classifying them like:
> This TCP packet is 100% sure, a packet that contains a piece of mp3 data .
>
> Try to encode a mp3 file, split it into very tiny chunks, remove all but
> one, and see if you can guess if it's a mp3 file..
>
> There is also encryption to deal with, terrible implemented TCP stacks in
> cheap modems and routers when trying to reassemble a whole stream,
> disecting, guessing different protocols and levels.. It's definitively
> a challenge so to speak..
>
> J.
>
> -- 
> Don't worry Ma'am. We're university students, - we know what we're doing.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: filtering .mp3 packets

[Ray Olszewski]

John T. Williams wrote:
> I don't know mp3 format, but surely they all have a header that is
> identifiable?  I mean where they store information about the mp3 such as
> speed and title and such.  Surely you could id an mp3 from that information.
> and terminate the stream.
[...]

"Surely" is one of those tricky words. As with most things involving 
traffic analysis, the devil is in the details.

Yes, an MP3 file has some known structure, in the form of (a) an 
*optional* (NOT required, and in practice not always present) "ID3" 
block that provides the sort of information you mention, and (b) a 
structured header to each actual block of musical data. (For more on 
both of these, take a look at 
http://www.oreilly.com/catalog/mp3/chapter/ch02.html .)

Even so, ID'ing an MP3 from this implementation is tricky, at two levels.

First, the standard kernel routing code cannot do it. You still need 
special code to analyze packet content, probably userspace code. As far 
as I know (and, to judge from the other responses in this thread, no one 
else here knows different), there is no off-the-shelf implementation 
available of this sort of filter.

Second, making the "signature" obscure is fairly trivial. Any encrypted 
transfer (e.g., scp, https) makes it impossible for intermediate points 
to analyze packet contents (since any method of doing so would 
constitute a successful man-in-the-middle attack on the encryption, 
hence be a security hole requiring repair. Even doing ZIP of tgz 
compression of the file would make life hard for the router.

Beyond that, the original poster mentioned MP3 as an example of the kind 
of file he wanted to detect and block. If there are several formats he 
wants to block (e.g., OGG, WMA as well as MP3), he'd have to do this on 
a type-by-type basis.

A better strategy might be to monitor the content of the outgoing 
packets to look for (say) http requests that ask for files with .mp3 
extensions to be downloaded. Then pseudo-404 the responses to them. This 
still has its problems, like the encryption problem I mention above, but 
it might be of some help and easier than dissecting the incoming binaries.

BTW, I did look around a bit for solutions, and all I came up with were 
ones that were variants on blacklisting the IP addresses of known 
sources of music files or were straightforward uses of proxy servers. If 
anyone has more general a content-level solution, it would seem to be 
proprietary, not Open Source.



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: filtering .mp3 packets

[joy merwin monteiro]

Hi,

Since this thread dealt mainly with blocking p2p downloading of 
mp3s since they consume large b/w, and has come to a discussion of
https and scp,
I wanted to know wether any p2p protocol uses the above......
or even wehter they use compression.......

if neither is the case, what John said seems to be reasonable,, since
MP3 _has_ to have a header......

blocking all outgoing http requests for or blocking all incoming MP3's
will prevent genuine users who need it. alternatively, there should be
a limit of connections that a user can open at a single time to get
MP3s... since most p2p protocol that i've encountered always try to process
the waiting list as fast as possible by downloading multiple files all
at once....

Comments. anyone?

regards,
Joy

> Second, making the "signature" obscure is fairly trivial. Any encrypted
> transfer (e.g., scp, https) makes it impossible for intermediate points
> to analyze packet contents (since any method of doing so would
> constitute a successful man-in-the-middle attack on the encryption,
> hence be a security hole requiring repair. Even doing ZIP of tgz
> compression of the file would make life hard for the router.
> 
> Beyond that, the original poster mentioned MP3 as an example of the kind
> of file he wanted to detect and block. If there are several formats he
> wants to block (e.g., OGG, WMA as well as MP3), he'd have to do this on
> a type-by-type basis.
> 
> A better strategy might be to monitor the content of the outgoing
> packets to look for (say) http requests that ask for files with .mp3
> extensions to be downloaded. Then pseudo-404 the responses to them. This
> still has its problems, like the encryption problem I mention above, but
> it might be of some help and easier than dissecting the incoming binaries.
> 
> BTW, I did look around a bit for solutions, and all I came up with were
> ones that were variants on blacklisting the IP addresses of known
> sources of music files or were straightforward uses of proxy servers. If
> anyone has more general a content-level solution, it would seem to be
> proprietary, not Open Source.
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs
> 


-- 
<ed__> riel: if it were a vax, gcc would probably be an opcode

	- excerpt from #kernelnewbies
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: filtering .mp3 packets

[Stephen Ray]

I don't know about compression, but I see two problems with filtering 
based on mp3 headers (other than the apparent lack of tools supporting 
it).  The first is that some p2p protocols, such as Bittorrent, divide 
the files into chunks, sending and receiving them out of order.  So the 
header may be the last part of the file to be sent.  The other problem 
is that in any protocol, an mp3 file is going to be too big for a tcp/ip 
packet.  It seems very likely that an mp3 packet will be split across 
two or more packets.  That would make identification more problematic, 
as you would have to make sure that a header fragment was a header 
fragment, and not part of a legitimate file that happens to be 
coincidentally identical to part of a mp3 header.

Stephen

joy merwin monteiro wrote:
> Hi,
> 
> Since this thread dealt mainly with blocking p2p downloading of 
> mp3s since they consume large b/w, and has come to a discussion of
> https and scp,
> I wanted to know wether any p2p protocol uses the above......
> or even wehter they use compression.......
> 
> if neither is the case, what John said seems to be reasonable,, since
> MP3 _has_ to have a header......
> 
> blocking all outgoing http requests for or blocking all incoming MP3's
> will prevent genuine users who need it. alternatively, there should be
> a limit of connections that a user can open at a single time to get
> MP3s... since most p2p protocol that i've encountered always try to process
> the waiting list as fast as possible by downloading multiple files all
> at once....
> 
> Comments. anyone?
> 
> regards,
> Joy
> 
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: filtering .mp3 packets

[joy merwin monteiro]

Hi,

Was going through lartc HOWTO and it says  that Linux
can throttle b/w TO certain computers on the network....
this can assure that all computers get the same amount of b/w
p2p or no p2p.......
how 'bout it, setting some amount of bandwidth to each user,
so he cannot receive or send more than his quota
and hose the network.......

Joy

On 4/29/05, Stephen Ray <stephen@mrmighty.net> wrote:
> I don't know about compression, but I see two problems with filtering
> based on mp3 headers (other than the apparent lack of tools supporting
> it).  The first is that some p2p protocols, such as Bittorrent, divide
> the files into chunks, sending and receiving them out of order.  So the
> header may be the last part of the file to be sent.  The other problem
> is that in any protocol, an mp3 file is going to be too big for a tcp/ip
> packet.  It seems very likely that an mp3 packet will be split across
> two or more packets.  That would make identification more problematic,
> as you would have to make sure that a header fragment was a header
> fragment, and not part of a legitimate file that happens to be
> coincidentally identical to part of a mp3 header.
> 
> Stephen
> 
> joy merwin monteiro wrote:
> > Hi,
> >
> > Since this thread dealt mainly with blocking p2p downloading of
> > mp3s since they consume large b/w, and has come to a discussion of
> > https and scp,
> > I wanted to know wether any p2p protocol uses the above......
> > or even wehter they use compression.......
> >
> > if neither is the case, what John said seems to be reasonable,, since
> > MP3 _has_ to have a header......
> >
> > blocking all outgoing http requests for or blocking all incoming MP3's
> > will prevent genuine users who need it. alternatively, there should be
> > a limit of connections that a user can open at a single time to get
> > MP3s... since most p2p protocol that i've encountered always try to process
> > the waiting list as fast as possible by downloading multiple files all
> > at once....
> >
> > Comments. anyone?
> >
> > regards,
> > Joy
> >
> >
> 


-- 
<ed__> riel: if it were a vax, gcc would probably be an opcode

	- excerpt from #kernelnewbies
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: filtering .mp3 packets

[Ray Olszewski]

joy merwin monteiro wrote:
> Hi,
> 
> Was going through lartc HOWTO and it says  that Linux
> can throttle b/w TO certain computers on the network....
> this can assure that all computers get the same amount of b/w
> p2p or no p2p.......
> how 'bout it, setting some amount of bandwidth to each user,
> so he cannot receive or send more than his quota
> and hose the network.......
[...]

Whether this is a good solution or not depends on what the perceived 
problem is.

If the issue is file sharers tying up bandwidth to the Internet, this is 
an excellent approach. It will limit all heavy users indiscriminately, 
though, so someone who (say) does a network-based upgrade of his or her 
Linux host (an "apt-get upgrade" in Debian terms, or the equivalent for 
other distros) or downloads ISO images of Linux-distro CDs will be 
limited in the same way as someone doing a lot of music downloads.

If the issue is preventing use of the Internet connection to download 
unauthorized copies of copyrighted materials, then this approach is 
probably not sufficiently targeted to accomplish what the original 
poster requested. It has the "false positive" problem in spades.

If the issue is inhibiting on-LAN exchanges of unauthorized copies of 
copyrighted materials ... well in that case, this entire discussion's 
focus on solutions at the router level is completely misplaced. If that 
is the perceived problem (in a college setting, I can easily imagine it 
being so, especially of the LAN provides service to dorm rooms), the 
solution needs to involve a heavy dose of on-LAN traffic sniffing. Even 
talking about that approach requires less abstraction from a particular 
LAN implementation then we have had here so far.

Whatever the case, this idea does have the advantage, relative to other 
approaches that have been discussed in this thread, of being based on 
Linux kernel capabilities that actually exist, not extensions that 
"should be easy" but that, in fact, have not been done, or (I suspect) 
even looked at closely by anyone with the technical expertise actually 
to implement them.

BTW, lest I be misinterpreted, I am not trying to present an argument 
for or against actually doing any particular kind of content filtering. 
I am only trying to think aloud about the technical issues involved in 
implementing solutions to various desires for control of network use.

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: filtering .mp3 packets

[joy merwin monteiro]

> Whether this is a good solution or not depends on what the perceived
> problem is.
> 
> If the issue is file sharers tying up bandwidth to the Internet, this is
> an excellent approach. It will limit all heavy users indiscriminately,
> though, so someone who (say) does a network-based upgrade of his or her
> Linux host (an "apt-get upgrade" in Debian terms, or the equivalent for
> other distros) or downloads ISO images of Linux-distro CDs will be
> limited in the same way as someone doing a lot of music downloads.

IMO, a local campus LAN with limited bandwidth, a net upgrade of
your system is as bad as p2p dowloading....... as you have mentioned,
if bandwidth
saving is the only issue, some legit computers can be allocated more b/w for 
such legitimate reasons.
> 
> If the issue is preventing use of the Internet connection to download
> unauthorized copies of copyrighted materials, then this approach is
> probably not sufficiently targeted to accomplish what the original
> poster requested. It has the "false positive" problem in spades.
> 
Totally agree, but if this problem had a ready solution, Linux based
or otherwise,
the RIAA would have made it mandatory by now :-)

> If the issue is inhibiting on-LAN exchanges of unauthorized copies of
> copyrighted materials ... well in that case, this entire discussion's
> focus on solutions at the router level is completely misplaced. If that
> is the perceived problem (in a college setting, I can easily imagine it
> being so, especially of the LAN provides service to dorm rooms), the
> solution needs to involve a heavy dose of on-LAN traffic sniffing. Even
> talking about that approach requires less abstraction from a particular
> LAN implementation then we have had here so far.
>
 
From my experience (being presently in college), I would prefer to burn a
CD with 700 MB of songs and distribute it to all the people who need it rather
than trying to send it over a LAN..... people who want to do it 
_will_ find a way to do it......

-- 
<ed__> riel: if it were a vax, gcc would probably be an opcode

	- excerpt from #kernelnewbies
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs