Re: path_mtu_discovery
On Mon, Jan 07, 2002 at 01:57:26PM +0200, Yonatan Bokovza wrote: > > -Original Message- > > From: Crist J. Clark [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, January 06, 2002 02:39 > > To: Leo Bicknell > > Cc: Rogier R. Mulhuijzen; [EMAIL PROTECTED] > > Subject: Re: path_mtu_discovery > [snip] > > I'd support it if anyone actually has any credible evidence that such > > attacks have ever occured. Or if there is are plausible ways to attack > > that don't require someone to sniff and inject into a connection in > > which the victim is participating (if you can do that, you can do much > > worse). > > The original message of the "old thread" mentioned: > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=4186+0+archive/2001/freebsd-sec > urity/20010715.freebsd-security > > Darren Reed's post to BugTraq implied, IIRC, that an attacker can > kill (or slow down) a server if he requests a large file with low MSS. I took part in that discussion and there was no mention of real exploits. And TCP MSS is not the same thing as the PMTU (though they can be related). As I pointed out in that thread, there are much more devistating TCP attacks to worry about that are still threats like "Daytona" attacks. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: path_mtu_discovery
> -Original Message- > From: Crist J. Clark [mailto:[EMAIL PROTECTED]] > Sent: Sunday, January 06, 2002 02:39 > To: Leo Bicknell > Cc: Rogier R. Mulhuijzen; [EMAIL PROTECTED] > Subject: Re: path_mtu_discovery [snip] > I'd support it if anyone actually has any credible evidence that such > attacks have ever occured. Or if there is are plausible ways to attack > that don't require someone to sniff and inject into a connection in > which the victim is participating (if you can do that, you can do much > worse). The original message of the "old thread" mentioned: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=4186+0+archive/2001/freebsd-sec urity/20010715.freebsd-security Darren Reed's post to BugTraq implied, IIRC, that an attacker can kill (or slow down) a server if he requests a large file with low MSS. 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:08:16PM -0500, Leo Bicknell wrote: > 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 ) 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. :-) I'd support it if anyone actually has any credible evidence that such attacks have ever occured. Or if there is are plausible ways to attack that don't require someone to sniff and inject into a connection in which the victim is participating (if you can do that, you can do much worse). The typical SYN flood or DDOS are real threats. This thread (and the previous ones like the one Darren started a few months back) have already expended more energy on the issue than the threat warrants. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: path_mtu_discovery
Jesper Skriver wrote: > On Fri, Jan 04, 2002 at 06:02:10PM -0500, 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). > > The code does that today That's why you spoof the route between the machine and the next hop, after making a *valid* connection... The only think that can get around it is an overly anal hop count comparison (which could fail, if there were multiple equivalent routes), or turning off the ICMP (which is what started this thread in the first place). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: path_mtu_discovery
> : 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. You'd be suprised. I measure SLIP's effeciency (in throughput) to be about 5-15% more effecient than PPP in older versions of FreeBSD (both using kernel versions, slip and ppp). Since both were using static configurations on both ends and the only traffic was TCP/IP, there was no reason to use PPP over SLIP so we opted for using the more effecient protocol. I can imagine this is SLIP is still more effecient than PPP in terms of CPU, although I haven't measured it in years. Nate 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 06:02:10PM -0500, 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). The code does that today src/sys/netinet/tcp_subr.c in tcp_ctlinput() added in rev 1.94 on february 26th 2001 when it was moved from src/sys/netinet/in_pcb.c in_pcbnotify() added in rev 1.70 on december 24th 2000 > This would make it more difficult to just spray these packets at host > and drop the MTU on routes. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. 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 03:11:45PM -0800, Terry Lambert wrote: > > 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... Thre is nothing 'unconditionally' in ipfilter. The IP packetheader and the first 8 bytes of the UDP/ICMP/TCP header are examined and checked if they match a valid state entry. -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: path_mtu_discovery
"M. Warner Losh" wrote: > 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. PPPOE over modem links can do this, as well. There are also intentional flow limits set on ATM muxes which implement the "leaky bucket" algorithm (c.v. Tom Ndousse, PhD's work on leaky bucket; I think he's at Arizona in Tucson, right now...). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
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
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
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
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
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 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 ) 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
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 ) 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
>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
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
[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 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
>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
"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
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
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
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
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: 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
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 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
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 >>> " 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
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 > > " 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: 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 > " 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
