Re: Fwd: [releng_8 tinderbox] failure on i386/i386
On Wed, 12 Jan 2011, Jeremy Chadwick wrote: Hi, CC'ing responsible committers... http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/if_llatbl.c Yes, it had the same problem in HEAD back then. kib fixed it that time and I just merged his fix as well that would ideally have gone in with the MFC or r215207. -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ 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 8.1 re0 shows half duplex
On Sun, 16 Jan 2011, Jeremy Chadwick wrote: On Mon, Jan 17, 2011 at 05:08:33AM +, Martin Wilke wrote: Howdy Guys, I have a strange problem, I'm on FreeBSD 8.1 and ifconfig re0 shows half-duplex (see output) and the download speed is damn slow, maximum 20 kbps. I'm not sure how to debug this so it would be nice if someone can help me to fix it. When i change it manually via command line, the media line appeared to have 2 entries -- full-duplex and half-duplex [cut] it all just means that you want to read the thread on net@ from last week. A workaround is in HEAD already. /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ 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: KERN - mfi driver for Dell raid h200 on r210 servers
On Sat, 29 Jan 2011, Damien Fleuriot wrote:
Hello lists,
I'm trying to get FreeBSD 8.0 or 8.1 to run on a Dell poweredge r210 server.
It ships with a SATA/SAS h200 RAID controller.
Sadly, the MFI driver doesn't seem to register for this card...
Find below the pciconf -lcvb
--
none6@pci0:1:0:0: class=0x010700 card=0x1f1d1028 chip=0x00721000
rev=0x02 hdr=0x00
vendor = 'LSI Logic (Was: Symbios Logic, NCR)'
class = mass storage
subclass = SAS
bar [10] = type I/O Port, range 32, base 0xfc00, size 256, enabled
bar [14] = type Memory, range 64, base 0xdf2b, size 65536, enabled
bar [1c] = type Memory, range 64, base 0xdf2c, size 262144, enabled
cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0
cap 10[68] = PCI-Express 2 endpoint max data 256(4096) link x8(x8)
cap 03[d0] = VPD
cap 05[a8] = MSI supports 1 message, 64 bit
cap 11[c0] = MSI-X supports 15 messages in map 0x14
--
I have added the following to /usr/src/sys/dev/mfi/mfi_pci.c at line 119:
--
{0x1000, 0x0072, 0x1028, 0x1f1e, MFI_FLAGS_GEN2, "Dell PERC H200 Integrated"},
--
It's 1f1d not 1f1e. I hope it was only a paste problem into email?
Rebuilt the kernel, tried it on the server, still no luck recognizing
the RAID card.
As a last resort I'll be setting the drives to passthrough and using a
software RAID, but I'd much rather this worked out.
Note that mfi actually recognizes Dell's h700 and h800 cards.
Anyone managed to get the h200 card working yet ?
@hackers: please keep me cc'd, I'm not subscribed to this list.
Regards,
--
dfl
___
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"
--
Bjoern A. Zeeb You have to have visions!
Going to jail sucks -- All my daemons like it!
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
___
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: KERN - mfi driver for Dell raid h200 on r210 servers
On Sun, 30 Jan 2011, Damien Fleuriot wrote: Ok I've loaded the newly patched mfi.ko and booted a MFS image. Here's the relevant snip from dmesg.run : at mfi0: port 0xfc00-0xfcff mem 0xdf2b-0xdf2b,0xdf2c-0xdf2f irq 16 at device 0.0 on pci1 mfi0: Megaraid SAS driver Ver 3.00 mfi0: firmware stuck in state 0 mfi0: Firmware not in READY state, error 6 I'll have to try mps then, unless someone has an idea about this "stuck in state 0" thing. it means that you should ask Dell for the information as the mfi(4) driver needs some special handling to support that exact chip. Probably needs some special initialization and a couple of if ()s, as usual. LSI/Dell are the people to talk to. /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ 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: RELEASE_6 -> RELEASE_8
On Mon, 31 Jan 2011, Mark Andrews wrote: I was trying to upgrade a machine from RELEASE_6 (latest) to RELEASE_8 (latest) via source. I was unable to get make buildworld to complete. You need latest N to go to N+1, so a 6.4-RELEASE or RELENG_6 after that should be able to go to 7.x but not straight to 8. Multi-Release-Hop-Updates have been working once in a while in the past with other releases but were never officially supported. Not even a say 7.1 might be able to go to straight 8.x btw. Unfortunately UPDATING wasn't really updated in that regard for a while and might still say "To upgrade in-place from 5.x-stable to current" in older branches; I know it was fixed in 9 for 8 in [1] as part of a large cleanup but I think a similar change never made it back to other stable branches. /bz [1] http://svn.freebsd.org/viewvc/base/head/UPDATING?revision=196789&view=markup -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ 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"
NATM still scheduled for removal - please follow up to keep it in-tree
Hi, now that stable/8 (not part of the upcoming 8.2-R) once again has support for NATM I'd like to remind people of http://lists.freebsd.org/pipermail/freebsd-net/2010-December/027215.html especially: :: 1) the extra couple of months; this will not prevent the evitable removal :: yet only defer it. :: :: 2) If anyone of you is using (or want to be able to (continue to) use) NATM :: or can test things, I re-enabled it with most of the code in HEAD and :: the patch is available for 8,x as well but need to work with somoene :: to make sure it'll really work. I am willing to spend more time on it :: if you send me an email. So if anyone of you is still using NATM, please follow-up with me to keep your functionality. If there is no feedback NATM is still scheduled for removal. Thank you. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. -- Forwarded message -- Date: Mon, 14 Feb 2011 16:54:03 + (UTC) From: Bjoern A. Zeeb To: src-committ...@freebsd.org, svn-src-...@freebsd.org, svn-src-sta...@freebsd.org, svn-src-stabl...@freebsd.org Subject: svn commit: r218684 - in stable/8/sys: conf netinet Author: bz Date: Mon Feb 14 16:54:03 2011 New Revision: 218684 URL: http://svn.freebsd.org/changeset/base/218684 Log: MFC r216466: Bring back (most of) NATM to avoid further bitrot after r186119. Keep three lines disabled which I am unsure if they had been used at all. This will allow us to seek testers and possibly bring it all back. Discussed with: rwatson Modified: stable/8/sys/conf/NOTES stable/8/sys/netinet/if_atm.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) ___ 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"
HEADS UP: will merge VNET socket push back changes to stable/8
Hi, this is a heads up in case anyone is relying on this in private VNET modules or code. I am planning on merging this code to stable/8 probably during the weekend. It should be a NOP for almost everyone, especially if not running a VIMAGE kernel. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. -- Forwarded message -- Date: Wed, 16 Feb 2011 21:29:14 + (UTC) From: Bjoern A. Zeeb To: src-committ...@freebsd.org, svn-src-...@freebsd.org, svn-src-h...@freebsd.org Subject: svn commit: r218757 - in head/sys: fs/nfsclient fs/portalfs kern net netgraph/bluetooth/socket netinet nfsclient rpc Author: bz Date: Wed Feb 16 21:29:13 2011 New Revision: 218757 URL: http://svn.freebsd.org/changeset/base/218757 Log: Mfp4 CH=177274,177280,177284-177285,177297,177324-177325 VNET socket push back: try to minimize the number of places where we have to switch vnets and narrow down the time we stay switched. Add assertions to the socket code to catch possibly unset vnets as seen in r204147. While this reduces the number of vnet recursion in some places like NFS, POSIX local sockets and some netgraph, .. recursions are impossible to fix. The current expectations are documented at the beginning of uipc_socket.c along with the other information there. Sponsored by: The FreeBSD Foundation Sponsored by: CK Software GmbH Reviewed by: jhb Tested by:zec Tested by:Mikolaj Golub (to.my.trociny gmail.com) MFC after:2 weeks ___ 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: IPv6 / ndp taking a long time to resolve in this weeks STABLE
On Wed, 13 Apr 2011, Pete French wrote: Hi, Hi, thanks for the email - I canb recreate this very easily here now. I have also shown that it the problem doesnt happen on a kernel from Feb 25th, but does happen on a kernel from this week. I assume both are stable/8? Are you sure on the Feb 25th kernel doing ok or could it be that you are just more lucky? cery easy to demonstarte - set up 2 machines. Ping one from the other so that it is pinging nicely. Then delete the ndp entry. The ping freezes - sometimes for 20 seconds! It eventually starts again with all the inrtervening packets lost. This only happens if the machone being oinged is running the newer kernel. If you do it the other way round then all is fine. Yes, that would make sense from what I have just observed elsewhere. So I guess my question about the Feb 25th kernel is irrelevant but getting a confirmation on the branch would be good. I would assume that if you have both machines running the newer kernel and would start ping6 from both things would also start working immediately. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: IPv6 / ndp taking a long time to resolve in this weeks STABLE
On Sun, 17 Apr 2011, Pete French wrote: I assume both are stable/8? Are you sure on the Feb 25th kernel doing ok or could it be that you are just more lucky? I've rolled everything back now to a kernel from April 1st - that works OK. The one from April 11th does not. If I get some time I will barrow it down. *wow* Thanks a lot for that update. That narrows it down a lot. I am looking. I would assume that if you have both machines running the newer kernel and would start ping6 from both things would also start working immediately. Didnt think to try that... hang on... [goes and tries] No, that doesnt work - they both hang for a while and eventually start. Ok, then it's even les obvious than what I thought. I'll keep you updated. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: IPv6 / ndp taking a long time to resolve in this weeks STABLE
On Apr 17, 2011, at 10:52 AM, Bjoern A. Zeeb wrote: > On Sun, 17 Apr 2011, Pete French wrote: > >>> I assume both are stable/8? Are you sure on the Feb 25th kernel >>> doing ok or could it be that you are just more lucky? >> >> I've rolled everything back now to a kernel from April 1st - that >> works OK. The one from April 11th does not. If I get some time I will >> barrow it down. > > *wow* Thanks a lot for that update. That narrows it down a lot. I > am looking. In addition to private email, if you are not on stable/8 but HEAD you can just update as I committed the patch I have emailed to HEAD already: http://svn.freebsd.org/changeset/base/220743 /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: UFS SU+J
On Jun 16, 2011, at 12:54 PM, nickolas...@gmail.com wrote: > I' like to know, if there plans to MFC journaled softupdates to 8-stable? > If yes, when it would be done? it cannot be done and will therefor not happen. There used to be a branch in user/jeff/ or somewhere in the /user or /project area in svn with an older version of a backport but I am not sure if it was ever updated again. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: commit PR 154469, ftp-proxy(8) bug ?
On Jun 22, 2011, at 12:11 PM, Kurt Jaeger wrote: > Hi! > > Can someone have a look at > > http://www.freebsd.org/cgi/query-pr.cgi?pr=154469 I have a pf45 universe tree sitting here with the works from max and ermal that needs to go in; without checking specifically it should have the fix and the fix could possibly be merges to 8 from there then but knowing that just this fix applied to stable/8 works would be good for that. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: ntpd couldn't resolve host name on system boot
On Tue, 25 Oct 2011, Miroslav Lachman wrote: Hi all, I have a problem with ntpd on many of our servers running 8.2-RELEASE or newer. Some of them are newly installed, most of them are 7.x upgraded to 8.2 or 8-STABLE amd64 with GENERIC. hmm, could it be I didn't MFC all fixes I had done to help that, which are partly (mostly, all these days) existent in newer upstream version (esepcially the latest devels). I'll go an look in my 70 oustanding MFCs. Would be cool if you could test 9 temporary and see if things are better there. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: fbsd 8.2, L2TP over IPsec and pf ?
On Thu, 3 Nov 2011, Kurt Jaeger wrote: Hello, I'm building a setup for incoming L2TP over IPsec connections using FreeBSD 8.2-REL. I assume you are explicitly using tunnel mode? IPsec based on ports/security/ipsec-tools, the l2tp part works from net/mpd5/. If I disable the PF rules, everything works. If I enable the PF rules, the IPsec connection still comes up, but the L2TP requests are lost somewhere in the PF rules 8-( Interestingly, tcpdump enc0 does not see any encrypted packets (!) as long as the PF rules are active. tried playing with the sysctls of enc(4)? net.enc.in.ipsec_bpf_mask=0x0003 net.enc.in.ipsec_filter_mask=0x0003 Any hints on the PF rules required to allow those packets in ? need more details (if you want also off-list). -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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"
ATA/Cdrom(?) panic
Hey, we have seen this or a very similar panic for about 1 year now once in a while and I think I reported it before; this is FreeBSD as guest on vmware. Seems it was a double panic this time. Could someone please see what's going on there?It was on 8.x-STABLE in the past and this is 8.2-RELEASE-p4. Thanks /bz acd0: WARNING - READ_TOC taskqueue timeout - completing request directly Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x1f4 fault code = supervisor read, page not present instruction pointer = 0x20:0xc08a1e9f stack pointer = 0x28:0xe6ad5b9c Fatal trap 12: page fault while in kernel mode frame pointer = 0x28:0xe6ad5bb4 cpuid = 2; code segment= base 0x0, limit 0xf, type 0x1bapic id = 02 = DPL 0, pres 1, def32 1, gran 1 fault virtual address = 0x1f4 processor eflags= fault code = supervisor read, page not presentinterrupt enabled, instruction pointer = 0x20:0xc08a1e9fresume, stack pointer = 0x28:0xe8e9e808IOPL = 0 frame pointer = 0x28:0xe8e9e820 current process = code segment= base 0x0, limit 0xf, type 0x1b12 (swi6: task queue) = DPL 0, pres 1, def32 1, gran 1 trap number = 12 processor eflags= interrupt enabled, panic: page faultresume, cpuid = 4IOPL = 0 current process = KDB: stack backtrace:25162 (bsnmpd) trap number = 12#0 0xc08e0d07 at kdb_backtrace+0x47 #1 0xc08b1dc7 at panic+0x117 #2 0xc0be4b53 at trap_fatal+0x323 #3 0xc0be4dd0 at trap_pfault+0x270 #4 0xc0be5315 at trap+0x465 #5 0xc0bcbecc at calltrap+0x6 #6 0xc08b0d86 at _sema_post+0x46 #7 0xc056fa47 at ata_completed+0x727 #8 0xc08eb97a at taskqueue_run_locked+0xca #9 0xc08ebc8a at taskqueue_run+0xaa #10 0xc08ebd53 at taskqueue_swi_run+0x13 #11 0xc088903b at intr_event_execute_handlers+0x13b #12 0xc088a75b at ithread_loop+0x6b #13 0xc0886d51 at fork_exit+0x91 #14 0xc0bcbf44 at fork_trampoline+0x8 Uptime: 5d20h1m56s (gdb) l *ata_completed+0x727 489 (request->callback)(request); 490 else 491 sema_post(&request->done); 492 493 /* only call ata_start if channel is present */ 494 if (ch) 495 ata_start(ch->dev); 496 } 497 498 void -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: ATA/Cdrom(?) panic
On Wed, 16 Nov 2011, Alexander Motin wrote: Hi. On 11/16/11 08:43, Bjoern A. Zeeb wrote: we have seen this or a very similar panic for about 1 year now once in a while and I think I reported it before; this is FreeBSD as guest on vmware. Seems it was a double panic this time. Could someone please see what's going on there?It was on 8.x-STABLE in the past and this is 8.2-RELEASE-p4. The part of code reporting "completing request directly" is IMHO broken by design. It returns request completion before request will actually be completed by lower levels without any knowledge of what's going on there. There is kind of protection against double request completion, but it looks like not always working. May be because that part of code is not locked and nothing prevents that semaphore timeout and normal request timeout/completion to happen simultaneously. It is surprising to see even two traps same time, not sure what synchronized them so precisely. Simple removing that semaphore timeout is not an option, because it will cause deadlock when this wait happen within taskqueue thread that is used to handle requests completion and abort that wait. Avoid waiting inside taskqueue is also impossible without major rewrite. That's why ATA_CAM drops that code completely. So the bottom line of what you are saying is: 1) it's hard to fix right in 8 2) it's not an issue in 9 anymore at all? -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: r228152: anyone got the None cipher working with base OpenSSH?
On 2. Dec 2011, at 22:57 , Freddie Cash wrote: > Looking through the commit messages for stable/8 and stable/9 I noticed > that the HPN patches were applied to OpenSSH in the base install. And > reading through the commit messages I see that one has to manually enable > the None cipher. However, I cannot, for the life of me, figure out how to > do that. > > The commit message for r228152 says to put "NONE_CIPHER_ENABLED=yes" into > /etc/make.conf. No, that's not what the commit message says. Read more carefully;-) However Jeremy's suggestion might be working better for the moment. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: 9.0-RC3
On 6. Dec 2011, at 13:30 , Dimitry Andric wrote: > On 2011-12-06 14:11, Matthew Seaman wrote: >> On 06/12/2011 12:51, George Kontostanos wrote: >>> I apologize for the noise, I am running 9.0-RC3 since last Sunday but >>> I haven't seen anything related in svn9-stable. Is it just me perhaps >> you mean svn-src-stabl...@freebsd.org ? You're not alone -- the last >> commit e-mail I've seen was on the 3rd. However, I don't think that's >> any cause for alarm. Occasional gaps of two or three days between >> commits seems to be quite normal. > > Direct commits for 9.0 release, such as this one, don't go into the > stable/9 branch, only into releng/9.0: > > http://svn.freebsd.org/changeset/base/228239 > > So you will not see messages about them in the svn9-stable mailing list. > > Apparently there is a svn-src-releng mailing list, though I was not able > to view the archive; http://lists.freebsd.org/pipermail/svn-src-releng/ > gives an error message. You should email postmaster to get this fixed. I assume you will not see (m)any more commits to releng/9.0 however as it's RC3 and that basically means unless major things affecting a lot of users come up soon it's pretty close to the release. I would assume RC3 will be announced the next couple of days - the usual rule is that it takes some days to get all arches build (esp. sparc64 usually takes a bit) and do basic testing, upload and then give them time to propagate to mirrors. That also means that stable/9 will probably soon be opened again for normal merge procedure. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: Is the svn2cvs gateway down ?
On 20. Dec 2011, at 10:01 , Claude Buisson wrote: > It seems (from my own csup's and cvswe.cgi) that the src commits are lost, > starting with r228697 Sun Dec 18 22:04:55 2011) > > What is going on (or off) ? Re $subject -- yes. It will be worked on. -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: Is the svn2cvs gateway down ?
On 21. Dec 2011, at 02:23 , Doug Barton wrote: > On 12/20/2011 02:01, Claude Buisson wrote: >> Hi, >> >> It seems (from my own csup's and cvswe.cgi) that the src commits are lost, >> starting with r228697 Sun Dec 18 22:04:55 2011) > > Yeah, my warning 2 days ago that this was going to happen seems to have > gone un-heeded. :) I'm sure you can take bz' word that it's being > looked at now though. It's been fixed and the changes should propagate to cvsup mirrors close to everyone the next two hours. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: Escaping from a jail with root privileges on the host
On 28. Dec 2011, at 08:58 , Marin Atanasov Nikolov wrote: > Hello, > > Today I've managed to escape from a jail by accident and ended up with > root access to the host's filesystem. This has been discussed to lengths within the last year (I think it was). See the updated man page: http://svnweb.freebsd.org/base/head/usr.sbin/jail/jail.8?r1=221665&r2=224286 /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: svn commit: r229497 - in stable/8/sys: conf modules modules/ipfw netinet/ipfw
On 4. Jan 2012, at 18:01 , John Baldwin wrote: > On Wednesday, January 04, 2012 12:50:38 pm Jason Hellenthal wrote: >> >> After this change I am recieving the attached error log. > > My fault, looks like stable/8 doesn't have WITH_INET / WITHOUT_INET. > I'm doing tests on a fix now. Alternatively I can MFC the knobs; they are part of the other 50 possible MFCs in my mailbox to do; I had just planned to wait on the entire stable/9/8/7 sweep to go by first. There was also a follow-up fix from me on this... /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: svn commit: r229497 - in stable/8/sys: conf modules modules/ipfw netinet/ipfw
On 4. Jan 2012, at 19:40 , John Baldwin wrote: > On Wednesday, January 04, 2012 2:09:44 pm Bjoern A. Zeeb wrote: >> On 4. Jan 2012, at 18:01 , John Baldwin wrote: >> >>> On Wednesday, January 04, 2012 12:50:38 pm Jason Hellenthal wrote: >>>> >>>> After this change I am recieving the attached error log. >>> >>> My fault, looks like stable/8 doesn't have WITH_INET / WITHOUT_INET. >>> I'm doing tests on a fix now. >> >> Alternatively I can MFC the knobs; they are part of the other 50 possible >> MFCs in my mailbox to do; I had just planned to wait on the entire > stable/9/8/7 >> sweep to go by first. >> >> There was also a follow-up fix from me on this... > > I have all your follow-ups AFAIK (I merged 3 changes). Oddly, > sys/modules/netgraph/ipfw/Makefile already references MK_INET_SUPPORT. I > guess no one has tried to build that outside of a kernel build on 8. > > Bjoern has volunteered to MFC the knob to 8 to fix this. That has happened. Let me know if it wasn't enough. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: HPN-SSH question
On 14. Jan 2012, at 23:56 , Steven Hartland wrote: > On a similar note I'm actually quite concerned by the inclusion of > these patches by default in the OS version of ssh as we've seen > several cases of it causing noticeable performance degradation > instead of improvement. > > I've not tested on 9, but this was certainly the case on 8.2. 8.2 did not shipped them so you had installed them yourself? What kind of performance degradations and in which kind of environment an how "noticeable"? /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: HPN-SSH question
On 15. Jan 2012, at 16:28 , Steven Hartland wrote: > Yep we installed openssh-portable + HPN and experienced noticeably > reduced transfer rates on high latency links, exactly the opposite > as one would expect. I don't have the exact figures I'm afraid as > we just went straight back to standard ssh. > > I'll try and get some time to retest and provide some proper > results. Thanks. If you do please try the bundled version in 8-STABLE or 9 and also gather the usual meta data (latency, packet loss, IPv4/v6, any socket buffer tuning, ...). /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: HPN-SSH question
On 16. Jan 2012, at 04:56 , Kevin Oberman wrote: > On Sun, Jan 15, 2012 at 10:58 AM, Bjoern A. Zeeb < > bzeeb-li...@lists.zabbadoz.net> wrote: > >> On 15. Jan 2012, at 16:28 , Steven Hartland wrote: >> >>> Yep we installed openssh-portable + HPN and experienced noticeably >>> reduced transfer rates on high latency links, exactly the opposite >>> as one would expect. I don't have the exact figures I'm afraid as >>> we just went straight back to standard ssh. >>> >>> I'll try and get some time to retest and provide some proper >>> results. >> >> Thanks. If you do please try the bundled version in 8-STABLE or 9 and >> also gather the usual meta data (latency, packet loss, IPv4/v6, any >> socket buffer tuning, ...). >> > > And, if it happens with 9, any chance of a tcpdump capture of all of the > headers for analysis? (No packet data needed.) We use the HPN version > extensively on high latency links (often trans-oceanic) and have never seen > that. I'd find running tcptrace and generating time plots very useful for > looking at this sort of performance issue. Or using siftr. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: Fighting with vnet / jails epair and so on
On 18. Jan 2012, at 15:13 , Shawn Webb wrote: > I've done a bit of research about vnet jails: > http://archive.0xfeedface.org/blog/2011-11-21/lattera/freebsd-vnet-jail-admin-project There's a simple shell script sample on the wiki as well but it would be really cool if you guys could help testing and review the framework jamie has posted on freebsd-jails@ in the past and give him feedback to get it into the tree. /bz > > On Wed, Jan 18, 2012 at 6:59 AM, Denny Schierz wrote: >> hi, >> >> after most parts works with my bridge setups works, I want to get vnet for >> my jails working. In the morning I started a jail and got only the local >> interface back, but no epair0b. Now I did something so that I can see _all_ >> interfaces from outside (bridge0 / bge* / epair0* ... ) but without any IPs. >> However, I'm not able to give epair0b inside the jail an ip address. I get >> "permission denied". >> >> Also it looks a bit strange: >> >> === -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: Fighting with vnet / jails epair and so on
On 19. Jan 2012, at 22:33 , Philipp Huebner wrote: > On 19/01/12 18:22, Denny Schierz wrote: >> hi, >> >> Am 18.01.2012 um 23:21 schrieb Philipp Huebner: >>> >>> I use 9.0.0 release for host and jail and a generic kernel with >>> OPTIONS VIMAGE being the only change/addition. No problem. >> >> so, how looks your rc.conf config ? Do you use vimage the tool? I >> can't use vimage (as I know) on sparc64. > > ... > > I do not use (and never have) the vimage commandline tool. Are you sure you (reading and posting here, plural, in general) sure, that you don't want to read up on freebsd-jail and give the framework a try which might make your life easier... http://lists.freebsd.org/pipermail/freebsd-jail/2011-July/thread.html#1568 I am sure Jamie would like feedback and now that 9.0 is done get review and get it in... /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: Reducing the need to compile a custom kernel
On 10. Feb 2012, at 15:56 , Panagiotis Christias wrote: > On 10/2/2012 15:56, Alexander Leidinger wrote: >> Hi, >> >> during some big discussions in the last monts on various lists, one of >> the problems was that some people would like to use freebsd-update but >> can't as they are using a custom kernel. With all the kernel modules we >> provide, the need for a custom kernel should be small, but on the other >> hand, we do not provide a small kernel-skeleton where you can load just >> the modules you need. >> >> This should be easy to change. As a first step I took the generic kernel >> and removed all devices which are available as modules, e.g. the USB >> section consists now only of the USB_DEBUG option (so that the module is >> build like with the current generic kernel). I also removed some storage >> drivers which are not available as a module. The rationale is, that I >> can not remove CAM from the kernel config if I let those drivers inside >> (if those drivers are important enough, someone will probably fix the >> problem and add the missing pieces to generate a module). >> >> Such a kernel would cover situations where people compile their own >> kernel because they want to get rid of some unused kernel code (and >> maybe even need the memory this frees up). >> >> The question is, is this enough? Or asked differently, why are you >> compiling a custom kernel in a production environment (so I rule out >> debug options which are not enabled in GENERIC)? Are there options which >> you add which you can not add as a module (SW_WATCHDOG comes to my >> mind)? If yes, which ones and how important are they for you? > > Hello, > > we are currently using on every server (in order to maintain a single custom > kernel) the following options: > > IPFIREWALL IPFIREWALL_DEFAULT_TO_ACCEPT loadable, tunable there for this > IPFIREWALL_FORWARD > ROUTETABLES=n melifaro and I are working on this; he'll fix the netgraph netflow part and I'll fix the #ifdefs and the tunable will be enough. > Soon, we will also add: > > IPSEC IPSEC_FILTERTUNNEL IPSEC_NAT_T crypto enc IPSEC_FILTERTUNNEL has long been obsolete. > Finally, once we upgrade our jail setup VIMAGE will be also a must. I have read that multiple times already and I'd love to but that's a looong way. The plan might be to one day provide a 2nd kernel to install from and that freebsd-update can handle but we'll see. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: Reducing the need to compile a custom kernel
On 10. Feb 2012, at 13:56 , Alexander Leidinger wrote: > Hi, > > during some big discussions in the last monts on various lists, one of the > problems was that some people would like to use freebsd-update but can't as > they are using a custom kernel. With all the kernel modules we provide, the > need for a custom kernel should be small, but on the other hand, we do not > provide a small kernel-skeleton where you can load just the modules you need. > > This should be easy to change. As a first step I took the generic kernel and > removed all devices which are available as modules, e.g. the USB section > consists now only of the USB_DEBUG option (so that the module is build like > with the current generic kernel). I also removed some storage drivers which > are not available as a module. The rationale is, that I can not remove CAM > from the kernel config if I let those drivers inside (if those drivers are > important enough, someone will probably fix the problem and add the missing > pieces to generate a module). And you completely seem to have missed the discussion about a device ID DB and loader being able to probe and load them for you? With that sound, firewire, but also NICs and storage drivers can mostly go away... But it needs infrastructure... lots of ... feel free to resume that thread but stable@ is obviously the wrong place. > Such a kernel would cover situations where people compile their own kernel > because they want to get rid of some unused kernel code (and maybe even need > the memory this frees up). > > The question is, is this enough? Or asked differently, why are you compiling > a custom kernel in a production environment (so I rule out debug options > zhich are not enabled in GENERIC)? Are there options which you add which you > can not add as a module (SW_WATCHDOG comes to my mind)? If yes, which ones > and how important are they for you? As a lot of the results will show... various parts of the network stack being loadable, which is not as easy as it sounds, especially making them unloadable again currently ... /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: 9-stable from i386 to amd64
On 11. Feb 2012, at 05:48 , Doug Barton wrote: > On 02/10/2012 20:56, Randy Bush wrote: >> is there a recipe for moving from i386 to amd64? > > Other than backup and reinstall, no. As you already discovered the old > world won't run on the new kernel. Installing the new world before > reboot isn't safe either, as at some point in the process it'll blow up. heh? An i386 world should run (almost) fine on an amd64 kernel. I know people who have done that update (but I know of no one done it headless). One trick is to install to a swap partition boot that and then update the normal installation but you need to know what you are doing in that case as well. If you are very careful, that can be done headless - did a re-paritioning in a similar way lately. But in general it's all a gamble if not a streamlined process and no console. /bz PS: do you happen to know why the amd64 kernel did hang on boot? -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: CARP carpdev
On 14. Feb 2012, at 22:04 , Hugo Silva wrote: > On 02/14/12 17:33, Freddie Cash wrote: >> On Tue, Feb 14, 2012 at 8:56 AM, Hugo Silva wrote: >>> Looks like there's been conversations about porting this to FreeBSD since at >>> least 2007. >>> >>> Are there any plans to have ifconfig carpdev available in 9.0-STABLE? >> >> CARP support has been redone in 10-CURRENT, removing the whole "carp0" >> pseudo-interface support, and just enabling the CARP protocol on the >> existing network interfaces. This includes the equivalent of "carpdev" >> support. >> >> Search the -current archives for more information, CFT, and so on. >> >> I don't recall seeing anything about specific plans to MFC to >> stable/9, but could be mis-remembering things. >> > > > http://svnweb.freebsd.org/base?view=revision&revision=228571 > > The single IP limitation may be a problem in some locations.. > > Did not find anything about a possible MFC either. glebius@ is cc'd, perhaps > he can add something, but based on > http://svn.freebsd.org/base/stable/9/UPDATING, I don't think it's been MFCd > (there's a primer for the new carp in current's UPDATING)\ There's no plans to MFC given it changes things significantly. I however wonder if someone wants to provide a user branch in SVN to provide regular patchsets for stable/9 and maybe even stable/8 (8.3R) to help people not going to HEAD? -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: [CFT] modular kernel config
On 21. Feb 2012, at 13:35 , Alexander Leidinger wrote: > You can download from > http://www.Leidinger.net/FreeBSD/current-patches/ > The files are > - i386_SMALL > - i386_SMALL_loader.conf > - amd64_SMALL > - amd64_SMALL_loader.conf I only looked at the laoder.conf for amd64 and the only comment I have is that I do not have the time to wait minutes for all individual modules to be loaded. This is going to be really bad for boot time. > The new stuff in the kernel config compared to GENERIC is (in order of number > of requests from users): > - IPSEC (+ device enc + IPSEC_NAT_T) You cannot ship that on by default for non-tecnical reasons in a kernel. Please do not commit a kernel config that can be booted (no LINT cannot be booted) with these on without consulting appropriate hats upfront. > - ALTQ > - SW_WATCHDOG > - QUOTA > - IPSTEALTH (disabled in loader.conf) > - IPFIREWALL_FORWARD (touches every packet, power users which need > a bigger PPS but not this feature can recompile the kernel, > discussed with julian@) > - FLOWTABLE (disabled in loader.conf) Which is not the same as it's not 100% disabled and will still allocate memory. -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0
On 10. Mar 2012, at 08:07 , Adam Strohl wrote: > I've now seen this on two different VMs on two different ESXi servers (Xeon > based hosts but different hardware otherwise and at different facilities): > > Everything runs fine for weeks then (seemingly) suddenly/randomly the clock > STOPS. Apart from the ntp vs. openvm-tools thing, do you have an idea what "for weeks" means in more detail? Can you check based on last/daily mails/.. how many days it was since last reboot to a) see if it's close to a integer wrap-around or b) to give anyone who wants to reproduce this maybe a clue on how long they'll have to wait? For that matter, is it a stock 9.0 or your own kernel? What other modules are loaded? /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: BURN_BRIDGES & /usr/src/sys/netinet6/ip6_output.c:582: undefined reference to `in6_selectroute_fib'
On 12. Apr 2012, at 17:10 , Jason Hellenthal wrote: > > While attempting to burn bridges... yeah yeah I know, may include some > civil infractions ;) > > On stable/8 i386 Last Changed Rev: 234180 fresh build > > linking kernel.debug > ip6_output.o(.text+0x334f): In function `ip6_output': > /usr/src/sys/netinet6/ip6_output.c:582: undefined reference to > `in6_selectroute_fib' It's basically a marker to not use this function anywhere new in the stable/ branches. It will change in HEAD soon given the code has now been in for almost two months (in HEAD) without further needs to re-adjustment. I am not sure we ever allowed compiling with BURN_BRIDGES set but I can change the #ifndef to THIS_IS_PART_OF_THE_PUBLIC_STABLE_KPI or something if needed. See the comment above it: http://svnweb.freebsd.org/base/stable/8/sys/netinet6/in6_src.c?annotate=232552#l820 /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: Support for IPSec NAT-T in transoprt mode
On 13. Apr 2012, at 04:28 , Zmiter wrote: > Hello. > Does FreeBSD 8.[0-4] support IPSec NAT-T in transport mode? Or it's still in > broken state? It's not broken; it was never implemented. No FreeBSD tree shipped does support transport mode at this time. There are patches but you also need to fix ipsec-tools or your ike daemon. If you do the latter I can commit the former. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: Support for releases
On 27. Mar 2012, at 18:57 , Charles Sprickman wrote: > On Mar 27, 2012, at 2:25 PM, Brett Glass wrote: > >> Everyone: >> >> I've just noted that as of this month, there is no release of FreeBSD -- on >> any branch -- whose EOL is less than a year away. Should there not be at >> least one release with extended support? > > That will be 8.3: > > > • 20120205 - Ping SecurityOfficer about expected support for 8.3 > (BjoernZeeb). > • 20120205 - ACK from SecurityOfficer on extended support > (ColinPercival). > > > http://wiki.freebsd.org/Releng/8.3TODO Which was already mentioned in an earlier pre-release announcement. > I assume once it's released, this will be updated: > > http://www.freebsd.org/security/#sup Which it was yesterday along with the release. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: RELENG_8 still identifies itself as 8.3-PRERELEASE
On 22. Apr 2012, at 21:59 , Adrian Wontroba wrote: > A RELENG_8 system built this morning still identifies itself as > 8.3-PRERELEASE. > > Any chance of this becoming 8.3-STABLE soon? While this is entirely > cosmetic, it does cause me issues at $JOB. Fixed. -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: Jails can't get routing info
On 1. May 2012, at 19:41 , David Thiel wrote: > Hello, > > So, I've been trying to debug an issue running nmap scans within jails, > partially documented here: > > http://seclists.org/nmap-dev/2012/q2/220 > > On further debugging, it's seeming like jails can't read routing > information directly at all: > > # route get 69.163.203.254 > route: writing to routing socket: No such process > > Now, this is normally done via reading the routing table via something like > socket(PF_ROUTE, SOCK_RAW, AF_INET), so one would suspect that this is a > problem with raw sockets; but raw sockets are enabled within the jail. > netstat is able to read routing information just fine, but I don't think > it's doing it via the socket() call. hmm, sure you don't have /dev/mem in the jail? netstat -rn I think is still using libkvm *sigh* and not the sysctl API. > Anyone know why this behavior might be happening? Without thinking too much (as in if I got the right case) I think you are hitting this one: http://svnweb.freebsd.org/base/head/sys/net/rtsock.c?annotate=234572#l792 /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: Jails can't get routing info
On 2. May 2012, at 05:11 , Jason Hellenthal wrote: > On Tue, May 01, 2012 at 09:01:33PM +0000, Bjoern A. Zeeb wrote: >> On 1. May 2012, at 19:41 , David Thiel wrote: >> >>> Hello, >>> >>> So, I've been trying to debug an issue running nmap scans within jails, >>> partially documented here: >>> >>> http://seclists.org/nmap-dev/2012/q2/220 >>> >>> On further debugging, it's seeming like jails can't read routing >>> information directly at all: >>> >>> # route get 69.163.203.254 >>> route: writing to routing socket: No such process >>> >>> Now, this is normally done via reading the routing table via something like >>> socket(PF_ROUTE, SOCK_RAW, AF_INET), so one would suspect that this is a >>> problem with raw sockets; but raw sockets are enabled within the jail. >>> netstat is able to read routing information just fine, but I don't think >>> it's doing it via the socket() call. >> >> hmm, sure you don't have /dev/mem in the jail? netstat -rn I think is still >> using libkvm *sigh* and not the sysctl API. >> > > Good lord I hope this makes it down to stable/8 Pardon, what do you mean? > >> >>> Anyone know why this behavior might be happening? >> >> Without thinking too much (as in if I got the right case) I think you are >> hitting this one: >> >> http://svnweb.freebsd.org/base/head/sys/net/rtsock.c?annotate=234572#l792 -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: Support for IPSec NAT-T in transoprt mode
On 2. May 2012, at 18:50 , Zmiter wrote: > 24.04.2012 23:10, Andreas Longwitz ?: >> There is one limitation I would like to get over. From man 8 setkey: >> System that do not perform the port check cannot support multiple >> endpoints behind the same NAT. I think this is a FreeBSD kernel restriction: >> For the first incoming L2TP packet the IPSEC part of the kernel does not >> save the source port in the corresponding SA (maybe a field like >> natt_l2tp_port). So the kernel does for outgoing L2TP packets not know >> the correct SA, if two ore more SA's with the same IP exists. >> >> I would like to know if the patch mentioned in this thread adresses this >> problem. > Thank you very much for your attention. > I've been testing those patches (actually, without your part) and YES it's a > big problem with clients (Android, Windows Mobile) behind the same NAT. I > cannot find the solution yet, but I'm very interested in it. > So, my Androids is some sort of stupid bricks, they do not send NAT-OA > payloads at phase 2, and ipsec-tools fills the SPD with IPs taken from IDs. > But this is not the correct way. IDs contain LAN (which is behind the NAT) > addresses, and FreeBSD cannot route packets to the IPSec crypto part. > I've made some quick patching of IPSec tools to get my devices working, but I > don't know if they accomodate to the RFCs and ISAKMP. The main idea is to > take NAT-OAi and NAT-OAr addresses not from IDs when we are using NAT-T, but > from real source and destination addresses of the server and client NATs. > > Here is my ipsec-tools patch (i've call it patch-zz-local-2.diff and place at > /usr/ports/security/ipsec-tools/files with two other patches from kern > /146190) ... > It differs from that in kern/146190 in one simple thing. I have problems with > the original patch from kern/146190. When there was no NAT-OAi or NAT-OAr > values in the kernel space, checksums was calculated at 0, but they were not > ignored despite of the sysctl net.inet.esp.esp_ignore_natt_cksum value. The > improvement allows to ignore every checksum in esp packets when > net.inet.esp.esp_ignore_natt_cksum=1. Just replying to the last one -- you all need to make sure that this will work with a double-NAT (both i and r sitting behind a NAT) and not just i behind a NAT and r sitting there with a globally routable IP. The changes suddenly become a lot more complex. Just my 5cts. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: ntpd couldn't resolve host name on system boot
On 17. May 2012, at 15:03 , Matthew Doughty wrote: > Dear Jerermy, > > Whilst searching for a solution to a problem, I found your post: > http://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064350.html > > Please could you explain how I can implement the netwait script to solve > the problem? I'm new to freenas/BSD but am willing to try working from the > Cmd line. ntpd in head 9.0 and later and 8.3 and later should not exhibit that problem anymore as it was fixed. Could you please tell me if that is not the case? /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: ntpd couldn't resolve host name on system boot
On 18. May 2012, at 13:28 , Matthew Doughty wrote: > Hello Bjoern, > > It's still a problem for me. Here is a list of my system information: > > > Hostname freenas.local > FreeNAS Build FreeNAS-8.0.4-RELEASE-p1-x64 (11059) > Platform AMD Athlon(tm) II X2 250 Processor > Memory8144MB > System Time Fri May 18 09:07:22 2012 > Uptime 9:07AM up 6 mins, 0 users > Load Average 0.00, 0.21, 0.16 > OS VersionFreeBSD 8.2-RELEASE-p6 > > Are you refering to the OS version? 9.0 or 8.3? Looks like I'm using 8.2. Right, 8.2 didn't have the fix yet. Sorry. The newer onces might still complain at boot time that DNS cannot be found but will retry themselves, which the old versions (pre-fix) didn't do. Thus after a couple of minutes ntpdcs -c peers and ntpdc -c sysinfo should be good and the logging should stop. I would assume that a newer FreeNAS release will pick these things up automatically once they go to 8.3 or 9.0. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: Config ipv4 and ipv6 aliases
On 1. Jun 2012, at 09:29 , Thomas Krause wrote: > Hi, > > (I'm using FreeBSD 9.0-REL). > > ifconfig_em0_ipv6_alias0 doesn't work. I've to use > ifconfig_em0_alias0 for both ipv4 and ipv6. > This is not consequent. It is actually a lot more consistent now that way than it was ever before. The reason the "primary" entries are still different is that "DHCP" for IPv4 etc is special magic as is some automatic handling depending on ifconfig_IF_ipv6 is there or not to make your life easier. At least, as you can guess, I it this way a lot better. The rc.conf man pages has a couple of rough edges still but... > My working config > looks like this: > > ifconfig_em0="inet 192.168.100.50/28" > ifconfig_em0_ipv6="inet6 2a00:abcd:0:405::2/64" > > ifconfig_em0_alias0="inet 192.168.100.51/32" > ifconfig_em0_alias1="inet6 2a00:abcd:0:405::3/64" > > defaultrouter="192.168.100.49" > ipv6_defaultrouter="2a00:abcd:0:405::1" > > Please correct me, if there is a better solution. -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: 8.2 EoL Schedule?
On 8. Jun 2012, at 20:58 , Jason Helfman wrote:
> On Fri, Jan 13, 2012 at 12:00:53PM +0100, Gót András thus spake:
>> Hi,
>>
>> 8.3 is on the way IMHO, but anyway RELENG_8 will be supported until
>> 2013 febr 24, by the current status.
>>
>> Regards,
>> Andras
>
> But if RELENG_8_{1,2}, aren't updated then that would follow EOL, right?
> Meaning, they won't be updated past July 31, 2012, unless there is an
> extension.
>
> Any clarity would be great on this.
The current expected EOL dates are available at
http://www.freebsd.org/security/#sup
8.1 and 8.2 will drop out of security support July 31 this year, given
8.3 has been available for at least 3 months then. Also 8.3 is an
extended release supported until 2014.
/bz
--
Bjoern A. Zeeb You have to have visions!
It does not matter how good you are. It matters what good you do!
___
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"
Disturbance in IPv6 force in stable/9
Hey, after some back and forth and quite a few people asking me for it and having asked re@ I have merged the IPv6 offload changes to stable/9 today rather than after 9.1 as I had planned. I did not merge driver changes and I am expecting that one or two might follow-up, as will SCTP be following most likely. I'd be very happy if people could test this the next days (this week) if using IPv6 to make sure nothing breaks for them. The changes have been in HEAD for more than a month but who knows:) In case you find something broke due to these MFCs please yell at me, loudly! Thanks, Bjoern -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: selective jail restriction controlling in rc.conf
On Sat, 3 Jul 2010, Harald Schmalzbauer wrote: Hallo Harald, Harald Schmalzbauer schrieb am 03.07.2010 10:05 (localtime): ... One have to seperatly define ip4 and ip6 addresses. The can be with or without mask, single oder comma seperated list, doesn't matter, thanks to the jail_handle_ips_option() coder, it just works :) I forgot to change that in defults/rc.conf. Please find attached the corrected version. there is currently an ongoing discussion about jail configuration on the freebsd-jail@ mailing list: http://lists.freebsd.org/pipermail/freebsd-jail/2010-June/thread.html#1308 I think your comments (and patches) are better sent there, rather than to sta...@. Gruesse, Bjern -- Bjoern A. ZeebFrom August on I will have a life. It's now up to you to do the maths and count to 64. -- Bondorf, Germany, 14th June 2010 ___ 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: if_rtdel: error 47
On Tue, 31 Aug 2010, Mike Tancsa wrote: Hey Mike, On a RELENG_8 box from aug 25th, I started seeing a constant spew of Aug 31 00:17:46 gate8 kernel: if_rtdel: error 47 Aug 31 00:18:29 gate8 kernel: ifa_del_loopback_route: deletion failed Aug 31 00:18:29 gate8 kernel: if_rtdel: error 3 Aug 31 00:18:29 gate8 last message repeated 2 times Aug 31 00:18:37 gate8 kernel: ifa_del_loopback_route: deletion failed Aug 31 00:18:37 gate8 kernel: if_rtdel: error 3 Aug 31 00:18:37 gate8 last message repeated 2 times Aug 31 00:18:38 gate8 kernel: ifa_del_loopback_route: deletion failed Aug 31 00:18:38 gate8 kernel: if_rtdel: error 3 Aug 31 00:18:38 gate8 last message repeated 2 times What do they mean and how can I find the cause of it ? The box acts as an LNS with about 700 ng interfaces with mpd5.5. ipv6 is enabled on this server as well, so I am guessing it might be related to ipv6 as I havent seen it on the other LNS boxes that have the same setup, except no ipv6. It was happily running for a few days until this error started showing up ? I thought this was fixed already but maybe only in HEAD and not merged. I'll go and look. /bz -- Bjoern A. Zeeb This signature is about you not me. ___ 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: kernel panic when accessing /dev/tap0
On Wed, 1 Sep 2010, Frank Razenberg wrote: Hey, Robert Watson described a problem in this discussion: http://lists.freebsd.org/pipermail/freebsd-stable/2006-May/025880.html Currently I'm experiencing a similar problem, but on amd64 and FreeBSD 8.1 Release. Accessing /dev/tap0 instantly results in a kernel panic, so it's most likely if_tap related. Is this a known problem? I've started encountering it ever since I rebuilt my kernel with "options vimage". this is expected. I have a work in progress fix in perforce for most/all cloned interfaces. It's only a matter of extracting patches now but it'll be anohter few days till I'll get to that. /bz PS: freebsd-virtualization@ might be the better place to post VIMAGE problems. -- Bjoern A. Zeeb This signature is about you not me. ___ 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: I4B: what happened, which options? [was: Policy for removing working code]
On Thu, 9 Sep 2010, Kevin Oberman wrote: Hey, I think I should try to summarize parts of the ISDN topic, which I have been disconnected from for more than 2 years now, to make this tail of a thread more helpful maybe. I agree that later release notes could have mentioned it but neither did they mention that it was back and I cannot remember anyone complaining about netatm not coming back either until now, nor can I remember many complaints after freebsd 7.0 which was more than 2 years ago. I am Cc:ing freebsd-isdn@ as that list exists and has been for years. Check the archives for the overwhelming interest. If ISDN is in any way interesting to you, respect the Reply-To: The temporary disconnect was announced there (which is where the plan to bring it back came from): http://lists.freebsd.org/pipermail/freebsd-isdn/2007-July/000711.html There was a call for help (also with GSoC): http://lists.freebsd.org/pipermail/freebsd-isdn/2008-March/000833.html There was a notice that the code will be removed: http://lists.freebsd.org/pipermail/freebsd-isdn/2008-May/000842.html And there was an UPDATING entry with the removal: http://svn.freebsd.org/viewvc/base?view=revision&revision=179315 There was probably more but those were the once I found again within five minutes. So what are the options and what is out there now and there are a few, depending on your needs: 1) the FreeBSD Foundation is sponsoring a project currently: "DAHDI FreeBSD driver port" http://www.freebsdfoundation.org/project%20announcements.shtml#Max 2) I am (was) still running C4B on amd64 on RELENG_8 with a privately hacked together capi call log, which is a hack without me even thinking about capi (specs) when doing it, but was doing the job for me for 7 and 8. Getting the last C4B compiled for 8/HEAD or amd64 isn't a lot of patching and I can probably provide patches to you, if you want to make it a port. The PRIV constants needed for this in the base system have been shiping for a while: http://svn.freebsd.org/viewvc/base?view=revision&revision=192577 3) HPSI4B exists and he seems to maintain it. If you need old drivers for cards he doesn't support, talk to him if you want to use or are using his stack with other cards. 4) The old I4B code is still here and could be brought back from Attic if someone was to invest the resources (time, coding or money, ...). People tried back then but failed for ETIME. It's not only locking. The device drivers and layers are written in a RELENG_4ish way and my conclusion was that it'll end in a partial re-write. I still have cards and I still have a machine with ISA slots to test things. If someone fixes the infrastructure and 1 driver I'll also happily ship them so (s)he can do the others as well and test and maintain things for the next couple of years. Pick your poison;-) HTH /bz -- Bjoern A. Zeeb Welcome a new stage of life. ___ 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 terminate a lot of jails correctly
On Mon, 20 Sep 2010, S.N.Grigoriev wrote: thank you for your tip. The only drawback of that approche is absence of ability to calculate a timeout. Try and error only. Well, you could do a try-run just shutiing down all your jails by time sh /etc/rc.d/jail stop measuring the time it takes and maybe add a bit for extra safety? /bz -- Bjoern A. Zeeb Welcome a new stage of life. ___ 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: BIND9 built w/--disable-ipv6 on 8.1-STABLE
On Tue, 21 Sep 2010, Diane Bruce wrote:
|> | why don't we want IPv6 enabled by default on new BIND installations?
|>
|> It has to do with whether or not IPv6 support is compiled into the
|> FreeBSD base system which is compiling BIND. If the configure option
...
If I'm still alive when IPv6 is the norm and IPv4 is the exception, I
promise to give it another look. :)
IPv6 is more prevalent than you think. I can't understand the illogic
of turning it off.
Can't we just do what lib/bind/config.mk already does?
Index: usr.sbin/named/Makefile
===
--- usr.sbin/named/Makefile (revision 211503)
+++ usr.sbin/named/Makefile (working copy)
@@ -9,7 +9,10 @@ SRCDIR=${BIND_DIR}/bin/named
PROG= named
-CONFIGARGS='--prefix=/usr' '--infodir=/usr/share/info'
'--mandir=/usr/share/man' '--enable-threads' '--disable-ipv6'
'--enable-getifaddrs' '--disable-linux-caps' '--with-openssl=/usr'
'--with-randomdev=/dev/random'
+CONFIGARGS='--prefix=/usr' '--infodir=/usr/share/info'
'--mandir=/usr/share/man' '--enable-threads' '--enable-getifaddrs'
'--disable-linux-caps' '--with-openssl=/usr' '--with-randomdev=/dev/random'
+.if ${MK_INET6_SUPPORT} == "no"
+CONFIGARGS+='--disable-ipv6'
+.endif
# Optional features
.if ${MK_BIND_LARGE_FILE} == "yes"
and leave it to the user to build world without INET6 support if (s)he
build the kernel without it?
Thanks,
/bz
--
Bjoern A. Zeeb Welcome a new stage of life.
___
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: C4B for modern FreeBSD [was: I4B: what happened, which options? [was: Policy for removing working code]]
On Thu, 9 Sep 2010, Bjoern A. Zeeb wrote: Hi, 2) I am (was) still running C4B on amd64 on RELENG_8 with a privately hacked together capi call log, which is a hack without me even thinking about capi (specs) when doing it, but was doing the job for me for 7 and 8. Getting the last C4B compiled for 8/HEAD or amd64 isn't a lot of patching and I can probably provide patches to you, if you want to make it a port. The PRIV constants needed for this in the base system have been shiping for a while: http://svn.freebsd.org/viewvc/base?view=revision&revision=192577 having sent out the patch to the only person who requested it privately, I thought for later reference I should post it here as well: ! Allow the latest Capi4BSD from http://www.nord-com.net/thomas.wintergerst/ ! to compile on amd64 as well as modern FreeBSD versions without suser() ! or I4B support. http://people.freebsd.org/~bz/20101016-01-c4b-amd64-priv.diff I have done some late changed to get the __FreeBSD_version checks as correct as possible and it compiles on my FreeBSD HEAD/amd64 but I haven't tested it more. I used to use it for a simple call log in the past but not more either. If you give it a try, send me feedback! /bz -- Bjoern A. Zeeb Welcome a new stage of life. ___ 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: ifconfig, vnets and interface names
On Sun, 17 Oct 2010, Nikolay Denev wrote: Hello, While playing with vnet jails I've discovered the following oddity, which probably is not what's expected to happen : ... And that's what ifconfig shows after this : [16:52]r...@nas:/home/ndenev# ifconfig <... snip lo0 and physical interface ...> epair0a: flags=8842 metric 0 mtu 1500 ether 02:8c:53:00:03:0a epair1a: flags=8842 metric 0 mtu 1500 ether 02:b6:49:00:05:0a eth0: flags=8842 metric 0 mtu 1500 ether 02:8c:53:00:04:0b ether 02:b6:49:00:06:0b Instead of two interfaces, I'm seeing one with to lladdrs, because of the interface names being the same. Then I'm trying to destroy them : [16:52]r...@nas:/home/ndenev# ifconfig eth0 destroy [16:53]r...@nas:/home/ndenev# ifconfig <... snip lo0 and physical interface ...> epair1a: flags=8842 metric 0 mtu 1500 ether 02:b6:49:00:05:0a eth0: flags=8842 metric 0 mtu 1500 ether 02:b6:49:00:06:0b [16:53]r...@nas:/home/ndenev# ifconfig eth0 destroy So in this case there may be not a clean way to address one of the interfaces specifically (i.e. destroy only the second one)? I've not investigated further, but I'm thinking probably this is just a "bug" in ifconfig interpreting/parsing the information from the kernel. Maybe a solution is to extend ifconfig to be able print the interface list along with the ifIndex values and also manage the interfaces by index? Auto renaming also is also probably a possible solution (i.e. eth0_1 , eth0_2 ) as these are interfaces coming from destroyed vnet's and are not likely to be in use. (but still sounds scary :) ) It's actually a bug in sys/net/if.c:if_vmove* we know about and that's on the todo list. I am not sure when the behaviour of ifconfig changed as previousy it would only show you one of the two interfaces with the single ether address. ifconfig -l however had shown eth0 twice. Neither is really what one would expect thus needs changing. /bz PS: freebsd-virtualization@ is the best list to report "VIMAGE" or "vnet" related problems. -- Bjoern A. Zeeb Welcome a new stage of life. ___ 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: repeating crashes with 8.1
On Sat, 23 Oct 2010, Mike Tancsa wrote:
Hi all,
At 12:41 AM 10/23/2010, Jack Vogel wrote:
Odd, can you make any connection between this and the em complaints??
I dont think so.
neither do I think so. The initial issue
This is on an igb nic and a different panic/behaviour. I
have the box sitting at the debugger prompt in the FreeBSD netperf cluster,
so hopefully someone can take a look and see what is the issue.
Ok, and I seem to have another email telling me the machine;-)
>>>>> Oct 22 02:06:02 i4 kernel: em1: discard frame w/o packet header
>>>>> Oct 22 02:06:10 i4 kernel: em2: discard frame w/o packet header
is if_em(4) receiving a packet and then passing it up in em_rxeof()
by calling ifp->if_input ending up in
sys/net/if_ethersubr.c:ether_input() and there's an early check on
1) that the interface is up, and 2)
580 /*
581 * Do consistency checks to verify assumptions
582 * made by code past this point.
583 */
584 if ((m->m_flags & M_PKTHDR) == 0) {
585 if_printf(ifp, "discard frame w/o packet header\n");
586 ifp->if_ierrors++;
587 m_freem(m);
588 return;
589 }
So whatever mbuf if_em(4) is passing up here isn't setup correctly and
it sounds like the mbuf chaining logic or receive ring handling could
have a problem, though I doubt that em_refresh_mbufs() would be at
fault ... but I'll leave that to Jack.
For the following one, I hope to know the problem for it and am
working on fixing this already. This is most likely more new-arp
fallout and the last we currrently know of (despite some nd6 locking
problems which will need to be addressed separately and are under
discussion)
Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0x80740a50
stack pointer = 0x28:0xff85a890
frame pointer = 0x28:0xff85a930
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (swi4: clock)
[thread pid 12 tid 17 ]
Stopped at in6_cksum+0x410:movzwl (%rsi),%r10d
db> bt
Tracing pid 12 tid 17 td 0xff00025083e0
in6_cksum() at in6_cksum+0x410
icmp6_reflect() at icmp6_reflect+0x312
icmp6_error() at icmp6_error+0x1ec
nd6_llinfo_timer() at nd6_llinfo_timer+0x208
softclock() at softclock+0x2a6
intr_event_execute_handlers() at intr_event_execute_handlers+0x66
ithread_loop() at ithread_loop+0xb2
fork_exit() at fork_exit+0x12a
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff85ad30, rbp = 0 ---
db>
Mike, as you found that in a lab setup and I was never able to
reproduce any of the reports before, I'll send you a patch over
the weekend and we'll see if you can still reproduce it after
patching.
/bz
--
Bjoern A. Zeeb Welcome a new stage of life.
Going to jail sucks -- All my daemons like it!
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
___
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: Name and JID support in /etc/rc.d/jail and jail(8) documentation
On Sun, 24 Oct 2010, Spil Oss wrote: Hi, Created a small patch for 8.1 to add name support to /etc/rc.d/jail. This doesn't upgrade /etc/rc.d/jail to the overhauled invocation of 8.0 but merely adds the ability to set a jail's name on start which was added in FreeBSD 7.2 (May 2009). Could this patch be considered to be applied to stable? # diff -ruN /etc/rc.d/jail-8.1 /etc/rc.d/jail [snip] short answer: no 1) add -n to the defaults of jail__flags in rc.conf and be done just now. No need for a new variable. 2) you want to follow the new jail management on the freebsd-jail list. I would expect that there will just be no further changes to the rc script unless security related ones. On Sun, Oct 24, 2010 at 10:52 AM, Spil Oss wrote: Hi All, When starting a jail you can, as of 8.0 if I'm not mistaken, set the JID and name for a jail. This change doesn't seem to have been incorporated into the /etc/rc.d/jail script? Looking at http://wiki.polymorf.fr/index.php/Howto:FreeBSD_jail_vnet it wouldn't be a huge change to add name support. The other additions in that script look a lot more intrusive. Are there any plans to merge this patch into the jail rc-script or is this "v2" style of jail invocation still considered to be experimental? As of 8.1 is seems to no longer be considered experimental looking at the release notes. The new style version was never considered "experimental". It wasn't just not advertised that much due to the lack of 2) above. The jail(8) documentation (mine lists FreeBSD 8.1 January 17, 2010) seems to be missing documentation on the vnet command (due to the experimental status)? Right, vnets are still considered experimental. /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ 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: repeating crashes with 8.1
On Fri, 22 Oct 2010, Mike Tancsa wrote: Hi Randy, Mike, At 10:18 AM 10/22/2010, Randy Bush wrote: > Do you know how this panic is triggered ? Are you able to > create it on demand ? no i do not. bring server up and it'll happen in half an hour. and the server was happy for two months. so i am thinking hardware. Perhaps. The reason I ask is that I had a box go down last night with the same set of errors. The box has a number of ipv6 routes, but its next hop was down and the problems started soon after. So I wonder if it has something to do with that. Do you have ipv6 on this box and are all the next hop addresses correct / reachable ? Oct 22 02:06:02 i4 kernel: em1: discard frame w/o packet header Oct 22 02:06:10 i4 kernel: em2: discard frame w/o packet header Oct 22 02:06:21 i4 kernel: em1: discard frame w/o packet header Just a shot in the dark, as I got another private report just now on this one; is any of you by chance running VLANs on the systems you see this happening? /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ 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: option DDB broken between r214547 - r214596
On Sun, 31 Oct 2010, David Wolfskill wrote: Hi, On one of my machines, I've been having some issues such that I adjusted the kernel config to include some debugging options: options KDB options KDB_TRACE options KDB_UNATTENDED options DDB options DDB_NUMSYM options GDB options DEBUG_REDZONE Now, I actually build for the system in question on my build machine (which builds a GENERIC kernel for itself, as well as kernels for the above-mentioned machine and another). This morning, it was running FreeBSD 8.1-STABLE r214547, building 8.1-STABLE r214596. The GENERIC build succeeded, and went on to the kernel "ALBERT". That failed, thus: ... stage 3.2: building everything ... cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/net/if_debug.c /usr/src/sys/net/if_debug.c: In function 'if_show_ifnet': /usr/src/sys/net/if_debug.c:65: error: 'struct ifnet' has no member named 'if_index_reserved' *** Error code 1 That would be mine though a universe had successfully completed with the merge. I'll go and look. /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ 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: option DDB broken between r214547 - r214596
On Sun, 31 Oct 2010, Bjoern A. Zeeb wrote: Hi David, Now, I actually build for the system in question on my build machine (which builds a GENERIC kernel for itself, as well as kernels for the above-mentioned machine and another). This morning, it was running FreeBSD 8.1-STABLE r214547, building 8.1-STABLE r214596. The GENERIC build succeeded, and went on to the kernel "ALBERT". That failed, thus: ... /usr/src/sys/net/if_debug.c /usr/src/sys/net/if_debug.c: In function 'if_show_ifnet': /usr/src/sys/net/if_debug.c:65: error: 'struct ifnet' has no member named 'if_index_reserved' *** Error code 1 That would be mine though a universe had successfully completed with the merge. I'll go and look. I still had the stable/8 LINT + 4 more different LINT configs all including DDB build logs form yesterday on ref8; none had an error though it was obviously there. I have no clue but that a KERNFAST build might not have cought it if this wasn't my first change to build test. It should be fixed with r214602. Thanks a lot for the report. /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ 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: repeating crashes with 8.1
On Sat, 23 Oct 2010, Bjoern A. Zeeb wrote:
Hi,
just to get this out. Jack you might want to review and if ok, include
in HEAD before we get feedback maybe. To my understanding worst it
would be overhead but not really harm.
>>>>> Oct 22 02:06:02 i4 kernel: em1: discard frame w/o packet header
>>>>> Oct 22 02:06:10 i4 kernel: em2: discard frame w/o packet header
The following is a random-guess by code reading that hasn't been tested
yet but believed to be correct; also ran it by gnn.
http://people.freebsd.org/~bz/20101122-03-em-pkthdr.diff
--- sys/dev/e1000/if_em.c.orig 2010-11-01 20:57:53.0 -0400
+++ sys/dev/e1000/if_em.c 2010-11-16 01:28:00.0 -0500
@@ -3754,8 +3769,13 @@ em_refresh_mbufs(struct rx_ring *rxr, in
** they can only be due to an error
** and are to be reused.
*/
- if (rxbuf->m_head != NULL)
+ if (rxbuf->m_head != NULL) {
+ rxbuf->m_head->m_len = rxbuf->m_head->m_pkthdr.len =
adapter->rx_mbuf_sz;
+ rxbuf->m_head->m_flags |= M_PKTHDR;
+ rxbuf->m_head->m_data = rxbuf->m_head->m_ext.ext_buf;
+ rxbuf->m_head->m_next = NULL;
goto reuse;
+ }
m = m_getjcl(M_DONTWAIT, MT_DATA,
M_PKTHDR, adapter->rx_mbuf_sz);
/*
I am not sure if igb and the others need a similar fix. Haven't
looked in detail. gnn mentioned similarities though good ones imho
in there.
If you were able to reproduce the pkthdr issue it would be great to
test it. If you always paniced it with IPv6 you may also want to test
the applicable patch (use the direct URLs mentioned) from the very end of
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/148857
to make sure you are not running into that race.
/bz
--
Bjoern A. Zeeb Welcome a new stage of life.
Going to jail sucks -- All my daemons like it!
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
___
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: tcp_do_segment....again
On Sun, 26 Oct 2008, Jose Amengual wrote: Hi, The problem persist even in stable 7.0, 7.1-PRERELEASE and 7.0-P5 , the postfix jail is living all the email in defer queue saying "Connection Time Out" This server give service to 300 clients and the network load os high. is there any clue how to resolve this ? sorry if I am not reading back various links which include mails I had sent which are entirely unrelated. So you are seeing TCP problems. And you are running with a firewall enabled? Have you tried tcpdumping and seeing what exactly goes wrong? do you have any offload stuff enabled (as the subject suggests)? If so what happens if you disable this? /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.x and multiple IPs in jails
On Tue, 28 Oct 2008, Charles Sprickman wrote: Hello all, I've been searching around and have come up with no current discussions on this issue. I'll keep it brief: In 7.0 or 7.1 is there any provision to have multiple IP addresses in a jail? Subscribe to the freebsd-jail mailinglist and check the archives. You'll find patches there. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.x and multiple IPs in jails
On Tue, 28 Oct 2008, Michael Butler wrote: Lorenzo Perone wrote: Hi, there's a patch by Bjoern A.Zeeb, available at http://people.freebsd.org/~bz/bz_jail7-20080920-01-at150161.diff which succeeds and works well with 7.1-PRERELEASE currently. I had similar issues to solve and patched several hosts with it, so far with success. Bjoern has made an excellent work in patching all relevant parts, so you'll be able to use the stock rc.d/jail script as well as having an updated manpage and a jls -v which shows all the IPs while preserving compatibility with scripts making assumptions on the usual jls output. Please see the freebsd-jail mailing list archives of the last weeks and months for more info. I hope very much that these patches will be included officially in RELENG_7 soon. This seems to imply that, at last, IPv6 addresses can be used in jails - is that true? yes -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.x and multiple IPs in jails
On Tue, 28 Oct 2008, Chris St Denis wrote: Hi, [ jail patches ] Serious question here (not trolling). These patches have been around for years, why have they never been committed to trunk/stable? Well, the multi-ipv4 patch has been for a while - what we are talking about at the moment is more. If you look at older status reports they said soemthing like "there is the need for this at the moment but it's not considered to be the right thing". There are multiple reasons for that, that I can think of: 1) some larger parts (of the network stack|kernel) get plastered with all kinds of if (this) if (that) checks complicating code, making it unreadbale, having to be maintained, not ignored for security, ... It's important to really catch all the places, .. which it seems we had been doing well though not 100% well as I just found out currerntly preparing more if (this) if (that) checks for something not really important but still being a problem - since the first day it turns out. 2) there is questionable logic in them and while we had been living with it up to now, it came up during review process for the commit to HEAD (so it could be merged to stable) and it turns out that properly solving it isn't a easy or simple task and multiple people have been pondering over this for days now. Even after removing some optional code paths for simplicity things are still not always definite in what would happen. 3) Nonetheless they are very helpful and very usable (else I wouldn't have worked on it). The plan as the status report will say is to get this in, merge it to stable/7 before 7.2 and keep it in 8. 8 will also have vimages and ideally I'd like to see this entire jail IP hacks be gone for 9, when vimage will provide the infrastructure, etc. This means that 8 would be the transition period. But that's just me and my ideas - we'll see how it'll go. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.x and multiple IPs in jails
On Thu, 30 Oct 2008, Michael Butler wrote: Hi, Hi, there's a patch by Bjoern A.Zeeb, available at http://people.freebsd.org/~bz/bz_jail7-20080920-01-at150161.diff which succeeds and works well with 7.1-PRERELEASE currently. I had similar issues to solve and patched several hosts with it, so far with success. Sadly, SVN rev 184481 (of today) breaks these patches :-( Is there an updated patch-set available or planned? I wonder if that was one of my MFCs - I guess so. One of the reasons I am doing those MFCs is to keep the diff between HEAD and 7 down to a minimum so that I have to ship less patches integrated into the jail patch for 7. So yes the plan is to finish the MFCs and generate a new patch for 7 the next days (most likely beginning of next week). Regards, Bjoern -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.3 gre and traceroute
On Fri, 14 Nov 2008, Robert Noland wrote: Hi, Also just using gre's without the underlying ipsec tunnels seems to work properly. The reason for this to my knowledge is: http://www.kame.net/dev/cvsweb2.cgi/kame/freebsd2/sys/netinet/ip_icmp.c#rev1.4 or looking at recent freebsd code: http://fxr.watson.org/fxr/source/netinet/ip_icmp.c#L164 Look for M_DECRYPTED. Now what happens in your case: you receive an IPSec ESP packet, which gets decryped, that sets M_DECRYPTED on the mbuf passes through various parts, gets up to gre, gets decapsulated is an IP packet (again) gets to ip_input, TTL expired, icmp_error and it's still the same mbuf that originally got the M_DECRYPTED set. Thus the packets is just freed and you never see anything. So thinking about this has nothing to do with gre (or gif for example as well) in first place. It's arguably that passing it on to another decapsulation the flag should be cleared when entering gre() for example. The other question of course is why we do not send the icmp error back even on plain ipsec? Is it because we could possibly leak information as it's not caught by the policy sending it back? /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hangs for 7.1-PRE [was: problem possibly related to multi-ip jail patch?]
On Sun, 16 Nov 2008, Lorenzo Perone wrote: Hi, I've been experiencing problems with one of the machines running FreeBSD 7.1-PRERELEASE #2: Thu Oct 16 20:23:09 CEST 2008 with the multi-ip patch bz_jail7-20080920-01-at150161.diff, and I'm wondering if it possibly related to the patch - in any case, any advice would be very welcome. bottom line is that most of this looks less likely to be a jail problem. It happens that mysql (tried both 4.0 and 5.1, in 2 separate jails), at some time stop responding to connections, and mysql gets stuck in sbwait state. It is only killable with kill -9 Yeah, I had been seeing mysql hang or go to 99% CPU for years once in a while; it's been more rare the last months. I have seen it in- and outside of jails, with or without patches. You could try to see if you can get backtraces of those processes. each of the two mysqlds is running in a jail on one private IP, serving connections to a webserver nearby - the latter having one public and one private IP, communicating with the other jail via the private network. I also experienced two complete system hangs (which must not be necessarily related to the mysql problem) both during a shutdown -r now. one was a panic, in another case the machine was still pingable but did not shut down completely. I could only reset it over the DRAC. here's a screenshot I made over the Dell RAC: http://lorenzo.yellowspace.net/stuck.png Looking at your image I see more problems before the shutdown so this as well is most likely not a jail problem. Since I'm also using zfs there and the kernel has been built with the DTRACE options. any advice (also about which more details that I should/could provide) would be very welcome... I am Cc:ing the answer to stable@ and setting reply-to: to move the discussion there. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ifconfig(8) interface description field
On Tue, 18 Nov 2008, cpghost wrote: On Tue, Nov 18, 2008 at 10:34:24AM +0100, [EMAIL PROTECTED] wrote: 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. Yes, that's a very useful addition. I'm administering a lot of Cisco boxes, and this desc field has been extremely useful over the years. Maybe an ifi_desc field could be added to: /usr/src/sys/net/if.h:struct if_data and some glue so that ifconfig(8) can read and write to it? How long should this field be at most? This is nothing the really belongs in the kernel. Add an "interface" to set/get the information per interface (index, name, ...) and store the actual data in a file maybe. Make the format extensible to store other meta data that people may want to think along with it in the future. After all you want the information to be peristent over a reboot so you have to write it out somehow anyway. Just my 0.02CAD /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ifconfig(8) interface description field
On Tue, 18 Nov 2008, cpghost wrote: Hi, On Tue, Nov 18, 2008 at 02:23:05PM +0100, cpghost wrote: On Tue, Nov 18, 2008 at 12:07:32PM +, Bjoern A. Zeeb wrote: On Tue, 18 Nov 2008, cpghost wrote: On Tue, Nov 18, 2008 at 10:34:24AM +0100, [EMAIL PROTECTED] wrote: 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. Yes, that's a very useful addition. I'm administering a lot of Cisco boxes, and this desc field has been extremely useful over the years. Maybe an ifi_desc field could be added to: /usr/src/sys/net/if.h:struct if_data and some glue so that ifconfig(8) can read and write to it? How long should this field be at most? This is nothing the really belongs in the kernel. Add an "interface" to set/get the information per interface (index, name, ...) and store the actual data in a file maybe. Make the format extensible to store other meta data that people may want to think along with it in the future. After all you want the information to be peristent over a reboot so you have to write it out somehow anyway. Yes, but some interfaces are created on-the-fly, and you never know in advance which name they'll get (think of tunN, ngN etc...). If those interfaces are meant to be queried frequently (every few minutes or so) by an snmpd, wouldn't it be more inefficient to check an external file than get the meta data from the kernel? Some network management apps could also decide to use the description field as a repository for more dynamic data; data that could be queried by applications running on the hosts. Here too, would'nt it be more efficient if descr. were in-kernel? For persistence, an /etc/rc.d script could always set the static interface descriptions via ifconfig calls any way it likes, including reading those definitions from a config file. Everything else will probably be set remotely via the network management software, which itself has its own persistence store (usually a database). Another reason you want to avoid using a file for this: what about appliances that run as dedicated routers and boot from a flash-based read-only filesystem? How would you change the interface description (remotely or on the console) if you can't write to a file? So how would you make it persistent across a reboot if you cannot write it anywhere? Regards, Bjoern -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPv6 routing on 7.1R
On Mon, 12 Jan 2009, Hiroki Sato wrote: Hi, I noticed an odd behavior regarding IPv6 after upgrading my 7.0R box to 7.1R. The situation and symptom are the following: 1. The box has two NICs. One has an address 2001:0db8:1::1/64 (NIC A), and another has 2001:0db8:2::1/64 (NIC B). These addresses are assigned manually ($ipv6_ifconfig in rc.conf). 2. RA is periodically sent to the network 2001:0db8:1::1/64 (NIC A) by a router on the subnet. The RA includes a source link-layer address option only. When setting net.inet6.ip6.accept_rtadv=1 in this configuration, I expected the box assigns an autoconf IPv6 address (prefix 2001:0db8:1::/64 + EUI64) to NIC A and an default route based on source link-layer address in the RA packet. Actually, these two were done as expected. However, after addresses are assigned, routes for NIC B disappeared from the routing table. More specifically, a cloning route "2001:0db8:2::1/64 -> link#2" was removed for some reason. Is this an expected behavior? I don't think so. Can you file a PR and get it assigned to bz@ and I'll look in two weeks or so once I am fully back. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. ___ 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"
HEADS UP: multi-IPv4/v6/no-IP jails merge to 7-STABLE ahead
Hi, I have a possible MFC candidate patch at: http://people.freebsd.org/~bz/20090128-02-jail7-mfc.diff to merge the multi-IPv4/v6/no-IP jails to 7-STABLE. My plan would be to do so during the weekend of 6-8th February 2009. In addition to what the patch says at the beginning (__FreeBSD_version bump), the patch also has the regenerated compat/freebsd32 sysctl stuff in it so that people can apply, compile and run it directly. For the merge this would be a second commit. For committers who want to review that I have done the merge right, it is an svn diff with mergeinfo included. For details about the patch, features, .. see the original commit message and follow-up a few days later (both in one post): http://lists.freebsd.org/pipermail/freebsd-jail/2008-December/000631.html Since then a few bug fixes went in, some older PRs were handled, ... Now is the time for you to try and review it for 7-STABLE, etc. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. ___ 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: HEADS UP: multi-IPv4/v6/no-IP jails merge to 7-STABLE ahead
On Wed, 28 Jan 2009, Bjoern A. Zeeb wrote: Hi, I have a possible MFC candidate patch at: http://people.freebsd.org/~bz/20090128-02-jail7-mfc.diff to merge the multi-IPv4/v6/no-IP jails to 7-STABLE. My plan would be to do so during the weekend of 6-8th February 2009. In addition to what the patch says at the beginning (__FreeBSD_version bump), the patch also has the regenerated compat/freebsd32 sysctl stuff in it so that people can apply, compile and run it directly. For the merge this would be a second commit. For committers who want to review that I have done the merge right, it is an svn diff with mergeinfo included. For details about the patch, features, .. see the original commit message and follow-up a few days later (both in one post): http://lists.freebsd.org/pipermail/freebsd-jail/2008-December/000631.html Since then a few bug fixes went in, some older PRs were handled, ... Now is the time for you to try and review it for 7-STABLE, etc. One more thing that I had forgotten and was pointed at: sys/kern/kern_jail.c includes the __FBSDID() line. I just manually edited the patch to contain the proper CVS (not SVN) value. You may a) want to check that things apply cleanly and/or b) to sure to manually apply the hunk from the .rej. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. ___ 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: HEADS UP: multi-IPv4/v6/no-IP jails merge to 7-STABLE ahead
On Mon, 2 Feb 2009, Mike Tancsa wrote: At 10:22 AM 1/28/2009, Bjoern A. Zeeb wrote: Hi, I have a possible MFC candidate patch at: http://people.freebsd.org/~bz/20090128-02-jail7-mfc.diff Hi Bjoern, Will this patch allow for the creation of tun interfaces inside of a jail ? Ideally I was hoping to run OpenVPN inside various jails which uses the tun device. Nope, you'll have to wait for vimages for that. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. ___ 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"
HEADS UP: multi-IPv4/v6/no-IP jails now in 7-STABLE
Hi, what has started a long time ago with patches from various people, was started, abandoned, resumed finally found an end. I am happy to hereby announce that the multi-IPv4/v6/no-IP jails work has been merged to 7-STABLE and thus can be used in FreeBSD 7 without the need to maintain or apply patches from now on. This also means that the updated jails will be included in 7.2 release. This update gives you (short selection): - zero, one or multi-IP jails. - IPv4 and IPv6 support. - cpuset support for jails. - jail names and states to ease administration. - 32bit compat on 64bit, jail v1 compat, .. You'll find a longer summary about all the new features and how to use them in a posting from December (you should really read it): http://lists.freebsd.org/pipermail/freebsd-jail/2008-December/000631.html Since the above posting, multiple PRs had been addressed and fixes include - SIOCGIFADDR ioctl handling which fixes the "samba inside jails problem" - no more arp and ndp information disclosure - updated rc.conf framework (fully backward compatible in 7), see man 5 rc.conf and /etc/defaults/rc.conf. - various documentation/man page updates - ... I'd like to thank everyone who had helped to make this possible! If you like the work, mayhap even use it for your business, or just want to support FreeBSD, you may want to visit http://www.freebsdfoundation.org/ and help donating some money. Enjoy your new jails! (and don't try to escape - you sure won't succeed;) /bz -- Bjoern A. Zeeb The greatest risk is not taking one. ___ 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"
make installkernel broken
Hi, I merged a change I had tested in my working but not a vanilla stable/7 tree. This broke make installkernel. I am currently investigating if it's easily fixable w/o side effects or I'll back it out in a bit. If your sys/conf/kern.post.mk has r188288 (from 14:55:29 UTC) you are affected by this. I'll let you know once it is fixed. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. ___ 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: make installkernel broken
On Sat, 7 Feb 2009, Bjoern A. Zeeb wrote: Hi, I merged a change I had tested in my working but not a vanilla stable/7 tree. This broke make installkernel. I am currently investigating if it's easily fixable w/o side effects or I'll back it out in a bit. If your sys/conf/kern.post.mk has r188288 (from 14:55:29 UTC) you are affected by this. I'll let you know once it is fixed. With r188296 (21:07:58 UTC) things should be fine again. In case you hit the problem you can use make installkernel KMODOWN=root KMODGRP=wheel as a workaround. In case you experience any problems/side efffects from the fix, let me know immediately. Sorry for the breakage. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. ___ 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"
"The LOR page" is back
Hi, in case you find a LOR, want to report it or want to see if it's known or find out more about it... you can go and check "The LOR page" again. It's up on a temporary setup (so in case it's not avail come back a bit later) until I can finally move the web elsewhere. The URL has stayed the same: http://sources.zabbadoz.net/freebsd/lor.html The page has a few instructions and links to further information. You may want to read them before doing anything else to help everybody. Thanks! /bz -- Bjoern A. Zeeb The greatest risk is not taking one. ___ 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"
HEADS UP: removal of PECOFF support in RELENG_[67]
Hi, I'd like to give you a heads up that I intend to also remove PECOFF support from the stable/7 and stable/6 branches. PECOFF support is non-working and unmaintained in those FreeBSD releases and has lately still seen public security problems. PECOFF support is already gone in the upcoming 8.0 RELEASE or the 9-CURRENT development branch. Should no valid complaints come up saying that someone needs (and actively uses *cough* PECOFF support on FreeBSD it'll be removed earliest Novemeber 29th 2009 00:00 UTC (in about one week). /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ 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: Jails working differently in FreeBSD-8
On Mon, 14 Dec 2009, Nathan Butcher wrote: Jails appear to be working differently in 8.0 compared with 7.x (due to the networking changes in 8 most likely). Anyway, I've created a jail in 8.0 and given it it's own IPv4 IP address. Problem is, when I attempt to SSH to this jail IP address, I'm arriving in the host environment, and not the jailed environment. In 7.x I would have landed inside the jail so what's going on in 8? Hopefully someone who has already solved this issue can help me out a bit. It may sound silly but can you confirm that sshd is running inside the jail? Also, how did you start the jail? jls -av output might be interesting. /bz PS: there is a freebsd-jail list as well. -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ 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: pkg_add thinks that -STABLE is -RELEASE (wrong __FreeBSD_version?)
On Sun, 3 Jan 2010, pluknet wrote: Hi, 2010/1/2 Paride Legovini : Hi, I'm running 8.0-STABLE and I noticed that by default pkg_add -r uses packages-8.0-release/Latest/ as PACKAGESITE. I read in the handbook[1] that pkg_add should use packages-5-stable/Latest/ as PACKAGESITE when one is running -STABLE. I took a look at the source code, and noticed that pkg_add considers the system -STABLE if getosreldate() (i.e. __FreeBSD_version) is between 800500 and 899000 (see src/usr.sbin/pkg_install/add/main.c:92). However, in RELENG_8, __FreeBSD_version is set to 800108. You can check it via cvsweb[2]. Sounds like something is wrong. Am I missing something? Do I just have to wait for the __FreeBSD_version to be bumped? Hi. I'm afraid that's because __FreeBSD_version wasn't bumped 800107->800500 in RELENG_8 just after RELENG_8_0 created (wrt changes in scheme for RELENG_8 timeframe where current/stable border moved to 800500: http://lists.freebsd.org/pipermail/svn-src-head/2009-June/007830.html It continued then as is (still ok), and eventually was incremented to 800108 (wrong here, though I hope it still can be safely corrected). I have just bumped the version on stable/8 so it should be fine now. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ 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: IPSec NAT-T in transport mode
On Fri, 22 Jan 2010, Nat Howard wrote: I'm very interested in this problem -- I want to run an L2TP server myself. Is anyone actually working on this? I might be able to chip in a few bucks... But I'm not seeing bad checksums. Here's my setup: L2tp server A<>B Freebsd NAT box C <---internal network--->D my mac Where should I be seeing the bad checksums? A, B, C, or D? Looking only at B, I don't see any bad udp checksums, but I'm seeing a bunch of these (IP numbers changed to bracketed names): This doesn't say if you are using IPsec but I will asume so, that would mean that you D "my mac" would initiate the connection and the A node "L2tp server" would then be the other end. If that's a FreeBSD box as well, you should check statistics there. The NAT gateway in between has nothing to do with this, only the IPsec ends. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ 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: 8.0-RELEASE -> -STABLE and size of /
On Fri, 22 Jan 2010, Oliver Brandmueller wrote: Hi, I just noticed somthing: I setup an 8.0-RELEASE amd64 box, / is default 512M. First step after setup was to csup to RELENG_8 and buildkernel and buildworld (no custom kernel, no make.conf). Instaling the new kernel failed, since /boot/kernel/ is already well over 230 MBytes in size. moving that to kernel.old and writing a new one with about the same size fails due to no space left on device. Replying to the first post in the thread. One first thing to help people to avoid problems with future upgrades could be to just make / 1G: http://people.freebsd.org/~bz/20100124-03-sysinstall-root-1g.diff Another entirely untested patch would compress the symbol files: http://people.freebsd.org/~bz/20100124-04-kernel-compress-symbols.diff It would be interesting to see if (a) they work and (b) how much the latter would safe. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ 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: Panic on 8-STABLE in pfctl with options VIMAGE on a DELL PowerEdge R300 (bge)
On Fri, 26 Feb 2010, Lorenzo Perone wrote: Hi, While I was just planning to experiment with VIMAGE, and it is not required for production (I'm aware of the message of it being experimental...), I thought it might be useful to report it. Please send me a note if I should file a pr. The panic does not occur with the same kernel compiled without options VIMAGE. FAQ from virtualization@ ; pf support for VIMAGE only basically exists here: http://svn.freebsd.org/base/user/eri/pf45/head/ but is not fully ready either. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ 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: panic during work with jailed postgresql8.4
On Thu, 1 Apr 2010, Oleg Lomaka wrote: Hi, I have a kernel panic when connect to postgresql8.4 server installed in one of jails from another jail. It's 100% reproducible. Also I have tried to connect from host machine to jailed pg server. That way it works fine without crash. Server configuration uses geli and zfs. Four disks encrypted using geli. And raidz2 is using ad8.eli, ad10.eli, ad12.eli, ad14.eli providers. All jails located at this raidz2 pool. Also I use ezjail for jails management. And it uses NFS to mount directories with base system. atal double fault rip = 0x8063510a rsp = 0xff80eaec5f50 rbp = 0xff80eaec6040 cpuid = 1; apic id = 02 panic: double fault cpuid = 1 Uptime: 7m11s Physical memory: 8169 MB uname -a FreeBSD cerberus.regredi.com 8.0-STABLE FreeBSD 8.0-STABLE #7 r206031: Thu Apr 1 13:43:57 EEST 2010 r...@cerberus.regredi.com:/usr/obj/usr/src/sys/GENERIC amd64 Link to dmesg.boot: http://docs.google.com/leaf?id=0B-irbkAqk9i7OGY2ZWJiODgtOWJmMy00NDQ1LTliZDctZjU3N2YwNmMxNjZl&hl=en Link to kernel core backtrace: http://docs.google.com/Doc?docid=0AeirbkAqk9i7ZGc5Yzc2ZndfM2M4NzYydmRw&hl=en Can I help to spot this trouble by providing additional info? Looking at the info I doubt it's related to jails or Pg in first place. Have you been running that same setup already before your Apr 1st, r206031, kernel? If so, from when was your last kernel? /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ 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: panic during work with jailed postgresql8.4
On Fri, 2 Apr 2010, Oleg Lomaka wrote: Hey, uname -a FreeBSD cerberus.regredi.com 8.0-STABLE FreeBSD 8.0-STABLE #7 r206031: Thu Apr 1 13:43:57 EEST 2010 r...@cerberus.regredi.com:/usr/obj/usr/src/sys/GENERIC amd64 Link to dmesg.boot: http://docs.google.com/leaf?id=0B-irbkAqk9i7OGY2ZWJiODgtOWJmMy00NDQ1LTliZDctZjU3N2YwNmMxNjZl&hl=en Link to kernel core backtrace: http://docs.google.com/Doc?docid=0AeirbkAqk9i7ZGc5Yzc2ZndfM2M4NzYydmRw&hl=en Can I help to spot this trouble by providing additional info? Looking at the info I doubt it's related to jails or Pg in first place. Have you been running that same setup already before your Apr 1st, r206031, kernel? If so, from when was your last kernel? Yes, this configuration works on another server fine (8.0-STABLE FreeBSD 8.0-STABLE #3 r205202) Made few more tests. All tests I make using psql command (as it is 100% reproducible, may be now try spot it using telnet/netcat, without involving pg). psql accomplish login operation fine, panic appears after i run any command like \d, so I think it depends on packet size. Current picture is: 1. When connect from host machine - works fine. 2. When I connect from other server - works fine. 3. When connect from another jail on the same box as db's jail (tried from few jails) - kernel fault. Also tried security.jail.allow_raw_sockets on/off - nothing changes. In addition to the private mail I have just sent you, the first thing you might try it to updat again; I hadn't realized before that your r206031 seems to be in the middle of a multi-commit merge from two people. It would be worth to update to the latest stable/8 and try again first. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ 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 7.3, reboot after panic: double fault
at tcp_offload.h:269 #54 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #55 0xc08fdcf8 in tcp_usr_send (so=0xc2ac1820, flags=0, m=0xc270ed00, nam=0x0, control=0x0, td=0xc28e2d80) at tcp_offload.h:269 #56 0xc0850405 in sosend_generic (so=0xc2ac1820, addr=0x0, uio=0xc28766c0, top=0xc270ed00, control=0x0, flags=0, td=0xc28e2d80) at /usr/src/sys/kern/uipc_socket.c:1243 #57 0xc084bf7f in sosend (so=0xc2ac1820, addr=0x0, uio=0xc28766c0, top=0x0, control=0x0, flags=0, td=0xc28e2d80) at /usr/src/sys/kern/uipc_socket.c:1285 #58 0xc0833c5b in soo_write (fp=0xc28e84c0, uio=0xc28766c0, active_cred=0xc28e5900, flags=0, td=0xc28e2d80) at /usr/src/sys/kern/sys_socket.c:103 #59 0xc082d2e7 in dofilewrite (td=0xc28e2d80, fd=24, fp=0xc28e84c0, auio=0xc28766c0, offset=-1, flags=0) at file.h:257 #60 0xc082d5c8 in kern_writev (td=0xc28e2d80, fd=24, auio=0xc28766c0) at /usr/src/sys/kern/sys_generic.c:402 #61 0xc082d816 in writev (td=0xc28e2d80, uap=0xccf6fcfc) at /usr/src/sys/kern/sys_generic.c:388 #62 0xc0a7f2d5 in syscall (frame=0xccf6fd38) at /usr/src/sys/i386/i386/trap.c:1101 #63 0xc0a636a0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:262 #64 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) (kgdb) quit tcp_output() calls tcp_mtudisc() if ip_output() returns EMSGSIZE: case EMSGSIZE: /* * For some reason the interface we used initially * to send segments changed to another or lowered * its MTU. * * tcp_mtudisc() will find out the new MTU and as * its last action, initiate retransmission, so it * is important to not do so here. * * If TSO was active we either got an interface * without TSO capabilits or TSO was turned off. * Disable it for this connection as too and * immediatly retry with MSS sized segments generated * by this function. */ if (tso) tp->t_flags &= ~TF_TSO; tcp_mtudisc(tp->t_inpcb, 0); return (0); But tcp_mtudisc() calls tcp_output(): tcpstat.tcps_mturesent++; tp->t_rtttime = 0; tp->snd_nxt = tp->snd_una; tcp_free_sackholes(tp); tp->snd_recover = tp->snd_max; if (tp->t_flags & TF_SACK_PERMIT) EXIT_FASTRECOVERY(tp); tcp_output_send(tp); return (inp); I'm not sure why it's not able to figure out the MTU, perhaps folks on net@ can help. However, it would seem that for the tcp_output() case, tcp_mtudisc() should probably not call tcp_output_send(), but instead tcp_output() should just loop back up to the top after calling tcp_mtudisc() and retry. I'm afraid to be wrong but it looks similar to another report for 8.0-STABLE (may it be a cross-major version regression somewhere around tcp_mtudisc()?): http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056063.html The backtrace indeed looks very similar. The reporter at that point had been cvs updated in the middle between two commits. Updating again seemed to have fixed it for him. None of those changes are in 7.3-RELEASE though and the endless loop indeed should no happen. Is the kernel and the core file still avail for further analyses? /bz -- Bjoern A. Zeeb It will not break if you know what you are doing.___ 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: kernel: arpresolve: can't allocate llinfo
On Wed, 21 Apr 2010, Denis Lamanov wrote: Hi, vmstat -m | grep lltable every 3 minutes increases :( lltable 16938 2149K -17779 128,256 I'll MFC the patches to fix that the next couple of days, maybe tommorow morning. In case you want to try them, you'd need SVN r206469,206470,206481 applied to 8-STABLE. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ 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: kernel: arpresolve: can't allocate llinfo
On Wed, 21 Apr 2010, Bjoern A. Zeeb wrote: On Wed, 21 Apr 2010, Denis Lamanov wrote: Hi, vmstat -m | grep lltable every 3 minutes increases :( lltable 16938 2149K -17779 128,256 I'll MFC the patches to fix that the next couple of days, maybe tommorow morning. In case you want to try them, you'd need SVN r206469,206470,206481 applied to 8-STABLE. Actually I just merged them. If you wait an hour or two for the changes to show up on your local mirror 8-STABLE should be fine. Please note that if you are using option FLOWTABLE you will still see the leak. I haven't gotten around to update my patches for that. I'll try to remember to post them once done. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ 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: Can't delete IPV6 addresses with ifconfig
On Thu, 14 Feb 2008, Daniel O'Connor wrote: Hi, I am experimenting with IPv6 and I can't seem to remove an IPv6 address from an interface, eg I have.. But I can't remove it, viz.. [midget 22:11] ~ >sudo ifconfig fxp0 -alias 2002:792d:8527::1:1/64 ifconfig: 2002:792d:8527::1:1/64: bad value [midget 22:27] ~ >sudo ifconfig fxp0 delete 2002:792d:8527::1:1/64 ifconfig: 2002:792d:8527::1:1/64: bad value [midget 22:27] ~ >sudo ifconfig fxp0 delete 2002:792d:8527::1:1 ifconfig: 2002:792d:8527::1:1: bad value [midget 22:27] ~ >sudo ifconfig fxp0 delete 2002:792d:8527::1:1 prefixlen 64 ifconfig: 2002:792d:8527::1:1: bad value [midget 22:27] ~ >sudo ifconfig fxp0 delete 2002:792d:8527::/64 ifconfig: 2002:792d:8527::/64: bad value Anyone know the right way to do this? :) yes, man ifocnfig says ifconfig [-L] [-k] [-m] interface [create] [address_family] [address [dest_address]] [parameters] The following parameters may be set with ifconfig: -alias Remove the network address specified. This would be used if you ... Conclusion: -alias is a "parameter" and belongs to the end after the address. The it works for IPv4 is "pure luck". /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7_0 buildworld failure on read only source tree
On Sun, 9 Mar 2008, Tom Judge wrote: Xin LI wrote: Tom Judge wrote: Hi, We have been building RELENG_6_x source trees from read only NFS file systems for well over a year now with out any problems. However I have just tried to do "make buildworld" on a RELENG_7_0 source tree from yesterday and it failed to build with the following error: [error snipped] Should it be possible to build RELENG_7_0 with a read only source tree? This can be worked around, I think touching the Makefile would do the trick. IIRC David (cc'ed) has fixed the Makefile at some point this January while he is updating the base cvs(1) for this exact issue, maybe we should MFC the changeset to RELENG_7? Cheers, Thanks for the response, it was indeed just a case of touching /usr/src/gnu/usr.bin/cvs/contrib/Makefile. Do you have the information about the relevent change sets that fix this? Then I can merge this fix to my local tree. I think it was this change: http://docs.freebsd.org/cgi/mid.cgi?200801130945.m0D9jsgf040114 -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Access Problems with 7.0
On Mon, 31 Mar 2008, Doug Hardie wrote: Hi, I recently upgraded 3 of my 5 servers to 7.0. Two of them are on new hardware and one is on hardware that used to run 6.2. Since then, 2 of my thousands of users are unable to access the servers running 7.0. They can access the server running 6.2 just fine. What happens is the server receives the SYN packet from the client properly and then responds with the SYN packet. Nothing more is heard from the client. The server sends a few duplicates of the SYN and then drops the connection. At this point I am not able to verify that the client receives the SYN. Neither of them has a clue about tcpdump. The packets look fine on this end (included later). Both are using Windows, including XP and Vista. I suspect they are receiving it and not accepting it for some reason. However, I don't really see anything that would cause that behavior in the packets. I can't reproduce the problem here. Every computer I can try works just fine. Here is one of the packet traces: 11:59:00.630414 00:00:0c:38:6f:e1 (oui Cisco) > 00:a0:cc:3e:87:9e (oui Unknown), ethertype IPv4 (0x0800), length 66: cpe-76-169-78-119.socal.res.rr.com.59025 > zool.lafn.org.8000: S 2779920420:2779920420(0) win 8192 11:59:00.630634 00:a0:cc:3e:87:9e (oui Unknown) > 00:00:0c:38:6f:e1 (oui Cisco), ethertype IPv4 (0x0800), length 66: zool.lafn.org.8000 > cpe-76-169-78-119.socal.res.rr.com.59025: S 2480373222:2480373222(0) ack 2779920421 win 65535 3,sackOK,eol> 11:59:03.613011 00:00:0c:38:6f:e1 (oui Cisco) > 00:a0:cc:3e:87:9e (oui Unknown), ethertype IPv4 (0x0800), length 66: cpe-76-169-78-119.socal.res.rr.com.59025 > zool.lafn.org.8000: S 2779920420:2779920420(0) win 8192 11:59:03.613194 00:a0:cc:3e:87:9e (oui Unknown) > 00:00:0c:38:6f:e1 (oui Cisco), ethertype IPv4 (0x0800), length 66: zool.lafn.org.8000 > cpe-76-169-78-119.socal.res.rr.com.59025: S 2480373222:2480373222(0) ack 2779920421 win 65535 Checking with the 6.2 server I see there are some differences in the TCP options. 7.0 includes wscale 3 where 6.2 does not. Is there a way to disable that feature using sysctl to see if thats the issue? You want to update to 7-STABLE which has the TCP fixes or you want to apply the following changes: 1.141.2.4 +10 -2 src/sys/netinet/tcp_output.c 1.157.2.2 +5 -2 src/sys/netinet/tcp_var.h In case you are not using MD5 that should be enough. Else see freebsd-net from the last 3 days for another patch. /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. ___ 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 and multiple IP (mijail-patch in 6.x)
On Mon, 31 Mar 2008, Johan Ström wrote: Hi, I got a machine running 6.2 right now, which is being replaced. And since SMP performance is much better on 7.x I'd like to go with 7.0 (and many ppl have indeed verified that it works good on this box, HP DL360 G5)... But, now when I start to setup the machine, I recalled that i've patched the 6.2 box with the freebsd mijail patch (http://www.digitaldaemon.com/FreeBSD/FreeBSD/FreeBSD_6.2-STABLE-mijail.patch). However, I cannot find anywhere about FreeBSD 7 and a similar patch. A quick look at the patch vs the 7.x source tells me it won't apply cleanly, but from what I've seen quickly, it could maybe be done. The differences I've seen doesn't look too advanced, but then again, I'm not a kernel developer... So, I'd like to know if anyone considered this on 7.x, or if anyone can tell me immediately that this wont work or will be LOTS of work, or just some patch line adjusting? Ie, how big are the changes from 6.x to 7.x in these sections? I had planned to have a patch for multiv4/v6 jails last month but it's not yet publicly available. I have sent it off to some people for review. In case the above is a successor of pjd's multi-ip v4 jail patch I can give you a plain forward port to a FreeBSD 7 system (which might have possible locking issues I have never experienced). All depends on how quickly you need it. /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time.___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: reboot after panic: privileged instruction fault
On Fri, 11 Apr 2008, Spil Oss wrote: Yesterday my to-be server running FreeBSD 7.0 #0 has rebooted after a kernel panic. FreeBSD newserver.example.net 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Fri Apr 4 07:22:22 CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BEASTIE70 i386 Please find messages and kernel-configuration attached. Could you get a backtrace? http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html might help you with further debugging. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Jail resource limits
On Thu, 22 May 2008, Peter Ankerstål wrote: Hi, If the are somebody with skills and time to resurrect some mentioned projects, I am willing to help with testing. I will also be happy to help in whatever way I can. I have no coding-experience to talk about. But testing in various env and so on. (and help with docs/wiki) I will have to go through all this again but it seems that there is more interest from multiple people on this work. As I am currently working on FreeBSD jails (see latetst status report http://www.freebsd.org/news/status/report-2008-01-2008-03.html#Multi-IPv4/v6/no-IP-jails and follow to my homepage to also find the slide from the BSDCan WIP session) I should look into this for everyone running FreeBSD 7. I'll try to get an overview on all the work out there based on the pointers already posted and will see how I can integrate that with whatever is going on in FreeBSD atm or come up with new patches.. Regards, Bjoern -- Bjoern A. Zeeb Stop bit received. Insert coin for new game.___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Regression with jails/IPv6/pf
On Thu, 26 Jul 2012, Matthew Seaman wrote: Just for the public; I am talking to him privately currently; I'll summarize findings either here or in a commit message. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: Regression with jails/IPv6/pf
On Thu, 26 Jul 2012, Matthew Seaman wrote:
Hi,
as there have been more people having problems with pf and IPv6 after
the changes I am replying to stable@ cc: pf@.
...
[...]
nat on $ext_if_plus from $xenophobe_int to any -> $xenophobe_ext
rdr inet6 proto tcp from to $xenophobe_ext \
port { 22, 80, 443, 548, 4700 } -> $xenophobe_int
When trying to ssh into the jail with a kernel exhibiting this problem,
tcpdump showed that traffic was reaching the sshd in the jail and
responses were being generated, but they didn't make it out onto the net.
Any of you who are expereincing problems with packets dropped due to
invalid checksums with IPv6 and pf after the recent merges, can you
report back if you also see this without "modulate state" in your
pf.conf (if you have 'modulate' in there, can you try changing it to
'keep' and see if that fixes the problem)?
/bz
--
Bjoern A. Zeeb You have to have visions!
Stop bit received. Insert coin for new address family.
___
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: Regression with jails/IPv6/pf
On Wed, 1 Aug 2012, Matthew Seaman wrote: On 01/08/2012 18:13, Bjoern A. Zeeb wrote: Any of you who are expereincing problems with packets dropped due to invalid checksums with IPv6 and pf after the recent merges, can you report back if you also see this without "modulate state" in your pf.conf (if you have 'modulate' in there, can you try changing it to 'keep' and see if that fixes the problem)? Alas, I was already using 'keep state'. I did just try 'modulate state,' just on the off-chance but it makes no difference. Modulate would only make it worse. -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: IPv4 vs. IPv6 Ethernet Performance
On Thu, 30 Aug 2012, Norbert Aschendorff wrote: Hi, I tested it using tcpdump: http://nopaste.info/9394068f54_nl.html The length field says for each packet 1408 bytes, so that should be OK. The Wireshark instance on the iperf server says something like "16732 bytes on wire" for the most packets (not always with 16732 bytes, but most packets over 10,000) - could that be reassembled somehow? only slowly catching up on email so... chiming in now. I'd assume in this case the iperf "server" is linux or did Jack add IPv6 LRO support to e1000? Sorry, I am not up-to-date. However, any modern peice of hardware should be able to fill the 1G link even with software doing csums or offloading really and all our routing table lookups. What's the well known FreeBSD machine of a machine? I can only imaging what's going on for you and some of the latest work was not yet merged to head or 9; I have 1 or 2 patches posted to net@ for review and testing though. Sorry not immediately helpful. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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 9.1-RC1 Available...
On Thu, 23 Aug 2012, Ken Smith wrote: Hi, let me reply to the very initial email in this monster of public thread. With both the doc and ports repositories now moved to SVN it has been decided to not export the 9.1 release branch activity to CVS. So csup/cvsup update mechanisms are not available for updating to 9.1-RC1. If you would like to use SVN the branch to use is releng/9.1. RELENG_9_1 is now exported the CVS as well and will be for as long as things will be exported to CVS. It will take another few hours to get near your local mirror as they'll all be chewing on each other the next 12 hours. Enjoy! Any further discussions on src export I'll leave to other people wearing hats. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: epair on 9-stable
> On 31 Mar 2015, at 21:31 , Johannes Totz wrote: > > Hi, > > Is epair (virtual ethernet) supposed to work on 9-stable? > I'm having trouble with it. > I want to connect one end to a bridge, e.g.: > > bge0 <===> bridge0 <===> epair0a <---> epair0b > > and run dhclient on epair0b. > But nothing comes through, not even on epair0a. > bridge0 itself receives packets. > No firewall involved. > > Any ideas? Just checking, are all interfaces UP? — Bjoern A. Zeeb Charles Haddon Spurgeon: "Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend." ___ 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"
