Re: Dell PowerEdge Virtual Media
For the record this appears to have been fixed in 8.1-BETA so we can now successfully use the fixit CD mounted from an iso under the IPMI tool on our supermicro machines. It even fixes the issue where previously you had to select device rescan for it to see the usb cdrom after boot :) - Original Message - From: "Steven Hartland" The ipmi implementation is limited to CD-sized media on the Supermicro ipKVM implementations. Try the CD boot media ISO. If thats the case why can it happily boot from it? The issue only seemed to occur here when you tried to access it via the fixit menu even though the console log showed it as being detected just fine. I've just retested on the machine now its up and running and see similar results with both dvd's and cdroms. Connect dvd iso: Dec 9 02:21:27 ipmitest root: Unknown USB device: vendor 0x14dd product 0x0002 bus uhub3 Dec 9 02:21:27 ipmitest kernel: ugen3.2: at usbus3 Dec 9 02:21:27 ipmitest kernel: umass0: on usbus3 Dec 9 02:21:27 ipmitest kernel: umass0: SCSI over Bulk-Only; quirks = 0x Dec 9 02:21:28 ipmitest kernel: umass0:1:0:-1: Attached to scbus1 Dec 9 02:21:28 ipmitest kernel: ums0: on usbus3 Dec 9 02:21:28 ipmitest kernel: ums0: 3 buttons and [Z] coordinates ID=0 Dec 9 02:21:28 ipmitest kernel: ukbd0: on usbus3 Dec 9 02:21:28 ipmitest kernel: kbd2 at ukbd0 Dec 9 02:21:28 ipmitest kernel: (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 Dec 9 02:21:28 ipmitest kernel: (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error Dec 9 02:21:28 ipmitest kernel: (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition Dec 9 02:21:28 ipmitest kernel: (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:29,0 Dec 9 02:21:28 ipmitest kernel: (probe0:umass-sim0:0:0:0): Power on, reset, or bus device reset occurred Dec 9 02:21:28 ipmitest kernel: (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) Dec 9 02:21:28 ipmitest kernel: cd0 at umass-sim0 bus 0 target 0 lun 0 Dec 9 02:21:28 ipmitest kernel: cd0: Removable CD-ROM SCSI-3 device Dec 9 02:21:28 ipmitest kernel: cd0: 40.000MB/s transfers Dec 9 02:21:28 ipmitest kernel: cd0: cd present [1058105 x 2048 byte records] Attempt to mount: Dec 9 02:23:58 ipmitest kernel: (cd0:umass-sim0:0:0:0): READ TOC/PMA/ATIP. CDB: 43 0 0 0 0 0 0 0 4 0 Dec 9 02:23:58 ipmitest kernel: (cd0:umass-sim0:0:0:0): CAM Status: SCSI Status Error Dec 9 02:23:58 ipmitest kernel: (cd0:umass-sim0:0:0:0): SCSI Status: Check Condition Dec 9 02:23:58 ipmitest kernel: (cd0:umass-sim0:0:0:0): UNIT ATTENTION asc:29,0 Dec 9 02:23:58 ipmitest kernel: (cd0:umass-sim0:0:0:0): Power on, reset, or bus device reset occurred Dec 9 02:23:58 ipmitest kernel: (cd0:umass-sim0:0:0:0): Retries Exhausted Dec 9 02:23:59 ipmitest kernel: g_vfs_done():cd0[READ(offset=32768, length=2048)]error = 5 disconnect iso: Dec 9 02:26:50 ipmitest kernel: ugen3.2: at usbus3 (disconnected) Dec 9 02:26:50 ipmitest kernel: umass0: at uhub3, port 6, addr 2 (disconnected) Dec 9 02:26:50 ipmitest kernel: (cd0:umass-sim0:0:0:0): lost device Dec 9 02:26:50 ipmitest kernel: (cd0:umass-sim0:0:0:0): removing device entry Dec 9 02:26:50 ipmitest kernel: ums0: at uhub3, port 6, addr 2 (disconnected) Dec 9 02:26:50 ipmitest kernel: ukbd0: at uhub3, port 6, addr 2 (disconnected) Dec 9 02:26:51 ipmitest kernel: ugen3.2: at usbus3 Dec 9 02:26:51 ipmitest kernel: ums0: on usbus3 Dec 9 02:26:51 ipmitest kernel: ums0: 3 buttons and [Z] coordinates ID=0 Dec 9 02:26:51 ipmitest kernel: ukbd0: on usbus3 Dec 9 02:26:51 ipmitest kernel: kbd2 at ukbd0 Dec 9 02:28:10 ipmitest kernel: ugen3.2: at usbus3 (disconnected) Dec 9 02:28:10 ipmitest kernel: ums0: at uhub3, port 6, addr 2 (disconnected) Dec 9 02:28:10 ipmitest kernel: ukbd0: at uhub3, port 6, addr 2 (disconnected) connect cdrom iso: Dec 9 02:28:11 ipmitest root: Unknown USB device: vendor 0x14dd product 0x0002 bus uhub3 Dec 9 02:28:11 ipmitest kernel: ugen3.2: at usbus3 Dec 9 02:28:11 ipmitest kernel: umass0: on usbus3 Dec 9 02:28:11 ipmitest kernel: umass0: SCSI over Bulk-Only; quirks = 0x Dec 9 02:28:13 ipmitest kernel: umass0:1:0:-1: Attached to scbus1 Dec 9 02:28:13 ipmitest kernel: ums0: on usbus3 Dec 9 02:28:13 ipmitest kernel: ums0: 3 buttons and [Z] coordinates ID=0 Dec 9 02:28:13 ipmitest kernel: ukbd0: on usbus3 Dec 9 02:28:13 ipmitest kernel: kbd2 at ukbd0 Dec 9 02:28:13 ipmitest kernel: (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 Dec 9 02:28:13 ipmitest kernel: (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error Dec 9 02:28:13 ipmitest kernel: (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition Dec 9 02:28:13 ipmitest kernel: (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:29,0 Dec 9 02:28:13 ipmitest kernel: (probe0:umass-sim0:0:0:0): Power on, reset, or bus device reset occurred Dec 9 02:28:13 ipmitest kernel: (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) Dec 9 02:28:13 ipm
Re: Dell PowerEdge Virtual Media
Steven Hartland wrote: > For the record this appears to have been fixed in 8.1-BETA so we can > now successfully use the fixit CD mounted from an iso under the IPMI > tool on our supermicro machines. It even fixes the issue where > previously you had to select device rescan for it to see the usb > cdrom after boot :) It should be SVN rev 203108 of 2010-01-28. -- 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"
Re: FreeBSD eats 169.254.x.x addressed packets
On 06/08/2010 03:00 PM, Stephen Clark wrote: On 06/08/2010 02:49 PM, Peter C. Lai wrote: On 2010-06-08 11:44:29AM -0700, Jeremy Chadwick wrote: On Tue, Jun 08, 2010 at 02:26:10PM -0400, Stephen Clark wrote: On 06/08/2010 02:05 PM, Jeremy Chadwick wrote: On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when 4.9 didn't? The following output would help: - ifconfig -a - netstat -rn - Contents of /etc/rc.conf Also, be aware that RELENG_6 is to be EOL'd at the end of this year: http://security.freebsd.org/ Hi Jeremy, I am not sure that information is relevant. We have two systems configured identically one using 4.9 the other 6.3. My concern was that someone had botched something up in rc.conf or during the OS upgrade/migration, resulting in there being no loopback interface. I also wanted to verify that your routing table looked correct for what ifconfig showed. Other users pointed you to RFC 3927. Wikipedia has this to say: http://en.wikipedia.org/wiki/Link-local_address "Based on RFC 3927, IPv4 uses the 169.254.0.0/16 range of addresses. However, the first and last /24 subnet (256 addresses each) in this block have been excluded from use and are reserved by the standard.[1]" I read this to mean 169.254.0.0/24 and 169.254.255.0/24. Your previous ifconfig statement shows: $ ifconfig rl0 rl0: flags=8843 mtu 1500 options=8 inet 192.168.129.1 netmask 0xff00 broadcast 192.168.129.255 inet 169.254.1.1 netmask 0x broadcast 169.254.255.255 ether 00:30:18:ae:7c:77 media: Ethernet autoselect (100baseTX) status: active With this configuration, you're using both the first and last /24 netblocks -- 169.254.0.0 for your network address, and 169.254.255.255 for your broadcast address. You should be able to avoid this by using 169.254.1.0/24. RFC 3927 also has complicated rules involving when one can or should not use a link-local address on the same interface as a routable IP, so at best your configuration may not be supported anyway. One should not use a link-local address as if it were under RFC 1918 rules, in particular because link-local involves self-assigned addresses and internal conflict mitigation. Again what happened we had a box in the field that was running 4.9 being used as a router/nat/vpn/firewall device. It was handing out ip addresses to the internal lan using the range 169.254.202.0/24, who knows why this address range was picked. It worked great but the hardware died, so we were replacing it with our current SW which is based on 6.3 we duplicated the configuration and have been struggling trying to get it to work for the customer since Saturday with no luck. Today I finally tried to ping the internal address from the box itself and it wouldn't ping, so I started trying using other addresses on the internal interface and they worked but not 169.254.202.1. In googling I discovered that 169.254/16 was supposed to be assigned if a box couldn't obtain an ip but saw nothing about an OS dropping them. So anyway I know the reason behind the change now. One final comment - I still don't understand why FreeBSD "won't" respond to pings when it has an address like 169.254.1.1. I can ssh to the unit but it won't respond to pings. I tried setting up a linux box with an address like 169.254.1.2 and it "would" respond to pings. -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) ___ 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: nfe0 loses network connectivity (8.0-RELEASE-p2)
On Mon 07 Jun 2010 at 22:48:46 +0300, Mikolaj Golub wrote: > It looks like the issue that has been fixed in STABLE. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/144330 Indeed, and I applied the patch in there, rebooted, and at least over the course of the past day, mbuf cluser useage seems not to grow anymore. Thanks! -Olaf. -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD eats 169.254.x.x addressed packets
On Wed, Jun 09, 2010 at 07:59:16AM -0400, Stephen Clark wrote: > On 06/08/2010 03:00 PM, Stephen Clark wrote: > >On 06/08/2010 02:49 PM, Peter C. Lai wrote: > >>On 2010-06-08 11:44:29AM -0700, Jeremy Chadwick wrote: > >>>On Tue, Jun 08, 2010 at 02:26:10PM -0400, Stephen Clark wrote: > On 06/08/2010 02:05 PM, Jeremy Chadwick wrote: > >On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: > >>Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when > >>4.9 didn't? > > > >The following output would help: > > > >- ifconfig -a > >- netstat -rn > >- Contents of /etc/rc.conf > > > >Also, be aware that RELENG_6 is to be EOL'd at the end of this year: > >http://security.freebsd.org/ > > > Hi Jeremy, > > I am not sure that information is relevant. We have two systems > configured > identically one using 4.9 the other 6.3. > >>> > >>>My concern was that someone had botched something up in rc.conf or > >>>during the OS upgrade/migration, resulting in there being no loopback > >>>interface. I also wanted to verify that your routing table looked > >>>correct for what ifconfig showed. > >>> > >>>Other users pointed you to RFC 3927. Wikipedia has this to say: > >>> > >>>http://en.wikipedia.org/wiki/Link-local_address > >>> > >>>"Based on RFC 3927, IPv4 uses the 169.254.0.0/16 range of addresses. > >>>However, the first and last /24 subnet (256 addresses each) in this > >>>block have been excluded from use and are reserved by the standard.[1]" > >>> > >>>I read this to mean 169.254.0.0/24 and 169.254.255.0/24. > >>> > >>>Your previous ifconfig statement shows: > >>> > $ ifconfig rl0 > rl0: flags=8843 mtu 1500 > options=8 > inet 192.168.129.1 netmask 0xff00 broadcast 192.168.129.255 > inet 169.254.1.1 netmask 0x broadcast 169.254.255.255 > ether 00:30:18:ae:7c:77 > media: Ethernet autoselect (100baseTX) > status: active > >>> > >>>With this configuration, you're using both the first and last /24 > >>>netblocks -- 169.254.0.0 for your network address, and 169.254.255.255 > >>>for your broadcast address. > >>> > >>>You should be able to avoid this by using 169.254.1.0/24. > >>> > >> > >>RFC 3927 also has complicated rules involving when one can or should not > >>use a link-local address on the same interface as a routable IP, so at > >>best your configuration may not be supported anyway. One should not use > >>a link-local address as if it were under RFC 1918 rules, in particular > >>because link-local involves self-assigned addresses and internal > >>conflict mitigation. > >> > >Again what happened we had a box in the field that was running 4.9 being > >used as a router/nat/vpn/firewall device. It was handing out ip addresses > >to the internal lan using the range 169.254.202.0/24, who knows why this > >address range was picked. It worked great but > >the hardware died, so we were replacing it with our current SW which is > >based on 6.3 we duplicated the configuration and have been struggling > >trying to > >get it to work for the customer since Saturday with no luck. Today I > >finally > >tried to ping the internal address from the box itself and it wouldn't > >ping, > >so I started trying using other addresses on the internal interface and > >they > >worked but not 169.254.202.1. In googling I discovered that 169.254/16 > >was supposed to be assigned if a box couldn't obtain an ip but saw > >nothing about > >an OS dropping them. > > > >So anyway I know the reason behind the change now. > > > One final comment - I still don't understand why FreeBSD "won't" respond to > pings > when it has an address like 169.254.1.1. I can ssh to the unit but it won't > respond to pings. I tried setting up a linux box with an address like > 169.254.1.2 and it "would" respond to pings. I tried to explain it as best as I could here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057191.html The IP stack (not a firewall, etc.) is basically blackholing the packet. -- | 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: FreeBSD eats 169.254.x.x addressed packets
One final comment - I still don't understand why FreeBSD "won't" respond to pings when it has an address like 169.254.1.1. I can ssh to the unit but it won't respond to pings. I tried setting up a linux box with an address like 169.254.1.2 and it "would" respond to pings. Linux is not really any measuring stick in standard compliance... -Reko ___ 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
On 12/08/09 12:41, Jeff Blank wrote: Hi, I'm having a little trouble using the "virtual media" function of Dell's PowerEdge R-series (R710 in this case) iDRAC6 under FreeBSD (7.1, 8.0). This is presented as /dev/cd0, a USB/"SCSI" device, I guess. This is in the dmesg buffer when I boot up the existing 7.1 installation with the virtual optical drive mapped to the 8.0-RELEASE amd64 DVD image: We're having some similar issues with our older PowerEdge 1850s (DRAC4). Things were alright on 6.3-RELEASE, but now there is a large hangup when trying to install 8.0-RELEASE: We see ~ 30x of these in dmesg: acd1: WARNING - READ_TOC read data overrun 20>12 Followed by this in sysinstall: "The disc in your drive looks more like an audio disc than a FreeBSD Release" (1). The DRAC Virtual Media and physical CDROM drives are probed like this in dmesg: acd1: DVR at ata2-slave PIO3 acd0: CDROM This is with the latest DRAC firmware available from Dell. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD eats 169.254.x.x addressed packets
On 06/09/2010 08:28 AM, Reko Turja wrote: One final comment - I still don't understand why FreeBSD "won't" respond to pings when it has an address like 169.254.1.1. I can ssh to the unit but it won't respond to pings. I tried setting up a linux box with an address like 169.254.1.2 and it "would" respond to pings. Linux is not really any measuring stick in standard compliance... -Reko ___ 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" But reading the RFC it says the packets should not be routed - I don't see where it says that pings should not be responded to. Think about it the RFC was for link local devices - shouldn't on device on a link be able to ping another device and get a response. -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD eats 169.254.x.x addressed packets
On 06/09/2010 08:28, Reko Turja wrote: >> One final comment - I still don't understand why FreeBSD "won't" >> respond to pings >> when it has an address like 169.254.1.1. I can ssh to the unit but it >> won't >> respond to pings. I tried setting up a linux box with an address like >> 169.254.1.2 and it "would" respond to pings. > > Linux is not really any measuring stick in standard compliance... > I do not believe that is what he was implying by comparing this to Linux. I think he might be using Linux as a example of "They have not limited their users to only changing source code" to get the objective completed. They should have. In this case and reviewing the previous messages + remembering these: http://bit.ly/9sigji http://bit.ly/9pfE9A http://bit.ly/9CNT3K FreeBSD takes the correct action for this scenario which could proudly be used as an exemplary piece of code that other forms of OS's should use as a reference for integrity. http://bit.ly/byHBzN Regards, -- jhell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD eats 169.254.x.x addressed packets
> > One final comment - I still don't understand why FreeBSD "won't" > > respond to pings > > when it has an address like 169.254.1.1. I can ssh to the unit but > > it won't > > respond to pings. I tried setting up a linux box with an address > > like > > 169.254.1.2 and it "would" respond to pings. > > Linux is not really any measuring stick in standard compliance... If 169.254.0.0/16 addresses are supposed to be link local then I'd definitely expect a reply to a ping from another box on the same LAN, sourced from another 169.254.0.0/16 address. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
(no subject)
Hi everyone! I have a problem to get my KDE4 Terminal working. I use a German keyboard, and I am not able to use some special keys. Especially I miss the pipe symbol ('|'), but there are some more like '§', '@', '€'. I compiled KDE on my own computer running a FreeBSD 8.0-STABLE kernel. All packages are up to date. Any hints? If I use an SSH connection (PuTTY), everything is fine. Thorsten Baumeister -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ 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: (no subject)
Hi Thorsten, On 9 June 2010 18:11, Thorsten Baumeister wrote: > Hi everyone! > I have a problem to get my KDE4 Terminal working. I use a German keyboard, > and I am not able to use some special keys. Especially I miss the pipe symbol > ('|'), but there are some more like '§', '@', '€'. I compiled KDE on my own > computer running a FreeBSD 8.0-STABLE kernel. All packages are up to date. > Any hints? If I use an SSH connection (PuTTY), everything is fine. I created a /etc/X11/xorg.conf file using # X -configure and added/changed the following section: Section "InputDevice" Identifier "Keyboard0" Driver "keyboard" Option "XkbModel" "pc105" Option "XkbLayout" "de" Option "XkbVariant" "nodeadkeys" Option "XkbOptions" "terminate:ctrl_alt_bksp" EndSection The last Option line isn't necessary, but it makes it possible to terminate the X server by pressing Ctrl+Alt+Backspace, which has been deactivated in recent default configurations. If you add the above mentioned Section "InputDevice", make sure that the Section "ServerLayout" contains a CoreKeyboard entry matching the given identifier. In my case, Section "ServerLayout" looks like: Section "ServerLayout" Identifier "XFree86 Configured" Screen 0 "Screen0" 0 0 InputDevice"Mouse0" "CorePointer" InputDevice"Keyboard0" "CoreKeyboard" Option "Clone" "off" EndSection HTH Christian Walther ___ 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: Resizing GPT partitions
Stephane Dupille wrote: > I dumped this disk image to a real machine, which has a 160 Go disk. > The system works fine, but I can only use 10 Go of disk space. How can > I gain more space ? > > How can I enlarge the last partition of the disk to use the whole disk ? > > I tried to create a new partition on the disk, and planned to add it > in the zfs pool, but that didn't work : > # gpart add -t freebsd-zfs -l disk0f ad0 > gpart: autofill: No space left on device > > That's odd, because it seems that gpart is aware of the new geometry. Currently there is no easy way to do it. GPT holds information about first and last usable sectors. You can see them in your output: > last: 20971486 > first: 34 You can look at freebsd-geom's mail list archive. There was a topic "OCE and GPT" with similar problem. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Dell PowerEdge Virtual Media
Try 8.1 to see if that helps, did here :) - Original Message - From: "Steve Polyack" We're having some similar issues with our older PowerEdge 1850s (DRAC4). Things were alright on 6.3-RELEASE, but now there is a large hangup when trying to install 8.0-RELEASE: We see ~ 30x of these in dmesg: acd1: WARNING - READ_TOC read data overrun 20>12 Followed by this in sysinstall: "The disc in your drive looks more like an audio disc than a FreeBSD Release" (1). The DRAC Virtual Media and physical CDROM drives are probed like this in dmesg: acd1: DVR at ata2-slave PIO3 acd0: CDROM This is with the latest DRAC firmware available from Dell. ___ 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" 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: FreeBSD eats 169.254.x.x addressed packets
> > > One final comment - I still don't understand why FreeBSD "won't" > > > respond to pings > > > when it has an address like 169.254.1.1. I can ssh to the unit but > > > it won't > > > respond to pings. I tried setting up a linux box with an address > > > like > > > 169.254.1.2 and it "would" respond to pings. > > > > Linux is not really any measuring stick in standard compliance... > > If 169.254.0.0/16 addresses are supposed to be link local then I'd > definitely expect a reply to a ping from another box on the same > LAN, sourced from another 169.254.0.0/16 address. Having tested this in the lab I'd say FreeBSD 7.x works exactly as expected. Traffic on the same LAN works, traffic to other LANs is not routed. All is well. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: netstat output changes in 8.0?
On Tue, Jan 26, 2010 at 12:49 PM, Nick Rogers wrote: > Thanks a lot. Thats a bummer. What are the chances of getting something > like that worked into arp(8) permanently? > > I recently noticed that arp(8) was changed a few months back to show when an entry expires. Thanks! http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/arp/arp.c?rev=1.75 ___ 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: arp -na performance w/ many permanent entries
On Sun, Jun 6, 2010 at 4:23 PM, Nick Rogers wrote: > > > On Sat, Jun 5, 2010 at 11:54 PM, Garrett Cooper wrote: >> >> >> I agree with Jeremy. I think that the problem that you've >> discovered is the fact that it's using stdio-based buffered output >> instead of buffering more of the contents in a string and punting it >> out in larger chunks. >> HTH, >> -Garrett >> > > I don't think so. The performance difference when taking out the interface > lookup is huge even though the data output to STDOUT is mostly the same. > I'll try the other lists, thanks. > > FYI there is a bugfix/patch for this issue being discussed in freebsd-hackers: http://www.mail-archive.com/freebsd-hack...@freebsd.org/msg157097.html Thanks again for suggesting I try another list. ___ 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"