Re: OS choice for an edge router
On Fri, 7 Sep 2007, Bakul Shah wrote: This is not the case. Flood ping doesn't reach the limit in any way. Have a look at the ping man page and flood ping description. Ah yes, I was forgetting about the strict synchrony. Flood ping neither floods nor is synchronous. As documented, it outputs packets as fast as they come back or 100 times per second, whichever is more. The magic 100 was a good approximation to infinity at 1Mbps, but it scales poorly. I see the following behaviour on a 1Gbps network that has a ping latency of ~100 usec: - initially the throughput is ~10 kpps, due to strict synchrony (sp?). The 100 Hz timeout is almost irrelevant because 100 is much less than 10k. - the throughput gradually (after about 1 minute) ramps up to ~120 kpps (equals only about 1/5 of ttcp max transmit-only throughput which saturates the transmitter). My explanation for this is that one side gets behind due to random delays and/or accidental sync with the 100 Hz timeout. Then the synchrony is not per-packet, but per burst of packets, where the burst size is some combination of the random delays, the magic 100, and the software and/or hardware queue lengths. The magic 100 is hard to increase much, since it is implemented as a timeout and timeouts have limited resolution. Utilities like ttcp have similar problems from this -- they tend to leave the network idle while they are waiting for a timeout, or are reduced to busy-waiting. On the same systems that have the highly variable ping throughput of 10-120 kpps due to the ramp-up: Modifying flood ping to actually flood gives a throughput of ~170 kpps at a cost of approximately doubling the latency. Modifying flood ping to be synchronous gives a constant throughput of ~8kpps. Apparently my ping throughput was never initially 10 kpps -- 10 is after some ramp-up, while 8 is consistent with the latency. The average latency at the time of measurement was 122 uS but I misremembered it as 95 uS. Bruce ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
UDP catchall
Hello,
I am a Google Summer of Code student working on mtund, aka Magic
Tunnel Daemon aka Super Tunnel Daemon,
http://wiki.freebsd.org/SuperTunnelDaemon.
For mtund it would be useful to listen on all unused UDP ports,
allowing a client behind firewall to use any possible hole it could
find. To achieve this, the easiest way seems to be to allow a raw
IP/UDP socket to receive UDP traffic that no regular UDP socket
wants. In the kernel this means passing the mbuf from udp_input to
rip_input(). Upon receiving a packet, the user space program would
inspect the UDP header and create a UDP socket bound to the correct
local port and connected to the right remote port and address.
The user space usage would then look as follows:
fd = socket(AF_INET, SOCK_RAW, IPPROTO_UDP);
recvfrom(fd, ...);
/* parse the UDP header for the source and destination addresses */
new_fd = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);
bind(new_fd, ...);
connect(new_fd, ...);
This catchall feature could be enabled/disabled via a sysctl variable,
net.inet.raw.udp_catchall. Furthermore, a rate limit could be used to
mitigate possible DoS misuse.
A simple testing program can be found under
http://p4web.freebsd.org/@md=d&cd=//depot/projects/soc2007/mharvan-mtund/sys.patches/test_catchall/&c=xpc@//depot/projects/soc2007/mharvan-mtund/sys.patches/test_catchall/ucatchalld.c?ac=22
and a more complex example is the udp catchall plugin for mtund
http://p4web.freebsd.org/@md=d&cd=//depot/projects/soc2007/mharvan-mtund/mtund.src/&c=SM3@//depot/projects/soc2007/mharvan-mtund/mtund.src/plugin_udp_catchall.c?ac=22
Matus
patch:
Index: udp_usrreq.c
===
RCS file: /home/ncvs/src/sys/netinet/udp_usrreq.c,v
retrieving revision 1.216
diff -d -u -r1.216 udp_usrreq.c
--- udp_usrreq.c10 Jul 2007 09:30:46 - 1.216
+++ udp_usrreq.c6 Sep 2007 21:59:31 -
@@ -125,6 +125,15 @@
SYSCTL_ULONG(_net_inet_udp, UDPCTL_RECVSPACE, recvspace, CTLFLAG_RW,
&udp_recvspace, 0, "Maximum space for incoming UDP datagrams");
+static int udp_catchall = 0;
+SYSCTL_INT(_net_inet_raw, OID_AUTO, udp_catchall, CTLFLAG_RW | CTLFLAG_SECURE,
+ &udp_catchall, 0, "Raw IP UDP sockets receive unclaimed UDP datagrams");
+
+static int catchalllim = 5;
+SYSCTL_INT(_net_inet_udp, OID_AUTO, catchalllim, CTLFLAG_RW | CTLFLAG_SECURE,
+ &catchalllim, 0,
+ "Rate limit on received UDP datagrams due to udp_catchall");
+
struct inpcbhead udb;/* from udp_var.h */
struct inpcbinfo udbinfo;
@@ -136,6 +145,11 @@
SYSCTL_STRUCT(_net_inet_udp, UDPCTL_STATS, stats, CTLFLAG_RW, &udpstat,
udpstat, "UDP statistics (struct udpstat, netinet/udp_var.h)");
+static struct rate {
+ struct timeval lasttime;
+ int curpps;
+} catchallr;
+
static voidudp_detach(struct socket *so);
static int udp_output(struct inpcb *, struct mbuf *, struct sockaddr *,
struct mbuf *, struct thread *);
@@ -515,6 +529,35 @@
*/
inp = in_pcblookup_hash(&udbinfo, ip->ip_src, uh->uh_sport,
ip->ip_dst, uh->uh_dport, 1, ifp);
+
+ /* catchall socket */
+ if (inp == NULL && udp_catchall != 0) {
+#ifdef DIAGNOSTIC
+ printf("IP UDP catchall active\n");
+ char dbuf[INET_ADDRSTRLEN], sbuf[INET_ADDRSTRLEN];
+ strcpy(dbuf, inet_ntoa(ip->ip_dst));
+ strcpy(sbuf, inet_ntoa(ip->ip_src));
+ printf("\tip_src: %s, sport: %hu\n\tip_dst: %s, dport: %hu\n",
+ sbuf, ntohs(uh->uh_sport), dbuf, ntohs(uh->uh_dport));
+#endif
+
+ /* rate limiting */
+ if (catchalllim > 0)
+ if (ppsratecheck(&catchallr.lasttime,
+ &catchallr.curpps, catchalllim)) {
+ rip_input(m, off);
+ INP_INFO_RUNLOCK(&udbinfo);
+ return;
+ }
+#ifdef DIAGNOSTIC
+ else
+ printf("ppsratecheck limited "
+ "udp_catchall\n");
+ else
+ printf("ppsratecheck limited udp_catchall\n");
+#endif
+ }
+
if (inp == NULL) {
if (udp_log_in_vain) {
char buf[4*sizeof "123"];
pgpqboabO52dk.pgp
Description: PGP signature
icmp echo_user
Hello,
I am a Google Summer of Code student working on mtund, aka Magic
Tunnel Daemon aka Super Tunnel Daemon,
http://wiki.freebsd.org/SuperTunnelDaemon.
For mtund it would be useful to tunnel in ICMP echo request/reply
pairs. For this being able to receive ICMP echo requests in the user
space would be helpful. Currently, ICMP echo requests are processed in
the kernel where an ICMP echo reply is generated, but they are not
passed to the user space. I would suggest the patch below, adding a
sysctl variable net.inet.icmp.echo_user, allowing to recevie the ICMP
echo requests in the user space on a raw IP/ICMP socket rather than
having the kernel generate a reply to them.
Matus
patch:
Index: ip_icmp.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_icmp.c,v
retrieving revision 1.117
diff -d -u -r1.117 ip_icmp.c
--- ip_icmp.c 19 Jul 2007 22:34:25 - 1.117
+++ ip_icmp.c 6 Sep 2007 21:26:08 -
@@ -124,6 +124,10 @@
SYSCTL_INT(_net_inet_icmp, OID_AUTO, bmcastecho, CTLFLAG_RW,
&icmpbmcastecho, 0, "");
+static int icmpechouser = 0;
+SYSCTL_INT(_net_inet_icmp, OID_AUTO, echo_user, CTLFLAG_RW | CTLFLAG_SECURE,
+&icmpechouser, 0, "Pass ICMP echo requests to userspace rather than"
+ "replying to them in the kernel");
#ifdef ICMPPRINTFS
inticmpprintfs = 0;
@@ -454,6 +458,9 @@
break;
case ICMP_ECHO:
+ if (icmpechouser)
+ goto raw;
+
if (!icmpbmcastecho
&& (m->m_flags & (M_MCAST | M_BCAST)) != 0) {
icmpstat.icps_bmcastecho++;
pgp4A2YLPDjQo.pgp
Description: PGP signature
TCP listenall
Hello,
I am a Google Summer of Code student working on mtund, aka Magic
Tunnel Daemon aka Super Tunnel Daemon,
http://wiki.freebsd.org/SuperTunnelDaemon.
For mtund it would be useful to listen on all unused TCP ports,
allowing a client behind firewall to use any possible hole it could
find. To achieve this I would suggest the patch below. It would add a
socket option TCP_LISTENALL. This clearly could only be set on one
socket. When activated, the global variable inp_tlistenall would be
used to assign traffic to unused TCP ports to that socket. In
particular, the changed code in tcp_input() would be used twice - once
for the SYN packet (1st packet) and once for the ACK packet (3rd
packet). inp_tlistenall is protected by the INP_INFO lock on tcbinfo
in all places.
The patch also includes rate limiting to mitigate possible DoS
misuse. With listenall enabled, a portscan becomes a syn
flood. However, as there are already mechanisms to protect against a
syn flood attack, such as syncache and syncookies, the rate limit
might be left out. The disadvanatage of the rate limit is that a
portscan becomes a DoS against the listenall socket.
A testing program is available in perforce:
http://p4web.freebsd.org/@md=d&cd=//depot/projects/soc2007/mharvan-mtund/sys.patches/test_catchall/&c=xpc@//depot/projects/soc2007/mharvan-mtund/sys.patches/test_catchall/tcatchalld.c?ac=22
Note that the tcp listenall feature would be usefull to other programs
beyond mtund, i.e., a modified ssh daemon for people who won't be able
to run mtund, but will be able to run ssh.
Matus
patch:
Index: netinet/tcp.h
===
RCS file: /home/ncvs/src/sys/netinet/tcp.h,v
retrieving revision 1.40
diff -d -u -r1.40 tcp.h
--- netinet/tcp.h 25 May 2007 21:28:49 - 1.40
+++ netinet/tcp.h 8 Sep 2007 10:35:57 -
@@ -147,6 +147,7 @@
#define TCP_NOOPT 0x08/* don't use TCP options */
#define TCP_MD5SIG 0x10/* use MD5 digests (RFC2385) */
#defineTCP_INFO0x20/* retrieve tcp_info structure */
+#defineTCP_LISTENALL 0x40/* listen on all unused TCP ports */
#defineTCPI_OPT_TIMESTAMPS 0x01
#defineTCPI_OPT_SACK 0x02
Index: netinet/tcp_input.c
===
RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v
retrieving revision 1.367
diff -d -u -r1.367 tcp_input.c
--- netinet/tcp_input.c 30 Jul 2007 11:06:41 - 1.367
+++ netinet/tcp_input.c 8 Sep 2007 10:35:57 -
@@ -144,9 +144,15 @@
SYSCTL_INT(_net_inet_tcp, OID_AUTO, recvbuf_max, CTLFLAG_RW,
&tcp_autorcvbuf_max, 0, "Max size of automatic receive buffer");
+static int listenalllim = 5;
+SYSCTL_INT(_net_inet_tcp, OID_AUTO, listenalllim, CTLFLAG_RW | CTLFLAG_SECURE,
+ &listenalllim, 0,
+ "Rate limit on sockets created by the TCP_LISTENALL socket");
+
struct inpcbhead tcb;
#definetcb6tcb /* for KAME src sync over BSD*'s */
struct inpcbinfo tcbinfo;
+struct inpcb *inp_tlistenall; /* listening on all unused TCP ports */
static void tcp_dooptions(struct tcpopt *, u_char *, int, int);
static void tcp_do_segment(struct mbuf *, struct tcphdr *,
@@ -258,6 +264,11 @@
struct tcphdr tcp_savetcp;
short ostate = 0;
#endif
+ static struct rate {
+ struct timeval lasttime;
+ int curpps;
+ } listenallr;
+
#ifdef INET6
isipv6 = (mtod(m, struct ip *)->ip_v == 6) ? 1 : 0;
@@ -460,6 +471,36 @@
goto dropunlock;
}
#endif /* IPSEC */
+
+ /* listenall socket */
+ if ((inp == NULL) && (inp_tlistenall != NULL)) {
+#ifdef DIAGNOSTIC
+ printf("listenall socket used (0x%x)\n",
+ (unsigned int)inp_tlistenall);
+ char dbuf[INET_ADDRSTRLEN], sbuf[INET_ADDRSTRLEN];
+ strcpy(dbuf, inet_ntoa(ip->ip_dst));
+ strcpy(sbuf, inet_ntoa(ip->ip_src));
+ printf("\tip_src: %s, sport: %hu\n\tip_dst: %s, dport: %hu\n",
+ sbuf, ntohs(th->th_sport), dbuf, ntohs(th->th_dport));
+#endif
+ /* do rate limiting for SYN packets */
+ if (thflags & TH_SYN) {
+ if (listenalllim > 0)
+ if (ppsratecheck(&listenallr.lasttime,
+ &listenallr.curpps, listenalllim))
+ inp = inp_tlistenall;
+#ifdef DIAGNOSTIC
+ else
+ printf("ppsratecheck limited "
+ "tcp_listenall\n");
+#endif
+#ifdef DIAGNOSTIC
+ else
+ printf("ppsratecheck limited tcp_listenall\n");
+#endif
+ } else
+ inp = inp_tlistenall;
+ }
/*
* If the IN
Re: new version of polling for FreeBSD 6.x
On 9/6/07, Fabien THOMAS <[EMAIL PROTECTED]> wrote: > Hi, > > After many years of good services we will stop using FreeBSD 4.x :) > During my performance regression tests under FreeBSD 6.2 i've found > that polling has lower performance than interrupt. > To solve that issue i've rewritten the core of polling to be more SMP > ready. > > You can find a summary of all my tests and the source code at the > following address: > http://www.netasq.com/opensource/pollng-rev1-freebsd.tgz > > Feel free to ask more detailed information if necessary and report > any bugs / comments. > Fabien, since you have the necesary hardware to stimulate the FreeBSD box, would it be too much to ask you to run some packet capture tests with your polling implementation and the capturing interface set to IFF_MONITOR? The userland program should use pcap and simply increment a counter and spit out capture average once every N seconds. It would be very interesting to see how polling affects packet capture, with varying BPF buffer sizes. > Fabien > > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Strange behaviour of route command
> > Tom Judge wrote: > >> Hi, > >> While making some changes to the routing table on one of our routers > >> today I noticed that "route add" was showing some strange > >> behaviour. When adding a route for 128/8 to the table rather than > >> adding 128.0.0.0/8 it would add 0.0.0.0/8, however adding 10/9 works > >> correctly. > >> > >> Is this a bug in route or the routing table? > > Hi, Can you take a look at this patch, please? http://leaf.dragonflybsd.org/mailarchive/submit/2007-09/msg0.html Thanks, Nuno ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
axe(4) and Linksys USB200M question
My Dell Inspiron XPS has just one built-in Ethernet port, and I need to have at least one other. Armed with a printed copy of Section 3.2 of the FreeBSD 6.2 Harware Notes, I went to the several electronics stores, looking to find a device on the list of supported devices. Eventually, I found and bought two Linksys USB200M Compact USB 2.0 Network Adapters, which are listed in the Hardware Notes as being supported by the axe(4) driver. Comments in if_axe.c specifically refer to the USB200M as a supported model. So, thinking I had found what I needed, I hooked one up to a USB port and booted my FreeBSD 6.2-STABLE system. The kernel did recognize that there was something attached to the USB port, but the device type was not identified, and no driver was associated with it, and therefore no axe0 network interface was created in the kernel. I've also tried connecting the card while the system was already up and running. Here's the resulting message in /var/log/messages: Sep 9 20:35:07 hellas kernel: ugen0: vendor 0x13b1 product 0x0018, rev 2.00/0.01, addr 3 Disconnecting the device yielded the following messages: Sep 9 20:36:15 hellas kernel: ugen0: at uhub4 port 6 (addr 3) disconnected Sep 9 20:36:15 hellas kernel: All threads purged from ugen0.3 Sep 9 20:36:15 hellas kernel: All threads purged from ugen0.2 Sep 9 20:36:15 hellas kernel: All threads purged from ugen0.1 Sep 9 20:36:15 hellas kernel: All threads purged from ugen0 Sep 9 20:36:15 hellas kernel: ugen0: detached Is the Linksys USB200M supported or not? What am I missing here? Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
