Routing question (GRE packet vs normal traceroute)?
Hi, A friend of mine has encountered some problem in his setup which consists a pair of GRE peer, one running on OpenBSD and another running FreeBSD 7.2-RELEASE; with 7.2-STABLE, there is no improvement over the situation. The problem we have observed seems to be related to GRE packet not being routed as observed, here is some details: - The FreeBSD box has one network interface connected to two (2) upstream network, with different IP and does not belong to the same subnet, say, one is 1.2.3.4/24 and another is 5.6.7.8/24 - The default gateway can be reached through the first IP address bound to the network interface; - An explicit route has been configured to the OpenBSD host, the gateway being used can be reached directly via the secondary (aliased 5.6.7.8/24) IP. - Both the default gateway and the explicit host route can reach the OpenBSD route. The problem they had is, while traceroute to the OpenBSD host can give the desired result, however, packets that is supposed to be transferred through the GRE tunnel, while they will be encapsulated into a GRE packet, the GRE packet itself won't go to the explicit host route, but end up going to the default gateway. The friend has configured his switch to bounce the packet back to the server by configuring a host route on L3 switch, and it seems that the FreeBSD box is able to route the GRE packet to its desired gateway this time. Any suggestions? Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net ___ 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
panic on devd disable
On my older Dell 2400 and 2500 systems I have been setting devd_enable=NO to avoid panicing the systems. Now I when I updated to 7.2p5 the following sysctl seems to panic the system at will. sysctl hw.bus.devctl_disable=1 I have removed /etc/rc.d/devd completely to get the system to boot into multiuser. I have a GENERIC Kernel and nothing in make.conf. I enabled set -x in rc.conf and rebooted to get this back trace Does anyone have any ideas why this happens or what patch I might try to fix it? Thanks, Ken Here is backtrace 118eval 118 _value=$devd_enable 118 118+ 118_value=NO 118 118+ 118debug 118 checkyesno: devd_enable is set to NO. 118 118+ 118return 118 1 118 118+ 118sysctl 118 hw.bus.devctl_disable=1 118 118hw.bus.devctl_disable: 1180 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 00 fault virtual address = 0xff08 fault code = supervisor write, page not present instruction pointer = 0x20:0xc080a1fa stack pointer = 0x28:0xefc07b34 frame pointer = 0x28:0xefc07b54 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 406 (sysctl) trap number = 12 panic: page fault cpuid = 1 Uptime: 6m45s Physical memory: 2035 MB Dumping 69 MB: 54 38 22 6 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at pcpu.h:196 196 __asm __volatile(movl %%fs:0,%0 : =r (td)); (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc07e25f7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e28c9 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0ae3f2c in trap_fatal (frame=0xefc07af4, eva=4278190088) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0ae41b0 in trap_pfault (frame=0xefc07af4, usermode=0, eva=4278190088) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc0ae4b5c in trap (frame=0xefc07af4) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc0ac926b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc080a1fa in sysctl_devctl_disable (oidp=0xc0c546e0, arg1=0x0, arg2=0, req=0xefc07ba4) at /usr/src/sys/kern/subr_bus.c:733 #8 0xc07ebe97 in sysctl_root (oidp=Variable oidp is not available. ) at /usr/src/sys/kern/kern_sysctl.c:1413 #9 0xc07ec034 in userland_sysctl (td=0xc5949d20, name=0xefc07c14, namelen=3, old=0x0, oldlenp=0x0, inkernel=0, new=0xbfbfee64, newlen=4, retval=0xefc07c10, flags=0) at /usr/src/sys/kern/kern_sysctl.c:1506 #10 0xc07ec184 in __sysctl (td=0xc5949d20, uap=0xefc07cfc) at /usr/src/sys/kern/kern_sysctl.c:1443 #11 0xc0ae4505 in syscall (frame=0xefc07d38) at /usr/src/sys/i386/i386/trap.c:1090 #12 0xc0ac92d0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #13 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) ___ 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
Merry Christmas to all on the list!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It's that time of year again. The time when we think about those who we have to thank for their efforts. Thank you all, for your efforts in making the day-to-day maintenance of my computer solutions easier. Thank you for your efforts in creating a solid software alternative to the shrink-wrap-licensed products. A merry Christmas to all of you! Regards, Svein Skogen - -- - +---+--- /\ |Svein Skogen | sv...@d80.iso100.no \ / |Solberg Østli 9| PGP Key: 0xE5E76831 X|2020 Skedsmokorset | sv...@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | sv...@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listm...@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +---+--- |msn messenger: | Mobile Phone: +47 907 03 575 |sv...@jernhuset.no | RIPE handle:SS16503-RIPE - +---+--- If you really are in a hurry, mail me at svein-mob...@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. - Picture Gallery: https://gallery.stillbilde.net/v/svein/ - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkszlAkACgkQODUnwSLUlKTZNACcC5MS+XLl7avCRJPrM1hSF7BD JJ0AmwbjcOJq/sppZv3hOBrvyONRQY3u =PEhK -END PGP SIGNATURE- ___ 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: Routing question (GRE packet vs normal traceroute)?
Xin LI wrote: Hi, A friend of mine has encountered some problem in his setup which consists a pair of GRE peer, one running on OpenBSD and another running FreeBSD 7.2-RELEASE; with 7.2-STABLE, there is no improvement over the situation. The problem we have observed seems to be related to GRE packet not being routed as observed, here is some details: - The FreeBSD box has one network interface connected to two (2) upstream network, with different IP and does not belong to the same subnet, say, one is 1.2.3.4/24 and another is 5.6.7.8/24 - The default gateway can be reached through the first IP address bound to the network interface; - An explicit route has been configured to the OpenBSD host, the gateway being used can be reached directly via the secondary (aliased 5.6.7.8/24) IP. - Both the default gateway and the explicit host route can reach the OpenBSD route. The problem they had is, while traceroute to the OpenBSD host can give the desired result, however, packets that is supposed to be transferred through the GRE tunnel, while they will be encapsulated into a GRE packet, the GRE packet itself won't go to the explicit host route, but end up going to the default gateway. The friend has configured his switch to bounce the packet back to the server by configuring a host route on L3 switch, and it seems that the FreeBSD box is able to route the GRE packet to its desired gateway this time. Any suggestions? there is a hack in the GRE code that you can turn off where the GRE envelope is looking up the address of the peer *WITH THE LAST BIT SWITCHED* try adding a route to the address of the openBSD host with /31 (not 32) I forget how to turn it off but th man page says. there IS a good reason for it if you want packets for the OpenBSD host itself to go through the tunnel.. Then you need to not use that address itself or you get a routing loop. Cheers, ___ 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.0: can't PXE Boot using nvidia nForce4 network card
On Wed, Dec 23, 2009 at 02:07:15PM +0100, Olivier Cochard-Labb? wrote: Hi all, I've got a PC which have 2 bugs with FreeBSD 8.0: It can't boot from USB (usb/139142) neither from PATA hard-drive (kern/139143). But I would boot this PC for giving acces to somes FreeBSD devs for debuging it: Then I've choose boot my buggy PC using PXE, then I've prepared a second PC with a DHCP/TFTP/NFS/serial-cable this bugguy PC. I've posted my problem on the FreeBSD forum some weeks ago, but didn't found usefull help: http://forums.freebsd.org/showthread.php?t=8324 The up-to-date 8.0-STABLE kernel boot fine from PXE/TFTP, but when it tries to mount the rootfilesystem from NFS it display an errror: Trying to mount root from nfs:10.0.0.1:/usr/tftpboot nfs_diskless: no interface ROOT MOUNT ERROR: The network card is a NVIDIA nForce4 CK804 MCP8. I've seen that the pxe loader populate correctly lot's of the needed boot variables (boot.netif.ip, boot.netif.netmask, boot.netif.gateway, etc...) but with the only expection of boot.netif.name. It seems to have a problem in /usr/src/sys/nfsclient/nfs_diskless.c that can't set this variable. Does some one have any clue for fixing this file ? Thanks, Olivier PS: Here is the full verbose boot messages: [...] nfe0: NVIDIA nForce4 CK804 MCP8 Networking Adapter irq 21 at device 10.0 on pci0 nfe0: Lazy allocation of 0x100 bytes rid 0x10 type 3 at 0x8100 nfe0: Reserved 0x100 bytes for rid 0x10 type 3 at 0x8100 nfe0: MII without any phy! ^^ Maybe this is the reason why you can't use NFS. If your BIOS has an option that disables management feature of ethernet controller try toggle the feature. device_attach: nfe0 attach returned 6 ___ 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
8-STABLE ahci fails to attach, does not fallback on ataahci
Hi lists, I gave ATA_CAM a try last night and believe I have a similar setup (crippled hardware) in my laptop as Doug Barton's, although my controller is ICH6M. Nonetheless, ahci detects my controller and tries to attach and fails (returns 6). No ada nodes are created and the boot process halts trying to find a root mount. Verbose booting reveals nothing special. Anything else I can do to try to reveal the problem? I tried modular ATA with the following: device atacore device atapci device ataahci device ataintel device ahci From reading the lists more thoroughly, I now have the impression that either ahci or ataahci are necessary and not both. If I remove 'device ahci' then 8-STABLE boots normally. However, I would think that if ahci failed to attach then the kernel should fallback on ataahci. If GENERIC included both ahci and ataahci, then I would never be able to boot FreeBSD let alone install it. `uname -a` FreeBSD LIGHTBULB.LOCAL 8.0-STABLE FreeBSD 8.0-STABLE #4: Thu Dec 24 02:40:23 EST 2009 ns...@lightbulb.local:/usr/obj/usr/src/sys/LIGHTBULB i386 Here's what appears in my dmesg: atapci0: Intel ICH6M SATA150 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18c0-0x18cf at device 31.2 on pci0 and the result of `pciconf -lv` atap...@pci0:0:31:2:class=0x010180 card=0x056a1014 chip=0x26538086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FBM (ICH6M) SATA Controller' class = mass storage subclass = ATA the kernel was built from 8-STABLE tree as of last night. Best Regards, Nathan Lay ___ 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: Hacked - FreeBSD 7.1-Release
On Tue, December 22, 2009 8:35 am, Andresen, Jason R. wrote: Squirrel wrote: most likely could be some kind of remote code execution or SQLi executed in the context of some php scripts, you should audit php code of your web interface and of the websites you host. also consider the strenght of your passwords, lots of login attempts to ssh/ftp may mean a he has tried a bruteforce (or a dictionary attack maybe). you should also check webmin logs, there are a few bruteforcer for webmin out there, (*hint*) consider the lenght of your average password if it's more than 7-8 characters aplhanumeric with simbols most likely this isn't the case. While it's true that it's a good idea to check your password strength, pretty much any host connected to the internet is going to be hit daily by bots looking for weak passwords. It's one area where you logs don't help much because there is too much noise. That's why there's GREP(1), AWK(1), FIND(1), TAIL(1), and CAT(1) Consider the following... adding the following to your /etc/rc.conf: # SECURITY RELATED syslogd_flags=-ss log_in_vain=YES tcp_keepalive=YES now your log file will /really/ sing (log_in_vain=YES). Of course, unless you have a great deal of time on your hands, visually parsing that noisy log will be quite tedious, and time consuming. So you have a few options... If your running X11, simply run tail in a root window - there are quite a few utilities in ports for doing just this - some that'll only write messages you want to see. You could also create a script out of cron that will only produce messages you are interested in, for example: ~# cat /var/log/messages | ssh will emit any attempt to ssh into your box you can also redirect the messages to a file: ~# cat /var/log/messages | ssh ~/EVIL_DOERS You could also add en entry to PERIODIC(8) that will provide a daily report on any attempts you are interested in. HTH --Chris H ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
php5-5.2.11_1 Vulnerabilities
I was wondering why this isn't available to upgrade... Affected package: php5-5.2.11_1 Type of problem: php -- multiple vulnerabilities. Reference: http://portaudit.FreeBSD.org/39a25a63-eb5c-11de-b650-00215c6a37bb.html Security Enhancements and Fixes in PHP 5.2.12 is what the above reference says. Standard methods of upgrading have no shown a fix for this...does anyone have information on when this will be fixed? Port:php5-5.2.11_1 Path:/usr/ports/lang/php5 Info:PHP Scripting Language Maint:a...@freebsd.org B-deps:autoconf-2.62 autoconf-wrapper-20071109 libiconv-1.13.1 libxml2-2.7.6_1 m4-1.4.13,1 perl-5.8.9_3 pkg-config-0.23_1 R-deps:libiconv-1.13.1 libxml2-2.7.6_1 pkg-config-0.23_1 WWW:http://www.php.net/ ___ 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: php5-5.2.11_1 Vulnerabilities
I think ale@ has posted a patch to update it to PHP 5.3.1 which is not vulnerable. Is it an option for you? http://www.alexdupre.com/php53.diff On Thu, Dec 24, 2009 at 8:49 PM, r00t r...@ellicit.org wrote: I was wondering why this isn't available to upgrade... Affected package: php5-5.2.11_1 Type of problem: php -- multiple vulnerabilities. Reference: http://portaudit.FreeBSD.org/39a25a63-eb5c-11de-b650-00215c6a37bb.html Security Enhancements and Fixes in PHP 5.2.12 is what the above reference says. Standard methods of upgrading have no shown a fix for this...does anyone have information on when this will be fixed? Port: php5-5.2.11_1 Path: /usr/ports/lang/php5 Info: PHP Scripting Language Maint: ...@freebsd.org B-deps: autoconf-2.62 autoconf-wrapper-20071109 libiconv-1.13.1 libxml2-2.7.6_1 m4-1.4.13,1 perl-5.8.9_3 pkg-config-0.23_1 R-deps: libiconv-1.13.1 libxml2-2.7.6_1 pkg-config-0.23_1 WWW: http://www.php.net/ ___ 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 -- Xin LI delp...@delphij.net http://www.delphij.net ___ 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-STABLE ahci fails to attach, does not fallback on ataahci
Nathan Lay wrote:
I gave ATA_CAM a try last night and believe I have a similar setup
(crippled hardware) in my laptop as Doug Barton's, although my
controller is ICH6M. Nonetheless, ahci detects my controller and tries
to attach and fails (returns 6). No ada nodes are created and the boot
process halts trying to find a root mount. Verbose booting reveals
nothing special. Anything else I can do to try to reveal the problem?
I tried modular ATA with the following:
device atacore
device atapci
device ataahci
device ataintel
device ahci
From reading the lists more thoroughly, I now have the impression that
either ahci or ataahci are necessary and not both.
They duplicate each other, but should not conflict.
If I remove 'device
ahci' then 8-STABLE boots normally. However, I would think that if ahci
failed to attach then the kernel should fallback on ataahci. If GENERIC
included both ahci and ataahci, then I would never be able to boot
FreeBSD let alone install it.
There is no fallback mechanism on attach failure in newbus. ataahci will
only be used is ahci fail probe, not an attach.
`uname -a`
FreeBSD LIGHTBULB.LOCAL 8.0-STABLE FreeBSD 8.0-STABLE #4: Thu Dec 24
02:40:23 EST 2009
ns...@lightbulb.local:/usr/obj/usr/src/sys/LIGHTBULB i386
Here's what appears in my dmesg:
atapci0: Intel ICH6M SATA150 controller port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18c0-0x18cf at device 31.2 on pci0
and the result of `pciconf -lv`
atap...@pci0:0:31:2:class=0x010180 card=0x056a1014 chip=0x26538086
rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = '82801FBM (ICH6M) SATA Controller'
class = mass storage
subclass = ATA
There is the answer. ICH6 chipsets are using chip ID convention
different from other ICHs. Same ID used for AHCI and legacy modes. It
was false positive probe. This chip now runs in legacy mode.
This patch should fix the issue:
--- ahci.c.prev 2009-12-08 13:27:31.0 +0200
+++ ahci.c 2009-12-25 09:28:32.0 +0200
@@ -115,8 +115,8 @@ static struct {
{0x43931002, ATI IXP700, 0},
{0x43941002, ATI IXP800, 0},
{0x43951002, ATI IXP800, 0},
- {0x26528086, Intel ICH6, 0},
- {0x26538086, Intel ICH6M, 0},
+ {0x26528086, Intel ICH6, AHCI_Q_NOFORCE},
+ {0x26538086, Intel ICH6M, AHCI_Q_NOFORCE},
{0x26818086, Intel ESB2, 0},
{0x26828086, Intel ESB2, 0},
{0x26838086, Intel ESB2, 0},
--
Alexander Motin
___
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
