Hi All, I have a quesiton on bandwidth limiting done by HTB to be specific. Okay now I put on a rule for FTP port 21 for 100Kbps. Now when I am retriving data from ftp server I think the port is different when doing passive ftp transfer. If I am not wrong then a new dynamic port is sent by the ftp server to the client.. and then client initiates a new connection on that port and then the real ftp data transfer happens. My Question is : Now when limiting the bandwidht will htb limit that data transfer(i.e. the real file transfer) also under 100Kbps or will that data transfer be not at all affected by the rule..? Just a novice question.. but please guide me... Thanks in Advance.. Dp _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hi there Dhirendra,
: Okay now I put on a rule for FTP port 21 for 100Kbps. Now when I am
: retriving data from ftp server I think the port is different when doing
: passive ftp transfer. If I am not wrong then a new dynamic port is sent
: by the ftp server to the client.. and then client initiates a new
: connection on that port and then the real ftp data transfer happens.
Yes. I think FTP should be summarily executed. It has been plaguing us
since the beginnings of firewalls and NAT. Sadly, another spiritually
impoverished but well-known operating system has two basic options for
file transfer: HTTP ("the Internet", of course!), and FTP (for
experts!).
Of course, on the other side of the divide, people (ab)use ssh for all
sorts of nefarious purposes....... (anybody remember a recent article in
some print periodical detailing NFS over ssh?)
There has been discussion on the question of FTP (port/passive) and
shaping on this list in the past. Here are some links.
See the following threads:
http://mailman.ds9a.nl/pipermail/lartc/2001q3/001473.html
http://mailman.ds9a.nl/pipermail/lartc/2002q1/002388.html
http://mailman.ds9a.nl/pipermail/lartc/2003q1/007498.html
See also Eric Leblond''s description of usage:
http://home.regit.org/connmark.html
: My Question is : Now when limiting the bandwidht will htb limit that
: data transfer(i.e. the real file transfer) also under 100Kbps or will
: that data transfer be not at all affected by the rule..?
That depends entirely on how you use the tools above. Take a look at Eric
Lelond''s description, and let us know if you are successful.
: Just a novice question.. but please guide me...
This question is in exactly the right forum, and I''m quite sure I
wouldn''t
call it a novice question....though it might well belong in that rumoured
FAQ.
Good luck,
-Martin
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
** Reply to message from "Martin A. Brown" <mabrown-lartc@securepipe.com> on Thu, 13 Mar 2003 20:37:33 -0600 (CST)> Hi there Dhirendra, > > : Okay now I put on a rule for FTP port 21 for 100Kbps. Now when I am > : retriving data from ftp server I think the port is different when doing > : passive ftp transfer. If I am not wrong then a new dynamic port is sent > : by the ftp server to the client.. and then client initiates a new > : connection on that port and then the real ftp data transfer happens. > > Yes. I think FTP should be summarily executed. It has been plaguing us > since the beginnings of firewalls and NAT. Sadly, another spiritually > impoverished but well-known operating system has two basic options for > file transfer: HTTP ("the Internet", of course!), and FTP (for experts!). > Of course, on the other side of the divide, people (ab)use ssh for all > sorts of nefarious purposes....... (anybody remember a recent article in > some print periodical detailing NFS over ssh?)<snip> Not trying to be argumentative or start a useless tangential thread here, but none other than Frank da Cruz provides his reason why he thinks ftp is better than ssh/scp at the following link: http://www.columbia.edu/kermit/ftpclient.html Note he is coming at this as the developer of the most capable comm program ever. jb -- Jack Bowling mailto:jbinpg@shaw.ca Prince George, BC _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Dhirendra Pal Singh
2003-Mar-14 04:19 UTC
Re: About HTB , bandwidth limiting for ftp port...
Hi Martin, First of all thanks for the info. Now among all the links you have sent I think, the one which says about using the helper and mark the packets will be the one which will best do the job. So I think what you are pointing to, is that mark all the ftp packets (control and data) with a specific mark and then do bandwidth policies on the basis of that mark.. is that right Martin? Also I ran ethereal for further analysis. To my surprise ethereal showed FTP-DATA in front of the data which is captured by it duing ftp transactions.? Any idea how did ethereal found that out ?? Thanks for helping and anticipation Dp PS.. In one of my previous querries you had asked about the idea of FAQ. I am totally for it... Martin A. Brown wrote:>Hi there Dhirendra, > > : Okay now I put on a rule for FTP port 21 for 100Kbps. Now when I am > : retriving data from ftp server I think the port is different when doing > : passive ftp transfer. If I am not wrong then a new dynamic port is sent > : by the ftp server to the client.. and then client initiates a new > : connection on that port and then the real ftp data transfer happens. > >Yes. I think FTP should be summarily executed. It has been plaguing us >since the beginnings of firewalls and NAT. Sadly, another spiritually >impoverished but well-known operating system has two basic options for >file transfer: HTTP ("the Internet", of course!), and FTP (for experts!). >Of course, on the other side of the divide, people (ab)use ssh for all >sorts of nefarious purposes....... (anybody remember a recent article in >some print periodical detailing NFS over ssh?) > >There has been discussion on the question of FTP (port/passive) and >shaping on this list in the past. Here are some links. > >See the following threads: > > http://mailman.ds9a.nl/pipermail/lartc/2001q3/001473.html > http://mailman.ds9a.nl/pipermail/lartc/2002q1/002388.html > http://mailman.ds9a.nl/pipermail/lartc/2003q1/007498.html > >See also Eric Leblond''s description of usage: > > http://home.regit.org/connmark.html > > : My Question is : Now when limiting the bandwidht will htb limit that > : data transfer(i.e. the real file transfer) also under 100Kbps or will > : that data transfer be not at all affected by the rule..? > >That depends entirely on how you use the tools above. Take a look at Eric >Lelond''s description, and let us know if you are successful. > > : Just a novice question.. but please guide me... > >This question is in exactly the right forum, and I''m quite sure I wouldn''t >call it a novice question....though it might well belong in that rumoured >FAQ. > >Good luck, > >-Martin > > >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
: > Yes. I think FTP should be summarily executed. It has been plaguing us
: > since the beginnings of firewalls and NAT. Sadly, another spiritually
: > impoverished but well-known operating system has two basic options for
: > file transfer: HTTP ("the Internet", of course!), and FTP
(for experts!).
: > Of course, on the other side of the divide, people (ab)use ssh for all
: > sorts of nefarious purposes....... (anybody remember a recent article
in
: > some print periodical detailing NFS over ssh?)
: <snip>
:
: Not trying to be argumentative or start a useless tangential thread
I engaged this tangential thread. Hook, line and sinker.
: here, but none other than Frank da Cruz provides his reason why he
: thinks ftp is better than ssh/scp at the following link:
:
: http://www.columbia.edu/kermit/ftpclient.html
Hm. Never read this before. I''ve never heard of Frank da Cruz before
either. I have heard of kermit, and remember using it a good deal in the
bad ol'' days. [ expression courtesy of a friend ]
: Note he is coming at this as the developer of the most capable comm
: program ever.
And I approach the problem from the perspective of an annoyed, grouchy,
and underfed dragon...er um...network administrator who has to deal with
broken FTP server and client implementations and installations on a
regular basis.
I have to admit that the original design of FTP is not that bad. But
PASV? That''s a jury-rigged solution to a problem which cropped up long
after the original design! And we have been stuck with essentially two
very different network layer characteristics for a "simple" protocol
over
an eternity of Internet time because people can''t live without their
FTP
servers. I don''t even want to talk about FXP.
Now--just think about all of those "Internet-enabled" applications
with
embedded FTP clients and servers, not all of which conform to or conform
to the same parts of the various FTP RFCs. A quick look at this link [1]
will show you the base materials on the FTP RFCs.
I ponder on the number of humans who have spent innumerable hours trying
to design proxies, packet filter code, and NAT code for a protocol
designed before NAT and firewalls. Surely there is a better way for us to
spend our time. Jettison FTP. But, sadly, that won''t be happening
anytime soon.
My counterarguments to Frank da Cruz in the matter of FTP versus another
protocol are from the perspective of a network administrator, not a
communications software programmer. I''ll use HTTP as an example foil
for
FTP in the argument:
- SSL can be used with HTTP (and many other application layer protocols)
- HTTP is scriptable (wget, perl libwww aka LWP::simple and friends,
python urllib, among others, if you don''t like using nc and lots of
shell)
- I wouldn''t consider that FTP''s ASCII vs binary mode has an
advantage
over MIME-types which are part of HTTP
- HTTP/1.1 (commonly, although not universally deployed) supports byte
ranges, for file download resumption
If I were to suggest a replacement protocol for (scriptable) FTP, however,
I would suggest rsync (InterMezzo seems young yet--and it, amusingly,
travels over HTTP):
- rsync is a superior solution to HTTP or FTP for bulk push or pull file
transfer, allowing resumption, file permissions, dates, and (sym)links
- rsync supports the notion of users, as do FTP (and HTTP)
- rsync can tunnel over ssh (I classify this technique as an abuse of
ssh, although I liberally employ this same strategy.)
Frank da Cruz''s arguments have unbeatable validity though in that FTP
is a
much more widely supported protocol in clients and servers on uncommon,
embedded, or non-commodity operating systems and devices--exactly where
they are a problem for network administrators. Conversely, my convenience
might very well be his frustration.
Many technologies are abused, overused, employed in a manner radically
different from their design or extended beyond usefulness. FTP''s
lifetime
has been tremendously extended. HTTP and SSH are the problems of our
future (if not today)....
With all of the above said, I would not begrudge a user the use of FTP,
as it is a widely supported protocol.
I would simply like to see FTP wither and die on the vine of progress.
-Martin
[1] http://www.wu-ftpd.org/rfc/
P.S., I think I just exceeded my rant quota for calendar year 2003.
Apologies in advance to those who suffered through it.
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Dhirendra Pal Singh
2003-Mar-14 19:00 UTC
Re: [offtopic FTP rant] HTB, bandwidth limiting for ftp
Hey Martin... Thanks for this detailed info... I liked reading it till the end... Actually one of the developer of FTP Protocol lives in Bay area(California) itself and I happen to know him(not personally). Its good to know the drawbacks of this protocol..sometime if we run into discussion may be I can talk... ;-) And anyhow my iq has increased, again after reading your post... Thanks Dp Martin A. Brown wrote:> : > Yes. I think FTP should be summarily executed. It has been plaguing us > : > since the beginnings of firewalls and NAT. Sadly, another spiritually > : > impoverished but well-known operating system has two basic options for > : > file transfer: HTTP ("the Internet", of course!), and FTP (for experts!). > : > Of course, on the other side of the divide, people (ab)use ssh for all > : > sorts of nefarious purposes....... (anybody remember a recent article in > : > some print periodical detailing NFS over ssh?) > : <snip> > : > : Not trying to be argumentative or start a useless tangential thread > >I engaged this tangential thread. Hook, line and sinker. > > : here, but none other than Frank da Cruz provides his reason why he > : thinks ftp is better than ssh/scp at the following link: > : > : http://www.columbia.edu/kermit/ftpclient.html > >Hm. Never read this before. I''ve never heard of Frank da Cruz before >either. I have heard of kermit, and remember using it a good deal in the >bad ol'' days. [ expression courtesy of a friend ] > > : Note he is coming at this as the developer of the most capable comm > : program ever. > >And I approach the problem from the perspective of an annoyed, grouchy, >and underfed dragon...er um...network administrator who has to deal with >broken FTP server and client implementations and installations on a >regular basis. > >I have to admit that the original design of FTP is not that bad. But >PASV? That''s a jury-rigged solution to a problem which cropped up long >after the original design! And we have been stuck with essentially two >very different network layer characteristics for a "simple" protocol over >an eternity of Internet time because people can''t live without their FTP >servers. I don''t even want to talk about FXP. > >Now--just think about all of those "Internet-enabled" applications with >embedded FTP clients and servers, not all of which conform to or conform >to the same parts of the various FTP RFCs. A quick look at this link [1] >will show you the base materials on the FTP RFCs. > >I ponder on the number of humans who have spent innumerable hours trying >to design proxies, packet filter code, and NAT code for a protocol >designed before NAT and firewalls. Surely there is a better way for us to >spend our time. Jettison FTP. But, sadly, that won''t be happening >anytime soon. > >My counterarguments to Frank da Cruz in the matter of FTP versus another >protocol are from the perspective of a network administrator, not a >communications software programmer. I''ll use HTTP as an example foil for >FTP in the argument: > > - SSL can be used with HTTP (and many other application layer protocols) > - HTTP is scriptable (wget, perl libwww aka LWP::simple and friends, > python urllib, among others, if you don''t like using nc and lots of > shell) > - I wouldn''t consider that FTP''s ASCII vs binary mode has an advantage > over MIME-types which are part of HTTP > - HTTP/1.1 (commonly, although not universally deployed) supports byte > ranges, for file download resumption > >If I were to suggest a replacement protocol for (scriptable) FTP, however, >I would suggest rsync (InterMezzo seems young yet--and it, amusingly, >travels over HTTP): > > - rsync is a superior solution to HTTP or FTP for bulk push or pull file > transfer, allowing resumption, file permissions, dates, and (sym)links > - rsync supports the notion of users, as do FTP (and HTTP) > - rsync can tunnel over ssh (I classify this technique as an abuse of > ssh, although I liberally employ this same strategy.) > >Frank da Cruz''s arguments have unbeatable validity though in that FTP is a >much more widely supported protocol in clients and servers on uncommon, >embedded, or non-commodity operating systems and devices--exactly where >they are a problem for network administrators. Conversely, my convenience >might very well be his frustration. > >Many technologies are abused, overused, employed in a manner radically >different from their design or extended beyond usefulness. FTP''s lifetime >has been tremendously extended. HTTP and SSH are the problems of our >future (if not today).... > >With all of the above said, I would not begrudge a user the use of FTP, >as it is a widely supported protocol. > >I would simply like to see FTP wither and die on the vine of progress. > >-Martin > > [1] http://www.wu-ftpd.org/rfc/ > >P.S., I think I just exceeded my rant quota for calendar year 2003. > Apologies in advance to those who suffered through it. > > >
On Friday 14 March 2003 05:19, Dhirendra Pal Singh wrote:> Hi Martin, > > First of all thanks for the info. > Now among all the links you have sent I think, the one which says about > using the helper and mark the packets will be the one which will best do > the job. > > So I think what you are pointing to, is that mark all the ftp packets > (control and data) with a specific mark and then do bandwidth policies > on the basis of that mark.. is that right Martin? > > Also I ran ethereal for further analysis. To my surprise ethereal showed > FTP-DATA in front of the data which is captured by it duing ftp > transactions.? Any idea how did ethereal found that out ?? > > Thanks for helping and anticipation > Dp > > PS.. In one of my previous querries you had asked about the idea of FAQ. > I am totally for it...I covered the subject on www.docum.org on the faq page :) Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Dhirendra Pal Singh
2003-Mar-15 00:16 UTC
Re: About HTB , bandwidth limiting for ftp port...
Hi Stef, I did check on docum or org specially the FAQ but couldnt find anything. http://www.docum.org/stef.coene/qos/docs/ was the link I searched. If you could please send me the link, it would be great. Thanks in advance Dp Stef Coene wrote:>On Friday 14 March 2003 05:19, Dhirendra Pal Singh wrote: > > >>Hi Martin, >> >>First of all thanks for the info. >>Now among all the links you have sent I think, the one which says about >>using the helper and mark the packets will be the one which will best do >>the job. >> >>So I think what you are pointing to, is that mark all the ftp packets >>(control and data) with a specific mark and then do bandwidth policies >>on the basis of that mark.. is that right Martin? >> >>Also I ran ethereal for further analysis. To my surprise ethereal showed >>FTP-DATA in front of the data which is captured by it duing ftp >>transactions.? Any idea how did ethereal found that out ?? >> >>Thanks for helping and anticipation >>Dp >> >>PS.. In one of my previous querries you had asked about the idea of FAQ. >>I am totally for it... >> >> >I covered the subject on www.docum.org on the faq page :) > >Stef > > >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Saturday 15 March 2003 01:16, Dhirendra Pal Singh wrote:> Hi Stef, > I did check on docum or org specially the FAQ but couldnt find anything. > http://www.docum.org/stef.coene/qos/docs/ was the link I searched. > > If you could please send me the link, it would be great.Go to www.docum.org and click on faq in the left frame. It''s the last entry in the list. But I only added a link to an external page for more information. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/