RE: TCP socket shutdown race condition
On Fri, 1 Aug 2003, Don Bowman wrote: > > u_short ui_ref; /* reference count */ > > }; > > > > We are pushing in the ~50-~70K TCP connections to this process. > > I think i see what you are suggesting :) > > --don Bingo. Change that u_short to a u_int, and see if that causes your problems to go away. Mike "Silby" Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: TCP socket shutdown race condition
> From: Mike Silbersack [mailto:[EMAIL PROTECTED]
> On Fri, 1 Aug 2003, Scot Loach wrote:
>
> > Earlier this week one of our FreeBSD 4.7 boxes panic'd.
> I've posted the
> > stack trace at the end of this message. Using google, I've
> found several
> > references to this panic over the past three years, but it
> seems its never
> > been taken to root cause.
> >
> > The box crashes because the cr_uidinfo pointer in the
> so_cred structure is
> > null. However, on closer inspection the so_cred structure
> is corrupted
> > (cr_ref=3279453304 for example), so I'm guessing it has
> already been freed.
> > Looking closer at the socket, I see that the SS_NOFDREF
> flag is set, which
> > supports my theory. The tcpcb is in the CLOSED state, and
> has the SENTFIN
> > flag set.
>
> About how many concurrent connections are you pushing this machine to?
>
> There's an unfortunate problem with uidinfo in 4.x:
>
> struct uidinfo {
> LIST_ENTRY(uidinfo) ui_hash;
> rlim_t ui_sbsize; /* socket buffer
> space consumed */
> longui_proccnt; /* number of processes */
> uid_t ui_uid; /* uid */
> u_short ui_ref; /* reference count */
> };
>
We are pushing in the ~50-~70K TCP connections to this process.
I think i see what you are suggesting :)
--don
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: T/TCP useless on FreeBSD 4.7?
On Fri, 1 Aug 2003, michael rabinovich wrote: > Hi, > > Does anyone know the status of T/TCP support on FreeBSD 4.7? It's clearly very rarely used, and may indeed be broken. I don't believe that the T/TCP breakage was intentional, but I'm not familiar enough with T/TCP to determine what the problem is. If you've figured out how to fix it, please post patches; we'll look into getting them incorporated into 4.8-stable. Thanks, Mike "Silby" Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP socket shutdown race condition
On Fri, 1 Aug 2003, Scot Loach wrote:
> Earlier this week one of our FreeBSD 4.7 boxes panic'd. I've posted the
> stack trace at the end of this message. Using google, I've found several
> references to this panic over the past three years, but it seems its never
> been taken to root cause.
>
> The box crashes because the cr_uidinfo pointer in the so_cred structure is
> null. However, on closer inspection the so_cred structure is corrupted
> (cr_ref=3279453304 for example), so I'm guessing it has already been freed.
> Looking closer at the socket, I see that the SS_NOFDREF flag is set, which
> supports my theory. The tcpcb is in the CLOSED state, and has the SENTFIN
> flag set.
About how many concurrent connections are you pushing this machine to?
There's an unfortunate problem with uidinfo in 4.x:
struct uidinfo {
LIST_ENTRY(uidinfo) ui_hash;
rlim_t ui_sbsize; /* socket buffer space consumed */
longui_proccnt; /* number of processes */
uid_t ui_uid; /* uid */
u_short ui_ref; /* reference count */
};
It doesn't look like we have any seatbelts preventing ui_ref from
overflowing, thus causing an early free on the way back down, thereby
making all the other references to the structure junk. Can you try going
into kern_resource.c, finding the function uifind, and changing:
if (uip == NULL)
uip = uicreate(uid);
uip->ui_ref++;
return (uip);
to
if (uip == NULL)
uip = uicreate(uid);
uip->ui_ref++;
if (uip->ui_ref == 0)
panic("ui_ref overflowed");
return (uip);
That would confirm that it is the problem you're running into. If that is
the case, please tell us so that we can transition to the political side
of the problem. :)
Mike "Silby" Silbersack
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multipath Routing
On Fri, 1 Aug 2003, Michael W. Oliver wrote: > +--- On Friday, August 01, 2003 15:30, > | Oldach, Helge proclaimed: > | > | > I am no programmer, so forgive my ignorance in that respect, but why > | > can't a > | > metric be used to differentiate routes to the same destination network > | > within the routing table? I happened to be googling and found: > | > > | > http://daily.daemonnews.org/view_story.php3?story_id=3878 > | > > | > which describes a patch to -STABLE that does exactly what I am talking > | > about. > | > | Routing will always follow the better metric. That's the paradigm. So > | if you have two routes the one with the better metric will always rule. > | The term 'metric' in the sense of this patch is not referring to routing metrics (like hopcount for route selection preferences). The term 'metric' in the patch looks as if it is just a counter that controls which gateway to send the packet to. If you look at the description in the patch: "Each gateway has a "metric" which is decremented for each packet. When it reaches zero, the next gateway in the list is selected." This use of the term 'metric' in this patch is not meant to mean a traditional routing 'metric' (commonly used in routing tables). Or at least this is what my interpretation of the patch is. > > What exactly is the syntax of entering a network route twice, using the same > mask, via two different gateways, using different metrics? The answer is you can't. You can't add the same route for a single subnet through multiple gateways using route(8)...at least not without this patch. I never have investigated whether this is a restriction enforced by route(8) or the kernel routing code. I would assume it is enforced by the kernel...maybe someone can clarify? If my memory serves me correct, it has to do with the routing tree structure... The reason the patch is not default is: because it is not :-) Many people will tell you to accomplish this use other things such as routing daemons, netgraph modules, etc. FreeBSD is not a router, it is an OS. I guess if it was marketed as a router then maybe this would be default...don't know, have to ask the -core. > > | Frankly, I don't quite see the rationale for such a hack. This can be > | solved using available mechanisms such as VRRP (or HSRP, if the gateways > | are decent routers). > | > > In my case, I am talking about using FreeBSD as the router. For sure, > FreeBSD + Zebra is one VERY powerful combination. There are several good reasons to use Multipath routing, most of which fall into 2 categories: Load Balancing & Redundancy. This patch is for load balancing only. HSRP has nothing to do with load balancing and is Cisco proprietary. VRRP has little to do with outbound load balancing as well. Nick Rogness <[EMAIL PROTECTED]> - How many people here have telekenetic powers? Raise my hand. -Emo Philips ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freeBSD NIS-server - LINUX NIS-client auth/login probs
On Fri, Aug 01, 2003 at 02:22:48PM +0200, Thomas Zauner wrote:
> hi,
>
> i set up a NIS server on freebsd(5.1) excactly like in the handbook and
> then started the NIS client on linux (RH-9).
>
>
> (i just have 1 test user for now)
>
>
> 1)
>
> here's the output from ypcat passwd:
> the client binds the server ok:
>
> [EMAIL PROTECTED] ypcat passwd
> testo:*:1003:1003:User &:/home/testo/:/usr/local/bin/bash
>
> (the home dir does exist on the client -- via NFS)
>
> also in the RH user-manager i can see the user testo but i CANT LOGIN
> i think its an auth problem.
>
You need a shadow NIS map for Linux.
> on the freeBSD side i use md5 as default encrypt. but thats ok with
> linux
> i think.(on the freebsd side in /etc/login.conf defined)
>
Yes.
> 2)
>
> there is a option in /var/yp/Makefile on the FREEBSD side
> "UNSECURE=true"
> but its commented out.
[...]
> DO I need this ?
>
No.
> 3)
> also i am not shure what config to use in nsswitch.conf on linux
> because i dunno what NIS(1/2/+) freebsd is using so is this ok?
>
> -SNIP (/etc/nsswitch.conf)--
> passwd: compat
> group: compat
> shadow: nis files # i think there is no compat for shadow
>
There is (the compat for shadow).
> passwd_compat: nis
> group_compat: nis
>
These are the defaults, IIRC.
> and then add the "+::" stuff to /etc/shadow passwd and groups
>
Yes, if you need to override some fields, which is typical.
> passwd: nis files
> shadow: nis files
> group: nis files
> ---
>
> and NOT use the +::: stuff in the passwd,group.shadow files ?
>
Yes, that's another option (if you don't need to override anything).
> or sth with nis+ in nsswitch.conf ?
>
No.
> 5)
> what about the diffrent styles of the "shadowed" password file of
> LINUX(/etc/shadow) and FREEBSD (/etc/master.passwd)
> the freebsd master.passwd has more fields then the linux equivalent
>
I use the attached patch for /var/yp/Makefile to generate the shadow
map.
> 6)
> BTW my umask is 0077 do others/group need read-access to and of the
> files
> in /var/yp/* ???
>
I don't think they need it.
> ok thats all i can think of right now
> PLS if someone can help "SAVE MY WEEKEND" and help me. LOL
>
You're welcome!
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
--- Makefile.dist Fri Mar 7 21:15:21 2003
+++ MakefileWed Jun 11 20:14:35 2003
@@ -188,6 +190,7 @@
aliases: mail.aliases
master.passwd: master.passwd.byname master.passwd.byuid
+master.passwd: shadow.byname
#
# This is a special target used only when doing in-place updates with
@@ -559,6 +562,22 @@
$(CAT) $(MASTER) | \
$(AWK) -F: '{ if ($$1 != "" && $$1 !~ "^#.*" && $$1 != "+") \
print $$3"\t"$$0 }' $^ \
+ | $(DBLOAD) ${S} -f -i $(MASTER) -o $(YPMAPDIR)/$@ - $(TMP); \
+ $(RMV) $(TMP) $@
+ @$(DBLOAD) -c
+ @if [ ! $(NOPUSH) ]; then $(YPPUSH) -d $(DOMAIN) $@; fi
+ @if [ ! $(NOPUSH) ]; then echo "Pushed $@ map." ; fi
+.endif
+
+
+shadow.byname: $(MASTER)
+ @echo "Updating [EMAIL PROTECTED]"
+.if ${MASTER} == "/dev/null"
+ @echo "Master.passwd source file not found -- skipping"
+.else
+ $(CAT) $(MASTER) | \
+ $(AWK) -F: '{ if ($$1 != "" && $$1 !~ "^#.*" && $$1 != "+") \
+ print $$1"\t"$$1":"$$2":::" }' $^ \
| $(DBLOAD) ${S} -f -i $(MASTER) -o $(YPMAPDIR)/$@ - $(TMP); \
$(RMV) $(TMP) $@
@$(DBLOAD) -c
pgp0.pgp
Description: PGP signature
Re: mbuf clusters exhausted w/o reaching max?
On Fri, 1 Aug 2003, Steve Francis wrote: > From LINT (see below), the comment says the VM_KMEM_SIZE_MAX is 200M, > yet the option says 100M. Comment typo, or typo in the option? > Is increasing the VM_KMEM_SIZE_MAX (which should take us to up to 256M > given 1G RAM) sufficient to allow extra space for mbuf clusters? The values listed in LINT are more for illustrative than functional purposes, so you can ignore them for the most part. The default VM_KMEM_SIZE_MAX is actually contained in /usr/src/sys/i386/include/vmparam.h, where it's set to 200 Megs. And I misremembered, the scale factor is 1/3rd, not 1/4th. If you want to change the kmem size, the easiest way to do it would be to edit /boot/loader.conf and set "kern.vm.kmem.size=300M" (Or more, perhaps.) > I googled and found this from [EMAIL PROTECTED] on a related question: > "Within the kernel's share of this address space, memory is split into > submaps, such as the mb_map (for the network), buffer_map for the > filesystem buffer cache, and the kmem_map for just about everything > else. These submaps are size-limited to prevent any one of them from > getting out of hand." > I presume I need to increase mb_map, but could not find a specific > option for that. Does that scale with an increased VM_KMEM_SIZE_MAX? > > These servers basically run one process, which is about 500M resident > and total size, on 1G RAM machine, and do tons of network IO with lots > of packets. Given that, do you still anticipate " causing other > problems in the process" if I tune this? > > > Thanks The mb_map is allocated as part of the kernel map, so if other kernel users eat up ram before the mbuf subsystem does, then the mbuf subsystem has to starve. Ram for mbufs is not allocated until it is actually used, so if you only ever use 200 clusters, that's all the real ram that will be used. However, ram used by mbufs (and clusters) is never freed back for non-mbuf usage, so if you have a load spike and use 1 clusters, that ram is unuseable by the rest of the system afterwards. I think if you stay under 400M that you'll probably be ok. The main issues with runaway memory usage occur on 2G and 4G machines, where the kernel map + buffer cache + swap stuff + etc was growing extremely large. However, if 50 failed memory allocations are all that you saw, and everything else is working properly, you might consider leaving things as they are. :) FWIW, Bosko Milekic is working on a new mbuf allocator for 5.x which will allow mbuf memory to be freed back to the common pool, PHK is thinking of ways to remove the memory usage of the buffer cache, and some other memory issues have already been fixed as the result of 5.x's UMA memory allocator. Hopefully by 5.2 or 5.3 you will no longer need to tweak any of these settings. (Very little of this work will be MFC'd to 4.x, due to the size of the changes.) Mike "Silby" Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multipath Routing
+--- On Friday, August 01, 2003 15:30, | Oldach, Helge proclaimed: | | > I am no programmer, so forgive my ignorance in that respect, but why | > can't a | > metric be used to differentiate routes to the same destination network | > within the routing table? I happened to be googling and found: | > | > http://daily.daemonnews.org/view_story.php3?story_id=3878 | > | > which describes a patch to -STABLE that does exactly what I am talking | > about. | | Routing will always follow the better metric. That's the paradigm. So | if you have two routes the one with the better metric will always rule. | What exactly is the syntax of entering a network route twice, using the same mask, via two different gateways, using different metrics? | Frankly, I don't quite see the rationale for such a hack. This can be | solved using available mechanisms such as VRRP (or HSRP, if the gateways | are decent routers). | In my case, I am talking about using FreeBSD as the router. For sure, FreeBSD + Zebra is one VERY powerful combination. | Furthermore: | | It doesn't detect when remote hosts are down. This is not the job of | the kernel. It's not a routing protocol, it's not an automatic failover | system. | | So what is this good for, that cannot be solved by already available | mechanisms? | As stated above, and in my first post, I am using Zebra, which is a suite of routing protocols. It is aware of routing path changes. -- +-+--+ | Michael W. Oliver, CCNP | "The tree of liberty must be | | IPv6 & FreeBSD mark | refreshed from time to time | | [EMAIL PROTECTED]| with the blood of patriots | | http://michael.gargantuan.com/| and tyrants."| | ASpath-tree, Looking Glass, etc. | - President Thomas Jefferson | | +--+ | gpg key - http://michael.gargantuan.com/gnupg/pubkey.asc | ++ pgp0.pgp Description: signature
Re: mbuf clusters exhausted w/o reaching max?
THanks for the reply... Question below. Mike Silbersack wrote: Mbufs & mbuf clusters are allocated from the kernel map, so it's possible for allocations to fail due to the kernel map being relatively full due to other parts of the kernel eating memory. This is probably what's happening in your case; given that only 50 allocations were denied, it probably didn't hurt your system much. Note that the kernel map is not the size of all ram; it's usually only 1/4 of the amount of ram available, with a ceiling of 256MB. You could try playing with those parameters, but you'll probably end up causing other problems in the process. :) From LINT (see below), the comment says the VM_KMEM_SIZE_MAX is 200M, yet the option says 100M. Comment typo, or typo in the option? Is increasing the VM_KMEM_SIZE_MAX (which should take us to up to 256M given 1G RAM) sufficient to allow extra space for mbuf clusters? I googled and found this from [EMAIL PROTECTED] on a related question: "Within the kernel's share of this address space, memory is split into submaps, such as the mb_map (for the network), buffer_map for the filesystem buffer cache, and the kmem_map for just about everything else. These submaps are size-limited to prevent any one of them from getting out of hand." I presume I need to increase mb_map, but could not find a specific option for that. Does that scale with an increased VM_KMEM_SIZE_MAX? These servers basically run one process, which is about 500M resident and total size, on 1G RAM machine, and do tons of network IO with lots of packets. Given that, do you still anticipate " causing other problems in the process" if I tune this? Thanks # Tune the kernel malloc area parameters. VM_KMEM_SIZE represents the # minimum, in bytes, and is typically (12*1024*1024) (12MB). # VM_KMEM_SIZE_MAX represents the maximum, typically 200 megabytes. # VM_KMEM_SIZE_SCALE can be set to adjust the auto-tuning factor, which # typically defaults to 4 (kernel malloc area size is physical memory # divided by the scale factor). # options VM_KMEM_SIZE="(10*1024*1024)" options VM_KMEM_SIZE_MAX="(100*1024*1024)" options VM_KMEM_SIZE_SCALE="4" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mbuf clusters exhausted w/o reaching max?
On Fri, 1 Aug 2003, Steve Francis wrote: > I have a FreeBSD 4.8-RELEASE #5 system that reported: > Aug 1 11:50:39 rack2-101 /kernel: All mbuf clusters exhausted, please see tuning(7). > Aug 1 11:50:39 rack2-101 /kernel: All mbufs exhausted, please see tuning(7). > > Yet its not close to the max allowed for clusters. > rack2-101.nyc# netstat -m > 1338/4240/131072 mbufs in use (current/peak/max): > 1338 mbufs allocated to data > 709/3366/32768 mbuf clusters in use (current/peak/max) > 7792 Kbytes allocated to network (7% of mb_map in use) > 50 requests for memory denied > 0 requests for memory delayed > 0 calls to protocol drain routines > rack2-101.nyc# Mbufs & mbuf clusters are allocated from the kernel map, so it's possible for allocations to fail due to the kernel map being relatively full due to other parts of the kernel eating memory. This is probably what's happening in your case; given that only 50 allocations were denied, it probably didn't hurt your system much. Note that the kernel map is not the size of all ram; it's usually only 1/4 of the amount of ram available, with a ceiling of 256MB. You could try playing with those parameters, but you'll probably end up causing other problems in the process. :) (Fair kernel memory management is an area we're still working on in -current.) Mike "Silby" Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: T/TCP useless on FreeBSD 4.7?
Bruce, Michael: Thanks a lot for the sysctl values tips. While 4.7 release does not seem to have drop_synfin option, syncookies indeed used to be 1 (but now we changed it to 0) on both machines: > sysctl net.inet.tcp | grep -E 'rfc1644|drop_synfin|cook' net.inet.tcp.rfc1644: 1 net.inet.tcp.syncookies: 0 > Unfortunately, setting it to 0 did not help: the tcp dump looks exactly the same. In addition, I tried the following changes on the server (although it was clear this would not make any diff, but just to be diligent) (a) replace "send" call (as in T/TCP book) with "sendto" call according to the ttcp manpage: sendto(sock, buf, len, MSG_EOF, (struct sockaddr *)0, 0) (b) not send any reply at all, just read from the socket and close it. (c) set "TCP_NOPUSH" option on the server's socket before writing response to it (with sendto call above). In all cases, the tcp dump shows a timeout + retransmission by the client... Also, what do you think about that source ode snippet I included into my original mail? It would certainly explain the behavior, except it would also mean that T/TCP is no longer usable. Unless that piece of code is somehow bypassed with proper options... Thanks again, Michael Bruce M Simpson wrote: > On Fri, Aug 01, 2003 at 11:14:12AM -0400, michael rabinovich wrote: > > Does anyone know the status of T/TCP support on FreeBSD 4.7? > ... > > Am I missing something (after all, FreeBSD is supposed to be a ref > > implementation of T/TCP!) and if not is there is a simple way around > > this problem, short of going back to earlier FreeBSD releases? > > I don't use T/TCP on my production 4.8-RELEASE system, and the following > sysctl values look fairly default:- > > net.inet.tcp.rfc1644: 0 > net.inet.tcp.syncookies: 1 > net.inet.tcp.drop_synfin: 0 > > SYN cookies and T/TCP can't co-exist. Please do check the above sysctl > values; I know RFC 1644 has to be enabled, and syncookies have to be disabled, > as well as drop_synfin. > > HTH, > BMS > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mbuf clusters exhausted w/o reaching max?
I have a FreeBSD 4.8-RELEASE #5 system that reported: Aug 1 11:50:39 rack2-101 /kernel: All mbuf clusters exhausted, please see tuning(7). Aug 1 11:50:39 rack2-101 /kernel: All mbufs exhausted, please see tuning(7). Yet its not close to the max allowed for clusters. rack2-101.nyc# netstat -m 1338/4240/131072 mbufs in use (current/peak/max): 1338 mbufs allocated to data 709/3366/32768 mbuf clusters in use (current/peak/max) 7792 Kbytes allocated to network (7% of mb_map in use) 50 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines rack2-101.nyc# I assume the problem is related to "50 requests for memory denied". However, this system has 1G RAM, and about half of it free, as far as I can tell. (ps -axlm ouput below, as well as systat and top.) So from all three tools, I see over 400M of inactive pages. I.e. pages that could be freed for use, and presumably allocated as mbuf clusters, but need to be flushed first. So is this an error in the mbuf cluster allocation code, the vm system not freeing pages fast enough to keep up with the demand for the mbufs, or something else again? Any ideas appreciated. Thanks ps -axlm UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 1002 87815 87814 75 2 0 390252 386472 - R ?? 668:11.73 ./bin/cCom_f 0 87829 1 0 2 0 4420 3764 select S p0- 9:50.28 /usr/bin/per 0 87823 1 1 2 0 4408 3752 select S p0- 13:29.65 /usr/bin/per 1002 87817 1 1 2 0 3344 1516 poll S ??2:31.43 BrokerLogger 0 87813 1 13 10 0 3256 2596 wait Is??0:00.00 /usr/bin/per 0 62540 62538 0 18 0 1328 840 pause Ssp00:00.04 -csh (csh) 0 388 257 0 3 0 1312 712 ttyin I+d10:00.01 -csh (csh) 0 115 1 0 2 0 3048 1756 select Ss??0:05.88 sendmail: ac 0 155 1 83 2 0 3932 2748 select I d1- 13:28.21 /usr/local/s 25 118 1 0 18 0 2920 1576 pause Is??0:00.47 sendmail: Qu 0 87814 87813 12 10 0 632 204 wait I ??0:00.00 sh -c ./bin/ 0 1 0 0 10 0 552 112 wait ILs ??0:00.01 /sbin/init - 0 101 1 0 2 0 1312 784 select Ss??0:06.99 /usr/sbin/nt 0 142 1 177 10 0 2076 1532 nanslp S d1- 1:09.31 /usr/bin/per 0 62538 110 0 2 0 5708 2180 select S ??0:00.21 sshd: [EMAIL PROTECTED] 0 64191 62540 0 28 0 428 248 - R+p00:00.00 ps -axlm 0 110 1 0 2 0 3008 1568 select Is??0:03.09 /usr/sbin/ss 0 108 1 0 10 0 1024 660 nanslp Ss??0:00.47 /usr/sbin/cr 1000 168 1 0 10 0 968 528 nanslp S d1- 0:06.88 /usr/local/b 0 257 1 0 10 0 1268 824 wait Isd10:00.03 login [pam] 023 1 71 18 0 212 44 pause Is??0:00.00 adjkerntz -i 097 1 0 2 0 940 580 select Ss??0:00.41 /usr/sbin/sy 0 112 1 0 2 0 924 468 select Ss??0:00.24 /usr/sbin/us 0 249 1 0 3 0 952 544 ttyin Is+ v10:00.00 /usr/libexec 0 248 1 0 3 0 952 544 ttyin Is+ v00:00.00 /usr/libexec 0 250 1 0 3 0 952 544 ttyin Is+ v20:00.00 /usr/libexec 0 251 1 0 3 0 952 544 ttyin Is+ v30:00.00 /usr/libexec 0 252 1 0 3 0 952 544 ttyin Is+ v40:00.00 /usr/libexec 0 253 1 0 3 0 952 544 ttyin Is+ v50:00.00 /usr/libexec 0 254 1 0 3 0 952 544 ttyin Is+ v60:00.00 /usr/libexec 0 255 1 0 3 0 952 544 ttyin Is+ v70:00.00 /usr/libexec 0 256 1 0 3 0 948 516 siodcd I ??0:00.00 /usr/libexec 0 0 0 3 -18 0 00 sched DLs ??0:00.00 (swapper) 0 6 0 0 -2 0 00 vlruwt DL??0:00.61 (vnlru) 0 4 0 0 -18 0 00 psleep DL??0:00.63 (bufdaemon) 0 3 0 3 18 0 00 psleep DL??0:00.00 (vmdaemon) 0 2 0 0 -18 0 00 psleep DL??0:00.24 (pagedaemon 0 5 0 0 18 0 00 syncer DL??0:45.58 (syncer) rack2-101.nyc# systat -vmstat: 2 usersLoad 0.65 0.65 0.61 Aug 1 12:43 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 4024246116 413732 5916 55372 count All 10264166792 3985912 7120 pages Interrupts Proc:r p d s wCsw Trp Sys Int Sof Flt 1 cow8151 total 2 10 6222 617086499 8151 110 11 155608 wirestray irq7 400952 act7921 mux irq9 16.4%Sys 19.0%Intr 26.3%User 0.0%Nice 38.3%Idl 416452 inact 2 ata0 irq14 |
RE: Multipath Routing
> I am no programmer, so forgive my ignorance in that respect, but why can't a > metric be used to differentiate routes to the same destination network > within the routing table? I happened to be googling and found: > > http://daily.daemonnews.org/view_story.php3?story_id=3878 > > which describes a patch to -STABLE that does exactly what I am talking > about. Routing will always follow the better metric. That's the paradigm. So if you have two routes the one with the better metric will always rule. Frankly, I don't quite see the rationale for such a hack. This can be solved using available mechanisms such as VRRP (or HSRP, if the gateways are decent routers). Furthermore: It doesn't detect when remote hosts are down. This is not the job of the kernel. It's not a routing protocol, it's not an automatic failover system. So what is this good for, that cannot be solved by already available mechanisms? Helge ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multipath Routing
Better yet would be equal cost multi-path, since the code to solve that should (mostly) be able to handle the general case :) [EMAIL PROTECTED] :) Content-Description: signed data > [this was posted under another thread, so I am reposting as a new thread to > hopefully generate some responses. thanks.] > > I am no programmer, so forgive my ignorance in that respect, but why can't a > metric be used to differentiate routes to the same destination network > within the routing table? I happened to be googling and found: > > http://daily.daemonnews.org/view_story.php3?story_id=3878 > > which describes a patch to -STABLE that does exactly what I am talking > about. > > Is there any reason why this shouldn't be implemented by default in the OS? > I am not being critical of the FreeBSD operating system by any means, just > curious. > > Personally, I would very much like the ability of Zebra to feed the kernel > the same route via multiple gateways, differentiating those routes by > metric value. > > Comments? > > -- > +-+--+ > | Michael W. Oliver, CCNP | "The tree of liberty must be | > | IPv6 & FreeBSD mark | refreshed from time to time | > | [EMAIL PROTECTED]| with the blood of patriots | > | http://michael.gargantuan.com/| and tyrants."| > | ASpath-tree, Looking Glass, etc. | - President Thomas Jefferson | > | +--+ > | gpg key - http://michael.gargantuan.com/gnupg/pubkey.asc | > ++ > > -- >-=-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-=-< Ryan Mooney [EMAIL PROTECTED] <-=-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-=-> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: T/TCP useless on FreeBSD 4.7?
Bruce M Simpson wrote: SYN cookies and T/TCP can't co-exist. Right, right, I forgot that one. Thanks. sysctl -a net.inet.tcp ;-) It's less than a screenful. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: T/TCP useless on FreeBSD 4.7?
Michael Sierchio wrote: > michael rabinovich wrote: > > > > Am I missing something (after all, FreeBSD is supposed to be a ref > > implementation of T/TCP!) and if not is there is a simple way around > > this problem, short of going back to earlier FreeBSD releases? > > sysctl net.inet.tcp | grep -E 'rfc1644|drop_synfin' > > ? > > sysctl net.inet.tcp | grep -E 'rfc1644|drop_synfin' net.inet.tcp.rfc1644: 1 > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: T/TCP useless on FreeBSD 4.7?
On Fri, Aug 01, 2003 at 11:14:12AM -0400, michael rabinovich wrote: > Does anyone know the status of T/TCP support on FreeBSD 4.7? ... > Am I missing something (after all, FreeBSD is supposed to be a ref > implementation of T/TCP!) and if not is there is a simple way around > this problem, short of going back to earlier FreeBSD releases? I don't use T/TCP on my production 4.8-RELEASE system, and the following sysctl values look fairly default:- net.inet.tcp.rfc1644: 0 net.inet.tcp.syncookies: 1 net.inet.tcp.drop_synfin: 0 SYN cookies and T/TCP can't co-exist. Please do check the above sysctl values; I know RFC 1644 has to be enabled, and syncookies have to be disabled, as well as drop_synfin. HTH, BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: T/TCP useless on FreeBSD 4.7?
michael rabinovich wrote: Am I missing something (after all, FreeBSD is supposed to be a ref implementation of T/TCP!) and if not is there is a simple way around this problem, short of going back to earlier FreeBSD releases? sysctl net.inet.tcp | grep -E 'rfc1644|drop_synfin' ? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
T/TCP useless on FreeBSD 4.7?
Hi,
Does anyone know the status of T/TCP support on FreeBSD 4.7?
A simple test using the ttcpcli and ttcpserv
examples from Stevens' T/TCP book shows basically the
same behavior as described in Sec. 3.7 of the book as "Solaris bug":
the server drops the data in the initial SYN
segment from the client, causing the client to timeout and retransmit
the data.
Specifically, tcpdump (see below) shows that both hosts do
exchange proper TTCP options (CC + CCecho), so TTCP is indeed used.
It's just that the server drops the data and causes a
timeout+retransmission on the client side.
The source code in /sys/netinet/tcp_syncache.c seems to support this
guess (see the snippet below).
For the test, I used FreeBSD 4.7 Release 2
as a client and FreeBSD 4.7 Release 0 as the server.
Am I missing something (after all, FreeBSD is supposed to be a ref
implementation of T/TCP!) and if not is there is a simple way around
this problem, short of going back to earlier FreeBSD releases?
Thanks so much in advance,
Michael Rabinovich
--
Michael Rabinovich [EMAIL PROTECTED]
AT&T Labs - Research(973)360-8778 (voice)
180 Park Ave, (973)360-8871 (fax)
Florham Park, NJ 07932 www.research.att.com/~misha
--
***
Here is the source code snippet from /sys/netinet/tcp_syncache.c:
***
/*
* Given a LISTEN socket and an inbound SYN request, add
* this to the syn cache, and send back a segment:
*
* to the source.
*
* IMPORTANT NOTE: We do _NOT_ ACK data that might accompany the SYN.
* Doing so would require that we hold onto the data and deliver it
* to the application. However, if we are the target of a SYN-flood
* DoS attack, an attacker could send data which would eventually
* consume all available buffer space if it were ACKed. By not ACKing
* the data, we avoid this DoS scenario.
*/
int
syncache_add(inc, to, th, sop, m)
struct in_conninfo *inc;
struct tcpopt *to;
struct tcphdr *th;
struct socket **sop;
struct mbuf *m;
{
**
Here is the TCP dump with CC options (I produced it with "-s 0" option
but removed some of the packet payloads for brevity):
**
15:40:37.716398 gs1.research.att.com.3000 > cdn2.research.att.com.: SFP
2663030787:2663031187(400) win 57600 (DF)
0x 4500 01d4 1861 4000 4006 87cf 0e2d[EMAIL PROTECTED]@..-
0x0010 87cf 0e22 0bb8 22b8 9eba a003 ..."..".
0x0020 c00b e100 2db4 0204 05b4 0103 0300-...
0x0030 0101 080a 0e68 4e39 0101 0b06.hN9
0x0040 0002 8be1 5265 7120 6672 6f6d 2067 7331Req.from.gs1
0x0050 2074 6f20 6364 6e32 00c7 0585 .to.cdn2
0x0060 35db 0485 7084 0408 c2f5 0685 1ad8 04855...p...
15:40:37.716695 cdn2.research.att.com. > gs1.research.att.com.3000: S
2005557341:2005557341(0) ack 2663030788 win 57344 (DF)
0x 4500 004c d61a 4000 4006 38a4 87cf 0e22[EMAIL PROTECTED]@.8"
0x0010 87cf 0e2d 22b8 0bb8 778a 605d 9eba a004...-"...w.`]
0x0020 e012 e000 efdf 0204 05b4 0103 0300
0x0030 0101 080a 0c4c b6e3 0e68 4e39 0101 0b06.L...hN9
0x0040 0440 0101 0d06 0002 8be1 [EMAIL PROTECTED]
15:40:37.716715 gs1.research.att.com.3000 > cdn2.research.att.com.: F 401:401(0)
ack 1 win 57600 (DF)
0x 4500 003c 1862 4000 4006 87cf 0e2dE..<[EMAIL PROTECTED]@..-
0x0010 87cf 0e22 0bb8 22b8 9eba a194 778a 605e..."..".w.`^
0x0020 a011 e100 2c1c 0101 080a 0e68 4e39,hN9
0x0030 0c4c b6e3 0101 0b06 0002 8be1 .L..
15:40:37.716843 cdn2.research.att.com. > gs1.research.att.com.3000: . ack 1 win
57600 (DF)
0x 4500 003c d61b 4000 4006 38b3 87cf 0e22E..<[EMAIL PROTECTED]@.8"
0x0010 87cf 0e2d 22b8 0bb8 778a 605e 9eba a004...-"...w.`^
0x0020 a010 e100 d496 0101 080a 0c4c b6e3.L..
0x0030 0e68 4e39 0101 0b06 0440 .hN9...@
15:40:38.913084 gs1.research.att.com.3000 > cdn2.research.att.com.: FP 1:401(400)
ack 1 win 57600 (DF)
0x 4500 01cc 1865 4000 4006 87cf 0e2d[EMAIL PROTECTED]@..-
0x0010 87cf 0e22 0bb8 22b8 9eba a004 778a 605e..."..".w.`^
0x0020 a019 e100 2dac 0101 080a 0e68 4eb1-hN.
0x0030 0c4c b6e3 0101 0b06 0002 8be1 5265 7120.L..Req.
0x0040 6672 6f6d 2067 7331 2074 6f20 6364 6e32from.gs1.to.cdn2
0x0050 00c7 0585 35
TCP socket shutdown race condition
Earlier this week one of our FreeBSD 4.7 boxes panic'd. I've posted the
stack trace at the end of this message. Using google, I've found several
references to this panic over the past three years, but it seems its never
been taken to root cause.
The box crashes because the cr_uidinfo pointer in the so_cred structure is
null. However, on closer inspection the so_cred structure is corrupted
(cr_ref=3279453304 for example), so I'm guessing it has already been freed.
Looking closer at the socket, I see that the SS_NOFDREF flag is set, which
supports my theory. The tcpcb is in the CLOSED state, and has the SENTFIN
flag set.
I was able to reproduce this crash, although when I reproduced it it was the
2msl timer that triggered it instead of the rexmt timer, and the socket was
in the TIME_WAIT state. To reproduce it, I ran a server on a SMP box that
accepts incoming TCP connections, adds each socket to a kqueue, reads data
and calls shutdown(), then calls close(), and I had another box making
thousands of connections per second. Since kqueue and shutdown were
involved, there's a slight chance that this could be related to kern/54331.
However I still need to fine-tune my test to narrow down the problem and
make it happen faster (it took over 12 hours to reproduce).
Any ideas on what the problem might be? Suggestions on how I can debug
this?
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:493
#1 0xc01ba7e8 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:322
#2 0xc01bad11 in panic (fmt=0xc0327ad9 "%s")
at /usr/src/sys/kern/kern_shutdown.c:608
#3 0xc02d414e in trap_fatal (frame=0xff807ca8, eva=48)
at /usr/src/sys/i386/i386/trap.c:974
#4 0xc02d3d7d in trap_pfault (frame=0xff807ca8, usermode=0, eva=48)
at /usr/src/sys/i386/i386/trap.c:867
#5 0xc02d381f in trap (frame={tf_fs = -820445160, tf_es = 16,
tf_ds = -8388592, tf_edi = 0, tf_esi = -1070280516, tf_ebp = -8356624,
tf_isp = -8356652, tf_ebx = -1, tf_edx = 1778434048, tf_ecx =
-93045248,
tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071185923, tf_cs =
8,
tf_eflags = 66054, tf_esp = -820398592, tf_ss = -820398592})
at /usr/src/sys/i386/i386/trap.c:466
#6 0xc026fffd in acquire_lock (lk=0xc034d0bc) at machine/globals.h:114
#7 0xc02749e4 in softdep_update_inodeblock (ip=0xcf19b600, bp=0xdb8ca0dc,
waitfor=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3813
#8 0xc026f03a in ffs_update (vp=0xfa743e00, waitfor=0)
at /usr/src/sys/ufs/ffs/ffs_inode.c:106
#9 0xc0278437 in ffs_sync (mp=0xcf0cfa00, waitfor=2, cred=0xc387b800,
p=0xc0378880) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1025
#10 0xc01f1e9b in sync (p=0xc0378880, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:576
#11 0xc01ba55b in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:241
#12 0xc01bad11 in panic (fmt=0xc0327ad9 "%s")
at /usr/src/sys/kern/kern_shutdown.c:608
#13 0xc02d414e in trap_fatal (frame=0xff807e84, eva=8)
at /usr/src/sys/i386/i386/trap.c:974
#14 0xc02d3d7d in trap_pfault (frame=0xff807e84, usermode=0, eva=8)
at /usr/src/sys/i386/i386/trap.c:867
#15 0xc02d381f in trap (frame={tf_fs = -1071579112, tf_es = -819986416,
tf_ds = -818085872, tf_edi = 0, tf_esi = 2147483647, tf_ebp =
-8356140,
tf_isp = -8356176, tf_ebx = -1, tf_edx = 1644167168, tf_ecx = 0,
tf_eax = 1644167168, tf_trapno = 12, tf_err = 0, tf_eip = -1071930883,
tf_cs = 8, tf_eflags = 66054, tf_esp = -272018704, tf_ss =
-272018816})
at /usr/src/sys/i386/i386/trap.c:466
#16 0xc01ba1fd in chgsbsize (uip=0x0, hiwat=0xefc952f4, to=0,
max=9223372036854775807) at /usr/src/sys/kern/kern_resource.c:780
#17 0xc01e0243 in sbrelease (sb=0xefc952f0, so=0xefc95280)
at /usr/src/sys/kern/uipc_socket2.c:437
#18 0xc01dd457 in sofree (so=0xefc95280) at
/usr/src/sys/kern/uipc_socket.c:262
#19 0xc020d44c in in_pcbdetach (inp=0xf24437e0)
at /usr/src/sys/netinet/in_pcb.c:567
#20 0xc021e97a in tcp_close (tp=0xf24438a0)
at /usr/src/sys/netinet/tcp_subr.c:754
#21 0xc021e7a3 in tcp_drop (tp=0xf24438a0, errno=60)
at /usr/src/sys/netinet/tcp_subr.c:604
#22 0xc0220eb6 in tcp_timer_rexmt (xtp=0xf24438a0)
at /usr/src/sys/netinet/tcp_timer.c:379
#23 0xc01c16de in softclock () at /usr/src/sys/kern/kern_timeout.c:131
#24 0xc02c2dfb in doreti_swi ()
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
freeBSD NIS-server - LINUX NIS-client auth/login probs
hi, i set up a NIS server on freebsd(5.1) excactly like in the handbook and then started the NIS client on linux (RH-9). (i just have 1 test user for now) 1) here's the output from ypcat passwd: the client binds the server ok: [EMAIL PROTECTED] ypcat passwd testo:*:1003:1003:User &:/home/testo/:/usr/local/bin/bash (the home dir does exist on the client -- via NFS) also in the RH user-manager i can see the user testo but i CANT LOGIN i think its an auth problem. on the freeBSD side i use md5 as default encrypt. but thats ok with linux i think.(on the freebsd side in /etc/login.conf defined) 2) there is a option in /var/yp/Makefile on the FREEBSD side "UNSECURE=true" but its commented out. here'S the discription of this option: -- # If you want to use a FreeBSD NIS server to serve non-FreeBSD clients # (i.e. clients who expect the password field in the passwd maps to be # valid) then uncomment this line. This will cause $YPDIR/passwd to # be generated with valid password fields. This is insecure: FreeBSD # normally only serves the master.passwd maps (which have real encrypted # passwords in them) to the superuser on other FreeBSD machines, but # non-FreeBSD clients (e.g. SunOS, Solaris (without NIS+), IRIX, HP-UX, # etc...) will only work properly in 'unsecure' mode. # #UNSECURE="True" DO I need this ? 3) also i am not shure what config to use in nsswitch.conf on linux because i dunno what NIS(1/2/+) freebsd is using so is this ok? -SNIP (/etc/nsswitch.conf)-- passwd: compat group: compat shadow: nis files # i think there is no compat for shadow passwd_compat: nis group_compat: nis -- and then add the "+::" stuff to /etc/shadow passwd and groups or just: passwd: nis files shadow: nis files group: nis files --- and NOT use the +::: stuff in the passwd,group.shadow files ? or sth with nis+ in nsswitch.conf ? i am soo confused ! 5) what about the diffrent styles of the "shadowed" password file of LINUX(/etc/shadow) and FREEBSD (/etc/master.passwd) the freebsd master.passwd has more fields then the linux equivalent here'an example: ---FREBSD(/etc/master.passwd)-- man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin -- nine ":"'s right LINUX(/etc/shadow)-- daemon:*:11833:0:9:7::: -- eight ":"'s i think linux is missing the class thing from BSD but that shouldn't be a prob for NIS because thats ecaxtly what it is there for, distrubution passwd+logins for diff. systems RIGHT. 6) BTW my umask is 0077 do others/group need read-access to and of the files in /var/yp/* ??? ok thats all i can think of right now PLS if someone can help "SAVE MY WEEKEND" and help me. LOL Thomas Zauner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: freevrrp
> From: Bryce Edwards [mailto:[EMAIL PROTECTED]
> Sent: Donnerstag, 31. Juli 2003 18:59
> To: [EMAIL PROTECTED]
> Subject: freevrrp
>
> I'm trying to run freevrrpd on a server with two interfaces
> for redundancy.
I would prefer a layer 2 based approach ("EtherChannel") instead because of
the much better convergence in case of failure, and you also get load
sharing in both directions. Bundling two or more interfaces by means of
netgraph would probably serve the job.
Are there any off-the-shelf, i.e. native FEC solutions available?
Helge
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
