* clearing dont-fragment bit @ 2003-10-09 13:43 Abraham van der Merwe 2003-10-09 14:03 ` Maciej Soltysiak 2003-10-09 16:23 ` Ralf Spenneberg 0 siblings, 2 replies; 14+ messages in thread From: Abraham van der Merwe @ 2003-10-09 13:43 UTC (permalink / raw) To: Netfilter Discussions Hi! Are there any iptables extensions out there that allow you to clear the DF (Dont Fragment) bit in ip headers? -- Regards Abraham The best diplomat I know is a fully activated phaser bank. -- Scotty ___________________________________________________ Abraham vd Merwe - Frogfoot Networks CC 9 Kinnaird Court, 33 Main Street, Newlands, 7700 Phone: +27 21 686 1665 Cell: +27 82 565 4451 Http: http://www.frogfoot.net/ Email: abz@frogfoot.net ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: clearing dont-fragment bit 2003-10-09 13:43 clearing dont-fragment bit Abraham van der Merwe @ 2003-10-09 14:03 ` Maciej Soltysiak 2003-10-09 14:08 ` Abraham van der Merwe 2003-10-09 16:23 ` Ralf Spenneberg 1 sibling, 1 reply; 14+ messages in thread From: Maciej Soltysiak @ 2003-10-09 14:03 UTC (permalink / raw) To: Abraham van der Merwe; +Cc: Netfilter Discussions Hi > Are there any iptables extensions out there that allow you to clear the DF > (Dont Fragment) bit in ip headers? AFAIK no. Why would you want to do that? I think I might write a module that would do that. Regards, Maciej ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: clearing dont-fragment bit 2003-10-09 14:03 ` Maciej Soltysiak @ 2003-10-09 14:08 ` Abraham van der Merwe 2003-10-09 14:43 ` Ramin Dousti 0 siblings, 1 reply; 14+ messages in thread From: Abraham van der Merwe @ 2003-10-09 14:08 UTC (permalink / raw) To: Maciej Soltysiak; +Cc: Netfilter Discussions Hi Maciej >@2003.10.09_16:03:26_+0200 > > Are there any iptables extensions out there that allow you to clear the DF > > (Dont Fragment) bit in ip headers? > AFAIK no. Why would you want to do that? > I think I might write a module that would do that. I need it for tunnels. In a perfect world that wouldn't be necessary at all, but reality is that there's many brain dead admins that filter icmp, so if you build a tunnel over the big bad internet, you're screwed. You can use the TCPMSS target which solves it for tcp, but you still have the same problem with udp packets, so imho the only way to solve this properly is to fragment packets even if DF=1. -- Regards Abraham Ask not for whom the telephone bell tolls... if thou art in the bathtub, it tolls for thee. ___________________________________________________ Abraham vd Merwe - Frogfoot Networks CC 9 Kinnaird Court, 33 Main Street, Newlands, 7700 Phone: +27 21 686 1665 Cell: +27 82 565 4451 Http: http://www.frogfoot.net/ Email: abz@frogfoot.net ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: clearing dont-fragment bit 2003-10-09 14:08 ` Abraham van der Merwe @ 2003-10-09 14:43 ` Ramin Dousti 2003-10-09 14:52 ` Abraham van der Merwe 0 siblings, 1 reply; 14+ messages in thread From: Ramin Dousti @ 2003-10-09 14:43 UTC (permalink / raw) To: Maciej Soltysiak, Netfilter Discussions, Abraham van der Merwe On Thu, Oct 09, 2003 at 04:08:19PM +0200, Abraham van der Merwe wrote: > Hi Maciej >@2003.10.09_16:03:26_+0200 > > > > Are there any iptables extensions out there that allow you to clear the DF > > > (Dont Fragment) bit in ip headers? > > AFAIK no. Why would you want to do that? > > I think I might write a module that would do that. > > I need it for tunnels. In a perfect world that wouldn't be necessary at all, > but reality is that there's many brain dead admins that filter icmp, so if > you build a tunnel over the big bad internet, you're screwed. > > You can use the TCPMSS target which solves it for tcp, but you still have > the same problem with udp packets, so imho the only way to solve this > properly is to fragment packets even if DF=1. The applications that set the DF bit, do so for a reason not just for the fun. Sometimes (well, actually most of the time) it's for the performance reasons in which case turning it off and having a poor performance is preferable than it not working at all. On the other hand, the DF bit would be set by the application probes to figure the PMTU. Setting that off on the firewall would harm the purpose. Can you come up with a list of the non-TCP-based application protocols that would use the PMTU (DF bit)? Ramin > > > -- > > Regards > Abraham > > Ask not for whom the telephone bell tolls... > if thou art in the bathtub, it tolls for thee. > > ___________________________________________________ > Abraham vd Merwe - Frogfoot Networks CC > 9 Kinnaird Court, 33 Main Street, Newlands, 7700 > Phone: +27 21 686 1665 Cell: +27 82 565 4451 > Http: http://www.frogfoot.net/ Email: abz@frogfoot.net > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: clearing dont-fragment bit 2003-10-09 14:43 ` Ramin Dousti @ 2003-10-09 14:52 ` Abraham van der Merwe 2003-10-09 15:49 ` Ramin Dousti 0 siblings, 1 reply; 14+ messages in thread From: Abraham van der Merwe @ 2003-10-09 14:52 UTC (permalink / raw) To: Ramin Dousti; +Cc: Netfilter Discussions Hi Ramin >@2003.10.09_16:43:34_+0200 > > > > Are there any iptables extensions out there that allow you to clear the DF > > > > (Dont Fragment) bit in ip headers? > > > AFAIK no. Why would you want to do that? > > > I think I might write a module that would do that. > > > > I need it for tunnels. In a perfect world that wouldn't be necessary at all, > > but reality is that there's many brain dead admins that filter icmp, so if > > you build a tunnel over the big bad internet, you're screwed. > > > > You can use the TCPMSS target which solves it for tcp, but you still have > > the same problem with udp packets, so imho the only way to solve this > > properly is to fragment packets even if DF=1. > > The applications that set the DF bit, do so for a reason not just for the > fun. Sometimes (well, actually most of the time) it's for the performance > reasons in which case turning it off and having a poor performance is > preferable than it not working at all. On the other hand, the DF bit would be > set by the application probes to figure the PMTU. Setting that off on the > firewall would harm the purpose. Ideally one would want to leave DF untouched unless a packet with DF=1 is resent in which case you clear it - that way you solve PMTU probes, but I suspect this would be overly complicated / resource intensive. Even better would be if there was a tunnelling protocol that would just take packets on side A (incl ip headers, galore), chop it up, and reassemble it on the other side. Unfortunately there is no such thing :P > Can you come up with a list of the non-TCP-based application protocols that > would use the PMTU (DF bit)? Basically any UDP application that sends packets bigger than the maximum allowed mtu. I would assume TFTP, SNMP, etc. would all get into trouble. I know that some protocols such as DNS try to stay below 512 bytes payload, but there is probably a gazillion protocols out there that don't. -- Regards Abraham The meek shall inherit the earth; the rest of us will go to the stars. ___________________________________________________ Abraham vd Merwe - Frogfoot Networks CC 9 Kinnaird Court, 33 Main Street, Newlands, 7700 Phone: +27 21 686 1665 Cell: +27 82 565 4451 Http: http://www.frogfoot.net/ Email: abz@frogfoot.net ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: clearing dont-fragment bit 2003-10-09 14:52 ` Abraham van der Merwe @ 2003-10-09 15:49 ` Ramin Dousti 2003-10-09 16:13 ` Abraham van der Merwe 0 siblings, 1 reply; 14+ messages in thread From: Ramin Dousti @ 2003-10-09 15:49 UTC (permalink / raw) To: Netfilter Discussions On Thu, Oct 09, 2003 at 04:52:48PM +0200, Abraham van der Merwe wrote: > Ideally one would want to leave DF untouched unless a packet with DF=1 is > resent in which case you clear it - that way you solve PMTU probes, but I > suspect this would be overly complicated / resource intensive. > > Even better would be if there was a tunnelling protocol that would just take > packets on side A (incl ip headers, galore), chop it up, and reassemble it > on the other side. Unfortunately there is no such thing :P Use conntrack on both sides at the entrance. It'll ensure the reassembly of the fragments... > > > Can you come up with a list of the non-TCP-based application protocols that > > would use the PMTU (DF bit)? > > Basically any UDP application that sends packets bigger than the maximum > allowed mtu. I would assume TFTP, SNMP, etc. would all get into trouble. I > know that some protocols such as DNS try to stay below 512 bytes payload, > but there is probably a gazillion protocols out there that don't. Neither TFTP nor SNMP set the DF bit and as you said DNS enforces the packet size itself. NFS might do that though (not sure) but one would think that NFS should not span over the Internet. So, what other UDP-based applications use the DF bit? Ramin ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: clearing dont-fragment bit 2003-10-09 15:49 ` Ramin Dousti @ 2003-10-09 16:13 ` Abraham van der Merwe 2003-10-09 19:44 ` Ramin Dousti 0 siblings, 1 reply; 14+ messages in thread From: Abraham van der Merwe @ 2003-10-09 16:13 UTC (permalink / raw) To: Ramin Dousti; +Cc: Netfilter Discussions Hi Ramin >@2003.10.09_17:49:06_+0200 > > Ideally one would want to leave DF untouched unless a packet with DF=1 is > > resent in which case you clear it - that way you solve PMTU probes, but I > > suspect this would be overly complicated / resource intensive. > > > > Even better would be if there was a tunnelling protocol that would just take > > packets on side A (incl ip headers, galore), chop it up, and reassemble it > > on the other side. Unfortunately there is no such thing :P > > Use conntrack on both sides at the entrance. It'll ensure the reassembly of > the fragments... I'm not sure I understand? You're saying that given the following scenario: +---+ | A | +---+ | eth0 (mtu=1500) | | | eth0 (mtu=1500) +---+ | B | +---+ | eth1 (mtu=1500), gre-tunnel-side-a (mtu=1476) | | | eth1 (mtu=1500), gre-tunnel-side-b (mtu=1476) +---+ | C | +---+ | eth0 (mtu=1500) | | | eth0 (mtu=1500) +---+ | D | +---+ Given that B and C have conntrack enabled, if A sends a 1500 byte packet to D with DF=1 then B will fragment the packet, send it to C which will then assemble it (in such a way that the packet that arrived at B will be identical to the one at C with just the ttl updated) and send it to D? If not, then please explain. The above behaviour is what I meant. > > > Can you come up with a list of the non-TCP-based application protocols that > > > would use the PMTU (DF bit)? > > > > Basically any UDP application that sends packets bigger than the maximum > > allowed mtu. I would assume TFTP, SNMP, etc. would all get into trouble. I > > know that some protocols such as DNS try to stay below 512 bytes payload, > > but there is probably a gazillion protocols out there that don't. > > Neither TFTP nor SNMP set the DF bit and as you said DNS enforces the > packet size itself. NFS might do that though (not sure) but one would > think that NFS should not span over the Internet. So, what other UDP-based > applications use the DF bit? Unless I'm missing something setting/clearing the DF bit is up to the kernel, not the application. So if I do fd = socket(PF_INET, SOCK_DGRAM, 0); sendto(fd, buf, 1500, 0, ...); from my shiny snmp server and buf contains a 1500 byte PDU, then it is up to the kernel to decide whether to set DF or not... -- Regards Abraham The 'A' is for content, the 'minus' is for not typing it. Don't ever do this to my eyes again. -- Professor Ronald Brady, Philosophy, Ramapo State College ___________________________________________________ Abraham vd Merwe - Frogfoot Networks CC 9 Kinnaird Court, 33 Main Street, Newlands, 7700 Phone: +27 21 686 1665 Cell: +27 82 565 4451 Http: http://www.frogfoot.net/ Email: abz@frogfoot.net ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: clearing dont-fragment bit 2003-10-09 16:13 ` Abraham van der Merwe @ 2003-10-09 19:44 ` Ramin Dousti 0 siblings, 0 replies; 14+ messages in thread From: Ramin Dousti @ 2003-10-09 19:44 UTC (permalink / raw) To: Netfilter Discussions > > Use conntrack on both sides at the entrance. It'll ensure the reassembly of > > the fragments... > > I'm not sure I understand? You're saying that given the following scenario: > > +---+ > | A | > +---+ > | eth0 (mtu=1500) > | > | > | eth0 (mtu=1500) > +---+ > | B | > +---+ > | eth1 (mtu=1500), gre-tunnel-side-a (mtu=1476) > | > | > | eth1 (mtu=1500), gre-tunnel-side-b (mtu=1476) > +---+ > | C | > +---+ > | eth0 (mtu=1500) > | > | > | eth0 (mtu=1500) > +---+ > | D | > +---+ > > Given that B and C have conntrack enabled, if A sends a 1500 byte packet to > D with DF=1 then B will fragment the packet, send it to C which will then > assemble it (in such a way that the packet that arrived at B will be > identical to the one at C with just the ttl updated) and send it to D? > > If not, then please explain. The above behaviour is what I meant. No, what I was meaning to say was that if the conntrack in enabled on, say C, then the reassembly takes place on C. But for the above situation, I'd suggest you (according to the Cisco page you sent in another email) to increase the MTU on the GRE interface and have it just fragment the encapsulating packets on B and defragment it on C without any involvement of the tunneled packets. Give it a go and see if it works. > > Neither TFTP nor SNMP set the DF bit and as you said DNS enforces the > > packet size itself. NFS might do that though (not sure) but one would > > think that NFS should not span over the Internet. So, what other UDP-based > > applications use the DF bit? > > Unless I'm missing something setting/clearing the DF bit is up to the > kernel, not the application. So if I do > > fd = socket(PF_INET, SOCK_DGRAM, 0); > sendto(fd, buf, 1500, 0, ...); > > from my shiny snmp server and buf contains a 1500 byte PDU, then it is up to > the kernel to decide whether to set DF or not... I think we're confusing two things here: 1) It is up to the IP stack to fragment based on the MTU of the interface, size of the packet and the DF bit. 2) It is up to the application to ask for the setting of the DF bit. I believe you need to work on a SOCK_RAW socket to (un)set this. But I leave this discussion to the programming guru's. A good source is Van Jacobson's traceroute. Ramin ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: clearing dont-fragment bit 2003-10-09 13:43 clearing dont-fragment bit Abraham van der Merwe 2003-10-09 14:03 ` Maciej Soltysiak @ 2003-10-09 16:23 ` Ralf Spenneberg 2003-10-09 16:50 ` Abraham van der Merwe 1 sibling, 1 reply; 14+ messages in thread From: Ralf Spenneberg @ 2003-10-09 16:23 UTC (permalink / raw) To: Abraham van der Merwe; +Cc: Netfilter Discussions Am Don, 2003-10-09 um 15.43 schrieb Abraham van der Merwe: > Hi! > > Are there any iptables extensions out there that allow you to clear the DF > (Dont Fragment) bit in ip headers? If you clear the DF-Bit and use Linux on either side of the tunnel where the packets are fragmented you are in deep trouble, because Linux 2.4 (when using PMTU) not only sets the DF-Bit but also clears the IP-ID which is needed to defragment the packets again. So, when clearing the DF-Bit you have to ensure unique numbers in the IP-ID field, too. Cheers, Ralf -- Ralf Spenneberg RHCE, RHCX Book: Intrusion Detection für Linux Server http://www.spenneberg.com IPsec-Howto http://www.ipsec-howto.org Honeynet Project Mirror: http://honeynet.spenneberg.org ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: clearing dont-fragment bit 2003-10-09 16:23 ` Ralf Spenneberg @ 2003-10-09 16:50 ` Abraham van der Merwe 2003-10-09 17:12 ` Ralf Spenneberg 0 siblings, 1 reply; 14+ messages in thread From: Abraham van der Merwe @ 2003-10-09 16:50 UTC (permalink / raw) To: Ralf Spenneberg; +Cc: Netfilter Discussions Hi Ralf >@2003.10.09_18:23:06_+0200 > > Are there any iptables extensions out there that allow you to clear the DF > > (Dont Fragment) bit in ip headers? > If you clear the DF-Bit and use Linux on either side of the tunnel where > the packets are fragmented you are in deep trouble, because Linux 2.4 > (when using PMTU) not only sets the DF-Bit but also clears the IP-ID > which is needed to defragment the packets again. So, when clearing the > DF-Bit you have to ensure unique numbers in the IP-ID field, too. Surely if I clear the DF-bit in the mangle table then the ipstack should only defragment the packet later on when it made a routing decision and decided over which interface to send the packet(s) and set the IP-ID fields and MF-bit accordingly? Are there any other side-effects when clearing the DF-bit? -- Regards Abraham Who loves me will also love my dog. -- John Donne ___________________________________________________ Abraham vd Merwe - Frogfoot Networks CC 9 Kinnaird Court, 33 Main Street, Newlands, 7700 Phone: +27 21 686 1665 Cell: +27 82 565 4451 Http: http://www.frogfoot.net/ Email: abz@frogfoot.net ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: clearing dont-fragment bit 2003-10-09 16:50 ` Abraham van der Merwe @ 2003-10-09 17:12 ` Ralf Spenneberg 2003-10-09 18:11 ` Abraham van der Merwe 0 siblings, 1 reply; 14+ messages in thread From: Ralf Spenneberg @ 2003-10-09 17:12 UTC (permalink / raw) To: Abraham van der Merwe; +Cc: Netfilter Discussions Am Don, 2003-10-09 um 18.50 schrieb Abraham van der Merwe: > Hi Ralf >@2003.10.09_18:23:06_+0200 > > > > Are there any iptables extensions out there that allow you to clear the DF > > > (Dont Fragment) bit in ip headers? > > If you clear the DF-Bit and use Linux on either side of the tunnel where > > the packets are fragmented you are in deep trouble, because Linux 2.4 > > (when using PMTU) not only sets the DF-Bit but also clears the IP-ID > > which is needed to defragment the packets again. So, when clearing the > > DF-Bit you have to ensure unique numbers in the IP-ID field, too. > > Surely if I clear the DF-bit in the mangle table then the ipstack should > only defragment the packet later on when it made a routing decision and > decided over which interface to send the packet(s) and set the IP-ID fields > and MF-bit accordingly? Usually the IP-ID field is set by the sender and not by the router fragmenting the packet. You have to set the IP-ID field and clear the DF-Bit at the same time. > > Are there any other side-effects when clearing the DF-bit? Only maybe the overhead when a fragment is lost. Cheers, Ralf -- Ralf Spenneberg RHCE, RHCX Book: Intrusion Detection für Linux Server http://www.spenneberg.com IPsec-Howto http://www.ipsec-howto.org Honeynet Project Mirror: http://honeynet.spenneberg.org ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: clearing dont-fragment bit 2003-10-09 17:12 ` Ralf Spenneberg @ 2003-10-09 18:11 ` Abraham van der Merwe 2003-10-10 5:13 ` Ralf Spenneberg 0 siblings, 1 reply; 14+ messages in thread From: Abraham van der Merwe @ 2003-10-09 18:11 UTC (permalink / raw) To: Ralf Spenneberg; +Cc: Netfilter Discussions Hi Ralf >@2003.10.09_19:12:51_+0200 > > > > Are there any iptables extensions out there that allow you to clear the DF > > > > (Dont Fragment) bit in ip headers? > > > If you clear the DF-Bit and use Linux on either side of the tunnel where > > > the packets are fragmented you are in deep trouble, because Linux 2.4 > > > (when using PMTU) not only sets the DF-Bit but also clears the IP-ID > > > which is needed to defragment the packets again. So, when clearing the > > > DF-Bit you have to ensure unique numbers in the IP-ID field, too. > > > > Surely if I clear the DF-bit in the mangle table then the ipstack should > > only defragment the packet later on when it made a routing decision and > > decided over which interface to send the packet(s) and set the IP-ID fields > > and MF-bit accordingly? > Usually the IP-ID field is set by the sender and not by the router > fragmenting the packet. You have to set the IP-ID field and clear the > DF-Bit at the same time. Yes, I know, but as long as all the fragments have unique ids it shouldn't matter. Also, if the packet is fragmented along the way under normal circumstances (i.e. DF=0), then the IP-ID field would have to be incremented by the router fragmenting the packet. Have a look at this: http://www.cisco.com/warp/public/105/56.html On IOS you can clear the DF-bit and Cisco actually recommends it for this particular problem so as long as IP-ID is unique for the fragments (which should be the case) I don't see any problems doing it on Linux other than degraded performance. -- Regards Abraham Why is it taking so long for her to bring out all the good in you? ___________________________________________________ Abraham vd Merwe - Frogfoot Networks CC 9 Kinnaird Court, 33 Main Street, Newlands, 7700 Phone: +27 21 686 1665 Cell: +27 82 565 4451 Http: http://www.frogfoot.net/ Email: abz@frogfoot.net ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: clearing dont-fragment bit 2003-10-09 18:11 ` Abraham van der Merwe @ 2003-10-10 5:13 ` Ralf Spenneberg 2003-10-10 8:17 ` Abraham van der Merwe 0 siblings, 1 reply; 14+ messages in thread From: Ralf Spenneberg @ 2003-10-10 5:13 UTC (permalink / raw) To: Abraham van der Merwe; +Cc: Netfilter Discussions Am Don, 2003-10-09 um 20.11 schrieb Abraham van der Merwe: > Yes, I know, but as long as all the fragments have unique ids it shouldn't > matter. Also, if the packet is fragmented along the way under normal > circumstances (i.e. DF=0), then the IP-ID field would have to be incremented > by the router fragmenting the packet. True but Linux 2.4 clears the IP-ID field when sending a packet with the DF-Bit set. You have to manually recreate a unique IP-ID field when clearing the DF-Bit on the firewall. Even when the router increments this field all packets will have the ID of 1. When defragmenting the receiver does not know which fragment belongs to which packet. Linux 2.4 is the only operating system I know of that shows this behavior. Cheers, Ralf -- Ralf Spenneberg RHCE, RHCX Book: Intrusion Detection für Linux Server http://www.spenneberg.com IPsec-Howto http://www.ipsec-howto.org Honeynet Project Mirror: http://honeynet.spenneberg.org ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: clearing dont-fragment bit 2003-10-10 5:13 ` Ralf Spenneberg @ 2003-10-10 8:17 ` Abraham van der Merwe 0 siblings, 0 replies; 14+ messages in thread From: Abraham van der Merwe @ 2003-10-10 8:17 UTC (permalink / raw) To: Ralf Spenneberg; +Cc: Netfilter Discussions [-- Attachment #1: msg.pgp --] [-- Type: application/pgp, Size: 1708 bytes --] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ralf >@2003.10.10_07:13:06_+0200 > Am Don, 2003-10-09 um 20.11 schrieb Abraham van der Merwe: > > Yes, I know, but as long as all the fragments have unique ids it shouldn't > > matter. Also, if the packet is fragmented along the way under normal > > circumstances (i.e. DF=0), then the IP-ID field would have to be incremented > > by the router fragmenting the packet. > True but Linux 2.4 clears the IP-ID field when sending a packet with the > DF-Bit set. You have to manually recreate a unique IP-ID field when > clearing the DF-Bit on the firewall. Even when the router increments > this field all packets will have the ID of 1. When defragmenting the > receiver does not know which fragment belongs to which packet. > > Linux 2.4 is the only operating system I know of that shows this > behavior. Ok, I see what you're getting at. That brings us back to my original suggestion. If the tunnel could do the fragmentation _and_ reassembly then this would not be a problem. *sigh* - -- Regards Abraham I hate it when my foot falls asleep during the day cause that means it's going to be up all night. -- Steven Wright ___________________________________________________ Abraham vd Merwe - Frogfoot Networks CC 9 Kinnaird Court, 33 Main Street, Newlands, 7700 Phone: +27 21 686 1665 Cell: +27 82 565 4451 Http: http://www.frogfoot.net/ Email: abz@frogfoot.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (GNU/Linux) Comment: Debian :: The Universal Operating System iD8DBQE/hmsl0jJV70h31dERAsLkAJ94k/LXfuSidWOmBIb2uZkF5Vi9jwCaA17A Fr8tm9CXx5vCLx7u0A8sLmM= =aaCy -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2003-10-10 8:17 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-10-09 13:43 clearing dont-fragment bit Abraham van der Merwe 2003-10-09 14:03 ` Maciej Soltysiak 2003-10-09 14:08 ` Abraham van der Merwe 2003-10-09 14:43 ` Ramin Dousti 2003-10-09 14:52 ` Abraham van der Merwe 2003-10-09 15:49 ` Ramin Dousti 2003-10-09 16:13 ` Abraham van der Merwe 2003-10-09 19:44 ` Ramin Dousti 2003-10-09 16:23 ` Ralf Spenneberg 2003-10-09 16:50 ` Abraham van der Merwe 2003-10-09 17:12 ` Ralf Spenneberg 2003-10-09 18:11 ` Abraham van der Merwe 2003-10-10 5:13 ` Ralf Spenneberg 2003-10-10 8:17 ` Abraham van der Merwe
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.