Re: Deprecating base system ftpd?
>> I propose deprecating the ftpd currently included in the base system >> before FreeBSD 14, and opened review D26447 >> (https://reviews.freebsd.org/D26447) to add a notice to the man page. >> I had originally planned to try to do this before 13.0, but it dropped >> off my list. FTP is not nearly as relevant now as it once was, and it >> had a security vulnerability that secteam had to address. > > I think this is an excellent start. My shopping list includes: > > - remove ftp(1) > - remove ftpd(8) > - remove telnet(1) > - remove telnetd(8) My preference would be to leave those four in the system. However, I can live with removal, as long as they are available as ports. > - remove ftp:// and http:// from libfetch. This is 2021 and we should all > use https://. Please don't. There is still a lot of content not available over https (and quite a few web sites with only "readonly" type content). Removal of ftp:// and http:// from libfetch simply means I'll have to install wget instead - and we're getting ever close to FreeBSD being only a kernel. > - replace DNS lookups with DoH and/or DoT. Why let your ISP see your DNS > traffic? Because I trust my (European) ISP significantly more than I trust big US companies? Yes, I have a pretty good idea what Cloudflare, Google etc have said about the queries they receive. I still don't see a reason to trust them, given their actions in other areas. Bert Hubert has written much better then I can about moving everything to DoH/DoT: https://blog.powerdns.com/2019/09/25/centralised-doh-is-bad-for-privacy-in-2019-and-beyond/ Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
BIND 9.16.1/9.16.2 memory leak?
>From https://lists.isc.org/pipermail/bind-users/2020-April/102998.html > We have what appears to be a significant memory leak in BIND-9.16.1. > > Environment: > FreeBSD 12.1-STABLE. > BIND-9.16.1 installed from packages. > Also uses libuv-1.35.0 installed from packages. > Authoritative only. > Around 800 zones of varying sizes. DNSSEC in use. > > Running a ps command for the named process every minute and logging > the result, I see the named virtual memory size (VSZ) increasing at > around 1.2 Mbyte/minute, and the resident size (RSS) increasing at > around 0.85 Mbyte/minute. No problems due to this so far, but pretty > obviously it's not viable in the long run. > > I tried reading the CHANGES from 9.16.2, and didn't see anything which > suggested a fix for a memory leak problem. I now have a pcap file of queries that I can replay with the "drool" application, and I'm consistently seeing similar memory leak problems (i.e. the problems are reproducible). The memory leak rate seems to be very approximately linear with the query rate - so replaying at 10 times the original speed means we also leak around 10 times as much per minute. Upgrading to 9.16.2 (and also libuv 1.36.0) makes no difference - the same memory leak is observed. Any suggestions? Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: haproxy syslog comptible
>> I mean you talk about different syslogd, not from FreeBSD: >> >> syslogd: illegal option -- O >> usage: syslogd [-468ACcdFknosTuv] [-a allowed_peer] >>[-b bind_address] [-f config_file] >>[-l [mode:]path] [-m mark_interval] >>[-P pid_file] [-p log_socket] > > Ah, I am see -- I am need syslogd from FreeBSD-12, thx. The option certainly exists in 11.3-PRERELEASE also: SYNOPSIS syslogd [-468ACcdFHkNnosTuv] [-a allowed_peer] [-b bind_address] [-f config_file] [-l [mode:]path] [-m mark_interval] [-O format] [-P pid_file] [-p log_socket] [-S logpriv_socket] Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
64-bit integer overflow computing user cpu time in calcru() in kern_resource.c
Hi, We use FreeBSD 11.2-STABLE for 5 recursive name servers, with PowerDNS recursor as the actual name server software. I recently complained on the pdns-users list that some graphs based on information from the name server process stopped working after a while (typically a week or less): https://mailman.powerdns.com/pipermail/pdns-users/2019-January/025739.html Bert Hubert of PowerDNS led me to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227689 and it definitely looks like this is the bug causing the disappearing graphs that I see. In https://mailman.powerdns.com/pipermail/pdns-users/2019-January/025742.html you can see the effect on the getrusage() call - in short, the values simply stop incrementing after a while. I fixed the problem by following the link from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227689 to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=76972 which has an attachment (kern_resource.c.patch.txt) at https://bz-attachments.freebsd.org/attachment.cgi?id=50537 After adding this patch and rebooting, the problem has not recoccurred in nearly two weeks. I'm reasonably sure that the problem really has been fixed. I checked the code at the same place in HEAD, from https://svnweb.freebsd.org/base/head/sys/kern/kern_resource.c?view=markup and the bug appears to still be present in HEAD. So, I'd love it if somebody could - Update bugs 76972 and 227689 to note that this affects more than one person. - Fix this in HEAD and hopefully also MFC to 11.2-STABLE. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Locale problem updating 10.3 to 11.1
> > However, since it was mentioned in a note starting with > > "Add support for unicode collation" I most likely didn't even read it > > since I'll never touch unicode. > > > > If you ever use anything other than LANG=C, you *are* touching Unicode. % echo $LANG LANG: Undefined variable. % echo $LC_CTYPE nb_NO.ISO8859-1 Works for me. But I did use a while to figure out what had happened between 10.3 and 11.1, since my Norwegian æøå suddenly stopped working (before changing LC_CTYPE to nb_NO.ISO8859-1). Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HP Smart array P440 support
> > I have HP DL20 Gen 9 server. But I can not install FreeBSD 10.2 in it. I > > have a HP smart array P440 in my server. I can not find out anywhere if ciss > > driver support include HP Gen 9 storage controllers. Could you please > > update the ciss driver in 10.3? > > Try 10.3 > > I know the release-notes say nothing about it, but I believe it is supported. > > If not that, 11.0 surely does (even though the release-notes don$,1ry(Bt > mention it, either) I can confirm that 10.3 supports the P440 controller. From a DL360 Gen9 server running 10.3 here: ciss0: port 0x2000-0x20ff mem 0x92c0-0x92cf,0x92d0-0x92d003ff irq 16 at device 0.0 on pci3 ciss0: PERFORMANT Transport ... da0 at ciss0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SPC-3 SCSI device da0: Serial Number PDNLH0BRH8S3RF da0: 135.168MB/s transfers da0: Command Queueing enabled da0: 139979MB (286677120 512 byte sectors) Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: X2APIC support
> > > Sorry, don't cleanly understund, what combination of BIOS setting I am > > > need to probe? > > > And what I am need to check? > > > > Set 'Hyper-Threading' to Enabled. > > Set 'X2APIC_OPT_OUT' to Enabled. > > Try to boot. > > Crashed at same point. A comment about X2APIC, on a different type of system: I had to disable X2APIC on HP ProLiant DL360 Gen9 servers in order to avoid 10.3-STABLE crashing during boot. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Can I get an ISO-8859-1 system back
> I upgraded from 9.? to 10.2. I used a custom kernel to avoid vt and raster > fonts in sc. I updated as many ports as would build. > > Now I cannot find an editor that will display my files with accent > characters correctly. I know the files are still iso-8859-1 because they > are the same size they were and when I cat them, they have the right > characters in them. This also shows that my term (cons25l1) can display > the characters correctly. But joe, joe2, ee, and pico-alpine seem to > convert them to some kind of UTF mess, with two bytes which display as grey > blocks. > > I have tried using LC_ALL and LANG as en_US.iso-8859-1 in .login_conf, and > unsetting them, I have tried several screen maps. I use "setenv LC_CTYPE no_NO.ISO8859-1" in my .cshrc (yes, I still use tcsh), and don't set LANG at all, on my 10.2 systems. This works like a charm - I can display my Norwegian characters (æøå) both on the command line and for instance in vi etc. No UTF here. Not at all sure this works with VGA characters though - I mainly use remote login via ssh. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Bind in FreeBSD, security advisories
Considering the topic, and how many times it's come up. I'm not sure that's a nything to be proud of. ;) Given not all CVE's are created equal and given the amount of internal self consistancy checks (all of which kill the server if they don't pass (and push the CVSS score to 7.x)) there are in BIND the number of advisaries is actually very small. Yes, this was a internal self consistancy check failing. We are human and despite code reviews, unit and system tests, static analysis checkers etc. some errors do make it through. I'm also more than a little surprised about people dragging out sendmail as a shining example of *good* (bug-free?) software. Does nobody remember any history here? It wasn't *that* many years ago that we seemed to have sendmail-bug-of-the-day... Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Bind in FreeBSD, security advisories
For years, a lot of security advisories have been present for bind. I'm just guessing if it's not a good idea to remove bind from base? This will probably free by half the number of FreeBSD SA's in the future. Sure, but no bind in base also implies no dig, nslookup or host. Exactly. It's a slippery slope - if we continue removing useful functionality from FreeBSD there are fewer and fewer arguments for why one should use FreeBSD and not Linux. Yes, I know everything can be installed from packages/ports. Two of *my* main reasons for using FreeBSD is that: 1. It's an integrated *system*, not just a kernel. 2. The base system contains a lot of the useful functionality I need. and every contrib part which is removed, detracts from this. YMMV. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Bind in FreeBSD, security advisories
and every contrib part which is removed, detracts from this. And every contrib part that is added to base is another piece of software that rots for the life of a major release and ends up getting replaced by frustrated endusers with the latest in ports... The tight integration of the base system that everyone appreciates and respects is far below high-level software like BIND. Speaking only for myself, I disagree rather strongly with this. Looking at /usr/src/contrib on an 8.4-STABLE system, I use the following frequently (often several times per day): bind9 diff less libreadline (used by lots of other stuff) ntp nvi tcp_wrappers tcpdump tcsh telnet top traceroute If you remove these contrib parts from FreeBSD, that means at least 12 packages I'd need to install on every new FreeBSD system to get the system in a (for me) functional state. Certainly not a *major* hassle - but having these parts integrated is part of the FreeBSD attraction. I don't think we should work to make FreeBSD less attractive... Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to bind a route to a network adapter and not IP
I loose packets because I use a WLAN adapter. Sometimes the link is down for various reasons, and then the routes start changing for manually created routes, and I want to prevent that. well that is certainly not a reason for changing routes I have the feeling you are not explaining good enough what really is going on and it may help sending your configurations and an example of routes and IP addresses before and after this route change Why is this so hard to understand? Link down leads to static route is deleted. This is standard FreeBSD behavior, and has been this way for as long as I can remember (btw, I believe this behavior is from the original BSD, not FreeBSD specific). You can show this by having a static default route pointing to an address on an Ethernet interface which has link. And then pulling the TP cable from the Ethernet interface. Observe that the default route is automatically removed. My claim is that this behavior is reasonable *but* I'd like the route restored when the link comes back up again. This is standard Cisco / Juniper behavior - but *not* standard FreeBSD behavior. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to bind a route to a network adapter and not IP
Perhaps you can ask the very same question in another way so its easier to understand why you losing packets? All in all I always thought TCP/IP was the basic unit in Internet based networking but feel free to correct me if you have any news I might have missed... :) This is an old and well known problem, with no solution as of today (unless you want to run quagga/zebra or similar). With Cisco and Juniper (and probably lots of other big name) routers, if I create a static route pointing to a next hop on one interface, and the interface goes down (e.g. Ethernet cable is unplugged), 1. the static route is removed from the routing table. But then, when the interface later comes back up 2. the static route is reinstalled in the routing table. With FreeBSD point 1 above happens, but not point 2. I would love to have the functionality where FreeBSD would reinstall the route as in point 2 above. I think this is definitely the least surprising behavior (POLA), and should happen even without running an explicit routing system like quagga. Steinar Haug, Nethelp consulting, sth...@nethelp.no On 06/15/2012 12:19 PM, Hans Petter Selasky wrote: Hi, Maybe there is a simple answer, but how do I bind a route to a network interface in 8-stable? Is that possible at all? I'm asking because the routes I add in my network setup are lost because of ARP packet drops. I.E. they exist for a while, but not forever like I want to. --HPS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Dell R620 Ethernet Ordering
I'm using several Dell servers with FreeBSD 8.2-STABLE and the bge driver. No problems that I can see. You are using R620/720 machines with the 5720 add on board? Sorry, my servers are slightly older Dell servers. No R620/720. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Dell R620 Ethernet Ordering
Incidentally, does the broadcom driver in either 8 or 9 work for anyone? When I try to use an 8 or 9 compiled in the past week I get unusable networking that bounces up and down. I'm using an R620 with the quad-port broadcom daughtercard. I'm using several Dell servers with FreeBSD 8.2-STABLE and the bge driver. No problems that I can see. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
How to set interface description containing space in 8.x
FreeBSD 8.x (well, at least 8.2) has the very nice feature of letting you set an interface *description* (just like you can on any Juniper/ Cisco/whatever router). This decription can contain spaces - so I can do for instance: xxx# ifconfig bge1 descr abc def xxx# ifconfig bge1 bge1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 description: abc def options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:13:72:20:b4:6f media: Ethernet autoselect (1000baseT full-duplex,flowcontrol,rxpause,txpause) status: active and we see that the decription includes a space. The question is - how can I include a description containing one or more spaces in rc.conf? The straighforward attempt, ifconfig_bge1=up descr abc def doesn't work - abc and def are given as separate parameters to the ifconfig command, resulting in abc being used and def regarded as an extra parameter: xxx# /etc/rc.d/netif start bge1 ifconfig: def: bad value I have tried several variants, ifconfig_bge1=up descr abc\ def ifconfig_bge1=up descr abc\\ def ifconfig_bge1=up descr 'abc def' ifconfig_bge1=up descr \abc def\ ifconfig_bge1=up descr abc_def but none have the desired result. Can anybody shed a light on this? Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to set interface description containing space in 8.x
So there may have been some rc.d framework changes that address your problem. Are you running -RELEASE? If so those fixes probably aren't available. And here's the commit that fixed it (src/etc/network.subr, which is /etc/network.subr): http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/network.subr#rev1.195.2.12 http://www.freebsd.org/cgi/query-pr.cgi?pr=156675 Yup, thank you for verifying this! I see now that it works on an 8.2-STABLE box with sources from October 4, while it doesn't work on one from early June. Problem solved. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RFC: Upgrade BIND version in RELENG_7 to BIND 9.6.x
In order to avoid repeating the scenario where we have a version of BIND in the base that is not supported by the vendor I am proposing that we upgrade to BIND 9.6-ESV in FreeBSD RELENG_7. ... I vote for the upgrade. It's easy and seamless for users, as far as I can tell, and it avoids problems in the long run. I agree with you that the situation that we had with FreeBSD 6 should be avoided. +1 here. I run several 7-STABLE boxes with BIND 9.6, no problems. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD eats 169.254.x.x addressed packets
One final comment - I still don't understand why FreeBSD won't respond to pings when it has an address like 169.254.1.1. I can ssh to the unit but it won't respond to pings. I tried setting up a linux box with an address like 169.254.1.2 and it would respond to pings. Linux is not really any measuring stick in standard compliance... If 169.254.0.0/16 addresses are supposed to be link local then I'd definitely expect a reply to a ping from another box on the same LAN, sourced from another 169.254.0.0/16 address. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD eats 169.254.x.x addressed packets
One final comment - I still don't understand why FreeBSD won't respond to pings when it has an address like 169.254.1.1. I can ssh to the unit but it won't respond to pings. I tried setting up a linux box with an address like 169.254.1.2 and it would respond to pings. Linux is not really any measuring stick in standard compliance... If 169.254.0.0/16 addresses are supposed to be link local then I'd definitely expect a reply to a ping from another box on the same LAN, sourced from another 169.254.0.0/16 address. Having tested this in the lab I'd say FreeBSD 7.x works exactly as expected. Traffic on the same LAN works, traffic to other LANs is not routed. All is well. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Results of BIND RFC
[1]: FreeBSD really needs to move away from the base system as a concept, as I've ranted about in the past. Strongly disagree. Or if it cannot, the base system needs to start using pkg_* (somehow) for use, and src.conf WITHOUT_xxx (where xxx = some software) removed. Concept being: I don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; pkg_delete base-lib32. Beautiful concept, hard to implement due to libraries being yanked out from underneathe binaries that are linked to them. But you get the idea. This *might* be workable. However, in general - a large part of the reason why I use FreeBSD is that the FreeBSD base system gives me most of what I want, in *one* well defined chunk, *without* having to install a zillion extra packages, and without umpteen different versions of config files and locations for the important information. So please don't destroy this. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: update to 8.0-RELEASE -- partition gone
If you installed dangerously dedicated and ended up with ad0s1a (note the s1), then you have an invalid partitioning and FreeBSD 8.x will not give you what you've been getting on FreeBSD 7.x. Most of the time you only need to wipe out the second sector on the disk to clean it up and have FreeBSD 8.x also give you ad0s1a. So what's an easy recipe we can run on 7.x hosts to see whether we would have problems with 8.x? Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: update to 8.0-RELEASE -- partition gone
If you installed dangerously dedicated and ended up with ad0s1a (note the s1), then you have an invalid partitioning and FreeBSD 8.x will not give you what you've been getting on FreeBSD 7.x. Most of the time you only need to wipe out the second sector on the disk to clean it up and have FreeBSD 8.x also give you ad0s1a. So what's an easy recipe we can run on 7.x hosts to see whether we would have problems with 8.x? From what's been said so far: If you have adXsY devices in 7, *and* bsdlabel adX finds a valid label (*note*: that is the whole disk, not the slice), then you have conflicting BSD and MBR labels at the start of the disk and you will have a problem in 8. So presumably if I have root on ad4s1a today, and bsdlabel shows # bsdlabel ad4 bsdlabel: /dev/ad4: no valid label found then I am ready for FreeBSD 8.x? Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS NAS configuration question
root filesystem is remounted read write only for some configuration changes, then remounted back to read only. Does this work reliably for you? I tried doing the remounting trick, both for root and /usr, back in the 4.x time frame. And could never get it to work - would always end up with inconsistent file systems. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD-6.x/7.x 1000BaseTX connection problem
We have never had a problem with FreeBSD and Cisco using em and bge. They do take a while to come up but that's just Cisco being Cisco. Same here. We use em interfaces with Cisco switches all the time, all ports configured with default which is autonegotiation. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Possible regression in ifconfig under7.0 - removes validdefault route
Oh yeah, since we're in wishful thinking mode, I want interface descriptions too... Have you looked at the 'name' and 'group' keywords in ifconfig(8)? If this isn't what you want, please expand on your wish. It is not what I want. On routers, switches and lots of other boxes from most vendors you can associate a description string with each interface - where interface can be a physical port, or for instance a VLAN based interface. This description string is useful to document things like - what is the box at the other end of the cable connected to this port - what is the port at the other end of the cable connected to this port - what is the circuit id for the circuit this port is connected to - what is this port used for etc. Typical example, from one of our switches (Cisco syntax): interface GigabitEthernet0/12 description TO: fs1.td ID: BTN-11510092 TXT: gi1/0/7 EoSDH 50 Mbps switchport trunk allowed vlan 123,770,1024,1500,1504,1528,1536 showing the first three points I mentioned above. Such a description string is can normally be retrieved using SNMP. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible regression in ifconfig under7.0 - removes validdefault route
Thanks for the confirmation on that its not a regression Jo. It really is a nasty little bug so I'll raise a PR for it, hopefully someone with the power will then fix it :) This leads to the question - what do people *want* with respect to static routes? I know what *I* want: The static route behavior that Cisco, Juniper and other big router vendors have, i.e. - A configured static route exists in the routing table as long as the nexthop IP address is valid. If the nexthop becomes invalid (for instance if you lose link on an Ethernet interface), the static route is also removed from the routing table. - But (and here's the big difference) - *if the nexthop comes back*, for instance because your Ethernet interface gets link again, the configured static route is inserted into the routing table again. Note that with this behavior, changing the IP address of an interface would not result in the default route being deleted, as long as the nexthop for the default route remained valid. Oh yeah, since we're in wishful thinking mode, I want interface descriptions too... Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fxp performance with POLLING
However, ethernet at 100Mbit is 4B5B coded at a 125mhz rate. So the raw synchronous data rate really is 12.5Mbytes/s. Minus the sync preamble of 8 bytes per packet and the mandatory inter-frame-gap of 12 bytes that's a physical layer rate of (12.5M * (1500/(1500+20))) or 12.34Mbyte/s. You need add Ethernet header (14 bytes) + CRC (4 bytes). This means you have a maximum data rate, assuming 1500 byte MTU, of 12.5M * 1500/1538 = 12.19 Mbyte/s. And for those used to powers of two, M here means one million, not 1048576. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Request for testing - top 3.8b1 in the base system
The big new features are a line upper part with kernel statistics (context-switches, traps, interrupts, faults etc) and the FLG table (if you window is big enough) Would it be possible to document the values in the FLG field? The meaning wasn't obvious to me... Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY
IMHO, a dirty filesystem should not be mounted until it's been fully analysed/scanned by fsck. So again, people are putting faith into UFS2+SU despite actual evidence proving that it doesn't handle all scenarios. Yes, I think the background fsck should be disabled by default, with a possibility to enable it if the user is sure that nothing will interfere with soft updates. Having been bitten by problems in this area more than once, I now always disable background fsck. Having it disabled by default has my vote too. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: WARNING: 7-STABLE BROKEN -- please wait to upgrade / Should be OK now
The breakage from the WITH_CTF build is indicated by Abort from the image activator. Signal 11, AKA segmentation fault, is not likely to be caused by the dtrace MFC problems. Just in case, if you have buildworld result intact, you should enter /usr/src/gnu/usr.bin/binutils/ld and do make install DEBUG_FLAGS=-g But I think your problem is not related. I cvsuped and built 7-STABLE just a couple of hours ago. No problems at all. So I agree that this may be a different problem. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em(4) on FreeBSD is sometimes annoying
Hasn't anyone really noticed yet that em(4) only appears when you boot FreeBSD with the interface physically attached to a switch for example? If you attach it later, after boot up, the interface won't power up and appear in the interface list (ifconfig)? I'm afraid I don't see your problem at all. My em interfaces appear as they should, even if not connected to a switch. And when I connect an em interface to a switch, I get link and things work as expected. Steps to reproduce: 1) Switch your PC/laptop off. Really OFF, no reboot. 2) Disconnect the em(4) NIC from your switch. 3) Boot FreeBSD. 4) Plug in the ethernet cable. 5) Tataa! All leds at the NIC stay off. You won't be able to use em(4) unless you reboot your machine. Something is not being initialized properly on em(4) devices, it seems. This may well be the case - but not that the em driver handles several different chip models. You may have a problem which is specific to one or a few chip models. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
I wrote in an earlier message: I've been trying out unbound-1.0.1 on a 7.0-STABLE box (2.67 GHz i86, uniprocessor, 32 bit mode, 2 GB memory). Don't know what I'm doing wrong so far - but I've been unable to scale Unbound to more than a couple of hundred q/s. Any more than that and I get serious (several hundred ms) delays on lots of queries, including stuff which is known to be in the cache. I'll be doing some more Unbound tests the next few days. For now, both CNS and PowerDNS handle our load (around 2.5K q/s) fine. As a followup: I'm now happily running Unbound (together with Nominum CNS) in our standard anycast configuration. I've gotten Unbound to handle our regular query load of 2000 - 2500 q/s just fine. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unbound success
As a followup: I'm now happily running Unbound (together with Nominum CNS) in our standard anycast configuration. I've gotten Unbound to handle our regular query load of 2000 - 2500 q/s just fine. Don't leave us all in suspense, what did you have to twiddle? :) Need to check some more details here (because I changed considerably more than one parameter). Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
If you're interested in a resolver-only solution (and that is not a bad way to go) then you should evaluate dns/unbound. It is a lightweight resolver-only server that has a good security model and already implements query port randomization. It also has the advantage of being maintained, and compliant to 21st Century DNS standards including DNSSEC (which, btw, is the real solution to the response forgery problem, it just can't be deployed universally before 8/5). I've been trying out unbound-1.0.1 on a 7.0-STABLE box (2.67 GHz i86, uniprocessor, 32 bit mode, 2 GB memory). Don't know what I'm doing wrong so far - but I've been unable to scale Unbound to more than a couple of hundred q/s. Any more than that and I get serious (several hundred ms) delays on lots of queries, including stuff which is known to be in the cache. I'll be doing some more Unbound tests the next few days. For now, both CNS and PowerDNS handle our load (around 2.5K q/s) fine. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
I'd said nearly a dozen times that the issues I have aren't specifics. I am questioning the overall policy for EoL here. Even if it was known to work properly on my hardware the overwhelming amount of bugs in 6.3 indicates an unstable release. No. 6.3 is very stable for us, on multiple machines. So is 7.0. And I have seen lots of other users basically saying the same thing. *You* are the one claiming that the overwhelming amount of bugs in 6.3 indicates an unstable release - yet you are unwilling to test 6.3 and you are also unwilling to show the PRs you claim exist. My sympathy for such a view is limited. Personally, I'm very happy with the work that the developers have put in and are *continuing* to put in. However, I'm just a user, not a developer. I have occasionally contributed bug fixes to FreeBSD, which is *my* best waying of returning the favor of all of the persons who have spent countless hours, often unpaid, to make FreeBSD a better system. I hope they continue! Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MFC of em/igb drivers
Have you tried disabling speed and duplex negotiation and explicitly stating speed and duplex like so? ifconfig_em0=... media 1000baseTX mediaopt full-duplex Disagree with this piece of advice. Cisco switches have a notorious history of not being friendly with non-Cisco hardware. Forcing duplex on both ends of the link (that means on both the host side, and the Cisco side!) usually fixes it. I might have said the same myself five years ago. But this is 2008, and we have autoneg as default on all ports (even at 100 Mbps). Our Cisco switch ports (and we have a *lot* of them) work just fine with autoneg. Note that GigE is different from FE here - autoneg is a compulsory part of the GigE standard, while it's not compulsory for FE. The only GigE ports that have needed anything else were some pre-standard GigE ports. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Desired behaviour of ifconfig -alias
In that situation, wouldn't deleting the primary IP cause connection issues for the rest of the IPs? No. I can delete _any_ of the above IP addresses, and the others would still work perfectly fine. I already did things like that (on a different machine). As for outgoing connections: It is true that the kernel picks a random matching IP address to be the source IP, which happens to be the first one, but that's just as coincidence as -alias picking the first one if none is given. ;-) If it is indeed true that the kernel picks a *random* IP address for the source IP, I'd have to say that's not at all good enough. I'm all for being able to use the same netmask for several addresses in the same subnet (I have asked for this before) - but the source IP used by traffic generated from the host itself *must* be predictable. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bge Ierr rate increase from 5.3R - 6.1R
When dealing with Cisco-othervendor, I've never seen auto-neg work properly. One has to always hard set the speed and duplex on both sides for it to work. Nowadays auto-neg almost always works for us, even for Fast Ethernet. We have Cisco-Extreme, Cisco-Juniper, Cisco-Cisco, Cisco-Riverstone and of course lots of Cisco-various hosts. Basically, things just work. We always use auto-neg for Gigabit Ethernet. 3-4 years ago the situation was different, and we always used to set speed/duplex. Not any more. Maybe you've been unlucky. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: netstat -ni - A lot of collisions...
I've never paid much attention to what ifconfig says, or what managed switches say, as far as speed or duplex negotiation go. Most vendors do not play well together. I'll repeat that because it needs repeating: most vendors do not play well together. Example: anyone familiar with Cisco Catalysts knows of the long-standing problem with auto-neg which ultimately requires both ends of the connection be set to 100/full. I disagree. Autonegotiation used to be a problem, and we used to force all links to 100/full. But that was 3-4 years ago. These days, the situation is much improved - and in most cases autonegotiation just works. That includes *lots* of Cisco Catalyst switches. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [fbsd] HEADS UP: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon
I realize that resources to keep chasing this stuff are in limited supply, but if you solicit the opinion of the community, I'd bet that more people would rather see 4.x support continue than 5.x support. I know that it would be a violation of the stated policy, but I think that supporting 4.x and 6.x over the next year would benefit way more people than the current plan of supporting 5.x and 6.x and eol'ing 4.x. Yes, fully agreed. I'd much rather have longer support for 4.x than 5.x. We still have lots of machines running 4.11 here. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6-stable and Tcpdump problems
Looks broken to me. Try the attached patch which should fix it. It would probably be better to try to stay in sync with the official tcpdump at www.tcpdump.org. Both the latest (current) version, fetched today: http://www.tcpdump.org/daily/tcpdump-current.tar.gz and the latest release version, 3.9.4: http://www.tcpdump.org/release/tcpdump-3.9.4.tar.gz have the -A option working the same way as in 5.x. 6.1-PRERELEASE seems to have tcpdump version 3.9.1. So I would recommend simply importing the 3.9.4 version instead of adding a local patch. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] Steve - Original Message - From: Michael Vince [EMAIL PROTECTED] Can any one agree with me there is a bug here? I have the same result on multiple machines. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel cpu entries
Is a minor update to the handbook needed in order avoid confusion then? e.g. I have been commenting out CPU_I586 on all my PIII systems in the (mistaken it would seem) belief that having CPU_I686 only was better. I've been doing the same thing myself - removing the CPU_I586 on PIII and newer systems. An update would be good. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA vs SCSI ...
Going through an old thread and saw your comment... What is the sysctl parameter to use to turn off WCE? camcontrol modepage Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 1000baseTX?
In man pages, dmesg and ifconfig of FreeBSD5, GbE operation over twisted pair is mostly referred as '1000baseTX'. I guess most of them should be replaced by '1000baseT'. 1000baseTX and 1000baseT are different standard and they are not compatible (TX needs CAT6 cable and uses pairs in different way). Also 1000baseTX support is very rare yet. I'm sorry I'm not sure if some devices really support TX. Do you have any documentation to back up this claim? 1000baseTX was an attempt at producing less expensive hardware (NICs etc) that could be used with Cat6 cabling. It is basically dead, and was never blessed by the IEEE. The IEEE is quite clear on the fact that Gigabit Ethernet on Cat5 UTP is called 1000Base-T. See for instance Chapter 34, Introduction to 1000 Mb/s baseband network, in IEEE 802.3-2002, available from http://standards.ieee.org/getieee802/802.3.html So using 1000baseTX as the name in FreeBSD is clearly wrong. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 1000baseTX?
The IEEE is quite clear on the fact that Gigabit Ethernet on Cat5 UTP is called 1000Base-T. See for instance Chapter 34, Introduction to 1000 Mb/s baseband network, in IEEE 802.3-2002, available from http://standards.ieee.org/getieee802/802.3.html So using 1000baseTX as the name in FreeBSD is clearly wrong. Probably just as right or wrong as 99% of the NIC cards docs. Well, Doug White asked for documentation. When it comes to the Gigabit Ethernet, I believe the IEEE standards are about as authoritative as you can get. If you check the specs for some of the Intel Gigabit Ethernet cards, e.g. http://www.intel.com/network/connectivity/resources/doc_library/data_sheets/pro1000gt_da.pdf you'll see that they refer to 100base-TX, but 1000base-T. So I stand by my claim that 1000base-T is clearly more correct than 1000baseTX. It would be nice to get this fixed - however, it is a minor point and I certainly believe that there are other tasks that are more important. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
While I agree that correct ports shouldn't be affected, I think that this will make a difference in how FreeBSD is looked at as a whole. I know that when I write stuff for other people in perl, it is presumed that perl is in /usr/bin, not /usr/local/bin because most of these people are running some Linux distribution. I also thought that is was requested to have perl in /usr/bin? I agree, having perl available in /usr/bin is one of the nice points of FreeBSD. I see strong reactions against removing the /usr/bin symlinks in 5.x. Good, presumably they will be allowed to stay. But I would also like to keep them for 6.x. As others have pointed out, removing those symlinks would create a lot of hassle for the users, for very little gain. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
Unless I hear too many cries don't do that (with justification), I plan to not create any perl symlinks in /usr/bin in the forthcoming upgrade of both lang/perl5.8 (to 5.8.6) and lang/perl5 (to 5.6.2). This will ONLY be true for FreeBSD 5.X and FreeBSD CURRENT; the existing pollution of /usr/bin will still be performed for older versions of FreeBSD, if requested via use.perl script. What purpose does this serve? To keep the base system clean? I'm not convinced that having just a few (2?) symlinks in /usr/bin will pollute the base system, but it does save having to modify potentially thousands of scripts. Isn't the latter *much* more expensive? Agreed. Removing perl symlinks in /usr/bin is an incredibly bad idea. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: serious networking (em) performance (ggate and NFS) problem
I changed cables and couldn't reproduce that bad results so I changed cables back but also cannot reproduce them, especially the ggate write, formerly with 2,6MB/s now performs at 15MB/s, but I haven't done any polling tests anymore, just interrupt driven, since Matt explained that em doesn't benefit of polling in any way. Results don't indicate a serious problem now but are still about a third of what I'd expected with my hardware. Do I really need Gigahertz Class CPUs to transfer 30MB/s over GbE? I would be highly surprised if you did. When I tested this a while ago (around FreeBSD 4.8) with a pair of Intel ISP 1100 1U servers using Pentium 700 and Intel GigE cards (em driver), I was able to get around 700 Mbps using ttcp. This was done with a normal 32 bit 33 MHz PCI bus. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCSI Disk Errors
I've started seein the following in my log (messages) file today. Google-ing doesn't seem to yield much and I was wondering if someone has an idea why this is happening: I got similar messages from two disks just before they died. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
