Re: poor ethernet performance?
On Sat, 17 Jul 1999, Vincent Poy wrote: Ah, you have a point there. The problem is we have so many wires, we don't know which port goes to what on the Catalyst so we had it on autodetect and FreeBSD does boot up with fxp0 showing 100Mbps Full Duplex. Cisco's can show you which mac-adresses are on which port. Probably Catalyst's can too. Or have somebody pull the cable in and out of the pc, and watch for the light go on and off on the switch :-) Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
Ah, you have a point there. The problem is we have so many wires, we don't know which port goes to what on the Catalyst so we had it on autodetect and FreeBSD does boot up with fxp0 showing 100Mbps Full Duplex. Cisco's can show you which mac-adresses are on which port. Probably Catalyst's can too. Or have somebody pull the cable in and out of the pc, and watch for the light go on and off on the switch :-) A combination of those two would probably be useful. Then make a note of the port configuration, and *keep it updated*. This is essential for a hassle-free switched Ethernet environment. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999, Leif Neland wrote: On Sat, 17 Jul 1999, Vincent Poy wrote: Ah, you have a point there. The problem is we have so many wires, we don't know which port goes to what on the Catalyst so we had it on autodetect and FreeBSD does boot up with fxp0 showing 100Mbps Full Duplex. Cisco's can show you which mac-adresses are on which port. Probably Catalyst's can too. The Catalyst is the name of the Switches made by Cisco. :-) I'm not sure if it shows the mac address of the cisco's port or the actual device connected to it... FastEthernet0/1 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc1 (bia 0090.abea.3bc1) FastEthernet0/2 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc2 (bia 0090.abea.3bc2) Seems more like the Cisco's port's arp address to me than the devices. Or have somebody pull the cable in and out of the pc, and watch for the light go on and off on the switch :-) That's a option too... Only problem is that can take forever. :-) Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
I'm not sure if it shows the mac address of the cisco's port or the actual device connected to it... FastEthernet0/1 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc1 (bia 0090.abea.3bc1) FastEthernet0/2 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc2 (bia 0090.abea.3bc2) Seems more like the Cisco's port's arp address to me than the devices. Yes, this is the MAC address of the Catalyst port. You want show mac-address-table Please read the documentation. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999 [EMAIL PROTECTED] wrote: I'm not sure if it shows the mac address of the cisco's port or the actual device connected to it... FastEthernet0/1 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc1 (bia 0090.abea.3bc1) FastEthernet0/2 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc2 (bia 0090.abea.3bc2) Seems more like the Cisco's port's arp address to me than the devices. Yes, this is the MAC address of the Catalyst port. You want show mac-address-table Please read the documentation. This is hard since the actual machines and switches are almost 6000 miles away from me and the last time I checked, it didn't come with manuals. I know my way around the Cisco routers but the switches is still a mystery... Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
Please read the documentation. This is hard since the actual machines and switches are almost 6000 miles away from me and the last time I checked, it didn't come with manuals. I know my way around the Cisco routers but the switches is still a mystery... All of the Cisco documentation is available on WWW. Use it! Start at http://www.cisco.com/, follow the "Technical documents" and then the "Documentation home page" link. The manual for your switch is available, that's where I found the "show mac-address-table" command. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
Greg Lehey [EMAIL PROTECTED] writes: mdoc.samples(7). Now tell me that that's not intuitive. It would seem mdoc.samples(7) does not teach by example :) des@des ~% man -t mdoc.samples | lpr -Plex Usage: .Rv -std sections 2 and 3 only DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting up a firewall with dynamic IPs
On Tue, 13 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote:
I was checking out the firewall setup in /etc/rc.firewall, and noticed that
the simple example relied on a fixed IP address for the external interface. I
don't know ahead of time what IP address is going to be allocated to me before
I dial up. Would it be possible to specify an interface (tun0) rather than an
IP address?
Yes. That's what the "via" keyword is for.
very late followup, but i am behind in my mail again.
to deal with this issue i use the following:
/etc/ppp/linkup:
#!/bin/sh
sh /etc/rc.firewall
/etc/rc.firewall (exerpt)
[snip]
if [ "${firewall_type}" = "MINE" ]; then
#
#
#
tun0=`ifconfig tun0 | grep netmask | cut -f 2 -d ' ' | tail -1`
ep0=`ifconfig ep0 | grep netmask | cut -f 2 -d ' '`
loopback="127.0.0.0/8"
net10="10.0.0.0/8"
net172="172.16.0.0/12"
net192="192.168.0.0/16"
localnet="192.168.250.0/24"
localhost="127.0.0.1"
ntpdate_host="128.115.14.97"
xntpd_host="204.91.99.129"
preppp="10.0.0.1"
#
# clear all rules
#
$fwcmd -f flush
#
# prevent source address spoofing
#
$fwcmd add 100 deny log all from ${tun0} to any in recv tun0
[snip]
this way, whenever i dialup, i get a new ip address.
the new ip address is used to create the firewall rules.
jmb
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
Tim Baird wrote: I hope everyone is benefitting by these simple facts *chuckle* "Simple facts.." You sound like my physics professor. I for one am benefitting very much from the discussion. I got hired at my current job as a software person, but I have a background in hardware so I try and make it into the NOC every excuse I get (promotability, don't you know). It always helps if sound like I have a vague idea what I'm talking about. :) I just made up my first ethernet cables the other day, and learned an interesting tidbit that I'm sure is beyond elementary to most of you, but may benefit someone else. What I was told is that the reason Cat 5 cable is so much more efficient is that each of the 4 pairs of wire is twisted at a different rate. This helps reduce the possibility of frequency synchronization for the EM fields the pairs create. Soaking it in, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Determining the return address
On 18 Jul 1999, Dag-Erling Smorgrav wrote: Alfred Perlstein [EMAIL PROTECTED] writes: This looks like what you are doing is trying to grab the data on the stack before "log" which is the return address. Yes. It actually works :) I doubt this is at all portable and may fail because of optimizations and ABI, such as archs that store the return address in a register... I know - I don't expect it to be portable. *slap* :) gdb and glibc have some functions to assist in runtime backtraces, perhaps a look there may help? I found out about __builtin_return_address(0). what is that? a function? available on freebsd? BTW, is dladdr() signal-safe? not according to the sigaction man page. OK, is there any way I can find out that I am being called from a signal handler, other than using a global variable? I want my logging functions to be signal-safe - that's why I use writev(), and I've gone to great lengths to ensure that log_makedate() (which uses localtime_r() and strftime() to build a date string) and lvformat() (a printf() clone with some additional goodies) are signal-safe. sigaltstack() ? If oss is non-zero, the current signal stack state is returned. The ss_flags field will contain the value SS_ONSTACK if the process is cur- rently on a signal stack and SS_DISABLE if the signal stack is currently disabled. by setting an alternate signal stack i think you can check if you are in a signal using this. this may not be the best way but it seems like a viable solution. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Determining the return address
On 18 Jul 1999, Dag-Erling Smorgrav wrote: Alfred Perlstein [EMAIL PROTECTED] writes: On 18 Jul 1999, Dag-Erling Smorgrav wrote: Alfred Perlstein [EMAIL PROTECTED] writes: I doubt this is at all portable and may fail because of optimizations and ABI, such as archs that store the return address in a register... I know - I don't expect it to be portable. *slap* :) It's #ifdef'ed so you can drop it on platforms where it doesn't work :) gdb and glibc have some functions to assist in runtime backtraces, perhaps a look there may help? I found out about __builtin_return_address(0). what is that? a function? available on freebsd? GCC builtin function. by setting an alternate signal stack i think you can check if you are in a signal using this. this may not be the best way but it seems like a viable solution. Hmm, I ended up using a global variable which I increment at the beginning of the signal handler, and decrement at the end. As long as you make sure the code won't have multiple access that would work. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Devloper
Just to remind everyone where the actual logic is contained... Check out swap_pager.c line 1135 (in version $Id: vm_pageout.c,v 1.129.2.6 1999/03/18 23:28:39 julian Exp $). FreeBSD is not 100% indiscriminant. It favors procs with PID 48 as targets. You could tune this to discriminate against procs 1000 if you wanted; that way no startup procs would be killed. Of course, if one of those is causing the problem, then you're up a creek. :) Dag-Erling Smorgrav wrote: "Daniel C. Sobral" [EMAIL PROTECTED] writes: * Dividing processes into those that ought to be killed first and those that ought to be killed last in low-memory situations Doug White Internet: [EMAIL PROTECTED]| FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite| www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: telnetd
Warner Losh [EMAIL PROTECTED] wrote: What purpose is served by the twisty maze of ifdefs in telnetd? Probably for portability. I'd like to unifdef many of them. I'm trying to track down a bug and the twisty maze makes it very hard to follow. Comments? There's nothing stopping you unifdefing telnetd on your system. I have no opinion as to the merits (or otherwise) of leaving the ifdef's in the main code tree. If you're just trying to follow the code, try 'cc -E -C -dD'. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
tee option on ipfw?
The man page says the tee option on ipfw is not yet supported. I'm wondering if that is still the case as of 3.2-stable, or if the doc is just out of date. I would like to make a copy of incoming UDP packets to a specific port for some testing. tee seems like an easy way to go. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
glibc
Has anybody done a port of glibc to FreeBSD? (I'm not interested in opinions about how poor it is or how evil the FSF are; I'm only asking to avoid duplicate work. Thanks.) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: telnetd
In message [EMAIL PROTECTED] Peter Jeremy writes: : There's nothing stopping you unifdefing telnetd on your system. I : have no opinion as to the merits (or otherwise) of leaving the : ifdef's in the main code tree. True, but since some of what I'm doing is making sure that there are no security implications to some of the paths, doing that would be useless, since that wouldn't be what is checked into the system. We really don't need the ifdefs for solaris, cray, etc, do we? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
I guess I forgot about the overhead. I've tested between two FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL Switch Full Duplex and never seen anything close to the speeds. using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. i use these machines for stressing every else we have at work. jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
Mike Smith wrote: The loader will, at some stage in the future, grow a persistent data store in which items like this can be saved. Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent data storage? There is little or no chance that the loader will gain the ability to write back to filesystems. Some of them don't support it (eg. iso9660), others may not (TFTP, NFS), and the code required for some of them (especially UFS) would be problematically large. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
Mike Smith wrote: The loader will, at some stage in the future, grow a persistent data store in which items like this can be saved. Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent data storage? There is little or no chance that the loader will gain the ability to write back to filesystems. Some of them don't support it (eg. iso9660), others may not (TFTP, NFS), and the code required for some of them (especially UFS) would be problematically large. But that's okay. If the persistent storage is the loader conf files, they can be updated from single or multi-user mode. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
On Sun, 18 Jul 1999, Mike Smith wrote: Mike Smith wrote: The loader will, at some stage in the future, grow a persistent data store in which items like this can be saved. Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent data storage? There is little or no chance that the loader will gain the ability to write back to filesystems. Some of them don't support it (eg. iso9660), others may not (TFTP, NFS), and the code required for some of them (especially UFS) would be problematically large. That's not quite true. It wouldn't be too hard to modify existant files, but writing new ones/truncating would take a lot of work. It's still not a great idea to try to use a file on the FS for storage of persistent data. Wouldn't it be possible to have the kernel itself read in persistent data (in some form such as getenv?) to be written to disk? That way, the boot loader could pass it easily, and not have to worry about storage. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
[trimming CC list] Dag-Erling Smorgrav wrote: Greg Lehey [EMAIL PROTECTED] writes: mdoc.samples(7). Now tell me that that's not intuitive. It would seem mdoc.samples(7) does not teach by example :) des@des ~% man -t mdoc.samples | lpr -Plex Usage: .Rv -std sections 2 and 3 only This is a bug in man, actually. Section 7 is misc, and anything *can* go there. It's perfectly possible to have something in need of section 2/3 features that happens not to qualify as section 2 or 3. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] Everything journalists write is true, except when they write about something you know. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Sun, Jul 18, 1999, Per Lundberg wrote: Has anybody done a port of glibc to FreeBSD? (I'm not interested in opinions about how poor it is or how evil the FSF are; I'm only asking to avoid duplicate work. Thanks.) Not that I know of, but what's the point? -- |Chris Costello [EMAIL PROTECTED] |Programming just with goto's is like swatting flies with a sledgehammer. ` To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Booting from vinum?
On Saturday, 17 July 1999 at 22:51:17 +0400, Alex Povolotsky wrote: Hello! Is it possible to have a root partition on vinum'ed disk and benefit from mirroring? If yes, how do I do it? Not yet. It's on the drawing board. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vinum is cool. anyone bitten recently?
On Saturday, 17 July 1999 at 15:07:12 -0500, Craig Johnston wrote: Well, I'm looking into doing striping and mirroring on a new webserver I am bringing up (3.2-stable) and I have to say, vinum looks very cool. It took me like half an hour to get it going from first contact. Nice job Greg -- very straightforward. Thanks. Now, the official status of vinum is still alpha, right? Wrong. It went out of alpha about a year ago. It's been released in 3.1 and 3.2. But then again I know that that was (is?) the official status of softupdates for quite some time and I have been using it with no problems. So my question is, has anyone actually been bitten by vinum recently? I'm willing to take my chances if I can at least be pretty sure that I won't suddenly lose everything on both plexes if I am mirroring. That shouldn't happen. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: implementing poll() in a device driver (fwd)
I have a test driver that returns these values from the poll() function. However, the application that called the select() is not getting an error. Instead, the select is returning that the particular file descriptor is, in this case, 'readable' ! Take a look at "selscan" algorithm in /usr/src/sys/kern/sys_generic.c if you wish to learn more. Basically, if your driver doesn't implement the poll() functionality, it can always return 0. This will ensure that select never wakes up because of a file descriptor associated with your driver. thanks for your reply. I realise that one can return 0. My point is that if the driver returns POLLERR or POLLHUP, it is not getting handled correctly in sys_generic.c... It seems to me that a positive (non-zero) return value is being interpreted as 'readiness', although there is a comment in sys_generic.c that the backend (driver) can also return POLLHUP or POLLERR. --Vasudha To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Determining the return address
Alfred Perlstein wrote: On 17 Jul 1999, Dag-Erling Smorgrav wrote: Is there any (evidently non-portable) way of determining a function instance's return address? I have an idea or two that involves the return address and dladdr(). The code I currently use looks like this: This looks like what you are doing is trying to grab the data on the stack before "log" which is the return address. I doubt this is at all portable and may fail because of optimizations and ABI, such as archs that store the return address in a register... On the SPARC, FWIW, the return address is in %i7. What is difficult to determine (programmatically) is if the function is a normal or leaf function; different return sequences are used for each. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tee option on ipfw?
Jaye Mathisen writes: The man page says the tee option on ipfw is not yet supported. I'm wondering if that is still the case as of 3.2-stable, or if the doc is just out of date. You are correct, it's still not implemented.. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Sat, 17 Jul 1999, Vincent Poy wrote: Ah, you have a point there. The problem is we have so many wires, we don't know which port goes to what on the Catalyst so we had it on autodetect and FreeBSD does boot up with fxp0 showing 100Mbps Full Duplex. Cisco's can show you which mac-adresses are on which port. Probably Catalyst's can too. Or have somebody pull the cable in and out of the pc, and watch for the light go on and off on the switch :-) Leif To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
Ah, you have a point there. The problem is we have so many wires, we don't know which port goes to what on the Catalyst so we had it on autodetect and FreeBSD does boot up with fxp0 showing 100Mbps Full Duplex. Cisco's can show you which mac-adresses are on which port. Probably Catalyst's can too. Or have somebody pull the cable in and out of the pc, and watch for the light go on and off on the switch :-) A combination of those two would probably be useful. Then make a note of the port configuration, and *keep it updated*. This is essential for a hassle-free switched Ethernet environment. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999, Leif Neland wrote: On Sat, 17 Jul 1999, Vincent Poy wrote: Ah, you have a point there. The problem is we have so many wires, we don't know which port goes to what on the Catalyst so we had it on autodetect and FreeBSD does boot up with fxp0 showing 100Mbps Full Duplex. Cisco's can show you which mac-adresses are on which port. Probably Catalyst's can too. The Catalyst is the name of the Switches made by Cisco. :-) I'm not sure if it shows the mac address of the cisco's port or the actual device connected to it... FastEthernet0/1 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc1 (bia 0090.abea.3bc1) FastEthernet0/2 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc2 (bia 0090.abea.3bc2) Seems more like the Cisco's port's arp address to me than the devices. Or have somebody pull the cable in and out of the pc, and watch for the light go on and off on the switch :-) That's a option too... Only problem is that can take forever. :-) Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Cable quality (was: poor ethernet performance?)
On Friday, 16 July 1999 at 19:15:31 -0700, Matthew Dillon wrote: : Actually, I was referring to *digital* Audio cables like those :used for CD Transports to Digital/Analog convertors such as Kimber Kable :would be higher grade compared to Monster Cable. You're correct about the :bit errors though. Digital is digital. Either it works or it doesn't. Anything that goes over copper isn't digital, it's digital simulated on analogue. Poor quality cables *can* cause problems. But I'm sure that most of the folklore that circulates on this subject is of the same nature as the advice to use loudspeaker cables with at least 20mm**2 cross section, preferably driven by tube-based amplifiers. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
I'm not sure if it shows the mac address of the cisco's port or the actual device connected to it... FastEthernet0/1 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc1 (bia 0090.abea.3bc1) FastEthernet0/2 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc2 (bia 0090.abea.3bc2) Seems more like the Cisco's port's arp address to me than the devices. Yes, this is the MAC address of the Catalyst port. You want show mac-address-table Please read the documentation. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999 sth...@nethelp.no wrote: I'm not sure if it shows the mac address of the cisco's port or the actual device connected to it... FastEthernet0/1 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc1 (bia 0090.abea.3bc1) FastEthernet0/2 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc2 (bia 0090.abea.3bc2) Seems more like the Cisco's port's arp address to me than the devices. Yes, this is the MAC address of the Catalyst port. You want show mac-address-table Please read the documentation. This is hard since the actual machines and switches are almost 6000 miles away from me and the last time I checked, it didn't come with manuals. I know my way around the Cisco routers but the switches is still a mystery... Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
Please read the documentation. This is hard since the actual machines and switches are almost 6000 miles away from me and the last time I checked, it didn't come with manuals. I know my way around the Cisco routers but the switches is still a mystery... All of the Cisco documentation is available on WWW. Use it! Start at http://www.cisco.com/, follow the Technical documents and then the Documentation home page link. The manual for your switch is available, that's where I found the show mac-address-table command. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Determining the return address
Alfred Perlstein bri...@rush.net writes: This looks like what you are doing is trying to grab the data on the stack before log which is the return address. Yes. It actually works :) I doubt this is at all portable and may fail because of optimizations and ABI, such as archs that store the return address in a register... I know - I don't expect it to be portable. gdb and glibc have some functions to assist in runtime backtraces, perhaps a look there may help? I found out about __builtin_return_address(0). BTW, is dladdr() signal-safe? not according to the sigaction man page. OK, is there any way I can find out that I am being called from a signal handler, other than using a global variable? I want my logging functions to be signal-safe - that's why I use writev(), and I've gone to great lengths to ensure that log_makedate() (which uses localtime_r() and strftime() to build a date string) and lvformat() (a printf() clone with some additional goodies) are signal-safe. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
Greg Lehey g...@lemis.com writes: mdoc.samples(7). Now tell me that that's not intuitive. It would seem mdoc.samples(7) does not teach by example :) d...@des ~% man -t mdoc.samples | lpr -Plex Usage: .Rv -std sections 2 and 3 only DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Setting up a firewall with dynamic IPs
On Tue, 13 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote:
I was checking out the firewall setup in /etc/rc.firewall, and noticed that
the simple example relied on a fixed IP address for the external interface.
I
don't know ahead of time what IP address is going to be allocated to me
before
I dial up. Would it be possible to specify an interface (tun0) rather than
an
IP address?
Yes. That's what the via keyword is for.
very late followup, but i am behind in my mail again.
to deal with this issue i use the following:
/etc/ppp/linkup:
#!/bin/sh
sh /etc/rc.firewall
/etc/rc.firewall (exerpt)
[snip]
if [ ${firewall_type} = MINE ]; then
#
#
#
tun0=`ifconfig tun0 | grep netmask | cut -f 2 -d ' ' | tail -1`
ep0=`ifconfig ep0 | grep netmask | cut -f 2 -d ' '`
loopback=127.0.0.0/8
net10=10.0.0.0/8
net172=172.16.0.0/12
net192=192.168.0.0/16
localnet=192.168.250.0/24
localhost=127.0.0.1
ntpdate_host=128.115.14.97
xntpd_host=204.91.99.129
preppp=10.0.0.1
#
# clear all rules
#
$fwcmd -f flush
#
# prevent source address spoofing
#
$fwcmd add 100 deny log all from ${tun0} to any in recv tun0
[snip]
this way, whenever i dialup, i get a new ip address.
the new ip address is used to create the firewall rules.
jmb
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
Tim Baird wrote: I hope everyone is benefitting by these simple facts *chuckle* Simple facts.. You sound like my physics professor. I for one am benefitting very much from the discussion. I got hired at my current job as a software person, but I have a background in hardware so I try and make it into the NOC every excuse I get (promotability, don't you know). It always helps if sound like I have a vague idea what I'm talking about. :) I just made up my first ethernet cables the other day, and learned an interesting tidbit that I'm sure is beyond elementary to most of you, but may benefit someone else. What I was told is that the reason Cat 5 cable is so much more efficient is that each of the 4 pairs of wire is twisted at a different rate. This helps reduce the possibility of frequency synchronization for the EM fields the pairs create. Soaking it in, Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Devloper
Assem Salama wrote: I am interested in helping in the development in FreeBSD. I'm not a hotshot programmer but I know how to program. Could someone please send me the available projects that I can work on and some info about them? Step one, ignore all those responses to the poster who sent you the handbook page, they are trying to drag you into freebsd's latest holy war. :) Step two, that handbook page has a lot of good stuff, read it. Step three, (and I can't believe this isn't mentioned in the handbook) if there isn't anything on that page that looks interesting to you, take a look at http://www.freebsd.org/cgi/query-pr-summary.cgi and see if anything there strikes your fancy. Look first at unsassigned PR's, but if one of them that is assigned to someone looks like something you can handle and have time to work on, mail the person it's assigned to and ask them about it. Looking forward to your first patch, Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Determining the return address
On 18 Jul 1999, Dag-Erling Smorgrav wrote: Alfred Perlstein bri...@rush.net writes: This looks like what you are doing is trying to grab the data on the stack before log which is the return address. Yes. It actually works :) I doubt this is at all portable and may fail because of optimizations and ABI, such as archs that store the return address in a register... I know - I don't expect it to be portable. *slap* :) gdb and glibc have some functions to assist in runtime backtraces, perhaps a look there may help? I found out about __builtin_return_address(0). what is that? a function? available on freebsd? BTW, is dladdr() signal-safe? not according to the sigaction man page. OK, is there any way I can find out that I am being called from a signal handler, other than using a global variable? I want my logging functions to be signal-safe - that's why I use writev(), and I've gone to great lengths to ensure that log_makedate() (which uses localtime_r() and strftime() to build a date string) and lvformat() (a printf() clone with some additional goodies) are signal-safe. sigaltstack() ? If oss is non-zero, the current signal stack state is returned. The ss_flags field will contain the value SS_ONSTACK if the process is cur- rently on a signal stack and SS_DISABLE if the signal stack is currently disabled. by setting an alternate signal stack i think you can check if you are in a signal using this. this may not be the best way but it seems like a viable solution. -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Determining the return address
Alfred Perlstein bri...@rush.net writes: On 18 Jul 1999, Dag-Erling Smorgrav wrote: Alfred Perlstein bri...@rush.net writes: I doubt this is at all portable and may fail because of optimizations and ABI, such as archs that store the return address in a register... I know - I don't expect it to be portable. *slap* :) It's #ifdef'ed so you can drop it on platforms where it doesn't work :) gdb and glibc have some functions to assist in runtime backtraces, perhaps a look there may help? I found out about __builtin_return_address(0). what is that? a function? available on freebsd? GCC builtin function. by setting an alternate signal stack i think you can check if you are in a signal using this. this may not be the best way but it seems like a viable solution. Hmm, I ended up using a global variable which I increment at the beginning of the signal handler, and decrement at the end. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Determining the return address
On 18 Jul 1999, Dag-Erling Smorgrav wrote: Alfred Perlstein bri...@rush.net writes: On 18 Jul 1999, Dag-Erling Smorgrav wrote: Alfred Perlstein bri...@rush.net writes: I doubt this is at all portable and may fail because of optimizations and ABI, such as archs that store the return address in a register... I know - I don't expect it to be portable. *slap* :) It's #ifdef'ed so you can drop it on platforms where it doesn't work :) gdb and glibc have some functions to assist in runtime backtraces, perhaps a look there may help? I found out about __builtin_return_address(0). what is that? a function? available on freebsd? GCC builtin function. by setting an alternate signal stack i think you can check if you are in a signal using this. this may not be the best way but it seems like a viable solution. Hmm, I ended up using a global variable which I increment at the beginning of the signal handler, and decrement at the end. As long as you make sure the code won't have multiple access that would work. -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Devloper
Just to remind everyone where the actual logic is contained... Check out swap_pager.c line 1135 (in version $Id: vm_pageout.c,v 1.129.2.6 1999/03/18 23:28:39 julian Exp $). FreeBSD is not 100% indiscriminant. It favors procs with PID 48 as targets. You could tune this to discriminate against procs 1000 if you wanted; that way no startup procs would be killed. Of course, if one of those is causing the problem, then you're up a creek. :) Dag-Erling Smorgrav wrote: Daniel C. Sobral d...@newsguy.com writes: * Dividing processes into those that ought to be killed first and those that ought to be killed last in low-memory situations Doug White Internet: dwh...@resnet.uoregon.edu| FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite| www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
tee option on ipfw?
The man page says the tee option on ipfw is not yet supported. I'm wondering if that is still the case as of 3.2-stable, or if the doc is just out of date. I would like to make a copy of incoming UDP packets to a specific port for some testing. tee seems like an easy way to go. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: telnetd
Warner Losh i...@village.org wrote: What purpose is served by the twisty maze of ifdefs in telnetd? Probably for portability. I'd like to unifdef many of them. I'm trying to track down a bug and the twisty maze makes it very hard to follow. Comments? There's nothing stopping you unifdefing telnetd on your system. I have no opinion as to the merits (or otherwise) of leaving the ifdef's in the main code tree. If you're just trying to follow the code, try 'cc -E -C -dD'. Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
glibc
Has anybody done a port of glibc to FreeBSD? (I'm not interested in opinions about how poor it is or how evil the FSF are; I'm only asking to avoid duplicate work. Thanks.) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: telnetd
In message 99jul19.084214est.40...@border.alcanet.com.au Peter Jeremy writes: : There's nothing stopping you unifdefing telnetd on your system. I : have no opinion as to the merits (or otherwise) of leaving the : ifdef's in the main code tree. True, but since some of what I'm doing is making sure that there are no security implications to some of the paths, doing that would be useless, since that wouldn't be what is checked into the system. We really don't need the ifdefs for solaris, cray, etc, do we? Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
I guess I forgot about the overhead. I've tested between two FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL Switch Full Duplex and never seen anything close to the speeds. using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. i use these machines for stressing every else we have at work. jmb To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: System unique identifier.....
Mike Smith wrote: The loader will, at some stage in the future, grow a persistent data store in which items like this can be saved. Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent data storage? There is little or no chance that the loader will gain the ability to write back to filesystems. Some of them don't support it (eg. iso9660), others may not (TFTP, NFS), and the code required for some of them (especially UFS) would be problematically large. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: System unique identifier.....
Mike Smith wrote: The loader will, at some stage in the future, grow a persistent data store in which items like this can be saved. Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent data storage? There is little or no chance that the loader will gain the ability to write back to filesystems. Some of them don't support it (eg. iso9660), others may not (TFTP, NFS), and the code required for some of them (especially UFS) would be problematically large. But that's okay. If the persistent storage is the loader conf files, they can be updated from single or multi-user mode. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: System unique identifier.....
On Sun, 18 Jul 1999, Mike Smith wrote: Mike Smith wrote: The loader will, at some stage in the future, grow a persistent data store in which items like this can be saved. Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent data storage? There is little or no chance that the loader will gain the ability to write back to filesystems. Some of them don't support it (eg. iso9660), others may not (TFTP, NFS), and the code required for some of them (especially UFS) would be problematically large. That's not quite true. It wouldn't be too hard to modify existant files, but writing new ones/truncating would take a lot of work. It's still not a great idea to try to use a file on the FS for storage of persistent data. Wouldn't it be possible to have the kernel itself read in persistent data (in some form such as getenv?) to be written to disk? That way, the boot loader could pass it easily, and not have to worry about storage. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: telnetd
On Sun, Jul 18, 1999 at 05:44:39PM -0600, Warner Losh wrote:
True, but since some of what I'm doing is making sure that there are
no security implications to some of the paths, doing that would be
useless, since that wouldn't be what is checked into the system. We
really don't need the ifdefs for solaris, cray, etc, do we?
#if defined(CRAY2) defined(UNICOS5)
if (!linemode) {
[...]
}
#endif /* defined(CRAY2) defined(UNICOS5) */
And around that, there should probably be a #ifdef LINEMODE to boot.
Please trash them. Especially the termio vs. termios ones.
It's not that I'm anti-portability, it's just that we very rarely
come-up with a usermode program that is worth exporting.
I like this one even better,
#if defined(LINEMODE) defined(KLUDGELINEMODE)
[...]
if (lmodetype KLUDGE_LINEMODE) {
lmodetype = KLUDGE_LINEMODE;
clientstat(TELOPT_LINEMODE, WILL, 0);
send_wont(TELOPT_SGA, 1);
} else if (lmodetype == NO_AUTOKLUDGE) {
lmodetype = KLUDGE_OK;
}
#endif /* defined(LINEMODE) defined(KLUDGELINEMODE) */
[It looks like the stupid thing is a runtime option anyways, after the
#ifdefs...]
In the first 90% of sys_term.c, I'm not sure I could find more than a
couple sets of 25 contiguous lines that don't contain at least one #if
or #endif...
--
This is my .signature which gets appended to the end of my messages.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
[trimming CC list] Dag-Erling Smorgrav wrote: Greg Lehey g...@lemis.com writes: mdoc.samples(7). Now tell me that that's not intuitive. It would seem mdoc.samples(7) does not teach by example :) d...@des ~% man -t mdoc.samples | lpr -Plex Usage: .Rv -std sections 2 and 3 only This is a bug in man, actually. Section 7 is misc, and anything *can* go there. It's perfectly possible to have something in need of section 2/3 features that happens not to qualify as section 2 or 3. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org Everything journalists write is true, except when they write about something you know. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: glibc
On Sun, Jul 18, 1999, Per Lundberg wrote: Has anybody done a port of glibc to FreeBSD? (I'm not interested in opinions about how poor it is or how evil the FSF are; I'm only asking to avoid duplicate work. Thanks.) Not that I know of, but what's the point? -- |Chris Costello ch...@calldei.com |Programming just with goto's is like swatting flies with a sledgehammer. ` To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Booting from vinum?
On Saturday, 17 July 1999 at 22:51:17 +0400, Alex Povolotsky wrote: Hello! Is it possible to have a root partition on vinum'ed disk and benefit from mirroring? If yes, how do I do it? Not yet. It's on the drawing board. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: vinum is cool. anyone bitten recently?
On Saturday, 17 July 1999 at 15:07:12 -0500, Craig Johnston wrote: Well, I'm looking into doing striping and mirroring on a new webserver I am bringing up (3.2-stable) and I have to say, vinum looks very cool. It took me like half an hour to get it going from first contact. Nice job Greg -- very straightforward. Thanks. Now, the official status of vinum is still alpha, right? Wrong. It went out of alpha about a year ago. It's been released in 3.1 and 3.2. But then again I know that that was (is?) the official status of softupdates for quite some time and I have been using it with no problems. So my question is, has anyone actually been bitten by vinum recently? I'm willing to take my chances if I can at least be pretty sure that I won't suddenly lose everything on both plexes if I am mirroring. That shouldn't happen. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: implementing poll() in a device driver (fwd)
I have a test driver that returns these values from the poll() function. However, the application that called the select() is not getting an error. Instead, the select is returning that the particular file descriptor is, in this case, 'readable' ! Take a look at selscan algorithm in /usr/src/sys/kern/sys_generic.c if you wish to learn more. Basically, if your driver doesn't implement the poll() functionality, it can always return 0. This will ensure that select never wakes up because of a file descriptor associated with your driver. thanks for your reply. I realise that one can return 0. My point is that if the driver returns POLLERR or POLLHUP, it is not getting handled correctly in sys_generic.c... It seems to me that a positive (non-zero) return value is being interpreted as 'readiness', although there is a comment in sys_generic.c that the backend (driver) can also return POLLHUP or POLLERR. --Vasudha To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Determining the return address
Alfred Perlstein wrote: On 17 Jul 1999, Dag-Erling Smorgrav wrote: Is there any (evidently non-portable) way of determining a function instance's return address? I have an idea or two that involves the return address and dladdr(). The code I currently use looks like this: This looks like what you are doing is trying to grab the data on the stack before log which is the return address. I doubt this is at all portable and may fail because of optimizations and ABI, such as archs that store the return address in a register... On the SPARC, FWIW, the return address is in %i7. What is difficult to determine (programmatically) is if the function is a normal or leaf function; different return sequences are used for each. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Per Lundberg wrote: Has anybody done a port of glibc to FreeBSD? (I'm not interested in opinions about how poor it is or how evil the FSF are; I'm only asking to avoid duplicate work. Thanks.) Perhaps if you explain what it is you're trying to accomplish, there might be an easier option than porting *shudder* glibc? - alex The sheep bleated twice. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
