Re: Added native socks support to libc in FreeBSD 7
Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Raffaele De Lorenzo wrote: Hi, i added a native (client) Socks V4/V5 support inside FreeBSD libc library. The work is based of my project (see http://csocks.altervista.org) CSOCKS. You can get it here: http://csocks.altervista.org/download/FreeBSD_libc.tar.gz Would you mind sending a PR for this? It sounds useful to me and I don't want it to lose... Cheers, - -- Xin LI <[EMAIL PROTECTED]>http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHWeEDhcUczkLqiksRAinRAJ9kxtecWCxOiXEH4kA7RW3veoYyiACg2KkX EUQGp7FdQIHmqlDFUN3MV88= =9dnN -END PGP SIGNATURE- . Hi, Many thanks for your intersted. You can go to http://csocks.altervista.org or in the FreeBSD ports collections (you must use the search keyword "csocks"). Instead, If you want to test the new libc with native socks support please download and install FreeBSD_libc.tar (fetch http://csocks.altervista.org/download/FreeBSD_libc.tar.gz). If you have any question for the installation procedure, you can contact me. cheers Raffaele ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Current problem reports assigned to freebsd-net@FreeBSD.org
Current FreeBSD problem reports Critical problems S Tracker Resp. Description f kern/115360 net[ipv6] IPv6 address and if_bridge don't play well toge 1 problem total. Serious problems S Tracker Resp. Description a kern/38554 netchanging interface ipaddress doesn't seem to work s kern/39937 netipstealth issue f kern/62374 netpanic: free: multiple frees s kern/81147 net[net] [patch] em0 reinitialization while adding aliase o kern/92552 netA serious bug in most network drivers from 5.X to 6.X s kern/95665 net[if_tun] "ping: sendto: No buffer space available" wit s kern/105943 netNetwork stack may modify read-only mbuf chain copies o kern/106316 net[dummynet] dummynet with multipass ipfw drops packets o kern/106438 net[hme] hme0: Interface unable to do tx and rx checksumm o kern/108542 net[bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/110959 net[ipsec] Filtering incoming packets with enc0 does not o kern/112528 net[nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net[patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 netIP v4 udp fragmented packet reject o kern/113457 net[ipv6] deadlock occurs if a tunnel goes down while the o kern/113842 net[ipv6] PF_INET6 proto domain state can't be cleared wi o kern/114714 net[gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net[fxp] fxp looses ability to speak with traffic o kern/115239 net[ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net6.2-STABLE panic during use of multi-cast networking c o kern/116172 netNetwork / ipv6 recursive mutex panic o kern/116185 netif_iwi driver leads system to reboot o kern/116328 net[bge]: Solid hang with bge interface o kern/116747 net[ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 netifconfig tunX destroy: panic o kern/117271 net[tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 netDuplicate IP on different interfaces o bin/117448 net[carp] 6.2 kernel crash o kern/117717 netKernel panic with Bittorrent client. 29 problems total. Non-critical problems S Tracker Resp. Description o conf/23063 net[PATCH] for static ARP tables in rc.network s bin/41647netifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net[nfs] [patch] NFS root configurations without dynamic s kern/60293 netFreeBSD arp poison patch o kern/95267 netpacket drops periodically appear f kern/95277 net[netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net[netisr] suggestion to fix suboptimal network polling o kern/102035 net[plip] plip networking disables parallel port printing o conf/102502 net[patch] ifconfig name does't rename netgraph node in n o conf/107035 net[patch] bridge interface given in rc.conf not taking a o kern/112654 net[pcn] Kernel panic upon if_pcn module load on a Netfin o kern/114915 net[patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net[patch] fstat(1): add INET/INET6 socket details as in o bin/117339 net[patch] route(8): loading routing management commands 14 problems total. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Added native socks support to libc in FreeBSD 7
Julian Elischer wrote:
Raffaele De Lorenzo wrote:
Hi,
i added a native (client) Socks V4/V5 support inside FreeBSD libc
library. The work is based of my project (see
http://csocks.altervista.org) CSOCKS.
You can get it here:
thanks for doing this. now we just need to see if thre is someone who
knows socks who can look at it..
The big question is whether it should be in libc or not. Making
everyone who does not use socks pay a cost is a big decision.
Obviously, for people who use socks, it is good. What is the cost for
others?
.
Hi,
I understand your doubts...
The socks implementation wraps some syscall socket functions like
"_connect" and "_bind" trasparently from the applications. When one of
these is called, the "socks" check starts:
1) Load rules from /etc/csocks.conf (if exist or there are rules..)
2) Check the rules ("check-rules") with the connection data (the check
have a O(1) cost because the rules are stored in a hash-table). If
"/etc/csocks.conf" doesn't exist or there are no rules inside it, the
entire socks check is skipped and go run native syscall (for example
"_connect") .
3) If a rule is matched, then starts the socksified's (connection )
processes, else run the native syscall
Now, if the users never will use the socks features (the configuration
file is empty), the computation cost is negligible, because the
"check-rules" are skipped. If some (or all) users use the socks
features, for each syscall wrapped by socks there is a low cost
identified by the "check-rule" procedure.
I tested this solution in a big network , up to 60 client rules and i
didn't see slowdowns for non-socks connections.
When a process calls a socks wrapped syscall for the first time (and
only the first time!) the entire rules are loaded in memory, and the
hash array (empty) too:
The hash array empty consumes around 5.6K of memory
The single rule consumes 20 Byte of memory
User Name and Password consume 2K of memory
Raffaele
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Added native socks support to libc in FreeBSD 7
Raffaele De Lorenzo <[EMAIL PROTECTED]> writes: > The socks implementation wraps some syscall socket functions like > "_connect" and "_bind" trasparently from the applications. When one of > these is called, the "socks" check starts: [...] You don't need to put this in libc; you can have wrappers in a separate library which you load with LD_PRELOAD. The strong symbols in the wrapper library will override the weak symbols in libc. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Added native socks support to libc in FreeBSD 7
Dag-Erling Smørgrav wrote: Raffaele De Lorenzo <[EMAIL PROTECTED]> writes: The socks implementation wraps some syscall socket functions like "_connect" and "_bind" trasparently from the applications. When one of these is called, the "socks" check starts: [...] You don't need to put this in libc; you can have wrappers in a separate library which you load with LD_PRELOAD. The strong symbols in the wrapper library will override the weak symbols in libc. DES You can see in the port-tree my project "csocks" and http://csocks.altervista.org. Raffaele ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Pipe queues
Hi, I'm having a hard time to understand what pipe queues are with respect to bandwidth limitation. ipfw(8) and dummynet(4) manuals didn't help me much. How does dummynet's traffic shaping function? Why does it need a queue at all? As each connection's queue takes some memory, can I just disable the queueing, or set its size to 1 slot (1500 bytes)? What if I set it to 1 slots, why should it wait to fill the queue before starting to send stuff out the network interface? As packets arrive, AFAIK they are stored in mbufs in system memroy. Do pipe queues also use mbufs? I might be servicing hundreds of pipes simultaneously, this is why I'm concerned about memory use. Thank you for any insights. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pipe queues
On Dec 10, 2007, at 8:56 AM, rihad wrote: Hi, I'm having a hard time to understand what pipe queues are with respect to bandwidth limitation. ipfw(8) and dummynet(4) manuals didn't help me much. Pipes and queues are two different things; a pipe simulates a network link, and a queue is used to hold packets which are backlogged because they are arriving faster than the outbound link (ie, a pipe) can transmit them. How does dummynet's traffic shaping function? It uses a variant of weighted fair queuing. Why does it need a queue at all? So the traffic shaper can choose which of the queues with traffic it should drain and send out next. Unless you use multiple queues, you won't be able to prioritize traffic between 'em. As each connection's queue takes some memory, can I just disable the queueing, or set its size to 1 slot (1500 bytes)? You could, but that would largely disable effective traffic shaping also. What if I set it to 1 slots, why should it wait to fill the queue before starting to send stuff out the network interface? Well, it *doesn't* wait for the queue to be filled before starting to send stuff out the network. As packets arrive, AFAIK they are stored in mbufs in system memroy. Do pipe queues also use mbufs? I might be servicing hundreds of pipes simultaneously, this is why I'm concerned about memory use. Pipes aren't queues. Queues buffer packets into mbufs. -- -Chuck ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pipe queues
On Mon, Dec 10, 2007 at 11:22:33AM -0800, Chuck Swiger wrote: > On Dec 10, 2007, at 8:56 AM, rihad wrote: > > Hi, > > > > I'm having a hard time to understand what pipe queues are with > > respect to bandwidth limitation. ipfw(8) and dummynet(4) manuals > > didn't help me much. > > Pipes and queues are two different things; a pipe simulates a network > link, and a queue is used to hold packets which are backlogged because > they are arriving faster than the outbound link (ie, a pipe) can > transmit them. > > > How does dummynet's traffic shaping function? > > It uses a variant of weighted fair queuing. actually the shaping uses a leaky bucket algorithm. The weighted fair queuing is the queue management scheme used when you have multiple queues attached to the same pipe cheers luigi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pipe queues
Luigi Rizzo wrote: On Mon, Dec 10, 2007 at 11:22:33AM -0800, Chuck Swiger wrote: On Dec 10, 2007, at 8:56 AM, rihad wrote: Hi, I'm having a hard time to understand what pipe queues are with respect to bandwidth limitation. ipfw(8) and dummynet(4) manuals didn't help me much. Pipes and queues are two different things; a pipe simulates a network link, and a queue is used to hold packets which are backlogged because they are arriving faster than the outbound link (ie, a pipe) can transmit them. How does dummynet's traffic shaping function? It uses a variant of weighted fair queuing. actually the shaping uses a leaky bucket algorithm. The weighted fair queuing is the queue management scheme used when you have multiple queues attached to the same pipe cheers luigi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" Pipes are used to limit bandwidth. Queues are used to assign priority to different classes of traffic. As an example suppose you wanted to limit bandwidth for a specific ip to 2mbs. You set up a pipe to do this and use ipfw to put traffic from this ip into the 2 mbs pipe. If you then wanted to prioritize ftp traffic at higher than priority than all other traffic for this same user you would create 2 queues to feed the 2mbs pipe. You would send the ftp traffic into the higher priority queue and all other traffic for this user into the other queue. hth, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pipe queues
Stephen Clark wrote: Luigi Rizzo wrote: On Mon, Dec 10, 2007 at 11:22:33AM -0800, Chuck Swiger wrote: On Dec 10, 2007, at 8:56 AM, rihad wrote: Hi, I'm having a hard time to understand what pipe queues are with respect to bandwidth limitation. ipfw(8) and dummynet(4) manuals didn't help me much. Pipes and queues are two different things; a pipe simulates a network link, and a queue is used to hold packets which are backlogged because they are arriving faster than the outbound link (ie, a pipe) can transmit them. How does dummynet's traffic shaping function? It uses a variant of weighted fair queuing. actually the shaping uses a leaky bucket algorithm. The weighted fair queuing is the queue management scheme used when you have multiple queues attached to the same pipe cheers luigi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" Pipes are used to limit bandwidth. Queues are used to assign priority to different classes of traffic. As an example suppose you wanted to limit bandwidth for a specific ip to 2mbs. You set up a pipe to do this and use ipfw to put traffic from this ip into the 2 mbs pipe. If you then wanted to prioritize ftp traffic at higher than priority than all other traffic for this same user you would create 2 queues to feed the 2mbs pipe. You would send the ftp traffic into the higher priority queue and all other traffic for this user into the other queue. And if I _only_ want to shape IP traffic to given speed, without prioritizing anything, do I still need queues? This was the whole point. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pipe queues
Chuck Swiger wrote:
On Dec 10, 2007, at 8:56 AM, rihad wrote:
Hi,
I'm having a hard time to understand what pipe queues are with respect
to bandwidth limitation. ipfw(8) and dummynet(4) manuals didn't help
me much.
Pipes and queues are two different things; a pipe simulates a network
link, and a queue is used to hold packets which are backlogged because
they are arriving faster than the outbound link (ie, a pipe) can
transmit them.
So you mean queues are only used on the sending side? (the box is acting
as a router) and that their purpose is to diminish packet loss rate due
to network congestion? Now I get it, thanks.
What if I set it to 1 slots, why should it wait to fill the queue
before starting to send stuff out the network interface?
Well, it *doesn't* wait for the queue to be filled before starting to
send stuff out the network.
This ipfw manpage section was the reason I asked (sorry for the
formatting). What's with the "queuing delay" part? I'm totally confused.
queue {slots | sizeKbytes}
Queue size, in slots or KBytes. Default value is 50 slots,
which
is the typical queue size for Ethernet devices. Note that
for slow
speed links you should keep the queue size short or your traffic
might be affected by a significant queueing delay. E.g., 50
max-
sized ethernet packets (1500 bytes) mean 600Kbit or 20s of
queue on
a 30Kbit/s pipe. Even worse effects can result if you get
packets
from an interface with a much larger MTU, e.g. the loopback
inter-
face with its 16KB packets.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pipe queues
Chuck Swiger wrote:
On Dec 10, 2007, at 8:56 AM, rihad wrote:
Hi,
I'm having a hard time to understand what pipe queues are with respect
to bandwidth limitation. ipfw(8) and dummynet(4) manuals didn't help
me much.
Pipes and queues are two different things; a pipe simulates a network
link, and a queue is used to hold packets which are backlogged because
they are arriving faster than the outbound link (ie, a pipe) can
transmit them.
So you mean queues are only used on the sending side? (the box is acting
as a router) and that their purpose is to diminish packet loss rate due
to network congestion? Now I get it, thanks.
What if I set it to 1 slots, why should it wait to fill the queue
before starting to send stuff out the network interface?
Well, it *doesn't* wait for the queue to be filled before starting to
send stuff out the network.
This ipfw manpage section was the reason I asked (sorry for the
formatting). What's with the "queuing delay" part? I'm totally confused.
queue {slots | sizeKbytes}
Queue size, in slots or KBytes. Default value is 50 slots,
which
is the typical queue size for Ethernet devices. Note that
for slow
speed links you should keep the queue size short or your traffic
might be affected by a significant queueing delay. E.g., 50
max-
sized ethernet packets (1500 bytes) mean 600Kbit or 20s of
queue on
a 30Kbit/s pipe. Even worse effects can result if you get
packets
from an interface with a much larger MTU, e.g. the loopback
inter-
face with its 16KB packets.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
