HEADS UP: sshd(8) + nologin(5) going to work again
Hi all, As some of us may have noticed, sshd(8) has ignored nologin(5) in its default configuration since it was PAM-ified. That is a pain to admins of multi-user systems as they have to resort to drastic means such as killing the sshd master process when they need to disable user logins temporarily. I'm about to MFC a fix for this problem to RELENG_6 in the hope that nobody relies on the bug, i.e., no one uses nologin(5) to prevent all logins into the system but those via sshd(8), because doing so would be a really poor idea. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up
On Mon, Mar 05, 2007 at 01:14:29PM -0500, Mikhail Teterin wrote: On Monday 05 March 2007 08:23, Yar Tikhiy wrote: = How will it break them? swap backing only touches swap if there is = memory pressure, i.e. precisely the situation in which malloc backing = will panic. = = I forgot that in BSD swap wouldn't be allocated in advance to its = consumers. Then removing the -M flag and making swap backing the = default is a very sound choice. Thank you for correcting me. Yar, would you change the man-page's advice and the default, then? Done in CURRENT. I'll MFC it in a week. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up
On Sun, Mar 04, 2007 at 10:59:46PM -0500, Kris Kennaway wrote: On Sun, Mar 04, 2007 at 10:59:46AM +0300, Yar Tikhiy wrote: On Tue, Feb 27, 2007 at 04:03:30PM -0500, Mikhail Teterin wrote: On Tuesday 27 February 2007 15:53, Alex Kozlov wrote: = Yes, I switched to swap-backed md already. But the malloc-based variety is = currently the _default_ (see /etc/defaults/rc.conf)... = Bad default. Filing a PR. Keep in mind that changing the default can break existing setups. Such setups are likely to be broken anyway, but... E.g., if we drop the -M flag, it will break systems with tons of RAM but little swap using tmpmfs. How will it break them? swap backing only touches swap if there is memory pressure, i.e. precisely the situation in which malloc backing will panic. I forgot that in BSD swap wouldn't be allocated in advance to its consumers. Then removing the -M flag and making swap backing the default is a very sound choice. Thank you for correcting me. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up
On Mon, Mar 05, 2007 at 01:14:29PM -0500, Mikhail Teterin wrote: On Monday 05 March 2007 08:23, Yar Tikhiy wrote: = How will it break them? swap backing only touches swap if there is = memory pressure, i.e. precisely the situation in which malloc backing = will panic. = = I forgot that in BSD swap wouldn't be allocated in advance to its = consumers. Then removing the -M flag and making swap backing the = default is a very sound choice. Thank you for correcting me. Yar, would you change the man-page's advice and the default, then? Yes, I'll be glad to if no objections arise until I finish updating my CURRENT machine, i.e., tomorrow. :-) Someone still needs to look into the panic... Who would that be? Obviously, Mr(s). Someone. :-) The md case exposes a quite tangled nature of the problem. Funnily enough, kernel malloc() cannot just fail in the case because it must not fail if called with M_WAITOK. This means that the system has quite a rough choice: - put the requesting thread to sleep forever; - grow kmem_map, eventually sacrifice all RAM to the greedy thread and die sooner or later; - panic immediately. If all malloc() callers in the kernel were ready to deal with allocation failure, the system could just tell the greedy thread to buzz off. But too many kernel parts depend on malloc(M_WAITOK) never failing. Perhaps it's the root of the problem. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up
On Mon, Mar 05, 2007 at 09:30:22PM +0200, Kostik Belousov wrote: On Mon, Mar 05, 2007 at 10:17:14PM +0300, Yar Tikhiy wrote: On Mon, Mar 05, 2007 at 01:14:29PM -0500, Mikhail Teterin wrote: On Monday 05 March 2007 08:23, Yar Tikhiy wrote: = How will it break them? swap backing only touches swap if there is = memory pressure, i.e. precisely the situation in which malloc backing = will panic. = = I forgot that in BSD swap wouldn't be allocated in advance to its = consumers. Then removing the -M flag and making swap backing the = default is a very sound choice. Thank you for correcting me. Yar, would you change the man-page's advice and the default, then? Yes, I'll be glad to if no objections arise until I finish updating my CURRENT machine, i.e., tomorrow. :-) Someone still needs to look into the panic... Who would that be? Obviously, Mr(s). Someone. :-) The md case exposes a quite tangled nature of the problem. Funnily enough, kernel malloc() cannot just fail in the case because it must not fail if called with M_WAITOK. This means that the system has quite a rough choice: - put the requesting thread to sleep forever; - grow kmem_map, eventually sacrifice all RAM to the greedy thread and die sooner or later; - panic immediately. If all malloc() callers in the kernel were ready to deal with allocation failure, the system could just tell the greedy thread to buzz off. But too many kernel parts depend on malloc(M_WAITOK) never failing. Perhaps it's the root of the problem. Mark callers that are ready for M_WAITOK failure with some additional flag, like M_FAILOK (feel free to propose meaningful name there). At least malloc()-based md could then use it. The problem isn't that we don't have such a flag yet. It's that some parts of the kernel would rather we didn't have it. :-) Of course, introducing the flag or changing semantics of malloc() in a similar way is a necessary start. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up
On Tue, Feb 27, 2007 at 04:03:30PM -0500, Mikhail Teterin wrote: On Tuesday 27 February 2007 15:53, Alex Kozlov wrote: = Yes, I switched to swap-backed md already. But the malloc-based variety is = currently the _default_ (see /etc/defaults/rc.conf)... = Bad default. Filing a PR. Keep in mind that changing the default can break existing setups. Such setups are likely to be broken anyway, but... E.g., if we drop the -M flag, it will break systems with tons of RAM but little swap using tmpmfs. OTOH, if we add '-o reserve', that will break systems with a too large but mostly unused tmpmfs. A sort of a loud announcement will be needed. By the way, I seem to be the one responsible for the paragraph in rc.conf(5) advocating -M for maximum performance and system stability at low memory conditions. When I wrote it, I thought as follows: were the system low on memory, additional swap activity due to mfs would just make the system start thrashing sooner, while malloc'd mfs would just report ENOSPC. I was unaware of the panic back then. Perhaps it was a misconception, either. I haven't heard of any real pitfalls in swap-backed mfs, and getting ENOSPC on /tmp early is no good. = Creation of a 2Gb malloc-based md should've failed on a machine with = 768Mb of RAM, shouldn't it have? = Only if you set '-o reserve'. Memory for malloc-based md was allocated = dynamically. But malloc can only allocate from RAM, right? So the amount of RAM is the hard limit, which a malloc-based md can not exceed even in theory. This means, md-creation should've failed... In fact, the limit should, of course, be even lower -- and mdmfs should be smart enough to substract the sizes of other kernel memory chunks from the maximum. Since even that would still not be a guarantee against running out, the system should be able to recover gracefully instead of panicing. Do you agree? FWIW, some discussion of the panic is in the audit trail of kern/87255. Irrespective of tmpmfs defaults, this is a way to panic the system with stock tools and without doing something totally stupid like writing junk to /dev/mem. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
How I updated 4.11 to 6.2 in a single reboot
Hi all, I hope the following story will divert a few potential subscribers from freebsd-eol and save some effort aimed to keep the 4.11 zombie dancing. DISCLAIMER: I take no responsibility for inconvenience or damage that can happen if one uses my story as a how-to guide, especially without full knowledge of what and why he is actually doing. YMMV. I had an old machine with its CD-ROM and floppy drives long-dead and PXE missing from its boot options. It was running 4.11-STABLE. Facing the virtual EOL of the entire 4-STABLE branch, I wanted to update the machine's OS to 6.2-RELEASE and forget about it for a while, bar running freebsd-update occasionally. You'll say I should have connected a working CD-ROM drive to the machine and used the opportunity to dust its inside. Alas, I felt too lazy even to walk to the console. So I chose the path of least effort: to replace the binaries in the live system through SSH. This might sound like installing a heart implant without narcosis, but the surgeon was sufficiently heartless himself. First, I downloaded the following 6.2 distribution parts from an FTP server to the machine: base, dict, games, info, kernels, manpages. Had I wanted a minimal set, it would have consisted of base, kernels, manpages. (I had been taught well in the past not to save on manpages irrespective of the system's role.) Second, I added the system users and groups that had been born between 4.11 and 6.2. The new users were proxy, _pflogd, _dhcp; the new groups were proxy, authpf, _pflogd, _dhcp, audit. I just grabbed the appropriate revisions of src/etc/master.passwd and src/etc/group from CVSWeb, extracted the new records from them, and added those records to /etc/master.passwd (using vipw) and /etc/group. The new master.passwd and group files could also have been extracted from the base 6.2 distro. Note that the next step, full extraction of distros, could have resulted in wrong file ownership without this step. After that, I set DESTDIR to /usr/tmp: # mkdir /usr/tmp # export DESTDIR=/usr/tmp and ran install.sh in each distro subdirectory: # for d in base dict games info manpages do ( cd $d sh install.sh ) done # cd kernels sh install.sh GENERIC So I got the new system's tree under /usr/tmp. At that stage, the old 4.11 tar(1) slightly mishandled the new archive format of the 6.2 distros by creating bogus PaxHeader directories instead of setting the schg flag on some files from the base distro. Fortunately, each PaxHeader directory hinted at which files should have had the schg flag set. Due to that I was able to save the list of files needing the flag. # find /usr/tmp -path */PaxHeader/* | sed -e s,/PaxHeader,, -e s,/usr/tmp,, /root/schg.lst I didn't set the flag on the files immediately because the files to be transferred to / would lose it anyway. (See below.) Then it was safe to remove the bogus directories: # find /usr/tmp -name PaxHeader | xargs rm -rf Having done with that, I created a scratch directory in / and transferred the respective files to it to make sure they fit in /: # mkdir /newroot # cd /usr/tmp # tar cf - COPYRIGHT bin boot dev etc lib libexec rescue sbin | ( cd /newroot tar xpf - ) Note my having used tar(1), not cp(1) there. Alas, cp(1) would mishandle hard links by copying each link as a separate file. OTOH, tar(1) would lose file flags -- that's why I had saved the schg candidate list. Then I fixed the default kernel: # cd /newroot/boot # cp -pR GENERIC/* kernel/ ... updated the boot blocks: # disklabel -B -b /newroot/boot/boot1 -s /newroot/boot/boot2 ad0s1 ... created the new system directories in /var (the others could wait): # cp -pR /usr/tmp/var/named /var/ # mtree -deU -f /newroot/etc/mtree/BSD.var.dist -p /var The mtree command was the second to require that the new system users and groups be created in advance. Then I transferred the most essential settings from /etc to /newroot/etc for the machine to be up and accessible over the network after a reboot. The following files could simply be copied: fstab, resolv.conf, ssh/*key*. A few files in /newroot/etc called for manual work: - rc.conf (see below); - master.passwd (added myself and the rest of local users); - group (the most important thing was to assign myself to the wheel group); - mail/aliases (set the root alias.) I also made sure I didn't have a shell from /usr/local. In addition, I disabled all extra services in the new rc.conf. The hostname, network interface configuration, defaultrouter, and sshd_enable=YES were basically needed in my case; stock services using the default configuration could also be enabled from the outset. After the preliminary merging of /etc, I built spwd.db and pwd.db in /newroot/etc: # pwd_mkdb -p -d /newroot/etc /newroot/etc/master.passwd To get the correct time zone after the reboot, I also copied /newroot/etc/localtime from /usr/tmp/usr/share/zoneinfo/Europe/Moscow. I should have created /newroot/etc/wall_cmos_clock
Re: negative runtime etc., the story continues
On Tue, Dec 19, 2006 at 11:49:43PM +0100, V??clav Haisman wrote: Hi, I wrote about how FreeBSD 6.1 RC1, with latest RELENG_6 kernel, prints loads of calcru: runtime went backwards... and calcru: negative runtime... messages when the FreeBSD runs as virtual server under Microsoft Virtual Server 2006 R2. When I wrote this I was compiling and installing lots of packages, setting up the OS. Now that it is idle I have noticed one quite bad thing. Any process that sleeps on timer or sleep() call will wake up much later than it should. For example, when I start top there should be two seconds delay between updates of the screen. It takes up to 20 seconds! But when there is compilation running or something else CPU intensive, the timer seems to work fine. I even tried setting different kern.timecounter.hardware (TSC, ACPI-safe, i8254) and kern.hz (to lower than the default 1000) but that did not help a bit. Is there anything I can do to get rid of the calcru messages apart from reinstalling to real hardware? Last time I was trying to run FreeBSD as a guest OS in MS VS, I found that TSC would work the best, but only if I made sure that the TSC frequency was correct. For some weird reason, the frequency initially detected by the kernel was totally bogus and changing from one boot to another, so I just estimated it from cpu-z output in the host OS, and it fairly worked. I still couldn't get rid of the annoying warnings, especially when under load. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel statistics weirdness on RELENG_6{_1,_2} / 64bit?
On Tue, Nov 28, 2006 at 07:54:52PM +0100, Joerg Pernfuss wrote: Hi, a while ago I noticed something odd on my 64bit FreeBSD 6 systems - two amd64, one alpha. I can't make head or tails of it, so I post it in hope that someone can. Box #1: [EMAIL PROTECTED]: ~% uname -srm FreeBSD 6.1-RELEASE-p7 amd64 [EMAIL PROTECTED]: ~% grep kern.ipc /boot/loader.conf kern.ipc.nsfbufs=8192 kern.ipc.nmbclusters=49152 [EMAIL PROTECTED]: ~% sysctl kern.ipc.nsfbufs kern.ipc.nmbclusters kern.ipc.nsfbufs: 0 kern.ipc.nmbclusters: 32768 [EMAIL PROTECTED]: ~% netstat -m 350/132/482/49152 mbuf clusters in use (current/cache/total/max) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 2864770 requests for I/O initiated by sendfile Box #2: [EMAIL PROTECTED]: ~% uname -srm FreeBSD 6.2-RC1 alpha [EMAIL PROTECTED]: ~% grep kern.ipc /boot/loader.conf kern.ipc.nsfbufs=4294967300 [EMAIL PROTECTED]: ~% sysctl kern.ipc.nsfbufs kern.ipc.nmbclusters kern.ipc.nsfbufs: 0 kern.ipc.nmbclusters: 1664 [EMAIL PROTECTED]: ~% netstat -m 64/80/144/1664 mbuf clusters in use (current/cache/total/max) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile Box #3: [EMAIL PROTECTED]: ~% uname -srm FreeBSD 6.1-RELEASE-p10 amd64 [EMAIL PROTECTED]: ~% grep kern.ipc /boot/loader.conf kern.ipc.nsfbufs=8192 kern.ipc.nmbclusters=49152 [EMAIL PROTECTED]: ~% sysctl kern.ipc.nsfbufs kern.ipc.nmbclusters kern.ipc.nsfbufs: 0 kern.ipc.nmbclusters: 32768 [EMAIL PROTECTED]: ~% grep NSF /root/kernel/RIVENDELL options NSFBUFS=8192 [EMAIL PROTECTED]: ~% netstat -m 64/118/182/49152 mbuf clusters in use (current/cache/total/max) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 35 requests for I/O initiated by sendfile For comparison, Box #4: [EMAIL PROTECTED]: ~% uname -srm FreeBSD 6.1-STABLE i386 [EMAIL PROTECTED]: ~% grep kern.ipc /boot/loader.conf kern.ipc.nsfbufs=8192 [EMAIL PROTECTED]: ~% sysctl kern.ipc.nsfbufs kern.ipc.nmbclusters kern.ipc.nsfbufs: 8192 kern.ipc.nmbclusters: 32768 [EMAIL PROTECTED]: ~% netstat -m 104/272/376/32768 mbuf clusters in use (current/cache/total/max) 1598/2635/8192 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 8938512 requests for I/O initiated by sendfile So, looking at the `netstat -m' output, setting kern.ipc.nmbclusters in the loader.conf seems to work, but the sysctl reports the default value that would be in place, if it wasn't overridden in the loader.conf. For the sendfile buffers, the stats are completely out of whack. The sysctl reports 0 for every value (`netstat-m' just prints the sysctl fields for these values if I understood the source right (unlikely). But sendfile() works and the accounting on the number of sendfile calls seems to work too. So I believe the NSFBUFS kernel option and the loader.conf setting work, but it is quite impossible to properly tune the buffers to the workload. I did not bother trying the NMBCLUSTERS kernel option, it was removed a while ago anyway. The loader.conf kern.ipc.nsfbufs value on box #2 is ridiculously high, yes, I tried to get beyond the boundary of a u_int_32 to see if maybe something good or bad happens. It did not. At this point, I wanted to include links to two mails on amd64@ I found when I first searched for this oddity, both of which had no reply. Instead I found a posting to net@ that occured in the meantime, and a reply to it by Yar Tikhiy two days ago explaining the nsfbufs issue. There are no such buffers on amd64, ia64 and alpha as they aren't needed. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=26091+0+current/freebsd-net Ok, that leaves the question why `sysctl kern.ipc.nmbclusters' reports a different value compared to the `netstat -m' output on box #1 and #3. netstat -m doesn't use the sysctl. It reads the zone limit via memstat_get_countlimit() from libmemstat(3) instead. Perhaps this can account for the difference observed. Thanks for any pointers, Joerg PS: documenting the nsfbufs issue on amd64/ia64/alpha might be a good PS: idea. loader(8) seems a good place. Opinions? I've already documented the issue in sendfile(2) in CURRENT. MFC is due. A small note in loader(8) would be good, too -- thanks for the suggestion. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pleading for commit
On Tue, Oct 24, 2006 at 03:04:09PM -0500, Dan Nelson wrote: In the last episode (Oct 24), Doug Barton said: Duane Whitty wrote: Patching it myself after every cvs update is not such a big deal; It is forgetting to patch it after every update which is a big deal. Write a little script for yourself that calls cvsup then runs patch so you won't forget. :) Or cvsup the CVS repository (instead of using checkout mode), check out your working tree from there, and run cvs update to update your sources, which will preserve local changes. ... or run a local CVS/SVN/whatever repo and keep your customized FreeBSD source tree in it and import recent FreeBSD changes once in a while, as tough guys do... :-) Well, returning to the main topic, inability to run Flash can be a good thing, after all, if your browser doesn't have a knob to turn the damned thing off. :-) But what else suffers in an unpatched system? -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: identity crisis of 6-STABLE in ipfw ipv6 ?
On Wed, Aug 16, 2006 at 10:57:02AM -0400, John Baldwin wrote: On Wednesday 16 August 2006 04:53, David Malone wrote: On Wed, Aug 16, 2006 at 08:13:20AM +0200, Kees Plonsz wrote: I just updated to 6-STABLE but my ipfw rules stopped working. It seems that me6 is vanished into thin air. # ipfw add 7000 allow ip from me6 to me6 ipfw: hostname ``me6'' unknown I think it was broken by some missing brackets in this commit: http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ipfw/ipfw2.c#rev1.88 Can you try the patch below? If it looks good, Max or I can commit the fix. David. Note that the strcmp() != 0 doesn't need extra ()'s as != is higher than in precedence. Ditto for ret == NULL on the same line. That can be spelled safely as: if (ret == NULL strcmp(av, any) != 0) It's the precedence of vs. || that can be mistaken easily. The rule is simple: is multiplication and || is addition, with their relative precedence the same as that of their arith counterparts. However, it's usually safer to use more paretheses around them because anybody but a die-hard C freak will have trouble interpreting long chains of logical subexpressions connected by 's and ||'s, with the meaning of some of them reversed by a bang. :-) Operator Associativity - ... == !=left to right ... left to right || left to right Index: ipfw2.c === RCS file: /FreeBSD/FreeBSD-CVS/src/sbin/ipfw/ipfw2.c,v retrieving revision 1.88 diff -u -r1.88 ipfw2.c --- ipfw2.c 14 May 2006 03:53:04 - 1.88 +++ ipfw2.c 16 Aug 2006 08:50:04 - @@ -3707,10 +3707,10 @@ inet_pton(AF_INET6, host, a)) ret = add_srcip6(cmd, av); /* XXX: should check for IPv4, not !IPv6 */ - if ((ret == NULL) proto == IPPROTO_IP || strcmp(av, me) == 0 || - !inet_pton(AF_INET6, host, a)) + if ((ret == NULL) (proto == IPPROTO_IP || strcmp(av, me) == 0 || + !inet_pton(AF_INET6, host, a))) ret = add_srcip(cmd, av); - if ((ret == NULL) strcmp(av, any) != 0) + if ((ret == NULL) (strcmp(av, any) != 0)) ret = cmd; free(host); @@ -3733,10 +3733,10 @@ inet_pton(AF_INET6, host, a)) ret = add_dstip6(cmd, av); /* XXX: should check for IPv4, not !IPv6 */ - if ((ret == NULL) proto == IPPROTO_IP || strcmp(av, me) == 0 || - !inet_pton(AF_INET6, av, a)) + if ((ret == NULL) (proto == IPPROTO_IP || strcmp(av, me) == 0 || + !inet_pton(AF_INET6, av, a))) ret = add_dstip(cmd, av); - if ((ret == NULL) strcmp(av, any) != 0) + if ((ret == NULL) (strcmp(av, any) != 0)) ret = cmd; free(host); ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Default route (IPv4) demolished by destroying clone (gif/gre) interface
On Wed, Aug 16, 2006 at 12:15:25PM -0500, Brooks Davis wrote:
On Wed, Aug 16, 2006 at 07:58:44PM +0400, Yar Tikhiy wrote:
On Wed, Aug 16, 2006 at 09:54:19AM -0500, Brooks Davis wrote:
On Wed, Aug 16, 2006 at 10:23:13AM +0200, Stefan Bethke wrote:
Ouch. Don't ppp(8), OpenVPN etc. destroy the tun interface they're
using when they exit? Flushing all routes then would be rather
harmful. I'm glad I haven't updated to a newer -stable yet then :-)
In general, no since tun interfaces can not be destroyed.
Did you mean in particular? :-)
The problem can be triggered by destroying any interface that can
be destroyed. Just imagine getting rid of a defunct gif tunnel on
a remote router, or removing an unused vlan, and totally losing
connectivity to the router due to its default route having been
flushed. The scenario still can be quite unpleasant. I'd rather
change the default for $removable_route_flush to NO and let the
kernel choose which routes should be flushed upon the physical
ejection or software destruction of an interface. Note that this
doesn't include static_routes_${ifn}, which are handled separately
by pccard_ether_stop().
Agreed. That code shouldn't be on by default. I've disabled in it HEAD
and will MFC in a few days. As another poster said, I'm not even sure
it should exist as an option.
Much appreciated!
--
Yar
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Default route (IPv4) demolished by destroying clone (gif/gre) interface
On Wed, Aug 16, 2006 at 03:59:13PM -0500, Brooks Davis wrote:
On Thu, Aug 17, 2006 at 08:49:27AM +1200, Andrew Thompson wrote:
On Wed, Aug 16, 2006 at 12:15:25PM -0500, Brooks Davis wrote:
On Wed, Aug 16, 2006 at 07:58:44PM +0400, Yar Tikhiy wrote:
On Wed, Aug 16, 2006 at 09:54:19AM -0500, Brooks Davis wrote:
On Wed, Aug 16, 2006 at 10:23:13AM +0200, Stefan Bethke wrote:
Ouch. Don't ppp(8), OpenVPN etc. destroy the tun interface they're
using when they exit? Flushing all routes then would be rather
harmful. I'm glad I haven't updated to a newer -stable yet then :-)
In general, no since tun interfaces can not be destroyed.
Did you mean in particular? :-)
The problem can be triggered by destroying any interface that can
be destroyed. Just imagine getting rid of a defunct gif tunnel on
a remote router, or removing an unused vlan, and totally losing
connectivity to the router due to its default route having been
flushed. The scenario still can be quite unpleasant. I'd rather
change the default for $removable_route_flush to NO and let the
kernel choose which routes should be flushed upon the physical
ejection or software destruction of an interface. Note that this
doesn't include static_routes_${ifn}, which are handled separately
by pccard_ether_stop().
Agreed. That code shouldn't be on by default. I've disabled in it HEAD
and will MFC in a few days. As another poster said, I'm not even sure
it should exist as an option.
Thanks for fixing this up, it certainly was odd to be flushing routes in
userland. I have one more bug report from the ifnet/devd change to look
at where renamed interfaces give some sort of an error.
It is a rather weird bit of code. It deletes all IPv4 routes on exit.
I suspect it's a hack left over from before interface removal really
worked. I may just delete the code in HEAD after the MFC. I think we
could also remove the arp flush or move it into netif stop and narrow
it with the -i option.
The -i option may not work in that case because the interface has
ceased to exist by the time devd(8) gets the notification and runs
/etc/pccard_ether. It could be better just to remove the arp flush
completely. The kernel should take care of the arp entries by itself.
Thanks!
--
Yar
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Default route (IPv4) demolished by destroying clone (gif/gre) interface
On Tue, Aug 15, 2006 at 07:26:08PM +0200, Stefan Bethke wrote: Am 14.08.2006 um 22:07 schrieb Darryl Yeoh: While destroying gif interface, I notice it also removes IPv4 default route. Has anyone else encountered this ? No problem on a FreeBSD 6.1-STABLE #8: Fri Jun 16 17:15:03 CEST 2006. ^^ You don't happen to have any devfs rules that would cause this? As a matter of fact, the issue appeared in 6-STABLE on Jul 24 and is still there. Now devd(8) will invoke /etc/pccard_ether stop when any network interface is destroyed. In turn, pccard_ether will flush all -inet routes if the rc.conf(5) variable removable_route_flush is set to YES, which is its default setting. Previously, this scenario would take place only when an Ethernet interface was destroyed. The question is: Do all the routes really need to be flushed upon the destruction of an interface? Any ideas? -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Default route (IPv4) demolished by destroying clone (gif/gre) interface
On Wed, Aug 16, 2006 at 09:54:19AM -0500, Brooks Davis wrote:
On Wed, Aug 16, 2006 at 10:23:13AM +0200, Stefan Bethke wrote:
Ouch. Don't ppp(8), OpenVPN etc. destroy the tun interface they're
using when they exit? Flushing all routes then would be rather
harmful. I'm glad I haven't updated to a newer -stable yet then :-)
In general, no since tun interfaces can not be destroyed.
Did you mean in particular? :-)
The problem can be triggered by destroying any interface that can
be destroyed. Just imagine getting rid of a defunct gif tunnel on
a remote router, or removing an unused vlan, and totally losing
connectivity to the router due to its default route having been
flushed. The scenario still can be quite unpleasant. I'd rather
change the default for $removable_route_flush to NO and let the
kernel choose which routes should be flushed upon the physical
ejection or software destruction of an interface. Note that this
doesn't include static_routes_${ifn}, which are handled separately
by pccard_ether_stop().
--
Yar
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Failing to understand getrusage()
On Tue, Mar 07, 2006 at 06:12:59PM +0200, Kostik Belousov wrote:
On Tue, Mar 07, 2006 at 06:06:31PM +0300, Yar Tikhiy wrote:
On Tue, Mar 07, 2006 at 12:11:56PM +0200, Kostik Belousov wrote:
On Tue, Mar 07, 2006 at 02:15:56AM +0300, Yar Tikhiy wrote:
Personally, I'd like to say a me too. /me too fails to see why
in a quiet, idle system ru_maxrss is very unpredictable over numerous
runs of the test program, both before and after the malloc+memset.
Filling the memory with a non-zero value doesn't matter. Is it the
Heizenberg daemon at work? :-)
I think that this is a statclock in work :). Just add some busy loops
before each calls to getrusage like
for (x = 0; x 0x100; x++)
getpid();
and you would get statisically stable results:
deviant% ./1mb
before: 424, after: 1548
deviant% ./1mb
before: 424, after: 1548
See,
% sysctl kern.clockrate
kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 }
133 Hz is very slow on 3GHz machine, and curproc-p_stats-p_ru is
updated on statclock tick, see sys/kern/kern_clock.c.
This sounds very clear and reasonable. I shouldn't have forgotten
about the driving role of statclock in collecting all rusage stats,
including those related to memory consumption.
It may be desirable to add ru_maxrss sampling at the calcru time too.
Something like this:
Index: sys/kern/kern_resource.c
===
RCS file: /usr/local/arch/ncvs/src/sys/kern/kern_resource.c,v
retrieving revision 1.156
diff -u -r1.156 kern_resource.c
--- sys/kern/kern_resource.c 22 Feb 2006 16:58:48 - 1.156
+++ sys/kern/kern_resource.c 7 Mar 2006 16:10:27 -
@@ -853,9 +853,16 @@
struct rusage *rup;
{
struct proc *p;
+ struct vmspace *vm;
+ long rss;
p = td-td_proc;
PROC_LOCK(p);
+ vm = p-p_vmspace;
+ rss = pgtok(vmspace_resident_count(vm));
+ if (rup-ru_maxrss rss)
+ rup-ru_maxrss = rss;
+
switch (who) {
case RUSAGE_SELF:
Please excuse me for a dumb question, but what makes ru_maxrss so
different from other ru_ fields that it deserves special handling
in kern_getrusage()? Perhaps the all-or-nothing approach will be
better for the sake of consistency...
--
Yar
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: www/en/releases/6.1R todo.sgml
On Mon, Mar 06, 2006 at 02:50:41PM -0800, Ade Lovett wrote: While we're at it, bin/94028 points out a fundamental problem with ifconfig(8) as it stands on 6.1-PRERELEASE, preventing MTUs from being set on vlan interfaces. I've taken the PR -- no reason to panic. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Failing to understand getrusage()
On Tue, Mar 07, 2006 at 12:11:56PM +0200, Kostik Belousov wrote:
On Tue, Mar 07, 2006 at 02:15:56AM +0300, Yar Tikhiy wrote:
Personally, I'd like to say a me too. /me too fails to see why
in a quiet, idle system ru_maxrss is very unpredictable over numerous
runs of the test program, both before and after the malloc+memset.
Filling the memory with a non-zero value doesn't matter. Is it the
Heizenberg daemon at work? :-)
I think that this is a statclock in work :). Just add some busy loops
before each calls to getrusage like
for (x = 0; x 0x100; x++)
getpid();
and you would get statisically stable results:
deviant% ./1mb
before: 424, after: 1548
deviant% ./1mb
before: 424, after: 1548
See,
% sysctl kern.clockrate
kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 }
133 Hz is very slow on 3GHz machine, and curproc-p_stats-p_ru is
updated on statclock tick, see sys/kern/kern_clock.c.
This sounds very clear and reasonable. I shouldn't have forgotten
about the driving role of statclock in collecting all rusage stats,
including those related to memory consumption.
Thank you for resolving our doubts! :-)
--
Yar
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: www/en/releases/6.1R todo.sgml
On Mon, Mar 06, 2006 at 02:50:41PM -0800, Ade Lovett wrote: While we're at it, bin/94028 points out a fundamental problem with ifconfig(8) as it stands on 6.1-PRERELEASE, preventing MTUs from being set on vlan interfaces. A patch has been sent to the audit trail of the PR. All interested folks, please test and review it. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Failing to understand getrusage()
On Thu, Mar 02, 2006 at 11:50:29PM +, Nick Barnes wrote:
At 2006-03-02 22:24:17+, Nik Clayton writes:
I'm failing to understand how getrusage() works, which is a bit perplexing,
because it doesn't seem like it would be terribly complicated.
ru_maxrss is the maximum resident set size, not the heap size.
malloc(big) doesn't grow the resident set. Touching the memory you
have allocated will grow the resident set. Try this:
getrusage(RUSAGE_SELF, ru);
printf(%lu\n, ru.ru_maxrss);
p = malloc(SIZE);
assert(p)
getrusage(RUSAGE_SELF, ru);
printf(%lu\n, ru.ru_maxrss);
for (i=0; iSIZE; ++i) {
p[i] = 0;
}
getrusage(RUSAGE_SELF, ru);
printf(%lu\n, ru.ru_maxrss);
Well, there was a call to memset() in the original Nik's program
while your code just does the same by itself.
Personally, I'd like to say a me too. /me too fails to see why
in a quiet, idle system ru_maxrss is very unpredictable over numerous
runs of the test program, both before and after the malloc+memset.
Filling the memory with a non-zero value doesn't matter. Is it the
Heizenberg daemon at work? :-)
--
Yar
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mount_smbfs trouble after cvsup
On Sun, Mar 05, 2006 at 08:01:31PM +, Gavin Atkinson wrote: On Fri, 24 Feb 2006, Yar Tikhiy wrote: On Wed, Feb 22, 2006 at 11:04:54AM +, Gavin Atkinson wrote: Is there a reason this change was made? And is there a reason why The change wasn't against NETSMBCRYPTO, it just corrected the way kernel modules get their options. NETSMBCRYPTO is not in GENERIC? To me, it seems that breaking smbfs between releases within 6.x violates POLA... I suspect a large number of people (myself included) have always used smbfs for passworded shares and it's just worked. This issue is under investigation by the Release Engineers and yours truly. I'm sorry my change to the kernel module framework caused the confusion, but so the whole issue has got attention at last. Of course, it must be fixed before 6.1-R. In the meanwhile, I'd like to hear about any reservations on making NETSMBCRYPTO the default case for netsmb/smbfs. Thanks! I don't see any problem with making it the default case, since before the framework cleanup, it effectively was default. Thank you for telling your opinion! I'm preparing the respective commit to HEAD right now, going to MFC it after a short period of testing by CURRENT users. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Remote Installworld
On Thu, Mar 02, 2006 at 01:28:34AM -0800, Nick Price wrote: I'm currently administering a machine about 1500mi from me with nobody local to the machine to assist me. Anyways, my only access to this machine is via SSH, no remote serial console or anything. When I try to do a make installworld I end up with install: rename: /lib/[EMAIL PROTECTED] to /lib/libcrypt.so.3: Operation not permitted very shortly thereafter. I cannot boot into single user mode because I am far, far away from the machine. What can I do to finish the installworld? It's probably because there schg flag set for this file. Try to # chflags noschg /lib/libcrypt.so if your securelevel allows it. Afterward try installworld one more time. The securelevel wouldn't allow me to change the flag. You'll have to reboot the machine in order to decrease its securelevel. This part is rather obvious: edit /etc/rc.conf, save, cross your fingers, reboot. In rc.conf, look for kern_securelevel_enable or kern_securelevel. Consult rc.conf(5) manpage for details. The question is whether that machine will succeed in booting to multi-user then, given that make installworld has already changed some system files. The libcrypt.so library gets installed rather early, so there's a good chance that your machine will book OK using old userland programs and libraries. Just make sure you haven't forgot to install the new kernel with make installkernel before the reboot. Assuming here that you haven't done a complete run of mergemaster(8): new files in /etc might confuse old programs. If still in doubt, try to reproduce the case locally on a test machine and see what happens. Apropos, clearing the schg flag on old system files is generally not needed before installworld because install(1) can deal with it if allowed to by the securelevel setting. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
On Wed, Mar 01, 2006 at 12:28:14AM +0900, Hajimu UMEMOTO wrote: Hi, On Mon, 27 Feb 2006 18:19:54 +0300 Yar Tikhiy [EMAIL PROTECTED] said: yar I finally spared some time to test your recent changes and found yar that the resolver still would retry using the first, and only the yar first, domain on the `search' list when the nameserver was down, yar which effectively led to another kind of request doubling. yar A similar effect was observed when a `domain' line was specified yar in resolv.conf in place of `search'. yar Is there a real reason to retry with a different domain when the yar nameserver doesn't respond at all? It seems yet another issue. The errors returned by res_querydomain() are not handled uniformity. Please try following patch: It works for me, thanks! -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
On Sat, Feb 25, 2006 at 04:28:50PM +0900, Hajimu UMEMOTO wrote:
On Sat, 25 Feb 2006 02:42:46 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
rosti I've found the problem in both: ftpd(8) and ftp(1). In the ftpd(8) a
rosti getaddrinfo() is called in two places with hints.ai_socktype == 0 and
rosti hints.ai_family == PF_UNSPEC. In the ftp(1) a command reply timeout is
rosti only 60 seconds. Those things are what I've changed to fix the problem.
rosti Two diffs are attached to this email. The ftpd.c.diff extends -4 and -6
rosti ftpd options. So if this patch is good, the ftpd(8) manual page and the
rosti default /etc/inetd.conf should also be changed appropriately.
For your ftpd.c.diff, I like your idea to reduce redundant query. It
is enough to query just appropriate address family. In inetd mode, we
know the address family already. So, we don't need to rely on the
-4/-6 option. The following diff is against ftpd.c with your patch
applied:
I finally tried the proposed patches for ftpd and really liked the
idea of reducing the name queries made to only one address family
if it's known. Thank you both!
I've got only one small remark on style, see below.
--- ftpd.c.rosti Sat Feb 25 15:41:52 2006
+++ ftpd.cSat Feb 25 16:01:46 2006
@@ -423,10 +423,6 @@ main(int argc, char *argv[], char **envp
}
}
-#ifdef VIRTUAL_HOSTING
- inithosts(family);
-#endif
-
if (daemon_mode) {
int *ctl_sock, fd, maxfd = -1, nfds, i;
fd_set defreadfds, readfds;
@@ -456,6 +452,10 @@ main(int argc, char *argv[], char **envp
sa.sa_handler = reapchild;
(void)sigaction(SIGCHLD, sa, NULL);
+#ifdef VIRTUAL_HOSTING
+ inithosts(family);
+#endif
+
/*
* Open a socket, bind it to the FTP port, and start
* listening.
@@ -525,6 +525,14 @@ main(int argc, char *argv[], char **envp
syslog(LOG_ERR, getpeername (%s): %m,argv[0]);
exit(1);
}
+
+#ifdef VIRTUAL_HOSTING
+ family = his_addr.su_family;
+ if (his_addr.su_family == AF_INET6
+ IN6_IS_ADDR_V4MAPPED(his_addr.su_sin6.sin6_addr))
+ family = AF_INET;
Perheps a better style here would be to use if/else:
if (his_addr.su_family == AF_INET6
IN6_IS_ADDR_V4MAPPED(his_addr.su_sin6.sin6_addr))
family = AF_INET;
else
family = his_addr.su_family;
+ inithosts(family);
+#endif
}
gotchild:
--
Yar
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
On Sat, Feb 25, 2006 at 02:08:21AM +0900, Hajimu UMEMOTO wrote:
On Fri, 24 Feb 2006 15:51:53 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
rosti Excellent! What about RES_DFLRETRY decreasing from 4 to 2? Does it need
rosti more testing or discussion?
It seems reasonable to me, and there are no objection here. So, I've
just committed both into HEAD.
I finally spared some time to test your recent changes and found
that the resolver still would retry using the first, and only the
first, domain on the `search' list when the nameserver was down,
which effectively led to another kind of request doubling.
A similar effect was observed when a `domain' line was specified
in resolv.conf in place of `search'.
Is there a real reason to retry with a different domain when the
nameserver doesn't respond at all?
--
Yar
P.S. Here's the details of what I'm talking about:
Commands:
vpc7# hostname
vpc7
vpc7# cat /etc/resolv.conf
search aaa.ru bbb.ru
nameserver 195.208.208.25
vpc7# ./gethost foo
foo: Host name lookup failure
vpc7# ./gethost foo.zzz.ru
foo.zzz.ru: Host name lookup failure
tcpdump:
=== for ./gethost foo ===
18:01:51.756764 IP 10.1.1.27.51030 195.208.208.25.53: 5443+ A? foo.aaa.ru.
(33)
18:01:56.971187 IP 10.1.1.27.57913 195.208.208.25.53: 5443+ A? foo.aaa.ru.
(33)
18:02:07.071088 IP 10.1.1.27.55508 195.208.208.25.53: 5444+ A? foo. (21)
18:02:12.210384 IP 10.1.1.27.62824 195.208.208.25.53: 5444+ A? foo. (21)
=== for ./gethost foo.zzz.ru ===
18:02:33.509361 IP 10.1.1.27.65031 195.208.208.25.53: 19867+ A?
foo.zzz.ru. (32)
18:02:38.567045 IP 10.1.1.27.55358 195.208.208.25.53: 19867+ A?
foo.zzz.ru. (32)
18:02:48.824136 IP 10.1.1.27.61855 195.208.208.25.53: 19868+ A?
foo.zzz.ru.aaa.ru. (44)
18:02:53.922071 IP 10.1.1.27.49351 195.208.208.25.53: 19868+ A?
foo.zzz.ru.aaa.ru. (44)
Here's ./gethost src. It essentially calls a single gethostbyname()
if given a host name or gethostbyaddr() if given an IP address.
=== gethost.c ===
#include sys/types.h
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
#include netdb.h
#include stdio.h
int
main(int argc, char **argv)
{
struct in_addr ia;
struct hostent *hp;
char *name;
char **st;
if (argc 2)
return (2);
name = argv[1];
if (inet_aton(name, ia))
hp = gethostbyaddr((char *)ia, sizeof(ia), AF_INET);
else
hp = gethostbyname(name);
if (hp == NULL) {
herror(name);
return (1);
}
printf(%s\n, hp-h_name);
for (st = hp-h_addr_list; *st; st++)
printf(%s\n, inet_ntoa(*(struct in_addr *)*st));
if (st == hp-h_addr_list)
printf(no address records\n);
return (0);
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
On Sat, Feb 25, 2006 at 02:42:46AM +0200, Rostislav Krasny wrote:
On Fri, 24 Feb 2006 20:40:07 +0300
Yar Tikhiy [EMAIL PROTECTED] wrote:
To Rostislav: Could you do now, with the resolver fixes applied,
the following experiment: find how many dead nameservers in resolv.conf
it takes for sshd to start timing out a connection to it? There
is still your PR open on this issue, so we should see whether
the default for LoginGraceTime needs a change, too. Thanks!
The maximum number of name servers those the resolver will work with is
MAXNS, which currently is 3. With three unreachable name servers in
resolv.conf I successfully connected from other, not patched, FreeBSD
6.1-PRERELEASE by ssh without touching LoginGraceTime. I've got the
password prompt after about 48.5 seconds, according to a stop watch in
my cell phone :-)
I also tested telnet connection and it worked properly in that
situation.
Sounds good! Thanks!
However I was unable to connect by ftp, even with only one unreachable
name server in resolv.conf. I got following error:
421 Service not available, remote server timed out. Connection closed
I've found the problem in both: ftpd(8) and ftp(1). In the ftpd(8) a
getaddrinfo() is called in two places with hints.ai_socktype == 0 and
hints.ai_family == PF_UNSPEC. In the ftp(1) a command reply timeout is
only 60 seconds. Those things are what I've changed to fix the problem.
Two diffs are attached to this email. The ftpd.c.diff extends -4 and -6
ftpd options. So if this patch is good, the ftpd(8) manual page and the
default /etc/inetd.conf should also be changed appropriately.
Could you explain please how your patch would affect ftpd(8) semantics
visible to the user?
Although I changed two getaddrinfo() calls in ftpd.c, only first of
them is really called on default FreeBSD configuration,
when /etc/ftphosts isn't existing yet. So there might be a need of
additional increase of the command reply timeout in ftp.c. Or better if
this timeout could be configurable by some new ftp(1) option, with 120
seconds by default.
--- libexec/ftpd/ftpd.c.orig Wed Feb 8 18:54:05 2006
+++ libexec/ftpd/ftpd.c Sat Feb 25 00:30:26 2006
@@ -239,7 +239,7 @@
}
#ifdef VIRTUAL_HOSTING
-static void inithosts(void);
+static void inithosts(int);
static void selecthost(union sockunion *);
#endif
static void ack(char *);
@@ -424,7 +424,7 @@
}
#ifdef VIRTUAL_HOSTING
- inithosts();
+ inithosts(family);
#endif
if (daemon_mode) {
@@ -663,7 +663,7 @@
*/
static void
-inithosts(void)
+inithosts(int family)
{
int insert;
size_t len;
@@ -689,7 +689,8 @@
memset(hints, 0, sizeof(hints));
hints.ai_flags = AI_CANONNAME;
- hints.ai_family = AF_UNSPEC;
+ hints.ai_family = family;
+ hints.ai_socktype = SOCK_STREAM;
if (getaddrinfo(hrp-hostname, NULL, hints, res) == 0)
hrp-hostinfo = res;
hrp-statfile = _PATH_FTPDSTATFILE;
@@ -759,9 +760,10 @@
/* NOTREACHED */
}
- hints.ai_flags = 0;
- hints.ai_family = AF_UNSPEC;
+ /* If no flag, assign hints.ai_flags to zero! */
Sorry, but I don't understand the purpose of this comment here.
hints.ai_flags = AI_PASSIVE;
+ hints.ai_family = family;
+ hints.ai_socktype = SOCK_STREAM;
if (getaddrinfo(vhost, NULL, hints, res) != 0)
goto nextline;
for (ai = res; ai != NULL ai-ai_addr != NULL;
--
Yar
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
On Sat, Feb 25, 2006 at 02:08:21AM +0900, Hajimu UMEMOTO wrote: On Fri, 24 Feb 2006 15:51:53 +0200 Rostislav Krasny [EMAIL PROTECTED] said: rosti Excellent! What about RES_DFLRETRY decreasing from 4 to 2? Does it need rosti more testing or discussion? It seems reasonable to me, and there are no objection here. So, I've just committed both into HEAD. IMHO the only principal reservation about changing RES_DFLRETRY was that its effect was unobvious due to the bug you've just fixed. Now all should be OK. Thank you a lot! To Rostislav: Could you do now, with the resolver fixes applied, the following experiment: find how many dead nameservers in resolv.conf it takes for sshd to start timing out a connection to it? There is still your PR open on this issue, so we should see whether the default for LoginGraceTime needs a change, too. Thanks! -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mount_smbfs trouble after cvsup
On Wed, Feb 22, 2006 at 11:04:54AM +, Gavin Atkinson wrote: On Tue, 2006-02-21 at 19:29 +0800, Tai-hwa Liang wrote: On Tue, 21 Feb 2006, Bachilo Dmitry wrote: I've cvsuped from 6.0 to 6.1-PRERELEASE and now I can't mount NT's shares with password. It worked fine before, but after cvsup i get mount_smbfs: unable to open connection: syserr = Authentication error and in /var/log/messages I get Feb 21 14:51:24 notebook kernel: netsmb_dev: loaded Feb 21 14:51:27 notebook kernel: smb_encrypt: password encryption is not available Feb 21 14:51:27 notebook kernel: smb_ntencrypt: password encryption is not available As far as I see, there is no option in mount_smbfs to disable password options NETSMBCRYPTO in kernel configuartion file. encryption, so I'm just stuck, what should I do? Thanks in advance. http://lists.freebsd.org/pipermail/freebsd-current/2006-January/059823.html Is there a reason this change was made? And is there a reason why The change wasn't against NETSMBCRYPTO, it just corrected the way kernel modules get their options. NETSMBCRYPTO is not in GENERIC? To me, it seems that breaking smbfs between releases within 6.x violates POLA... I suspect a large number of people (myself included) have always used smbfs for passworded shares and it's just worked. This issue is under investigation by the Release Engineers and yours truly. I'm sorry my change to the kernel module framework caused the confusion, but so the whole issue has got attention at last. Of course, it must be fixed before 6.1-R. In the meanwhile, I'd like to hear about any reservations on making NETSMBCRYPTO the default case for netsmb/smbfs. Thanks! -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
On Sun, Feb 19, 2006 at 10:57:01PM +0200, Rostislav Krasny wrote: On Sun, 19 Feb 2006 13:49:12 +0300 Yar Tikhiy [EMAIL PROTECTED] wrote: On Sat, Feb 18, 2006 at 01:20:29AM +0200, Rostislav Krasny wrote: On Thu, 16 Feb 2006 08:35:18 +0100 [EMAIL PROTECTED] (Dag-Erling Sm??rgrav) wrote: David Malone [EMAIL PROTECTED] writes: I did once mail des@ to ask him if he'd mind me changing the default login timeout for sshd to be (say) 5 minutes rather than 1 minute, but I think he was busy at the time. Judging by the PR mentioned above it should be at least 2m30s by default. Des, would you mind this change being made? No objection, just let me see the patch first. In conjunction to what David had proposed, what do you think about decreasing the RES_DFLRETRY from 4 to 2, like in other systems and in BIND9's resolver? Could you try this change in your system and report the exact results, such as output from tcpdump? That is how we could judge the change in question... Or were the results reported already? Ok, I rebuilded the world and the kernel with this change and tested it with tcpdump and a small program from the bin/62139 PR. During the test I saw two A? yahoo.com. requests, then two A? yahoo.com.lan. requests and that all taked only 30 seconds for gethostbyname() to give up with one unreachable DNS. Now it looks better than before. But I think there is still a bug. If I change hostname from saturn.lan to just saturn I see 4 A? yahoo.com. requests, like in the PR with options attemts:2. Why it tries to repeat the requests when the domain name is empty and so is the search list by default? That is the doubling I had wrote about in the PR. The doubling happens only to name-IP lookups, but not to reverse lookups, according to my observations. Therefore DNS requests by sshd and friends shouldn't be affected. However, sshd will make 3 (!) lookups on the client IP address by itself. I wonder if there is a good reason for that. I also found that the second round of the doubling would use the first domain from `search' line if it is in resolv.conf. The rest of domains specified on `search' line are ignored. Hoping this observation will come useful, should somebody want to fix this bug. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6 weird '..' permission troubles
On Sun, Feb 19, 2006 at 01:27:48PM +0100, Nicolas Rachinsky wrote: * Yar Tikhiy [EMAIL PROTECTED] [2006-02-19 13:58 +0300]: This looks like a file-a-PR case if you are sure you didn't overlook anything. To the best of my knowledge, the underlying mount point permissions should affect nothing since the FS was mounted. But you didn't show us output from ls -la / so please judge by yourself. This behaviour is known and documented. http://www.freebsd.org/cgi/man.cgi?query=mountapropos=0sektion=0manpath=FreeBSD+6.0-RELEASE+and+Portsformat=html After a successful mount, the permissions on the original mount point determine if .. is accessible from the mounted file system. The minimum permissions for the mount point for traversal across the mount point in both directions to be possible for all users is 0111 (execute for all). Thanks for pointing us out at this. To my shame, I read about the caveat some years ago, but then forgot about it completely because had never run into it in my practice. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
On Sat, Feb 18, 2006 at 01:20:29AM +0200, Rostislav Krasny wrote: On Thu, 16 Feb 2006 08:35:18 +0100 [EMAIL PROTECTED] (Dag-Erling Sm??rgrav) wrote: David Malone [EMAIL PROTECTED] writes: I did once mail des@ to ask him if he'd mind me changing the default login timeout for sshd to be (say) 5 minutes rather than 1 minute, but I think he was busy at the time. Judging by the PR mentioned above it should be at least 2m30s by default. Des, would you mind this change being made? No objection, just let me see the patch first. In conjunction to what David had proposed, what do you think about decreasing the RES_DFLRETRY from 4 to 2, like in other systems and in BIND9's resolver? Could you try this change in your system and report the exact results, such as output from tcpdump? That is how we could judge the change in question... Or were the results reported already? -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6 weird '..' permission troubles
On Thu, Feb 16, 2006 at 04:57:57PM +0300, Dmitry Morozovsky wrote: On Thu, 16 Feb 2006, James Wyatt wrote: JW I've seen something very similar when the permissions of the mount point's JW underlieing subdirectory wasn't 777. Really strange to see, but it was a JW fallout from a company-wide change to make umask and directory permissions JW that wasn't quite implemented correctly. Hope this helps - Jy@ Exactly, see my other followup. I suppose 0777 is bad choice because if for some reason file system would not mount, anyone can fill up this directory. 0111 or 0555 or standard 0755 would be safe though. This looks like a file-a-PR case if you are sure you didn't overlook anything. To the best of my knowledge, the underlying mount point permissions should affect nothing since the FS was mounted. But you didn't show us output from ls -la / so please judge by yourself. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPv6 and IPFW
On Sun, Feb 19, 2006 at 04:38:21PM +0900, Hajimu UMEMOTO wrote: Hi, On Sat, 18 Feb 2006 17:34:35 -0800 Peter Losher [EMAIL PROTECTED] said: plosher [1 text/plain; ISO-8859-1 (quoted-printable)] plosher Hajimu UMEMOTO wrote: The ipfw in 6-STABLE has an IPv6 awareness, but it is not enabled as far as you use ipfw as a KLD module. If ipfw is compiled into kernel, ipfw does filterling an IPv6 as well. plosher Will this change in 6.1, or will we have to wait for ip6fw to be plosher completly removed before the module will support v6 by default? (You plosher would have to admit that it's somewhat confusing the way it is now) It was already MFC'ed into RELENG_6. So, ipfw.ko obeys the kernel config, now. Please note here that ipfw.ko obeys INET6 and IPSEC options, but not IPFIREWALL_* ones yet. The latter still are to be fixed for the module build. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: smb_ntencrypt: password encryption is not available #2
On Sat, Feb 18, 2006 at 09:51:24AM +0100, Per olof Ljungmark wrote: Per olof Ljungmark wrote: Well, options NETSMBCRYPTO options NETSMB did not work out very well: Do I need anything else here? smb_usr.o(.text+0x4ad):/usr/src/sys/netsmb/smb_usr.c:274: undefined reference to `md_get_mem' smb_usr.o(.text+0x4fe): In function `smb_cpdatain': /usr/src/sys/netsmb/smb_usr.c:291: undefined reference to `mb_init' smb_usr.o(.text+0x513):/usr/src/sys/netsmb/smb_usr.c:294: undefined reference to `mb_put_mem' smb_usr.o(.text+0x63a): In function `smb_usr_t2request': /usr/src/sys/netsmb/smb_usr.c:340: undefined reference to `md_get_mem' smb_usr.o(.text+0x689):/usr/src/sys/netsmb/smb_usr.c:353: undefined reference to `md_get_mem' *** Error code 1 Stop in /usr/obj/usr/src/sys/IKO. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ___ apparently the answer was to use options NETSMBCRYPTO only. I'm glad you figured that out by yourself. I should have posted a heads-up on this change to -stable earlier, sorry. P.S. options NETSMB will tell to compile NETSMB in the main kernel file, which requires additional options, LIBMCHAIN and LIBICONV. OTOH, they are auto-loaded as modules when smbfs is a module, too. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP: build-time options for kernel modules
Hi all, As some folks have already noticed, a change affecting modules' build-time options was merged to RELENG_6. Namely, almost all modules now get their options from the main kernel conf file. The only exceptions I'm aware of are pf.ko and ipfw.ko -- the latter gets INET6 and IPSEC stuff, but not IPFIREWALL_* stuff. The consequence is that now you may get a different set of options in the modules you build and use with the kernel. If you still stick to MODULES_WITH_WORLD, your modules will be the same, but using MODULES_WITH_WORLD is strongly discouraged today as it can lead to a fatally broken kernel-module interface. Here's the full list of options you may want to pay attention to: device atm options ALT_BREAK_TO_DEBUGGER options CODA_COMPAT_5 options ETHER_8022 options ETHER_8023 options ETHER_II options ETHER_SNAP options HIFN_DEBUG options IPX options KDB options NATM options NETATALK options NETGRAPH options NETSMBCRYPTO options PPP_BSDCOMP options PPP_DEFLATE options PPP_FILTER options SAFE_DEBUG options SCSI_DELAY=15000 options TDFX_LINUX options UBSEC_DEBUG options WI_SYMBOL_FIRMWARE If you run the GENERIC kernel, don't need the *DEBUG stuff, and the exact value of SCSI_DELAY doesn't matter to you, then the list boils down to: # if_ef options ETHER_8022 options ETHER_8023 options ETHER_II options ETHER_SNAP # smbfs options NETSMBCRYPTO # 3dfx options TDFX_LINUX Measures are being taken to make the binary modules to be shipped in 6.1-RELEASE compatible with existing installations. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6 weird '..' permission troubles
On Sun, Feb 19, 2006 at 04:01:53PM +0300, Dmitry Morozovsky wrote: On Sun, 19 Feb 2006, Yar Tikhiy wrote: YT On Thu, Feb 16, 2006 at 04:57:57PM +0300, Dmitry Morozovsky wrote: YT On Thu, 16 Feb 2006, James Wyatt wrote: YT YT JW I've seen something very similar when the permissions of the mount point's YT JW underlieing subdirectory wasn't 777. Really strange to see, but it was a YT JW fallout from a company-wide change to make umask and directory permissions YT JW that wasn't quite implemented correctly. Hope this helps - Jy@ YT YT Exactly, see my other followup. YT YT I suppose 0777 is bad choice because if for some reason file system would not YT mount, anyone can fill up this directory. 0111 or 0555 or standard 0755 would YT be safe though. YT YT This looks like a file-a-PR case if you are sure you didn't overlook YT anything. To the best of my knowledge, the underlying mount point YT permissions should affect nothing since the FS was mounted. But YT you didn't show us output from ls -la / so please judge by yourself. I can't show you exact output of ls -la / before other FS mount because of headlessness (nor serial console) of machine in question. However, there was one file system which I could unmount without dropping to single user, and I *did* see underlying directory mode of 0750. I just wanted to make sure that your / (which was /usr/..) was readable for the unpriviliged user. Your test case below shows that the problem is there indeed. What should I file? Test case? It's rather simple (attached). Please include everything needed for a PR: a synopsis, description, how-to-repeat, and perhaps a fix ;-) Script started on Sun Feb 19 15:59:12 2006 [EMAIL PROTECTED]:/var/tmp# unalias ls [EMAIL PROTECTED]:/var/tmp# cd /var/tmp [EMAIL PROTECTED]:/var/tmp# dd if=/dev/zero of=image1.img bs=1m count=4 4+0 records in 4+0 records out 4194304 bytes transferred in 0.057493 secs (72953335 bytes/sec) [EMAIL PROTECTED]:/var/tmp# mdconfig -a -t vnode -f image1.img md1 [EMAIL PROTECTED]:/var/tmp# newfs /dev/md1 /dev/md1: 4.0MB (8192 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 1.02MB, 65 blks, 192 inodes. super-block backups (for fsck -b #) at: 160, 2240, 4320, 6400 [EMAIL PROTECTED]:/var/tmp# mkdir -m 700 mnt [EMAIL PROTECTED]:/var/tmp# ls -la mnt total 4 drwx-- 2 root wheel 512 Feb 19 16:00 . drwxrwxrwt 8 root wheel 512 Feb 19 16:00 .. [EMAIL PROTECTED]:/var/tmp# mount /dev/md1 mnt [EMAIL PROTECTED]:/var/tmp# ls -la mnt total 6 drwxr-xr-x 3 root wheel 512 Feb 19 16:00 . drwxrwxrwt 8 root wheel 512 Feb 19 16:00 .. drwxrwxr-x 2 root operator 512 Feb 19 16:00 .snap [EMAIL PROTECTED]:/var/tmp# echo '/bin/sh -c ls -la /var/tmp' | su -m nobody total 54560 drwxrwxrwt 8 root wheel 512 Feb 19 16:00 . drwxr-xr-x 26 root wheel 512 Feb 16 12:59 .. drwxrwxr-x 2 marck wheel 512 Feb 7 16:21 cd drwx-- 3 marck wheel 512 Feb 14 16:20 gconfd-marck -rw-r--r-- 1 root wheel 4194304 Feb 19 16:00 image1.img -rw-r--r-- 1 root wheel 51579766 Jan 31 18:50 jdk-1.5.0p2_3.tbz drwxr-xr-x 3 root wheel 512 Feb 19 16:00 mnt drwx-- 2 marck wheel 512 Feb 14 22:17 orbit-marck drwxrwxrwt 5 root wheel 512 Jan 26 14:17 texfonts drwxrwxrwt 2 root wheel 512 Jan 31 16:17 vi.recover [EMAIL PROTECTED]:/var/tmp# echo '/bin/sh -c ls -la /var/tmp/mnt/' | su -m nobody ls: ..: Permission denied total 4 drwxr-xr-x 3 root wheel 512 Feb 19 16:00 . drwxrwxr-x 2 root operator 512 Feb 19 16:00 .snap [EMAIL PROTECTED]:/var/tmp# exit exit Script done on Sun Feb 19 16:00:47 2006 -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions about building releng_6
On Sun, Feb 12, 2006 at 01:29:10AM -0600, Z.C.B. wrote: I was just looking at building releng_6 on a releng_5 box. What I am wondering about is how to specify a location other than /usr/obj and Just set the MAKEOBJDIRPREFIX variable in the environment to the desired path, and the build system will use it instead of /usr/obj. Keep in mind that you cannot set it on the make command line or in make.conf, it must be set in the environment. Also note that you still can use /usr/obj if the RELENG_5 and RELENG_6 sources are at different locations, like /usr/src and /usr/src-6, because the binaries will be built in /usr/obj/usr/src and /usr/obj/usr/src-6, respectively. once I get it built, how do I do a install to a different path. Just set DESTDIR (can be either an environment or make variable) to the destination path. The 6.0 release has a bit of a problem booting on the board I have and was just looking at trying out releng_6 and seeing how it would go. Note here that in order to get a new functional 6.x system while keeping your 5.x system, you'll have to install 6.x to a free slice or disk labelled, newfs'd, and mounted, e.g., under /mnt. Unlike with some other operating systems, you cannot easily have several working FreeBSD installations in the same file tree: each FreeBSD installation needs a tree of its own: /, /boot, /etc, /bin, /usr, and all that. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Restartable system call behaviour
On Wed, Feb 01, 2006 at 08:48:30PM +, Pete French wrote: I have a piece of coode which does some networking, in which I see read and write calls failing with 'Interrupted system call' from time to time. You will get EINTR if the interrupt occurs before any data is read or written. Will it also happen with recv() with MSG_WAITALL flag set? Actually I have narrowed this down now, and I wwas wrong in the original posting - I was getting the EINTR returned by connect. Now I am not sure if this is correct behaviour or not - if a signal has SA_RESTART set then it should restart, but connect returns EINTR and then continues to connect in the background. I had alwways belived that if system calls are restrtable then you will never see EINTR at all. Now I dont know if this is a problem with my understanding of how the system works, or an actual bug. have filed a pr anyway, just in case it *is* a bug. To the best of my knowledge, connect() being always interruptable is correct and well-known. And my 4.11-STABLE system will interrupt connect() on a signal with SA_RESTART set, which disagrees with your observations yet agrees with the standard. Perhaps some logic in your software has changed since 4.11 times. Your software can poll, select, or just loop over connect() until errno != EALREADY if connect() returned EINTR. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem with vlan interfaces in 6-STABLE
On Tue, Jan 24, 2006 at 02:01:47AM +0300, Yar Tikhiy wrote: On Mon, Jan 23, 2006 at 01:28:00PM +0100, Oliver Brandmueller wrote: After my latest update to FreeBSD hudson 6.0-STABLE FreeBSD 6.0-STABLE #15: Mon Jan 23 12:29:38 CET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NFS-32-FBSD6 i386 I have a small problem with my vlan interfaces configured from rc.conf: They get configured well, but they are simply not in up state as they were before autmatically. I can login via console and do ifconfig vlan340 up and all is fine. The config did not change during the update: cloned_interfaces=vlan340 ifconfig_em0=up vlanhwtag vlanmtu ifconfig_vlan340=inet xx.xx.xx.xx netmask 255.255.255.192 vlan 340 vlandev em0 The problem you're experiencing may be related to changes I committed to ifconfig in RELENG_6. I'll investigate the issue ASAP and report my results in this list. In short, I've just backed out my commit to ifconfig in RELENG_6, which should return ifconfig to the good old behaviour. The long story enchased with tech details is as follows. Historically our ifconfig used to set vlan parameters (vlan vlandev) before IP ones when both kinds of them were specified on the same command line. (This is the case when vlanX is configured using rc.conf.) My change to ifconfig reversed the order (I had overlooked that,) which triggered a couple of kernel bugs. The old version of the if_vlan driver used to just overwrite a vlan interface's flags upon attaching it to its parent, some bits with those from the parent, the others just with 0. Consequently, the UP flag initially set by the IP layer was just reset to 0 by the code. It was the problem reported here. Then glebius@ merged if_vlan from CURRENT to RELENG_6, which remedied the UP loss problem, because now if_vlan was getting a subset of flags from its parent while keeping the others, UP among them. However, another problem has been noticed and tracked down. Namely, the subset of copied flags includes IFF_BROADCAST and IFF_MULTICAST, which means that the IP layer handles a fresh vlan interface differently depending on whether the parent is attached to it. Just assign IP to vlanX first, attach the parent then, and see a bogus or missing broadcast address on the vlanX in a wide range of FreeBSD versions. Today oleg@ and /me investigated the issue and worked out several approaches to it. I'm going to discuss them on net@ and choose an optimal one. The ifconfig utility will stick to its old semantics until then. Sorry for all the inconvenience involved. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem with vlan interfaces in 6-STABLE
On Mon, Jan 23, 2006 at 01:28:00PM +0100, Oliver Brandmueller wrote: Hi everybody, After my latest update to FreeBSD hudson 6.0-STABLE FreeBSD 6.0-STABLE #15: Mon Jan 23 12:29:38 CET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NFS-32-FBSD6 i386 I have a small problem with my vlan interfaces configured from rc.conf: They get configured well, but they are simply not in up state as they were before autmatically. I can login via console and do ifconfig vlan340 up and all is fine. The config did not change during the update: cloned_interfaces=vlan340 ifconfig_em0=up vlanhwtag vlanmtu ifconfig_vlan340=inet xx.xx.xx.xx netmask 255.255.255.192 vlan 340 vlandev em0 The problem you're experiencing may be related to changes I committed to ifconfig in RELENG_6. I'll investigate the issue ASAP and report my results in this list. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Build failure in procfs module
On Tue, Aug 16, 2005 at 01:29:45AM +0400, Boris Samorodov wrote: On Thu, 11 Aug 2005 19:34:09 +0400 Yar Tikhiy wrote: On Thu, Aug 04, 2005 at 12:28:35PM +0400, Boris Samorodov wrote: On Mon, 18 Jul 2005 19:19:24 +0400 Yar Tikhiy wrote: On Thu, Jul 14, 2005 at 02:15:07PM +0400, Yar Tikhiy wrote: I ran into a problem that might be triggered by Peter's recent changes to procfs. Namely, the buildworld procedure would fail in the procfs module if MODULES_WITH_WORLD were set. I noticed it first in CURRENT and then tested it in a clean environment by building a freshly CVSup'd RELENG_6 on a freshly installed 5.4-RELEASE, with MODULES_WITH_WORLD set. I think it's a route of upgrading quite a few people will follow. Here's the diagnostics: [snip] The problem appears to have to do with Peter's changes to procfs: The procfs source files now include opt_compat.h, which is not available by default when building with MODULES_WITH_WORLD set. The attached patch seems to fix the problem in the conventional way. However, I'm unsure which COMPAT_* options are really needed to the procfs module. COMPAT_43 should be enough according to my quick examining /sys/fs/procfs. Was the case corrected in BETA2? A couple of days ago I upgraded from CURRENT (middle of June 2005) to BETA1. The problem existed but the patch helped. Alas, no one has displayed interest in fixing this bug since I left for vacation. I committed the fix to CURRENT today although I don't use procfs, which is a kind of a situation I hate. MFC to RELENG_6 is due in 3 days. Could you (or somebody else) MFC the patch to RELENG_6? RELENG_6 is frozen now, so I must receive RE's approval before merging my change to the branch. Discussion with re@ and some expert developers is under way. Applying for the approval has appeared the best way to draw attention to the issue :-) -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALTQ, pf and VLANs
On Thu, Mar 31, 2005 at 04:45:52PM +0100, Max Laier wrote: On Thursday 31 March 2005 04:38, Marko ??uk wrote: Max, that solution works fine. I have tried it and it works fine for me. Thanks. Anyway, do you know some issues with dropping traffic on em0 vlan enabled interfaces and tcpdump-ing ? The average traffic, that we tcpdump is cca 10-20mbit/s and when tcpdump-ing, we get allmost 90% packet loss on interfaces. Any clue ? Ugh, I know of such an issue, but was thinking that it should be fixed by now. Can you make sure that you have your kernel/em(4) built with if_em.c 1.44.2.6 or later? The effect should simply be that it disables VLAN hardware support which doesn't seem to work with promiscuous mode. You could also try to disable it manually (ifconfig) to see if that improves on the packet loss. Max, I'm not sure it's using VLAN acceleration in em(4) that causes _partial_ packet loss. The case you referred to manifested itself in full traffic halt on attached vlan(4) interfaces and not in its partial loss. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel Panic on 4.3-RC #0 using PPPoE
Hi,
On Tue, Mar 27, 2001 at 12:40:11PM -0800, Archie Cobbs wrote:
Mike Tancsa writes:
Not sure why this hasn't been detected before though. Below is
a possible patch.
It has been at http://www.freebsd.org/cgi/query-pr.cgi?pr=25478 and
discussed a few times in freebsd-net.
Here is the better (?) patch. I'd like to commit this if nobody
objects..
Please take a careful look at the frames 6 through 9 of the stack
trace in PR#25478, so you may notice that your patch happens to do
nothing about the broblem. You are going to add a check for IFF_UP
to ether_output_frame() while that function is just a bottom half
of ether_output(), which does do the check at its very beginning.
The real problem is that ethernet card drivers rely on ether_output()
making sure they are up before calling their if_output()s. AFAIK
the vlan driver is the only piece of code where the standard
ether_output()-if_output() order is bypassed, and an if_output()
routine of an ethernet card is called directly. Therefore, the
IFF_UP check should be in the vlan code, and I'm going to commit
a corresponding fix (PR: kern/22179). Any objections?
Luigi: would you mind reviewing this for possible BRIDGE problems?
-Archie
__
Archie Cobbs * Packet Design * http://www.packetdesign.com
Index: if_ethersubr.c
===
RCS file: /home/ncvs/src/sys/net/if_ethersubr.c,v
retrieving revision 1.70.2.15
diff -u -r1.70.2.15 if_ethersubr.c
--- if_ethersubr.c2001/03/13 22:00:32 1.70.2.15
+++ if_ethersubr.c2001/03/27 20:39:38
@@ -366,6 +366,11 @@
{
int s, error = 0;
+ if ((ifp-if_flags (IFF_UP|IFF_RUNNING)) != (IFF_UP|IFF_RUNNING)) {
+ m_freem(m);
+ return (ENETDOWN);
+ }
+
#ifdef BRIDGE
if (do_bridge BDG_USED(ifp) ) {
struct ether_header *eh; /* a ptr suffices */
SY, Yar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: Kernel Panic on 4.3-RC #0 using PPPoE
On Wed, Mar 28, 2001 at 11:30:49AM +0400, Yar Tikhiy wrote: Please take a careful look at the frames 6 through 9 of the stack trace in PR#25478, so you may notice that your patch happens to do nothing about the broblem. You are going to add a check for IFF_UP to ether_output_frame() while that function is just a bottom half of ether_output(), which does do the check at its very beginning. Just a clarifying note: Please keep in mind that ether_output() (frame 9) through vlan_start() (frame 7) are called on a vlan interface while fxp_start() (frame 6) is called on a different interface - fxp. The real problem is that ethernet card drivers rely on ether_output() making sure they are up before calling their if_output()s. AFAIK the vlan driver is the only piece of code where the standard ether_output()-if_output() order is bypassed, and an if_output() routine of an ethernet card is called directly. Therefore, the IFF_UP check should be in the vlan code, and I'm going to commit a corresponding fix (PR: kern/22179). Any objections? Please substitute "if_output" with "if_start" when reading the above paragraph. Sorry :-) SY, Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
