path_mtu_discovery
Hello, I'm using FreeBSD-4.4-STABLE and have an OpenBSD-2.9 router to connect to the internet (via DSL). If i try to do a cvsup (cvsup.de.freebsd.org, cvsup2.de.freebsd.org, cvsup.freebsd.org) i'm getting a lot of icmp: Destination unreachable, need to frag mtu 1488 messages and cvsup fails (timeout). The curious thing is if i disable net.inet.tcp.path_mtu_discovery or if i lower the MTU to 1488, everything is fine (of course). That's why i wanted to ask wether FreeBSD fails to lower the MTU (it should lower it due to the icmp messages, shouldn't it?) or is there any pppoe specific problem between me and the cvsup servers? Martin PS: AFAICS cvsup is the only problem ftp/http/nntp works fine -- The instructions said to use Windows 98 or better, so I installed FreeBSD. -- Jim Levie in comp.unix.bsd.freebsd.misc -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
On Fri, Jan 04, 2002 at 11:08:06AM +0100, Martin Kaeske wrote: Hello, I'm using FreeBSD-4.4-STABLE and have an OpenBSD-2.9 router to connect to the internet (via DSL). If i try to do a cvsup (cvsup.de.freebsd.org, cvsup2.de.freebsd.org, cvsup.freebsd.org) i'm getting a lot of icmp: Destination unreachable, need to frag mtu 1488 messages and cvsup fails (timeout). The curious thing is if i disable net.inet.tcp.path_mtu_discovery or if i lower the MTU to 1488, everything is fine (of course). That's why i wanted to ask wether FreeBSD fails to lower the MTU (it should lower it due to the icmp messages, shouldn't it?) or is there any pppoe specific problem between me and the cvsup servers? Martin PS: AFAICS cvsup is the only problem ftp/http/nntp works fine You have not, by any chance, firewalled ICMP replies, have you - either outgoing on the router, or incoming on the FreeBSD box? G'luck, Peter -- This sentence no verb. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
--- Peter Pentchev [EMAIL PROTECTED] wrote: On Fri, Jan 04, 2002 at 11:08:06AM +0100, Martin Kaeske wrote: Hello, I'm using FreeBSD-4.4-STABLE and have an OpenBSD-2.9 router to connect to the internet (via DSL). If i try to do a cvsup (cvsup.de.freebsd.org, cvsup2.de.freebsd.org, cvsup.freebsd.org) i'm getting a lot of icmp: Destination unreachable, need to frag mtu 1488 messages and cvsup fails (timeout). The curious thing is if i disable net.inet.tcp.path_mtu_discovery or if i lower the MTU to 1488, everything is fine (of course). That's why i wanted to ask wether FreeBSD fails to lower the MTU (it should lower it due to the icmp messages, shouldn't it?) or is there any pppoe specific problem between me and the cvsup servers? Martin PS: AFAICS cvsup is the only problem ftp/http/nntp works fine You have not, by any chance, firewalled ICMP replies, have you - either outgoing on the router, or incoming on the FreeBSD box? G'luck, Peter I have the same setup as Martin but i cant say i have the same problem. I am also blocking all incoming icmp traffic - in fact i have explicitly denied almost all incoming traffic so i do not thing that is the problem. however if you are running ipf on the openbsd machine (which i am assuming you are) you might want to check your ruleset, it sounds like you might have something in there that is causing it. Kristopher __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: boot1
On 04-Jan-02 Matthew Emmerton wrote: On 03-Jan-02 David E. Cross wrote: I'd like to create a /boot.config switch that will have boot1 _not_ read from the console; this is for a secure setup. Would others be interested in these patches when I finish them? Yes. I've seen other places use this, and I would commit it. :) How would this affect systems where you *have* to hit enter at the first boot: prompt in order to kick off a boot sequence? I've got two identical machines (same hardware, cloned hard drives), and one of them simply won't boot unless you hit enter. Turning off console imput would render this system useless after a reboot :) I think there's a PR open about this somewhere. Errr, why do you have to hit enter? If this patch does what I think it does, you won't even get a boot: prompt at all, it will just jump straight into the loader (or kernel). Besides, it wouldn't be on by default. You would have to explicitly turn it on via a flag in /boot.config. As Mike Silbersack (sp?) pointed out, it's a rogue problem that people run into every now and then. I think it's BIOS/motherboard related. In any case, if the patch bypasses the prompt entirely, then there's no problem in my case (and would actually make things better for me.) -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
On Friday, January 4, 2002, at 07:45 AM, Kristopher Kublinski wrote: --- Peter Pentchev [EMAIL PROTECTED] wrote: On Fri, Jan 04, 2002 at 11:08:06AM +0100, Martin Kaeske wrote: Hello, I'm using FreeBSD-4.4-STABLE and have an OpenBSD-2.9 router to connect to the internet (via DSL). If i try to do a cvsup (cvsup.de.freebsd.org, cvsup2.de.freebsd.org, cvsup.freebsd.org) i'm getting a lot of icmp: Destination unreachable, need to frag mtu 1488 messages and cvsup fails (timeout). The curious thing is if i disable net.inet.tcp.path_mtu_discovery or if i lower the MTU to 1488, everything is fine (of course). That's why i wanted to ask wether FreeBSD fails to lower the MTU (it should lower it due to the icmp messages, shouldn't it?) or is there any pppoe specific problem between me and the cvsup servers? Martin PS: AFAICS cvsup is the only problem ftp/http/nntp works fine You have not, by any chance, firewalled ICMP replies, have you - either outgoing on the router, or incoming on the FreeBSD box? I have the same setup as Martin but i cant say i have the same problem. I am also blocking all incoming icmp traffic - in fact i have explicitly denied almost all incoming traffic so i do not thing that is the problem. however if you are running ipf on the openbsd machine (which i am assuming you are) you might want to check your ruleset, it sounds like you might have something in there that is causing it. Blocking all ICMP is bad m'kay? See also: http://www.worldgate.net/~marcs/mtu/ ipfilter with 'keep state' on the connections will automatically allow back in relevant ICMP messages such as mustfrag. The icmp messages coming up on the users console might be logged blocked packets or some such? I don't seem to recall any of the RELENG_4 systems I run spewing stuff to console if the PMTU-D was turned on. Also I wonder if the user's OpenBSD box and FreeBSD box agree on what their MTU is. In any case, barring anyone being able to repeat this it probably belongs on -questions@. -- William Carrel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Tell gcc I have a i686
I want to create a Makefile for a C program that includes some Pentium II specific inline assembler code. How do I tell the compiler whether we are compiling on a i686? For Linux, I can do something like this (for gnu-make) Arch = $(shell arch) cc .. -DArch . and inside the program #ifdef i686 But arch doesn't exist on FreeBSD. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tell gcc I have a i686
* Stephen Montgomery-Smith [EMAIL PROTECTED] [020104 12:02] wrote:
I want to create a Makefile for a C program that includes some Pentium
II specific inline assembler code. How do I tell the compiler whether
we are compiling on a i686?
For Linux, I can do something like this (for gnu-make)
Arch = $(shell arch)
cc .. -DArch .
and inside the program
#ifdef i686
But arch doesn't exist on FreeBSD.
Isn't this somewhat trivial?
ARCH=i686
CFLAGS+=-D${ARCH}
?
--
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using 1970s technology,
start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Tell gcc I have a i686
Alfred Perlstein wrote:
* Stephen Montgomery-Smith [EMAIL PROTECTED] [020104 12:02] wrote:
I want to create a Makefile for a C program that includes some Pentium
II specific inline assembler code. How do I tell the compiler whether
we are compiling on a i686?
For Linux, I can do something like this (for gnu-make)
Arch = $(shell arch)
cc .. -DArch .
and inside the program
#ifdef i686
But arch doesn't exist on FreeBSD.
Isn't this somewhat trivial?
ARCH=i686
CFLAGS+=-D${ARCH}
?
What I want is a makefile that automatically detects whether it is on an
i686 or not (not for me to tell it so).
--
Stephen Montgomery-Smith
[EMAIL PROTECTED]
http://www.math.missouri.edu/~stephen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Tell gcc I have a i686
Stephen Montgomery-Smith [EMAIL PROTECTED] wrote: What I want is a makefile that automatically detects whether it is on an i686 or not (not for me to tell it so). In general, that's not a good idea, IMO. It should be up to the user to decide which optimizations he wants and which not, and we do have /etc/make.conf and CFLAGS for exactly that purpose. I always hate super-clever makefiles and configure scripts that strip -O from my CFLAGS and insert -O6 -march=i686 or other unwanted things. It's a PITA. Just my 0.02 Euro. Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. All that we see or seem is just a dream within a dream (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tell gcc I have a i686
On 04-Jan-02 Stephen Montgomery-Smith wrote:
Alfred Perlstein wrote:
* Stephen Montgomery-Smith [EMAIL PROTECTED] [020104 12:02] wrote:
I want to create a Makefile for a C program that includes some Pentium
II specific inline assembler code. How do I tell the compiler whether
we are compiling on a i686?
For Linux, I can do something like this (for gnu-make)
Arch = $(shell arch)
cc .. -DArch .
and inside the program
#ifdef i686
But arch doesn't exist on FreeBSD.
Isn't this somewhat trivial?
ARCH=i686
CFLAGS+=-D${ARCH}
?
What I want is a makefile that automatically detects whether it is on an
i686 or not (not for me to tell it so).
This doesn't support a user who wants to compile an app that they want to run
on some other machine. :) On FreeBSD, you can see if CPUTYPE is set from
make.conf, but it's not required to be set.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use 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: Tell gcc I have a i686
On Fri, Jan 04, 2002 at 11:20:55AM -0800, John Baldwin wrote:
On 04-Jan-02 Stephen Montgomery-Smith wrote:
Alfred Perlstein wrote:
* Stephen Montgomery-Smith [EMAIL PROTECTED] [020104 12:02] wrote:
...
But arch doesn't exist on FreeBSD.
Isn't this somewhat trivial?
ARCH=i686
CFLAGS+=-D${ARCH}
?
What I want is a makefile that automatically detects whether it is on an
i686 or not (not for me to tell it so).
This doesn't support a user who wants to compile an app that they want to run
on some other machine. :) On FreeBSD, you can see if CPUTYPE is set from
make.conf, but it's not required to be set.
However, if this behavior is insisted upon I would recommend doing
something with the output of 'sysctl hw.model'. Implementation is
left as an exercise for the reader.
Ralph
--
Ralph N. Smith
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Tell gcc I have a i686
If you do this, then I beg of you, for the sake of your successor's sanity... Comment your makefile ad nauseum and even put in a few echoes to inform builder what nastiness you enforced. I spend a lot of my time finding such optimizations in legacy code, well they were optimizations 5 years ago, and undoing them. Have pity on your successors. Mike Smith [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
On Fri, Jan 04, 2002 at 02:48:22PM +0200, Peter Pentchev wrote: You have not, by any chance, firewalled ICMP replies, have you - either outgoing on the router, or incoming on the FreeBSD box? No. Since i can see the icmp-messages with tcpdump, i thought there is a problem with FreeBSD not lowering the MTU. But i'm going to check the router's configuration. Martin -- The instructions said to use Windows 98 or better, so I installed FreeBSD. -- Jim Levie in comp.unix.bsd.freebsd.misc -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
[no subject]
auth 9002357b subscribe freebsd-hackers [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
William Carrel wrote: Blocking all ICMP is bad m'kay? First, I agree... ipfilter with 'keep state' on the connections will automatically allow back in relevant ICMP messages such as mustfrag. Heh... I need to try to write a mustfrag daemon, which will spoof them back whenever it sees traffic... and see what happens. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
On Fri, Jan 04, 2002 at 07:45:43AM -0800, Kristopher Kublinski wrote: I have the same setup as Martin but i cant say i have the same problem. I am also blocking all incoming icmp traffic - in fact i have explicitly denied almost all incoming traffic so i do not thing that is the problem. however if you are running ipf on the openbsd machine (which i am assuming you are) you might want to check your ruleset, it sounds like you might have something in there that is causing it. Well, i played a bit with cvsup and found that if i wait long enough (1 or 2 timeouts of cvsup) and then try again, it works. I checked this with cvsup2.de.freebsd.org, i got some message to big and then it worked. Strange. Martin -- The instructions said to use Windows 98 or better, so I installed FreeBSD. -- Jim Levie in comp.unix.bsd.freebsd.misc -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
[no subject]
auth 07120204 unsubscribe freebsd-hackers [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
On Friday, January 4, 2002, at 12:46 PM, Terry Lambert wrote: William Carrel wrote: ipfilter with 'keep state' on the connections will automatically allow back in relevant ICMP messages such as mustfrag. Heh... I need to try to write a mustfrag daemon, which will spoof them back whenever it sees traffic... and see what happens. See now you've made me curious, and I ask myself questions like: How robust is PMTU-D against someone malicious who wants to make us send tinygrams? Could the connection eventually be forced down to an MTU so low that no actual data transfer could occur, or TCP frames with only one byte of information? Granted, the malicious person has to send back a valid set of headers with their ICMP to get through ipfilter; but now I have this bad feeling lurking in the back of my mind... The bad feeling is helped along by observing sys/netinet/ip_icmp.c and the fact that as long as the MTU suggested is greater than 296 bytes we accept the values of any ICMP mustfrag that comes in provided we have a host route for it. I suppose we'll always get a couple hundred bytes in edgewise anyway, but it all makes for an interesting exercise. I wonder about the robustness of other operating systems to such an attack... -- Andy Carrel - [EMAIL PROTECTED] - +1 (425) 201-8745 Señor Systems Eng. - Corporate Infrastructure Applications - InfoSpace To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Solaris /usr/proc/bin/pstack functionality?
On Thu, Jan 03, 2002 at 02:02:09PM +0100, Oliver Fromme wrote: Jos Backus [EMAIL PROTECTED] wrote: - Forwarded message from Justin Erenkrantz [EMAIL PROTECTED] - +1. =) I've talked to the FreeBSD people and they just laugh maniacally when I ask for a truss that follows children. AIUI, NetBSD has this, so it is possible to port these changes over, but it requires an overhaul to procfs from what I've been told. FreeBSD has a long way to get the stellar debugging capabilities of Solaris. -- justin I think that the output from FreeBSD's truss is pretty pathetic and unusable. ktrace is somewhat better. Mmmm - I can't compare... On alpha: === Building for strace-4.4 cc -b alpha--freebsd5.0 -Wall -DHAVE_CONFIG_H -I. -Ifreebsd/alpha -I./freebsd/alpha -Ifreebsd -I./freebsd -D_GNU_SOURCE -O -pipe -mcpu=ev56 -c strace.c In file included from strace.c:34: defs.h:96: #error FreeBSD support is only for i386 arch right now. strace.c: In function `trace': strace.c:1461: warning: label `FOUND' defined but not used *** Error code 1 I asume this should be tagged i386 only in the port. On i386: ticso@cicely5# strace sleep 1 strace: PIOCSTATUS: Inappropriate ioctl for device trouble opening proc file Exit 1 PS: I tried strace under -stable only. I don't know if it works under -current as well. Seems not. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
On Fri, Jan 04, 2002 at 12:46:19PM -0800, Terry Lambert wrote: William Carrel wrote: Blocking all ICMP is bad m'kay? First, I agree... ipfilter with 'keep state' on the connections will automatically allow back in relevant ICMP messages such as mustfrag. Heh... I need to try to write a mustfrag daemon, which will spoof them back whenever it sees traffic... and see what happens. The sender will start sending smaller segments. That's it. But if you are in the patch between sender and receiver you can do worse things than that. -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
One possibility is that the code in icmp_input() processing the PMTU discovery-induced ICMP message could verify that the returned header in fact is associated with a connection on the host and maybe even has sane sequence numbers (for TCP segments). This would make it more difficult to just spray these packets at host and drop the MTU on routes. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
Guido van Rooij wrote: ipfilter with 'keep state' on the connections will automatically allow back in relevant ICMP messages such as mustfrag. Heh... I need to try to write a mustfrag daemon, which will spoof them back whenever it sees traffic... and see what happens. The sender will start sending smaller segments. That's it. But if you are in the patch between sender and receiver you can do worse things than that. I knew that I could multiply the number of packets sent by a factor of 5... I was pointing out a flaw in the idea of allowing path MTU ICMP back in, unconditionally... Now ask me how to DOS attack any server daemon that works by using the sendfile interface... PS: *Don't* ask me how the SYN-cache overflow SYN-cookie code can be ACK-flooded, to make the kernel spend all its time doing MD5 calculations, since that one is obvious... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
Louis A. Mamakos wrote: One possibility is that the code in icmp_input() processing the PMTU discovery-induced ICMP message could verify that the returned header in fact is associated with a connection on the host and maybe even has sane sequence numbers (for TCP segments). This would make it more difficult to just spray these packets at host and drop the MTU on routes. Of course, now you've let the dirty little secret out of the bag: the MTU is on the *route*, which means on the next hop, so a spoof that got through would frag basically all traffic out of the victim machine down to 296 bytes... A client machine could do much worse, of course, fragging the inverse traceroute until the fragging was successful, after sending the SYN, in response to the server's SYN-ACK... The obvious fix for that is to not let the MTU be dropped if the last sent packet's size is smaller than the drop-to (can't use a max successful because of multiple routes and/or route assymetry). This would prevent doing it on the SYN-ACK, or other small packet (maybe disallowing it entirely, until the first data packet has been sent). But the obvious fix for the obvious fix is to establish a connection, and then trigger the largest packet you can to be sent from the server (e.g. request a big HTTP document, which most initial pages in fact are). It's always an arms race... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
I suppose we'll always get a couple hundred bytes in edgewise anyway, but it all makes for an interesting exercise. I wonder about the robustness of other operating systems to such an attack... I think malicious people will point their ears at this line here ^^ Maybe make the minimum size a sysctl? Set default at the current number and put it in a how to make your FreeBSD more robust document that this might be raised to a higher number? DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
In a message written on Fri, Jan 04, 2002 at 03:35:35PM -0800, Terry Lambert wrote: Of course, now you've let the dirty little secret out of the bag: the MTU is on the *route*, which means on the next hop, so a spoof that got through would frag basically all traffic out of the victim machine down to 296 bytes... I might be assuming something here, but I want to clarify. It is _NOT_ the case that a box with say, only a default route, would limit _ALL_ TCP connections to the lowest returned MTU. The MTU is on the *route*, where *route* == the cloned route, correct? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
[reducing CC creep] On Friday, January 4, 2002, at 03:46 PM, Leo Bicknell wrote: In a message written on Fri, Jan 04, 2002 at 03:35:35PM -0800, Terry Lambert wrote: Of course, now you've let the dirty little secret out of the bag: the MTU is on the *route*, which means on the next hop, so a spoof that got through would frag basically all traffic out of the victim machine down to 296 bytes... I might be assuming something here, but I want to clarify. It is _NOT_ the case that a box with say, only a default route, would limit _ALL_ TCP connections to the lowest returned MTU. The MTU is on the *route*, where *route* == the cloned route, correct? That is certainly the way that the relevant code looks to me. FWIW, this is really a rehash of the same topic that came up on Bugtraq a couple years ago, and was cross-posted into freebsd-security at one point. I'm not sure if anything came of it then. -- Andy Carrel - [EMAIL PROTECTED] - +1 (425) 201-8745 Señor Systems Eng. - Corporate Infrastructure Applications - InfoSpace To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
In a message written on Fri, Jan 04, 2002 at 01:26:54PM -0800, William Carrel wrote: See now you've made me curious, and I ask myself questions like: How robust is PMTU-D against someone malicious who wants to make us send tinygrams? Could the connection eventually be forced down to an MTU so low that no actual data transfer could occur, or TCP frames with only one byte of information? I don't have the RFC handy, but aren't all Internet connected hosts required to support a minimum MTU of 576 from end to end with no fragmentation? Thus if we ever got an MTU less than 576 we should ignore it. Right? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
snip description=put minimum mtu in tuneable sysctl/ I suppose so, but then you won't be able to connect to machines with miniscule path MTU's, and that should definately be a warning. But then it beats Linux which allows the path MTU to be reduced to 69 bytes (ouch!). Ouch indeed. Well default would be what we have now, but you'd be able to tune it. The way I see it is that the attack would be most common on the internet, and minuscule MTUs would most probably occur in specialistic environments. Admins of potential targets would raise the minimum to a nice value (say 512 or 1024), and print a message when something requests something below this minimum, for troubleshooting ease. Or maybe a soft limit and a hard limit. Soft limit triggers a message, hard limit is enforced. Out of curiosity, where do MTUs ~512 occur? The best solution is to try and make sure that the mustfrag messages are coming from real connections we have open, and perhaps even, make sure that the host on the remote end hasn't already ACK'ed a packet whose header shows up in the ICMP mustfrag. (It would be kind of silly to get an ACK and a mustfrag.) Although, then it is just a race to see who gets their packet to us first. What about a mustfrag flood? Wouldn't this be a tad much to process? DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
I don't have the RFC handy, but aren't all Internet connected hosts required to support a minimum MTU of 576 from end to end with no fragmentation? Thus if we ever got an MTU less than 576 we should ignore it. Right? If we're on the internet yes. If you're in an environment other than one connected to the internet (do those even exist grin/) no. Hence my tuneable sysctl idea. DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
In a message written on Sat, Jan 05, 2002 at 01:14:45AM +0100, Rogier R. Mulhuijzen wrote: If we're on the internet yes. If you're in an environment other than one connected to the internet (do those even exist grin/) no. Hence my tuneable sysctl idea. I'll support a sysctl, however I'll also be quite insistant that our defaults match the Internet. I'm fairly sure more FreeBSD boxes are connected to the Internet than any other network. :-) -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
usr.sbin/pkg_install/sign code error?
So, I'm poking at pkg_sign, trying to see what it would take to enable
GPG as well as PGP, and came across something that appears odd. (It
might just be me, mind you.) Pointers to clue would be appreciated,
if it's me.
First, pkg_sign doesn't seem to work at all with PGP. I get no chance
to enter a passphrase, as all this stuff scrolls past:
pedicular~;pkg_sign imlib2-1.0.4.tgz
Short-circuiting handle_pgp_passphrase
Pretty Good Privacy(tm) 2.6.3ia - Public-key encryption for the masses.
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-03-04
International version - not for use in the USA. Does not use RSAREF.
Current time: 2002/01/05 00:19 GMT
You specified no user ID to select your secret key,
so the default user ID and key will be the most recently
added key on your secret keyring.
Error: Bad pass phrase.
Signature error
For a usage summary, type: pgp -h
For more detailed help, consult the PGP User's Guide.
Bus error (core dumped)
pedicular~;
So, I start tracing code. It seems fairly straightforward; at the
point where pkg_sign should be getting a passphrase it calls
handle_pgp_passphrase.
...
void
handle_pgp_passphrase()
{
pid_t pid;
int fd[2];
char *p;
printf(Short-circuiting %s\n, __FUNCTION__);
return;
/* Retrieve the pgp passphrase */
...
Now, it sure looks to me like the return statement on line 233 of
pgp_sign.c unconditionally stops the action before you actually get
the PGP passphrase, tie it to a fd so you can pass it to PGP, or
anything else. Yet this is fairly new code, and I'd guess it is
supposed to work... folks don't make a habit of committing b0rked
code, after all.
Am I just dumb, or does this really need correction? (And no, it
doesn't work if you just whack out the printf and the return. :-)
Thanks,
==ml
--
Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED]
my FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons
http://www.blackhelicopters.org/~mwlucas/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
On Friday, January 4, 2002, at 03:56 PM, Leo Bicknell wrote: In a message written on Fri, Jan 04, 2002 at 01:26:54PM -0800, William Carrel wrote: See now you've made me curious, and I ask myself questions like: How robust is PMTU-D against someone malicious who wants to make us send tinygrams? Could the connection eventually be forced down to an MTU so low that no actual data transfer could occur, or TCP frames with only one byte of information? I don't have the RFC handy, but aren't all Internet connected hosts required to support a minimum MTU of 576 from end to end with no fragmentation? Thus if we ever got an MTU less than 576 we should ignore it. Right? RFC 879 (http://www.rfc.net/rfc879.html) would tend to disagree... (10) Gateways must be prepared to fragment datagrams to fit into the packets of the next network, even if it smaller than 576 octets. -- Andy Carrel - [EMAIL PROTECTED] - +1 (425) 201-8745 Señor Systems Eng. - Corporate Infrastructure Applications - InfoSpace To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
In a message written on Fri, Jan 04, 2002 at 04:03:35PM -0800, William Carrel wrote: RFC 879 (http://www.rfc.net/rfc879.html) would tend to disagree... (10) Gateways must be prepared to fragment datagrams to fit into the packets of the next network, even if it smaller than 576 octets. Hmm, I'd swear there was a defined minimum, I may have the wrong one. For reference, it appears Cisco IOS based devices won't allow MTU smaller than 128 to be configured. I have no idea if that's based on some standard. It seems like there should be a minimum global standard. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
In a message written on Sat, Jan 05, 2002 at 01:14:24AM +0100, Rogier R. Mulhuijzen wrote: I suppose so, but then you won't be able to connect to machines with miniscule path MTU's, and that should definately be a warning. But then it beats Linux which allows the path MTU to be reduced to 69 bytes (ouch!). Ouch indeed. Well default would be what we have now, but you'd be able to tune it. The way I see it is that the attack would be most common on the internet, and minuscule MTUs would most probably occur in specialistic environments. Admins of potential targets would raise the minimum to a nice value (say 512 or 1024), and print a message when something requests something below this minimum, for troubleshooting ease. Or maybe a soft limit and a hard limit. Soft limit triggers a message, hard limit is enforced. ftp://ftp.isi.edu/in-notes/rfc791.txt ]Every internet module must be able to forward a datagram of 68 ]octets without further fragmentation. This is because an internet ]header may be up to 60 octets, and the minimum fragment is 8 octets. And ]Every internet destination must be able to receive a datagram of 576 ]octets either in one piece or in fragments to be reassembled. Not as good as I hoped. So, it would seem the roadmap would look something like this: 1) Insure FreeBSD won't allow an MTU 68 bytes ever. (ifconfig, icmp mtu messages, anything) 2) Implement a warning if the MTU is set smaller than some minimum value (perhaps 576 for the global internet) if admins which to see such things. 3) Allow admins to enforce a higher minimum size for servers in attack situations, knowing this violates the RFC. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: path_mtu_discovery
I don't have the RFC handy, but aren't all Internet connected hosts required to support a minimum MTU of 576 from end to end with no fragmentation? Thus if we ever got an MTU less than 576 we should ignore it. Right? No, all hosts are required to be able to reassemble IP datagram fragments of at least 576 bytes, but there's no lower bound on the MTU of the interface. Small MTUs first appeared on low-bandwidth SLIP links. Along with TCP header compression, this put a lower-bound on how long you'd have to wait for a single packet to be transmitted on the interface. If your network interface was clever, and looked at the TOS bits in the header or peeked at the TCP port numbers, you could arrange to queue interactive traffic (telnet, rlogin, now ssh) ahead of non-interactive traffic (FTP, SMTP, etc.) to improve the perceived response time with remote character echos. If the MTU was large, a large FTP packet might just be starting its way out the interface when you want to transmit interactive traffic; the small MTU limits the pain. (Digression: NORTEL (at least) had an interesting encapsulation on their multiservice frame relay switch trunks where they could interrupt a packet being transmitted and insert delay sensitive traffic in the middle of a larger packet. Cool hack.) Also, even though this is on a cloned route, someone could attack well known routes that might be on your computer. For instance, the route to well-known recursive name servers on a network, which are pretty easy to guess for dial-up users on a modem pool. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
what slice did I boot from?
I dunno if this has come up before or not, but thought I would ask. I've got one of the litle soekris net4501 boards that I use as a router/firewall/NAT box, and it works really good. I have a stripped down FreeBSD system that I run in a 16MB partition on an 32MB Compact Flash card plugged into the net4501. Actually, I have two 16MB slices, and my goal is to be running from one, and installing the next version into the second slice. That way, if the new one distribution screws up, I can back-out to the older on on the other partition. That problem is that I have to generate a distribution with the right /etc/fstab to reflect which of the two slices it will be installed into, which is ugly. What would be Really Nice is a version of the compatibility disk devices which would be associated with the active slice that was booted from, rather than the first FreeBSD slice found on the disk. This seems like one mechanism to get what I want. Unfortunately, this information doesn't seem to get propagated up to the slice code from what I can tell. Any suggestions on alternative mechanisms? louie To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
sessionlimit
Hi all, if I want to change behavior of sessionlimit behavior in login.conf, where I should look first since I can't find it in /usr/src/libutil thx before. Best regards To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Overriding ARG_MAX
Apologies if this belongs on -questions. I couldn't find what I needed in the archives or handbook. I have a system where I need/want to handle lots of files in a single directory. Lots as in 100-200K files. ls | wc -l breaks because the value of ARG_MAX in sys/syslimits.h is too small. If I change it from 65536 to 4meg and rebuild the world it works fine. I do cvsup from time to time and have to re-edit the file, which I usually forget. Is there a way to set this parameter in make.conf or the config file so it's always done when compiling the kernel? Thanks in advance, --- David To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Overriding ARG_MAX
On Fri, Jan 04, 2002 at 09:50:45PM -0500, David Miller wrote: Apologies if this belongs on -questions. I couldn't find what I needed in the archives or handbook. It almost certaintly did. I have a system where I need/want to handle lots of files in a single directory. Lots as in 100-200K files. ls | wc -l breaks because the value of ARG_MAX in sys/syslimits.h is too small. If I change it from 65536 to 4meg and rebuild the world it works fine. ls | xargs wc -l would work with an arbitrary number of files. I do cvsup from time to time and have to re-edit the file, which I usually forget. Is there a way to set this parameter in make.conf or the config file so it's always done when compiling the kernel? One solution is to use cvsup to maintain a local copy of the cvs tree and check out source tree out using cvs. This will mean that cvs's automerging support will keep your changes untouched. You may have to resolve an occational conflict if something changes near your changes, but otherwise your changes will remain intact. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg30712/pgp0.pgp Description: PGP signature
Re: Overriding ARG_MAX
David Miller wrote: Apologies if this belongs on -questions. I couldn't find what I needed in the archives or handbook. I have a system where I need/want to handle lots of files in a single directory. Lots as in 100-200K files. ls | wc -l breaks because the value of ARG_MAX in sys/syslimits.h is too small. If I change it from 65536 to 4meg and rebuild the world it works fine. I don't believe you. There is no ARG_MAX limit on pipes. Probably, you are doing something whic you aren't telling us, like saying ls *.c | wc -l or otherwise using globbing that the shell expands to too large a list. The easy answer is use ``find'' instead of ``ls''. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Overriding ARG_MAX
Brooks Davis wrote: I have a system where I need/want to handle lots of files in a single directory. Lots as in 100-200K files. ls | wc -l breaks because the value of ARG_MAX in sys/syslimits.h is too small. If I change it from 65536 to 4meg and rebuild the world it works fine. ls | xargs wc -l would work with an arbitrary number of files. No, it wouldn't. First off, you would be line counting the file contents, not the number of files. Second, the ls command alone will *never* hit ARG_MAX, and neither will wc -l, if it's pipe'd to to count the number of files. He's obviously using a globbing expression he's not telling us about, and the message is from the shell expasion of the expression. Thirdly, even if it was the number of lines in the files he wanted to count, the totals will be off if xargs were to invoke wc -l multiple times, so the command as written can't work anyway. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Phobos 4-port NIC
Howdy, I have recently acquired a pair of Phobos 4-port NIC's, the P430TX model. On it, it has 4 Intel 21143TD chips, and one larger Intel 21152AB chip. The driver (binary only) provided by Phobos is from 1999. Does FreeBSD have any support for this card? Perhaps by the dc or de drivers? If not, how difficult would it be to add it, keeping in mind I'm best described as a junior junior kernel hacker. : Thanks in advance for any info. Regards, -Eric Busto To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Overriding ARG_MAX
On Fri, 4 Jan 2002, Terry Lambert wrote: David Miller wrote: Apologies if this belongs on -questions. I couldn't find what I needed in the archives or handbook. I have a system where I need/want to handle lots of files in a single directory. Lots as in 100-200K files. ls | wc -l breaks because the value of ARG_MAX in sys/syslimits.h is too small. If I change it from 65536 to 4meg and rebuild the world it works fine. I don't believe you. There is no ARG_MAX limit on pipes. My apologies. Leo also noted that. I was trying to give a quick example to a general problem and I got a little too quick. What I usually want to do is something more like ls *.out |wc -l, or grep something *.data or cat *.foo | grep something. I have rebuilt the system in the past after greatly expanding ARG_MAX, and that does what I want. I'm just looking for an easy way to preserve it across cvsups, not looking for alternate ways to list the files in a directory:) Probably, you are doing something whic you aren't telling us, like saying ls *.c | wc -l or otherwise using globbing that the shell expands to too large a list. The easy answer is use ``find'' instead of ``ls''. Indeed, but it doesn't answer the basic questions, which was: Is there any easy way to override ARG_MAX (or arbitrary other paramaters) in make.conf or a config file, or something else altogether? --- David To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Phobos 4-port NIC
I had a similar (if not identical) phobos card. Turned out to be supported. (Tulip I think) Pop it in a machine and see if it works :) -Bill On Fri, Jan 04, 2002 at 07:54:27PM -0800, Eric Busto wrote: Howdy, I have recently acquired a pair of Phobos 4-port NIC's, the P430TX model. On it, it has 4 Intel 21143TD chips, and one larger Intel 21152AB chip. The driver (binary only) provided by Phobos is from 1999. Does FreeBSD have any support for this card? Perhaps by the dc or de drivers? If not, how difficult would it be to add it, keeping in mind I'm best described as a junior junior kernel hacker. : -- -=| Bill Swingle - unfurl@(dub.net|freebsd.org) -=| Every message PGP signed -=| Fingerprint: C1E3 49D1 EFC9 3EE0 EA6E 6414 5200 1C95 8E09 0223 -=| Different all twisty a of in maze are you, passages little msg30717/pgp0.pgp Description: PGP signature
Re: what slice did I boot from?
Louis A. Mamakos writes: I dunno if this has come up before or not, but thought I would ask. I've got one of the litle soekris net4501 boards that I use as a router/firewall/NAT box, and it works really good. I have a stripped down FreeBSD system that I run in a 16MB partition on an 32MB Compact Flash card plugged into the net4501. Actually, I have two 16MB slices, and my goal is to be running from one, and installing the next version into the second slice. That way, if the new one distribution screws up, I can back-out to the older on on the other partition. That problem is that I have to generate a distribution with the right /etc/fstab to reflect which of the two slices it will be installed into, which is ugly. What would be Really Nice is a version of the compatibility disk devices which would be associated with the active slice that was booted from, rather than the first FreeBSD slice found on the disk. This seems like one mechanism to get what I want. Unfortunately, this information doesn't seem to get propagated up to the slice code from what I can tell. Any suggestions on alternative mechanisms? I usually swap whole partitions. For example label: The data for partition 1 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 254016, size 254016 (124 Meg), flag 80 (active) The data for partition 4 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 254016 (124 Meg), flag 0 and: The data for partition 1 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 254016 (124 Meg), flag 80 (active) The data for partition 4 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 254016, size 254016 (124 Meg), flag 0 on the same disk. -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
A Helping Hand
Whichever hacker, Upon reading section 3.1 in ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/4.4-RELEASE/floppies/README.TXT, I learned that you can always use a helping hand. I, however, do not know how to program just yet. The project aroused my interest, and I'd like to help out when I can. If you'd like, I'll take any and all advice provided on how to go about helping the freebsd team through recommended reads, practices, and people to talk to. I learn very fast, and I am quite aspiring. If you're interested, we could talk more on IRC. --Seamy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Overriding ARG_MAX
On Fri, Jan 04, 2002 at 07:53:52PM -0800, Terry Lambert wrote: Brooks Davis wrote: I have a system where I need/want to handle lots of files in a single directory. Lots as in 100-200K files. ls | wc -l breaks because the value of ARG_MAX in sys/syslimits.h is too small. If I change it from 65536 to 4meg and rebuild the world it works fine. ls | xargs wc -l would work with an arbitrary number of files. No, it wouldn't. Correct, I misread what he was trying to do. The second part of my answer is a working solution to do what he asked to do. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg30720/pgp0.pgp Description: PGP signature
Re: path_mtu_discovery
In message: [EMAIL PROTECTED] Rogier R. Mulhuijzen [EMAIL PROTECTED] writes: : Out of curiosity, where do MTUs ~512 occur? Old slip links that used it to reduce latency. I suspect that there aren't too many of them left in the world. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
