Re: PCengines ALIX boot0sio serial input failes
> On 12/10/2009 2:32 AM, Daniel Braniss wrote: > >> Which ALIX board exactly? There are some differences (even various BIOSes). > >> Any chance you have vga driver in kernel? TinyBIOS emulates VGA a bit, > >> redirects output to serial port. If at the beginning you are trying both > >> VGA > >> and serial port, output is doubled. Similar behavior is observed on older > >> WRAP boards, too. > > > > I have tried ALIX-1 and 2 > > here is an example: > > > > PC Engines ALIX.3 v0.99h > > 640 KB Base Memory > > 261120 KB Extended Memory > > Waiting for HDD ... > > > > 01F0 Master 848A SanDisk SDCFH2-002G > > Phys C/H/S 3970/16/63 Log C/H/S 992/64/63 > > > > 1 FreeBSD > > 2 FreeBSD > > 3 FreeBSD > > > > 6 PXE > > Boot: 1 > > > > any key I hit, it echoes as # and is ignored. > > at this point the kernel is not yet involved, so having vga+kb support > > is not the reason, though I will try out the alix-3, which has vga support, > > and > > a different BIOS soon. i have now, and the results are: - serial works - bios boot skips boot0, and goes straight to boot slice 1. The good side is that PXE boot works, but switching to boot from disk is a pain, on other systems, hitting ^C at the dhcp will stop it, and the boot will continue from disk, which if fails (forgot some critical setup :-), reboot, fix, boot ^C ... > > A lot of users have seen that happen, but typically it has been cleared > up by using ALIX BIOS v0.99h, which that box already appears to have, > and setting the BIOS for CHS mode. > > I haven't tried any of the ALIX models with VGA, but I have heard they > are working as long as you set the BIOS for APM power management. it's actualy setting Power Management to anything but ACPI. > (See > the previous -STABLE thread titled "8.0-rc2 dropped hardsupport". > > Jim cheers, danny ___ 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: proxy arp and MPD in RELENG_8
Hi, I think I managed to reproduce this issue. The root cause appears to be the SIN_PROXY usage, which is no longer part of any routing entry after the L2/L3 rewrite. As such, the RTM_GET command should be issued once in the ARP utility, not twice. In addition, since ARP does not apply to PPP link type, the prefix route of the local end point needs to be returned in order for the subsequent RTM_ADD command to succeed. I need to update the routing code a bit more to properly handle such proxy-arp scenario. In the meantime, please try a hack at http://people.freebsd.org/~qingli/ppp-patch.diff and let me know how it works out for you. The hack appears to work in my test environment. I need just a bit more time to work out the permanent solution in the kernel routing code, as well as the utilities in the userland. -- Qing > -Original Message- > From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- > curr...@freebsd.org] On Behalf Of Li, Qing > Sent: Wednesday, December 09, 2009 12:04 PM > To: Mario Pavlov; freebsd-stable@freebsd.org; freebsd- > curr...@freebsd.org > Subject: RE: proxy arp and MPD in RELENG_8 > > > Let me look into this issue and work with you offline. > > I have been quite busy with day job and just starting to slowly > resume my FreeBSD work. > > -- Qing > > > -Original Message- > From: owner-freebsd-sta...@freebsd.org on behalf of Mario Pavlov > Sent: Wed 12/9/2009 11:01 AM > To: freebsd-stable@freebsd.org; freebsd-curr...@freebsd.org > Subject: proxy arp and MPD in RELENG_8 > > > Hi, > some time ago I noticed that there's a problem with the new arp > implementation - proxy arp was somehow not working when mpd is involved. > I decided to try this out again assuming it was fixed for the > release...unfortunately the problem is still there... > Here are the last few lines of the mpd output: > > > [B-1] IPCP: state change Ack-Rcvd --> Opened > [B-1] IPCP: LayerUp > [B-1] 192.168.10.1 -> 192.168.10.50 > [B-1] IFACE: Connecting tcpmssfix > [B-1] IFACE: Add address 192.168.10.1/32->192.168.10.50 to ng0 > [B-1] exec: /usr/sbin/arp -S 192.168.10.50 0:e0:28:62:e:9 pub > [B-1] system: command "/usr/sbin/arp" returned 256 > [B-1] IFACE: Up event > [B-1] IFACE: idle-timeout: 1800 seconds > [B-1] IFACE: Change interface flags: -0 +1 > > > there this is mpd.conf: > > > startup: > > default: > load pptp_server > > pptp_server: > > set ippool add pool1 192.168.10.50 192.168.10.99 > > create bundle template B > set iface enable proxy-arp > log +iface2 > set iface idle 1800 > set iface enable tcpmssfix > set ipcp yes vjcomp > set ipcp ranges 192.168.10.1/32 ippool pool1 > set ipcp dns 192.168.10.1 > set bundle enable compression > set ccp yes mppc > set mppc yes e40 > set mppc yes e128 > set mppc yes stateless > > create link template L pptp > set link action bundle B > set link enable multilink > set link yes acfcomp protocomp > set link no pap chap > set link enable chap > set link keep-alive 10 60 > set link mtu 1460 > set pptp self pub.ip.add.res > set link enable incoming > > > this is probably the most common VPN setup and it was working fine with > 7.2-STABLE but after I upgraded to 8-STABLE it broke up... > Is there a workaround or a plan to fix this? Or should I just go back > to RELENG_7? > > thank you. > > P.S. this is discussed in the forums as well: > http://forums.freebsd.org/showthread.php?t=8427 > > - > ? ?? ?? iZone.bg ? ??? ?? 5?? ??? > Acer! > http://www.izone.bg/6/index.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" > > ___ > freebsd-curr...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current- > unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309
Hello, and thank you very much for your reply. On Thu, December 10, 2009 5:48 am, John Baldwin wrote: > On Wednesday 09 December 2009 8:52:06 pm Chris H wrote: > >> On Wed, December 9, 2009 6:50 am, John Baldwin wrote: >> >>> On Tuesday 08 December 2009 7:06:18 pm Chris H wrote: >>> >>> Greetings, I am receiving the following in dmesg (verbose) during boot in 8-RELEASE (GENERIC) cvsuped 2009-12-08 @1am: ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309 As I create the KERNCONF for this machine, I want to confirm that this message is caused by the fact that APM is shut off in the BIOS, and won't cause any averse problems. We're having issues with "timeout" errors on some 50 TYAN server MB's since 7-RELEASE regarding the disk media (no matter how many different drives we use). So as I attempt to create a STABLE - in the sense that the servers are reliable, I want to eliminate any potential issues. more (informational) "noise" follows: >>> >>> You can ignore the message, I do think it is due to disabling ACPI in your >>> BIOS. Do you have problems when ACPI is enabled? ACPI is generally going >>> to be more reliable than !ACPI in the future as it seems many BIOS vendors >>> no longer test the !ACPI case as much (e.g. I've seen Intel motherboards >>> with incomplete or incorrect MP Tables because no commercial OS uses the MP >>> Table anymore). >>> >> >> Hello, and thank you very much for your reply. >> So the message is simply "informative" - good to know. >> As to the ACPI. Closer examination seemed to indicate the BIOS was >> incomplete. >> While I could have flashed it, assuming that it 1) would have all current >> updates 2) it would then also be complete >> I opted to simply take another new board off the shelf and try again. This >> time, taking your advice, and /enabling/ full ACPI. I performed an install, >> and just now cvsupped src && ports. It's in the process of building >> world/kernel as I write this reply. Hope all turns out well - "Fingers >> crossed". :) > > Ok. > FreeBSD 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu Dec 10 01:10:25 PST 2009 i386 All completed as intended. only 1 timeout error at the /very/ beginning. Which was very short, and recovered immediately. > >> If you (or anyone else) can tell me... >> I have had issues with periodic "timeouts" with disks (SCSI,ATA && CD/DVD >> ROMS) >> ever since late 6. After experimenting with /many/ kernels. I'm left with the >> suspicion the it has to do with SCHED_4BSD vs. SCHED_ULE. In other words, >> ever since SCHED_ULE became default/preferred most of the PIII based boards >> have exhibited this anomaly. Often the "retries" aren't exhausted, and they >> recover. But many times they don't which will lead to freeze that requires >> "bouncing" the >> machine, and performing FSCK(8). I haven't seen anything in UPDATING. But >> wonder; should I assume that anything in the PIII category /requires/ >> SCHED_4BSD. Or >> would it be better to tune a kernel via SYSCTL(8)? > > Hmmm, there isn't anything CPU-specific in ULE vs 4BSD, and I would expect > ULE to work fine on a PIII. I would generally expect device timeouts to be > more of a driver issue than a scheduler issue. > Ahh, I see. Good to know. I'm not sure where to try and "tune" things in this regard. I can say that the timeouts /only/ occur during writes, and even then, only during "bursts" of large, or many writes. Example output emitted from one of the drives: (da1:ahc0:0:2:0): Request Requeued (da1:ahc0:0:2:0): Retrying Command (da1:ahc0:0:2:0): Request Requeued (da1:ahc0:0:2:0): Retrying Command (da1:ahc0:0:2:0): Request Requeued (da1:ahc0:0:2:0): Retrying Command (da1:ahc0:0:2:0): Request Requeued (da1:ahc0:0:2:0): Retrying Command (da1:ahc0:0:2:0): Queue Full (da1:ahc0:0:2:0): Retrying Command (da1:ahc0:0:2:0): tagged openings now 64 While this new install seems to be better that previous installs in this regard. I experimented with several drives on this board. ATA disks seemed to be more problematic than SCSI. So I opted to only use SCSI drives on this board with the exception of 1 DVDRW, and 1 CDROM - each as master on ports 0, and 1. I should probably mention that the SCSI ports are driven by Adaptec onboard controllers . The Drives were both "blanked" (formatted) using the format utility provided in the Adaptec BIOS. There were no errors indicated, and there was no indication of excessive re-mapping of sectors indicative of old/tired drives. Both drives are of equal speed, and are of the same manufacturer: Fixed Direct Access SCSI-2 device Serial Number RD2L5450 80.000MB/s transfers Fixed Direct Access SCSI-3 device Serial Number AKL08764 80.000MB/s transfers Thank you again for all your time and consideration. --Chris H > -- > John Baldwin > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-
Re: IPv6 - bad neighbor solicitation messages
Its been happening for a while. I've attached the tcpdump textual output, the tcpdump raw saved file, and before and after netstat -s output. Thanks, Tom On Dec 10, 2009, at 10:22 PM, Li, Qing wrote: > I haven't made any significant changes in the IPv6 code > for 3 months now. Could you please get a packet capture and > email it to me? > > Thanks, > > -- Qing 22:59:51.008261 IP6 (hlim 63, next-header ICMPv6 (58) payload length: 16) 2610:28:1800:4001:225:ff:fef1:7305 > 2610:28:1800:4001:2a0:c9ff:fe45:326c: [icmp6 sum ok] ICMP6, echo request, length 16, seq 0 22:59:51.008291 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) 2610:28:1800:4001:2a0:c9ff:fe45:326c > 2610:28:1800:4001:225:ff:fef1:7305: [icmp6 sum ok] ICMP6, echo reply, length 16, seq 0 22:59:52.562108 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2610:28:1800:4001:225:ff:fef1:7305 > ff02::1:ff45:326c: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2610:28:1800:4001:2a0:c9ff:fe45:326c source link-address option (1), length 8 (1): 00:25:00:f1:73:05 22:59:52.562134 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2610:28:1800:4001:2a0:c9ff:fe45:326c > 2610:28:1800:4001:225:ff:fef1:7305: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is 2610:28:1800:4001:2a0:c9ff:fe45:326c, Flags [solicited, override] destination link-address option (2), length 8 (1): 00:a0:c9:45:32:6c 22:59:52.562382 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 120) fe80::20e:cff:fe74:9778 > 2610:28:1800:4001:2a0:c9ff:fe45:326c: [icmp6 sum ok] ICMP6, redirect, length 120, 2610:28:1800:4001:225:ff:fef1:7305 to 2610:28:1800:4001:225:ff:fef1:7305 redirected header option (4), length 80 (10): 0x: 040a 6000 0020 3afe 0x0010: 2610 0028 1800 4001 02a0 c9ff fe45 326c 0x0020: 2610 0028 1800 4001 0225 00ff fef1 7305 0x0030: 8800 2ee6 6000 2610 0028 1800 4001 0x0040: 02a0 c9ff fe45 326c 0201 00a0 c945 326c 22:59:53.562387 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2610:28:1800:4001:225:ff:fef1:7305 > ff02::1:ff45:326c: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2610:28:1800:4001:2a0:c9ff:fe45:326c source link-address option (1), length 8 (1): 00:25:00:f1:73:05 22:59:53.562405 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2610:28:1800:4001:2a0:c9ff:fe45:326c > 2610:28:1800:4001:225:ff:fef1:7305: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is 2610:28:1800:4001:2a0:c9ff:fe45:326c, Flags [solicited, override] destination link-address option (2), length 8 (1): 00:a0:c9:45:32:6c 22:59:53.562556 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 120) fe80::20e:cff:fe74:9778 > 2610:28:1800:4001:2a0:c9ff:fe45:326c: [icmp6 sum ok] ICMP6, redirect, length 120, 2610:28:1800:4001:225:ff:fef1:7305 to 2610:28:1800:4001:225:ff:fef1:7305 redirected header option (4), length 80 (10): 0x: 040a 6000 0020 3afe 0x0010: 2610 0028 1800 4001 02a0 c9ff fe45 326c 0x0020: 2610 0028 1800 4001 0225 00ff fef1 7305 0x0030: 8800 2ee6 6000 2610 0028 1800 4001 0x0040: 02a0 c9ff fe45 326c 0201 00a0 c945 326c 22:59:54.562607 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2610:28:1800:4001:225:ff:fef1:7305 > ff02::1:ff45:326c: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2610:28:1800:4001:2a0:c9ff:fe45:326c source link-address option (1), length 8 (1): 00:25:00:f1:73:05 22:59:54.562630 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2610:28:1800:4001:2a0:c9ff:fe45:326c > 2610:28:1800:4001:225:ff:fef1:7305: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is 2610:28:1800:4001:2a0:c9ff:fe45:326c, Flags [solicited, override] destination link-address option (2), length 8 (1): 00:a0:c9:45:32:6c 22:59:54.562770 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 120) fe80::20e:cff:fe74:9778 > 2610:28:1800:4001:2a0:c9ff:fe45:326c: [icmp6 sum ok] ICMP6, redirect, length 120, 2610:28:1800:4001:225:ff:fef1:7305 to 2610:28:1800:4001:225:ff:fef1:7305 redirected header option (4), length 80 (10): 0x: 040a 6000 0020 3afe 0x0010: 2610 0028 1800 4001 02a0 c9ff fe45 326c 0x0020: 2610 0028 1800 4001 0225 00ff fef1 7305 0x0030: 8800 2ee6 6000 2610 0028 1800 4001 0x0040: 02a0 c9ff fe45 326c 0201 00a0 c945 326c 22:59:56.008687 IP6 (hlim 63, next-header ICMPv6 (58) payload length: 16) 2610:28:1800:4001:225:ff:fef1:7305 > 2610:28:1800:4001:2a0:c9ff:fe45:326c: [icmp6 sum ok] ICMP6, echo request, length 16, seq 5 22:59:56.008704 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) 2610:28:1800:4001:2a0:c9ff:fe45:326c > 2610:28:1800:4001:225:ff:fef1
RE: IPv6 - bad neighbor solicitation messages
I haven't made any significant changes in the IPv6 code for 3 months now. Could you please get a packet capture and email it to me? Thanks, -- Qing From: owner-freebsd-sta...@freebsd.org on behalf of Tom Pusateri Sent: Thu 12/10/2009 7:15 PM To: freebsd-stable@freebsd.org Subject: IPv6 - bad neighbor solicitation messages I'm having intermittent IPv6 issues on one FreeBSD 8-stable box. I've tried to ping6 the FreeBSD-8 stable (crag) (as of 12/9/09) from snow leopard (glow) and from a freebsd 7.2 box (gw). I've tried replacing the fxp0 interface in the FreeBSD-8 stable box with an em0 interface and it works with the FreeBSD 7.2 box but the same problem from the Snow Leopard box. The bad neighbor solicitation messages keep increasing with the IPv6 pings. Any other thing I can collect to troubleshoot? Thanks, Tom glow pusateri$ ping6 crag PING6(56=40+8+8 bytes) 2610:28:1800:4001:225:ff:fef1:7305 --> 2610:28:1800:4001:20e:cff:fe9f:faad Request timeout for icmp_seq=0 Request timeout for icmp_seq=1 Request timeout for icmp_seq=2 Request timeout for icmp_seq=3 16 bytes from 2610:28:1800:4001:20e:cff:fe9f:faad, icmp_seq=4 hlim=63 time=0.784 ms Request timeout for icmp_seq=5 Request timeout for icmp_seq=6 Request timeout for icmp_seq=7 Request timeout for icmp_seq=8 16 bytes from 2610:28:1800:4001:20e:cff:fe9f:faad, icmp_seq=9 hlim=63 time=0.633 ms Request timeout for icmp_seq=10 Request timeout for icmp_seq=11 Request timeout for icmp_seq=12 Request timeout for icmp_seq=13 16 bytes from 2610:28:1800:4001:20e:cff:fe9f:faad, icmp_seq=14 hlim=63 time=0.654 ms Request timeout for icmp_seq=15 ^C --- crag.foo.com ping6 statistics --- 17 packets transmitted, 3 packets received, 82.4% packet loss round-trip min/avg/max/std-dev = 0.633/0.690/0.784/0.067 ms tcp: 153 packets sent 146 data packets (31776 bytes) 3 data packets (240 bytes) retransmitted 1 data packet unnecessarily retransmitted 0 resends initiated by MTU discovery 4 ack-only packets (2 delayed) 0 URG only packets 0 window probe packets 0 window update packets 0 control packets 196 packets received 137 acks (for 31777 bytes) 6 duplicate acks 0 acks for unsent data 52 packets (4277 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 0 connection requests 1 connection accept 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 1 connection established (including accepts) 4 connections closed (including 0 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 137 segments updated rtt (of 73 attempts) 2 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 0 correct ACK header predictions 50 correct data packet header predictions 1 syncache entry added 0 retransmitted 1 dupsyn 0 dropped 1 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 1 cookie sent 0 cookies received 1 SACK recovery episode 1 segment rexmit in SACK recovery episodes 48 byte rexmits in SACK recovery episodes 7 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 169 datagrams received 0 with incomplete header
IPv6 - bad neighbor solicitation messages
I'm having intermittent IPv6 issues on one FreeBSD 8-stable box. I've tried to ping6 the FreeBSD-8 stable (crag) (as of 12/9/09) from snow leopard (glow) and from a freebsd 7.2 box (gw). I've tried replacing the fxp0 interface in the FreeBSD-8 stable box with an em0 interface and it works with the FreeBSD 7.2 box but the same problem from the Snow Leopard box. The bad neighbor solicitation messages keep increasing with the IPv6 pings. Any other thing I can collect to troubleshoot? Thanks, Tom glow pusateri$ ping6 crag PING6(56=40+8+8 bytes) 2610:28:1800:4001:225:ff:fef1:7305 --> 2610:28:1800:4001:20e:cff:fe9f:faad Request timeout for icmp_seq=0 Request timeout for icmp_seq=1 Request timeout for icmp_seq=2 Request timeout for icmp_seq=3 16 bytes from 2610:28:1800:4001:20e:cff:fe9f:faad, icmp_seq=4 hlim=63 time=0.784 ms Request timeout for icmp_seq=5 Request timeout for icmp_seq=6 Request timeout for icmp_seq=7 Request timeout for icmp_seq=8 16 bytes from 2610:28:1800:4001:20e:cff:fe9f:faad, icmp_seq=9 hlim=63 time=0.633 ms Request timeout for icmp_seq=10 Request timeout for icmp_seq=11 Request timeout for icmp_seq=12 Request timeout for icmp_seq=13 16 bytes from 2610:28:1800:4001:20e:cff:fe9f:faad, icmp_seq=14 hlim=63 time=0.654 ms Request timeout for icmp_seq=15 ^C --- crag.foo.com ping6 statistics --- 17 packets transmitted, 3 packets received, 82.4% packet loss round-trip min/avg/max/std-dev = 0.633/0.690/0.784/0.067 ms tcp: 153 packets sent 146 data packets (31776 bytes) 3 data packets (240 bytes) retransmitted 1 data packet unnecessarily retransmitted 0 resends initiated by MTU discovery 4 ack-only packets (2 delayed) 0 URG only packets 0 window probe packets 0 window update packets 0 control packets 196 packets received 137 acks (for 31777 bytes) 6 duplicate acks 0 acks for unsent data 52 packets (4277 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 0 connection requests 1 connection accept 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 1 connection established (including accepts) 4 connections closed (including 0 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 137 segments updated rtt (of 73 attempts) 2 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 0 correct ACK header predictions 50 correct data packet header predictions 1 syncache entry added 0 retransmitted 1 dupsyn 0 dropped 1 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 1 cookie sent 0 cookies received 1 SACK recovery episode 1 segment rexmit in SACK recovery episodes 48 byte rexmits in SACK recovery episodes 7 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 169 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 1 dropped due to no socket 23 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 145 delivered 134 datagrams output 0 times multicast source filter matched sctp: 0
Re: vge problem
On Thu, Dec 10, 2009 at 01:52:49PM -0800, Pyun YongHyeon wrote: > On Tue, Dec 08, 2009 at 10:08:36AM -0800, Pyun YongHyeon wrote: > > On Tue, Dec 08, 2009 at 10:52:07AM +0900, Yoshiaki Kasahara wrote: > > > On Fri, 4 Dec 2009 10:43:01 -0800, > > > Pyun YongHyeon said: > > > > > > >> before I replaced vge(4). I guess the system froze while initializing > > > >> vge(4), but I'm not really sure actually. > > > > > > > > Yes, that's also possible. But I can't explain how the patch can > > > > freeze the box. Another user also reported the similar vge(4) issue > > > > in private mail and tried the same patch and he could successfully > > > > boot with patched vge(4). Unfortunately the issue does not seem to > > > > fix his issue. I'm still working on it. > > > > > > > >> > > > >> What can I do to narrow the cause of problems? Is it useful to build > > > >> kernel with options KDB and DDB? > > > >> > > > > > > > > Yes. > > > > > > Ok, now I'm ready to boot a DDB enabled kernel to try kernel debugging > > > on my PC. I can't read email during debugging my PC under current > > > configuration, so could you please tell me any specific instructions > > > to collect information you need? I'm reading the Handbook now, but I'm > > > not very sure... > > > > > > > Sorry, another user also reported similar problem in my patch. I > > have to look closely before doing any further testing. Since I've > > ordered the controller I would get access to hardware in near > > future. I'll let you know when I have a working patch. > > > > FYI: I received ordered hardware and fixed the patch to make it > work again. Try the patch at the following URL. > http://people.freebsd.org/~yongari/vge/vge.busdma.diff2 > > The TCP/UDP bulk Tx performance seem to be really poor(less than > 700Mbps) and vge(4) generates too many interrupts(more than 40k > interrupts/s). Rx performance looks reasonable(about 928Mbps) > though. I'll have to see what triggers its poor Tx performance > after fixing TCP connection stall issue. While reading the code again I found some suspicious part which could be related with your issue. The controller's CMZ field has 3bits so it can handle 7 fragments of a TX frame. However, controller wants to see number of fragments + 1 in this field which means we can't use all 7 fragments in a TX descriptor. I changed the patch to reduce number of TX fragments to 6. Does the following patch make any difference for you? http://people.freebsd.org/~yongari/vge/vge.busdma.diff3 ___ 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: vge problem
On Tue, Dec 08, 2009 at 10:08:36AM -0800, Pyun YongHyeon wrote: > On Tue, Dec 08, 2009 at 10:52:07AM +0900, Yoshiaki Kasahara wrote: > > On Fri, 4 Dec 2009 10:43:01 -0800, > > Pyun YongHyeon said: > > > > >> before I replaced vge(4). I guess the system froze while initializing > > >> vge(4), but I'm not really sure actually. > > > > > > Yes, that's also possible. But I can't explain how the patch can > > > freeze the box. Another user also reported the similar vge(4) issue > > > in private mail and tried the same patch and he could successfully > > > boot with patched vge(4). Unfortunately the issue does not seem to > > > fix his issue. I'm still working on it. > > > > > >> > > >> What can I do to narrow the cause of problems? Is it useful to build > > >> kernel with options KDB and DDB? > > >> > > > > > > Yes. > > > > Ok, now I'm ready to boot a DDB enabled kernel to try kernel debugging > > on my PC. I can't read email during debugging my PC under current > > configuration, so could you please tell me any specific instructions > > to collect information you need? I'm reading the Handbook now, but I'm > > not very sure... > > > > Sorry, another user also reported similar problem in my patch. I > have to look closely before doing any further testing. Since I've > ordered the controller I would get access to hardware in near > future. I'll let you know when I have a working patch. > FYI: I received ordered hardware and fixed the patch to make it work again. Try the patch at the following URL. http://people.freebsd.org/~yongari/vge/vge.busdma.diff2 The TCP/UDP bulk Tx performance seem to be really poor(less than 700Mbps) and vge(4) generates too many interrupts(more than 40k interrupts/s). Rx performance looks reasonable(about 928Mbps) though. I'll have to see what triggers its poor Tx performance after fixing TCP connection stall issue. ___ 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.1: QUOTA: kernel panics in jailed()
On Wed, 9 Dec 2009 15:52:23 -0600 Mike Pritchard wrote: > On Mon, Dec 07, 2009 at 10:23:49AM +0200, Mikolaj Golub wrote: >> On Sun, 6 Dec 2009 20:18:13 +0200 Kostik Belousov wrote: >> >> > The kernel paniced because chkdq was supplied NULL credentials and >> > _positive_ blocks use count change. Line 276 calls chkdq with >> > -datablocks as the change. This could happen if you have problems >> > either with hardware (e.g. memory or CPU cache), or your fs >> > is damaged. >> > >> > Another possibility is random corruption of the kernel memory, but >> > I recommend to start with fsck and then continue with memory testers >> > if fsck have shown no problems. >> >> We have checked FS -- looks OK. So far we have just rebooted to the kernel >> without quota. To check the hardware is in our plans. Thank you. > > Did you happen to turn quotas off then back on for the file system in > question? Do you mean at the moment of the crash? No, our admins were far from the host then :-). -- Mikolaj Golub ___ 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: pf: unlocked lookup
Hello! On Thu, Dec 10, 2009 at 10:22:09AM -0800, Derek Kulinski wrote: > Hello Max, > > Thursday, December 10, 2009, 9:38:41 AM, you wrote: > > > this is a generic informational message that was put into the code to figure > > out if the hack that is "debug.pfugidhack" is actually required. You can > > get > > rid of the message by setting the debug level of pf to something below > > "misc" > > (e.g. pfctl -x urgent). > > Well, the hack actually is required, my system crashes when I disable > it. Please note that depending on workload and actual rules the hack may do more harm than good. We had some machines which were deadlocking[1] in minutes with hack enabled but were almost stable without it. Anyway, the only safe solution right now is to avoid uid/gid rules. [1] http://lists.freebsd.org/pipermail/freebsd-net/2009-October/023350.html Maxim Dounin ___ 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: atheros problem
I found more - apparently 802.11a works (there are no 11a nodes at work, but the box connects at home where I have a dual-band AP.) So the problem I see is specific to g (and not auth mode since at work we have all of open, wpa, wpa2, wep visible.) wlandebug sheds no light on the problem. I still think it stems from the update to ah_regdomain.c since all worked fine before that. I'm not specifying a default realm but when I specified US in ifconfig once it didn't help. To reiterate: the problem is that ifconfig scan never returns (^c does make it exit...) and never sees a AP at work where we have between 7 and 20 visible 7x24. It is as if the 11g receiver is completely disabled. ... To answer my improper second bug in the original note - I worked around with debug.acpi.disable="ec" and got rid of the panic. Doesn't help with the real issue, of course, but at least I can use the laptop. -- Pete ___ 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: pf: unlocked lookup
Hello Max, Thursday, December 10, 2009, 9:38:41 AM, you wrote: > this is a generic informational message that was put into the code to figure > out if the hack that is "debug.pfugidhack" is actually required. You can get > rid of the message by setting the debug level of pf to something below "misc" > (e.g. pfctl -x urgent). Well, the hack actually is required, my system crashes when I disable it. > The pfugidhack is automatically enabled when you use rules with user or group > filters. These rules are a layering violation and the hack is required to > make them work. I'd rather get rid of them altogether, but since it is a much > demanded functionality we introduced the workaround instead. > Just lower the debugging level (s.a.), ignore the messages, or rebuild your > kernel/pf module with the respective DPRINTF lines (sys/contrib/pf/net/pf.c) > commented out. I might just move them to the loud level in the main tree, > though. So if I understand correctly, chances of fixing the workaround are really small? At least now I know how to disable those messages, thanks. -- Best regards, Derekmailto:tak...@takeda.tk Come to think of it, there are already a million monkeys on a million typewriters, and Usenet is *nothing* like Shakespeare. -- Blair Houghton ___ 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: pf: unlocked lookup
Hello Derek, On Thursday 10 December 2009 04:45:12 Derek Kulinski wrote: > My console gets flooded by "pf: unlocked lookup" message anyone knows > what circumstances cause this message, so I could figure out which pf > rule is causing it? this is a generic informational message that was put into the code to figure out if the hack that is "debug.pfugidhack" is actually required. You can get rid of the message by setting the debug level of pf to something below "misc" (e.g. pfctl -x urgent). > After searching on google I found few people asking about it, though no > real answer. The first result talks about debug.pfugidhack being set to > 1. > > It is set to 1 on my system, though I don't have anything in > /etc/syctl.conf, also when I switched it to 0, the system crashed within > an hour or so. > > Is this somehow related to rules that have rules with attached to a > specific user? The pfugidhack is automatically enabled when you use rules with user or group filters. These rules are a layering violation and the hack is required to make them work. I'd rather get rid of them altogether, but since it is a much demanded functionality we introduced the workaround instead. Just lower the debugging level (s.a.), ignore the messages, or rebuild your kernel/pf module with the respective DPRINTF lines (sys/contrib/pf/net/pf.c) commented out. I might just move them to the loud level in the main tree, though. Regards, -- Max ___ 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: ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309
On Thu, Dec 10, 2009 at 08:48:31AM -0500, John Baldwin wrote: > Hmmm, there isn't anything CPU-specific in ULE vs 4BSD, and I would expect > ULE to work fine on a PIII. I would generally expect device timeouts to be > more of a driver issue than a scheduler issue. We've run nodes in the package build cluster on ULE for years. mcl ___ 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
Squirrel wrote: > I do have most of measure you've mentioned implemented. There is one website > that is required to have register_global, which I have set on his > directory/.htaccess to prevent site-wide. Currently, I'm in process of > upgrading all my ports. > Don't forget to check vulnerable php codes for SQL injection, LFI/RFI, problematic file uploads etc. Ganbold > Thanks for info. > > > -Original message- > From: Matthew Seaman m.sea...@infracaninophile.co.uk > Date: Thu, 10 Dec 2009 02:24:34 -0600 > To: squir...@isot.com > Subject: Re: Hacked - FreeBSD 7.1-Release > > >> Squirrel wrote: >> >>> I've just finished the rtld patch. Now in process of regenerating >>> all the keys and certs. Next will look into php. But far as rtld >>> vulnerability, doesn't it require at least a local user account? >>> Looking at all the authentication, there wasn't any authenticated >>> session during the time frame. So I'm leaning more towards php >>> 5.2.9, and checking all my ports. >>> >> You don't necessarily need to have a login session (ie. recorded in wtmp) >> to exploit the rtld bug -- just control over some process and the ability >> to run commands through it. Although the rtld bug is "only" a local root >> compromise, since it is so simple to exploit it is a lot more dangerous >> than most, and in combination with just about any form of remote exploit >> it means your box get rooted. >> >> Upgrading PHP and all ports is a good move. portaudit(1) is a good idea >> but it doesn't necessarily address the direct route your attackers used_ >> My suspicions (in the absence of any detailed forensic examination of >> your machine) are that you are running some vulnerable PHP code. This >> may be part of a well known application, or it may be something locally >> written. >> >> In this case, I'd recommend a number of measures: >> >>* Run a security scanner like nikto (ports: security/nikto) >> against each of the websites on your server. Do this at >> regular intervals, and take action to fix any problems it >> discovers. >> >>* Make sure that you only grant the minimum necessary permissions >> on the filesystem to allow apache to run your applications. In >> general, everything under your doc root should be *readable* by >> uid www but not *writable* -- don't be seduced by the idea of >> making the webroot owned by www:www --- root:wheel is a much >> better idea, and files should be mode 644, directories mode 755 >> unless there's a good reason to have them otherwise. >> >>* Refuse to run any PHP application that requires you to have >> 'register_globals = YES' or to similarly poke enormous holes >> in security through php.ini. Any application developer that >> has not modified their code to use the $GLOBALS array by now >> is lazy and incompetent and their code is likely to have all >> sorts of other holes. >> >>* Similarly give your web application only the minimum necessary >> permissions it needs to access any databases. You'll frequently >> see instructions to do things like: 'GRANT ALL PRIVILEGES ON foo.* >> TO w...@localhost WITH GRANT OPTION;' This is way too much and should >> be trimmed down. Web apps rarely have any need to make schema >> changes, and creating other UIDs is right out, so >> 'GRANT SELECT,INSERT,UPDATE,DELETE ON foo.* TO w...@localhost' is a >> much more reasonable starting point. >> >>* Where a web application has a legitimate reason to want to write >> to the filesystem (eg. uploading files), preferably confine the >> write access to a separate directory tree outside the web root -- >> /tmp or /var/tmp aren't bad choices, but it might be better to >> create a specific location for a particular application. >> >>* Where a web application has an administrative mode preferably >> arrange to run this over HTTPS thus protecting any passwords >> from snooping. If the administrative mode needs to have generic >> read/write access to the web tree, then consider running it in a >> completely separate Apache instance with different user credentials >> than the generally accessible web server. >> >> Making the last point work with some arbitrary web application is >> frequently challenging, but usually at least possible by a combination >> of mod_rewrite and mod_proxy functions in the Apache config. >> >> Cheers, >> >> Matthew >> >> -- >> Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard >> Flat 3 >> PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate >> Kent, CT11 9PW >> >> >> >> > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-st
Re: Hacked - FreeBSD 7.1-Release
I do have most of measure you've mentioned implemented. There is one website that is required to have register_global, which I have set on his directory/.htaccess to prevent site-wide. Currently, I'm in process of upgrading all my ports. Thanks for info. -Original message- From: Matthew Seaman m.sea...@infracaninophile.co.uk Date: Thu, 10 Dec 2009 02:24:34 -0600 To: squir...@isot.com Subject: Re: Hacked - FreeBSD 7.1-Release > Squirrel wrote: > > I've just finished the rtld patch. Now in process of regenerating > > all the keys and certs. Next will look into php. But far as rtld > > vulnerability, doesn't it require at least a local user account? > > Looking at all the authentication, there wasn't any authenticated > > session during the time frame. So I'm leaning more towards php > > 5.2.9, and checking all my ports. > > You don't necessarily need to have a login session (ie. recorded in wtmp) > to exploit the rtld bug -- just control over some process and the ability > to run commands through it. Although the rtld bug is "only" a local root > compromise, since it is so simple to exploit it is a lot more dangerous > than most, and in combination with just about any form of remote exploit > it means your box get rooted. > > Upgrading PHP and all ports is a good move. portaudit(1) is a good idea > but it doesn't necessarily address the direct route your attackers used. > My suspicions (in the absence of any detailed forensic examination of > your machine) are that you are running some vulnerable PHP code. This > may be part of a well known application, or it may be something locally > written. > > In this case, I'd recommend a number of measures: > >* Run a security scanner like nikto (ports: security/nikto) > against each of the websites on your server. Do this at > regular intervals, and take action to fix any problems it > discovers. > >* Make sure that you only grant the minimum necessary permissions > on the filesystem to allow apache to run your applications. In > general, everything under your doc root should be *readable* by > uid www but not *writable* -- don't be seduced by the idea of > making the webroot owned by www:www --- root:wheel is a much > better idea, and files should be mode 644, directories mode 755 > unless there's a good reason to have them otherwise. > >* Refuse to run any PHP application that requires you to have > 'register_globals = YES' or to similarly poke enormous holes > in security through php.ini. Any application developer that > has not modified their code to use the $GLOBALS array by now > is lazy and incompetent and their code is likely to have all > sorts of other holes. > >* Similarly give your web application only the minimum necessary > permissions it needs to access any databases. You'll frequently > see instructions to do things like: 'GRANT ALL PRIVILEGES ON foo.* > TO w...@localhost WITH GRANT OPTION;' This is way too much and should > be trimmed down. Web apps rarely have any need to make schema > changes, and creating other UIDs is right out, so > 'GRANT SELECT,INSERT,UPDATE,DELETE ON foo.* TO w...@localhost' is a > much more reasonable starting point. > >* Where a web application has a legitimate reason to want to write > to the filesystem (eg. uploading files), preferably confine the > write access to a separate directory tree outside the web root -- > /tmp or /var/tmp aren't bad choices, but it might be better to > create a specific location for a particular application. > >* Where a web application has an administrative mode preferably > arrange to run this over HTTPS thus protecting any passwords > from snooping. If the administrative mode needs to have generic > read/write access to the web tree, then consider running it in a > completely separate Apache instance with different user credentials > than the generally accessible web server. > > Making the last point work with some arbitrary web application is > frequently challenging, but usually at least possible by a combination > of mod_rewrite and mod_proxy functions in the Apache config. > > Cheers, > > Matthew > > -- > Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard > Flat 3 > PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate > Kent, CT11 9PW > > > ___ 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: ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309
On Wednesday 09 December 2009 8:52:06 pm Chris H wrote: > On Wed, December 9, 2009 6:50 am, John Baldwin wrote: > > On Tuesday 08 December 2009 7:06:18 pm Chris H wrote: > > > >> Greetings, > >> I am receiving the following in dmesg (verbose) during boot in 8-RELEASE > >> (GENERIC) > >> cvsuped 2009-12-08 @1am: ACPI Error: A valid RSDP was not found 20090521 > >> tbxfroot-309 > >> > >> As I create the KERNCONF for this machine, I want to confirm that this > >> message is caused by the fact that APM is shut off in the BIOS, and won't > >> cause any averse problems. We're having issues with "timeout" errors on > >> some > >> 50 TYAN server MB's > >> since 7-RELEASE regarding the disk media (no matter how many different > >> drives > >> we use). So as I attempt to create a STABLE - in the sense that the servers > >> are reliable, I want to eliminate any potential issues. > >> > >> more (informational) "noise" follows: > > > > You can ignore the message, I do think it is due to disabling ACPI in your > > BIOS. Do you have problems when ACPI is enabled? ACPI is generally going > > to > > be more reliable than !ACPI in the future as it seems many BIOS vendors no > > longer > > test the !ACPI case as much (e.g. I've seen Intel motherboards with > > incomplete > > or incorrect MP Tables because no commercial OS uses the MP Table anymore). > > Hello, and thank you very much for your reply. > So the message is simply "informative" - good to know. > As to the ACPI. Closer examination seemed to indicate the BIOS was incomplete. > While I could have flashed it, assuming that it 1) would have all current > updates > 2) it would then also be complete > I opted to simply take another new board off the shelf and try again. This > time, > taking your advice, and /enabling/ full ACPI. I performed an install, and just > now cvsupped src && ports. It's in the process of building world/kernel as I > write this reply. Hope all turns out well - "Fingers crossed". :) Ok. > If you (or anyone else) can tell me... > I have had issues with periodic "timeouts" with disks (SCSI,ATA && CD/DVD > ROMS) > ever since late 6. After experimenting with /many/ kernels. I'm left with the > suspicion the it has to do with SCHED_4BSD vs. SCHED_ULE. In other words, ever > since SCHED_ULE became default/preferred most of the PIII based boards have > exhibited this anomaly. Often the "retries" aren't exhausted, and they > recover. > But many times they don't which will lead to freeze that requires "bouncing" > the > machine, and performing FSCK(8). I haven't seen anything in UPDATING. But > wonder; > should I assume that anything in the PIII category /requires/ SCHED_4BSD. Or > would it be better to tune a kernel via SYSCTL(8)? Hmmm, there isn't anything CPU-specific in ULE vs 4BSD, and I would expect ULE to work fine on a PIII. I would generally expect device timeouts to be more of a driver issue than a scheduler issue. -- John Baldwin ___ 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: PCengines ALIX boot0sio serial input failes
On 12/10/2009 2:28 AM, Daniel Braniss wrote: >> On 12/9/2009 11:13 AM, Daniel Braniss wrote: >>> hi, >>> FreeBSD-8 works great on these boards, but there are some >>> gotchas, the boot and the serial: output works fine, but input >>> is 'problematic'. the pxeboot serial handling is ok, the boot menu >>> is ok, but booting off the CF (using boot0sio), the input 'screwy' >>> at the selection of partition it is ignored, at the OK: prompt >>> from the boot (i had no kernel in the slice), the input is usually >>> doubled: >>> sshooww instead of show >>> which is probably similar to what is happening with boot0sio but it >>> only echoes # (the current bell). >>> >>> Once the kernel is up, the serial works fine. >> >> The development version of pfSense (2.0) is running on FreeBSD 8.0 using >> NanoBSD and its serial input/output works pretty well on ALIX, the >> 2d3.2d13 version at least (and others, but those are the only two I have >> used personally). >> >> My test ALIX is at home unplugged at the moment, but based on what I see >> in the image file there are a few things that were done: >> >> /boot/device.hints contains: >> hint.uart.0.at="isa" >> hint.uart.0.port="0x3F8" >> hint.uart.0.flags="0x10" >> hint.uart.0.irq="4" >> >> /boot.config contains: >> -h >> >> The initial boot0cfg on an image is done with: >> boot0cfg -B -b /path/to/boot/boot0sio -o packet -s 1 -m 3 >> >> Here is what shows up when I mount an md device from a CF image: >> # boot0cfg -v /dev/md0 >> # flag start chs type end chs offset size >> 1 0x80 0: 1: 1 0xa5444: 15:63 63 448497 >> 2 0x00445: 1: 1 0xa5889: 15:63 448623 448497 >> 3 0x00890: 0: 1 0xa5991: 15:63 897120 102816 >> >> version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) >> options=packet,update,nosetdrv >> volume serial ID 9090-9090 >> default_selection=F1 (Slice 1) >> >> Seems to work pretty well there. If you want the details, you can check >> out the pfSense tools git repository which contains the build scripts >> that generate the images. > > I have the same /boot/device.hints. > can you confirm that > 1) when booting from CF, the boot0sio accepts input > 2) the /boot/boot accepts input from the serial? I can give serial input at any stage of booting, from the 1/2 boot slice choice, the loader (I can get an OK prompt), etc. I overlooked the "#" character you were getting when replying to this message before, that typically means it cannot read the partition for some reason, not that it isn't accepting input. If this were a WRAP I'd say it might also be packet vs nopacket mode when booting, but every ALIX I've had my hands on will boot pfSense images with packet mode on the most current BIOS (0.99h). You might try using a pfSense 2.0/FreeBSD 8 snapshot on a CF to see if it exhibits the same behavior as your CF image. They should be available from http://snapshots.pfsense.org/ There are also images for pfSense 1.2.3/FreeBSD 7.2 available on the normal download mirrors from http://pfsense.org if you want to try those out. Just grab an image sized for your CF (or smaller). Jim ___ 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: PCengines ALIX boot0sio serial input failes
On 12/10/2009 2:32 AM, Daniel Braniss wrote: >> Which ALIX board exactly? There are some differences (even various BIOSes). >> Any chance you have vga driver in kernel? TinyBIOS emulates VGA a bit, >> redirects output to serial port. If at the beginning you are trying both VGA >> and serial port, output is doubled. Similar behavior is observed on older >> WRAP boards, too. > > I have tried ALIX-1 and 2 > here is an example: > > PC Engines ALIX.3 v0.99h > 640 KB Base Memory > 261120 KB Extended Memory > Waiting for HDD ... > > 01F0 Master 848A SanDisk SDCFH2-002G > Phys C/H/S 3970/16/63 Log C/H/S 992/64/63 > > 1 FreeBSD > 2 FreeBSD > 3 FreeBSD > > 6 PXE > Boot: 1 > > any key I hit, it echoes as # and is ignored. > at this point the kernel is not yet involved, so having vga+kb support > is not the reason, though I will try out the alix-3, which has vga support, > and > a different BIOS soon. A lot of users have seen that happen, but typically it has been cleared up by using ALIX BIOS v0.99h, which that box already appears to have, and setting the BIOS for CHS mode. I haven't tried any of the ALIX models with VGA, but I have heard they are working as long as you set the BIOS for APM power management. (See the previous -STABLE thread titled "8.0-rc2 dropped hardsupport". Jim ___ 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"
cannot alter 'to' addess in email on 8.0
Only just noticed this, but there seems to be a small, but annoying, pieece of breakage in email under 8.0 try and send a simple piece of email, type a few lines, then use '~h' to try and change the 'to' header (or any of them actually). what you get is a set of blank headers, instead of the original values to edit. It also doesnt always seem to hold any values typed in, as I foudn this out by having two bits of email dumped after trying to edit the 'to' headers. have not been able to reproduce that reliably though :-( -pete. ___ 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
As long as you have to re-install everything from scratch, you can consider installing 8.0 and having your services jailed. The new jail is announced to be much improved. Markiyan. Paul Procacci wrote: >> But far as rtld vulnerability, doesn't it require at least a local user account? No, it requires a script and a kiddie. ;) You'd expect your "index.php" (or similar) files would require a ftp/ssh/telnet connection, but useful "kids" have useful resources 'n which these things are not always required. Anyone can execute any code (apparently) on your machine via the exploit, having anything they want running on your machine, (i.e. that can set their env to whatever they want and get access to your machine pre -p5. Your safest bet especially since you weren't patched to the latest FreeBSD version which includes the rtld patch, is to simply not trust your machine at all; regardless of whether you are patching it now or not. I'd personally save your data, reformat the machine, and reinstall the items you need. ~Cheers This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/emaildisclaimer.aspx for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Dell PowerEdge Virtual Media
- Original Message - From: "Stuart Barkley" Does anyone here find this stuff useful? Yes its is very useful for remote installs etc but it doest have its limitations when it doesnt play nice with the OS. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Dell PowerEdge Virtual Media
Stuart Barkley wrote: On Tue, 8 Dec 2009 at 20:07 -, Miroslav Lachman wrote: Virtual Media / Virtual Console from all vendors is paint in the [...] So I am disapointed by this hyped feature ;( Does anyone here find this stuff useful? We have a vendor pushing "Virtual Media" on us and I don't see the point at all. I also don't see the point of the screen scraping and graphics virtual display support. It would be useful in our environment if 100% functional. It allows us to remotely do everything with the server - deploy new OS from new media, change BIOS settings, recovery from failure when server boots in to single user etc. All this meens shorter downtime for us without need to drive to the datacenter. I've just started playing with IPMI capable motherboard and another system with an IPMI add in card. Seems like at lot of extra stuff I need to disable to secure my operations. nmap shows ssh, http, https, portmap and some other ports of unknown purpose (plus the silly thing was configured to send email to the manufacture). The web interface is a little useful, but not when dealing with several hundred systems. It is better to have it in private LAN (VPN) or firewalled, not allowing public access to management interfaces. [...] Miroslav Lachman ___ 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
>> But far as rtld vulnerability, doesn't it require at least a local user account? No, it requires a script and a kiddie. ;) You'd expect your "index.php" (or similar) files would require a ftp/ssh/telnet connection, but useful "kids" have useful resources 'n which these things are not always required. Anyone can execute any code (apparently) on your machine via the exploit, having anything they want running on your machine, (i.e. that can set their env to whatever they want and get access to your machine pre -p5. Your safest bet especially since you weren't patched to the latest FreeBSD version which includes the rtld patch, is to simply not trust your machine at all; regardless of whether you are patching it now or not. I'd personally save your data, reformat the machine, and reinstall the items you need. ~Cheers This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/emaildisclaimer.aspx for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ 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: PCengines ALIX boot0sio serial input failes
Am 09.12.2009 um 17:13 schrieb Daniel Braniss: [B]ooting off the CF (using boot0sio), the input 'screwy' at the selection of partition it is ignored, at the OK: prompt from the boot (i had no kernel in the slice), the input is usually doubled: sshooww instead of show which is probably similar to what is happening with boot0sio but it only echoes # (the current bell). I've seen this happening when the BIOS also tries to talk to the serial port at the same time. Try changing the BIOS to stop doing console redirection once it starts booting, or replace boot0sio with boot0, and change boot(8) and loader(8) to only use the serial or BIOS console, but not both. Since I don't dual-boot anymore, I've replaced boot0 with a standard MBR, and start off with boot(8) on all machines. HTH, Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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 Wed, Dec 09, 2009 at 06:40:17PM -0600, Squirrel wrote: > My server was hacked, and the hacker was nice enough to not cause damage > except changing index.php of couple of my websites. The index.php had the > following info: > > "Hacked By Top > First Warning That's Bug From Your Servers > Next Time You Must Be Careful And Fixed Your Site Before Coming Another > Hacker And Hacked You Again > Sorry Admin And Don't Worry Just I Change Index > ALTBTA > For Contact : l...@hotmail.com > Best Wishes" > > Of course, I sent him email, just in case it's valid, asking how he did it or > how should I patch things up. But haven't got a reply yet. I've looked at > all the log files, particularly auth.log, although there were thousands of > login attempts to SSH and FTP, but none succeeded. And I don't know where > else to look, please help. > > I'm using FreeBSD 7.1-Release with below daemons > > Apache 2.2.11 > ProFTP 1.32 > OpenSSH 5.1 > Webmin 1.480 > MySQL 5.0.67 > BIND 9.6.0 > ___ > 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" 1) Immediately disable all forms of network connectivity from the Internet to this box. Do it physically if possible, otherwise cross your fingers (that nothing low-level got tinkered with) and use pf. 2) Format the box + reinstall OS. Don't bother trying to "fix up what may have been changed", nor simply rebuilding world/kernel + rebooting. There is absolutely no guarantee the individual did not backdoor something, including libraries or even replace kernel modules. Don't risk it: reinstall the entire OS and rebuild from scratch, or restore necessary (non-OS) pieces from backups (assuming you know absolutely 100% for sure when the person "hacked the box" -- chances are it could've been hacked long before the person told you and your backups contain the same backdoors). Don't have backups? Use this situation as justification for 'em. :-) -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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
Squirrel wrote: My server was hacked, and the hacker was nice enough to not cause damage except changing index.php of couple of my websites. The index.php had the following info: "Hacked By Top First Warning That's Bug From Your Servers Next Time You Must Be Careful And Fixed Your Site Before Coming Another Hacker And Hacked You Again Sorry Admin And Don't Worry Just I Change Index ALTBTA For Contact : l...@hotmail.com Best Wishes" i won't be sure he has changed only indexes, it's a good rule to check carefully every other file or revert to a backup precedent to the hacking. Of course, I sent him email, just in case it's valid, asking how he did it or how should I patch things up. But haven't got a reply yet. I've looked at all the log files, particularly auth.log, although there were thousands of login attempts to SSH and FTP, but none succeeded. And I don't know where else to look, please help. I'm using FreeBSD 7.1-Release with below daemons Apache 2.2.11 ProFTP 1.32 OpenSSH 5.1 Webmin 1.480 MySQL 5.0.67 BIND 9.6.0 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. check (if you have them) logs of urls requested and mysql errors, the answer could be find here probably. regards ocean ___ 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"
