Re: can any one log into ftp.freebsd.org
On Fri, Feb 01, 2002 at 11:21:52AM -, Bri wrote: I can't. It's running with a very high load, as as it's welcome message says, check the below URL for a closer mirror, normally you will find one. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html /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 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: 4G phisical memory kernel trap
On Wed, Dec 05, 2001 at 03:57:22PM +0300, Varshavchick Alexander wrote: Hi, I have a PIII box with 4G phisical memory and FreeBSD 4.2 and it traps while booting - fatal trap 12 page fault. With less than 4G memory the server is working good. There is no MAXMEM option in the kernel (as is by default). What would you suggest to make this box running with 4G? May be, specifying MAXMEM slightly less than 4G, or what else? Thank you. Try upgrading it to 4.4-STABLE, there has been dome some work regarding this since 4.2 /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: ftpd....
On Wed, Jul 04, 2001 at 12:48:38PM -0700, Terry Lambert wrote: Mike Smith wrote: Unless I'm mistaken, the current ftpd doesn't offer the functionality you're asking for either, so there's no valid reason to block the import of the lukem ftpd on these grounds. And, I'm quite certain that Luke would happily consider patches, if you were to put them forward. Neither one of them hold a candle to the load CDROM.COM can handle. How about we import dg-ftpd instead? I'm sure we'd all like to be able to support 1TB a day of data transferred... According to jkh it's quite ftp.FreeBSD.org specific ... /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: How to disable software TCP checksumming?
On Tue, May 29, 2001 at 02:41:14PM -0500, Bob Willcox wrote:
Hi,
I am working on a device driver for a GSN adapter that has hardware CRC
checking and need to know if there is a way to disable the software CRC
checking for TCP? This is on a FreeBSD 4.2-stable system.
Not without modifying the source, the below should do it from a
quick look.
Index: src/sys/netinet/tcp_input.c
===
RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v
retrieving revision 1.130
diff -u -r1.130 tcp_input.c
--- src/sys/netinet/tcp_input.c 2001/05/29 19:54:45 1.130
+++ src/sys/netinet/tcp_input.c 2001/05/29 20:07:22
@@ -401,6 +401,7 @@
th = (struct tcphdr *)((caddr_t)ip + off0);
tlen = ip-ip_len;
+#if 0
if (m-m_pkthdr.csum_flags CSUM_DATA_VALID) {
if (m-m_pkthdr.csum_flags CSUM_PSEUDO_HDR)
th-th_sum = m-m_pkthdr.csum_data;
@@ -423,6 +424,7 @@
tcpstat.tcps_rcvbadsum++;
goto drop;
}
+#endif
#ifdef INET6
/* Re-initialization for later version check */
ip-ip_v = IPVERSION;
/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: systat -vmstat or iostat IO help
On Mon, Mar 05, 2001 at 06:08:25PM -0800, Matt Dillon wrote: :I am trying to figure out corelation between Inactive and Free then. :Inact would be unused ram right? :Free would be what how much of Active is being used? So what you are :saying is if there is to much free then alot of active pages are being :killed for some reason...as seen in error logs etc? just trying to get :a quick overview of what a good accessment that was...never thought of :that. 'free' (from systat -vm or top) is all that matters in your case. Active/Inactive/Cache are best simply added together. Their individual values will depend heavily on the load on the machine because the VM system doesn't bother to keep things in their proper queues if the memory load is low. Could you please give a pointer to a description of the meaning of Active, Inactive and Cache, on a machine I see this Mem: 138M Active, 661M Inact, 114M Wired, 48M Cache, 112M Buf, 44M Free Swap: 1612M Total, 16K Used, 1612M Free Yes I know it has too much memory, but I'm surprised why more isn't used for disk caching /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: qmail IO--qmail vs postfix competition
On Tue, Feb 20, 2001 at 01:22:57AM -0800, Gordon Tetlow wrote: My company (online greeting cards) sent our 4 million emails in 4 hours using a cluster of about 30 mailers with qmail on FreeBSD (old version of FreeBSD at that). That averages to 16,666 mail messages per minute or about 500 per minute per server. The best part was the servers weren't breaking a sweat. Is that 4 million different emails, or a much lower number of mails with multiple recipients ? /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: React to ICMP administratively prohibited ? - commit candidate ?
On Fri, Nov 17, 2000 at 09:10:13PM +0100, Jesper Skriver wrote:
As said before, I've not got this code working, when the sysctl
'net.inet.tcp.icmp_admin_prohib_like_rst' is set to 1, we'll treat a
ICMP administratively prohibited (icmp type 3 code 9, 10 and 13) as if
we recived a TCP RST, but only if the TCP session is in SYN_SENT state.
This is actually required by rfc1122 (Requirements for Internet Hosts)
section 3.2.2.1
A Destination Unreachable message that is received MUST be
reported to the transport layer. The transport layer SHOULD
use the information appropriately; for example, see Sections
4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol
that has its own mechanism for notifying the sender that a
port is unreachable (e.g., TCP, which sends RST segments)
MUST nevertheless accept an ICMP Port Unreachable for the
same purpose.
Because of this, I suggest that we by default enable this feature, but
it would be a change of current behaviour, so if people prefer to leave
it disabled by default, at least for now, this would be ok for me, the
attached diff actually have the sysctl set to 0 by default.
The only difference from the attached diff, to the one I mailed
yesterday is comments.
Does anyone have any objections to this being committed ? If no, who
will do it ?
/Jesper
--
Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456
Work:Network manager @ AS3292 (Tele Danmark DataNetworks)
Private: Geek@ 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.
diff -ru sys/netinet.old/ip_icmp.c sys/netinet/ip_icmp.c
--- sys/netinet.old/ip_icmp.c Thu Nov 2 10:46:23 2000
+++ sys/netinet/ip_icmp.c Mon Nov 20 22:33:43 2000
@@ -328,6 +328,11 @@
case ICMP_UNREACH_NET_UNKNOWN:
case ICMP_UNREACH_NET_PROHIB:
+ if (icp-icmp_ip.ip_p == IPPROTO_TCP) {
+ code = PRC_UNREACH_PORT;
+ break;
+ }
+
case ICMP_UNREACH_TOSNET:
code = PRC_UNREACH_NET;
break;
@@ -335,11 +340,21 @@
case ICMP_UNREACH_HOST_UNKNOWN:
case ICMP_UNREACH_ISOLATED:
case ICMP_UNREACH_HOST_PROHIB:
+ if (icp-icmp_ip.ip_p == IPPROTO_TCP) {
+ code = PRC_UNREACH_PORT;
+ break;
+ }
+
case ICMP_UNREACH_TOSHOST:
code = PRC_UNREACH_HOST;
break;
case ICMP_UNREACH_FILTER_PROHIB:
+ if (icp-icmp_ip.ip_p == IPPROTO_TCP) {
+ code = PRC_UNREACH_PORT;
+ break;
+ }
+
case ICMP_UNREACH_HOST_PRECEDENCE:
case ICMP_UNREACH_PRECEDENCE_CUTOFF:
code = PRC_UNREACH_PORT;
diff -ru sys/netinet.old/tcp_subr.c sys/netinet/tcp_subr.c
--- sys/netinet.old/tcp_subr.c Fri Oct 27 13:45:41 2000
+++ sys/netinet/tcp_subr.c Tue Nov 21 21:16:27 2000
@@ -134,6 +134,15 @@
SYSCTL_INT(_net_inet_tcp, OID_AUTO, pcbcount, CTLFLAG_RD,
tcbinfo.ipi_count, 0, "Number of active PCBs");
+/*
+ * Treat ICMP administratively prohibited like a TCP RST
+ * as required by rfc1122 section 3.2.2.1
+ */
+
+static int icmp_admin_prohib_like_rst = 0;
+SYSCTL_INT(_net_inet_tcp, OID_AUTO, icmp_admin_prohib_like_rst, CTLFLAG_RW,
+ icmp_admin_prohib_like_rst, 0, "Treat ICMP administratively prohibited
+messages like TCP RST, rfc1122 section 3.2.2.1");
+
static voidtcp_cleartaocache __P((void));
static voidtcp_notify __P((struct inpcb *, int));
@@ -961,6 +970,8 @@
if (cmd == PRC_QUENCH)
notify = tcp_quench;
+ else if ((icmp_admin_prohib_like_rst == 1) (cmd == PRC_UNREACH_PORT)
+(ip))
+ notify = tcp_drop_syn_sent;
else if (cmd == PRC_MSGSIZE)
notify = tcp_mtudisc;
else if (!PRC_IS_REDIRECT(cmd)
@@ -1071,6 +1082,20 @@
if (tp)
tp-snd_cwnd = tp-t_maxseg;
+}
+
+/*
+ * When a ICMP unreachable is recieved, drop the
+ * TCP connection, but only if in SYN_SENT
+ */
+void
+tcp_drop_syn_sent(inp, errno)
+ struct inpcb *inp;
+ int errno;
+{
+ struct tcpcb *tp = intotcpcb(inp);
+ if((tp) (tp-t_state == TCPS_SYN_SENT))
+ tcp_drop(tp, errno);
}
/*
diff -ru sys/netinet.old/tcp_var.h sys/netin
Re: React to ICMP administratively prohibited ?
On Sat, Nov 18, 2000 at 03:54:46PM +0100, Jesper Skriver wrote:
On Fri, Nov 17, 2000 at 02:29:04PM -0800, Alfred Perlstein wrote:
* Jesper Skriver [EMAIL PROTECTED] [001117 12:11] wrote:
[snip]
This timeout could be avoided if the sending mail server reacted to the
'ICMP administratively prohibited' they got from our router.
[snip]
$ telnet nemo.dyndns.dk 25
Trying 193.89.247.125...
telnet: Unable to connect to remote host: No route to host
$ uname -a
Linux xyz.dk 2.0.32 #1 Wed Nov 19 00:46:45 EST 1997 i586 unknown
Wouldn't it be a idea to implement a similar behaviour in FreeBSD ?
Probably not, what if one started a stream of spoofed ICMP lying
about the state of the route between the two machines? I have
the impression that the Linux box wouldn't be able to connect
because of this behavior.
Correct, a attacker could in theory make sure we couldn't connect to
a given remote box, but as I see it, it's mostly in teory.
We could only react to this if we had a TCP session where we was
waiting for a SYN/ACK from this specific host, this only leaves a very
narrow window for a attacker to abuse, as he had to know both
destination and time.
Do you agree ?
A coworker of mine got into "rfc mode" and found the below, as we both
read it, it says that we MUST treat a ICMP unreachable like a TCP RST.
##
... A transport protocol
that has its own mechanism for notifying the sender that a
port is unreachable (e.g., TCP, which sends RST segments)
MUST nevertheless accept an ICMP Port Unreachable for the
same purpose.
##
A more complete quote.
##
RFC1122 (Requirements for Internet Hosts -- Communication Layers):
[...]
3.2.2.1 Destination Unreachable: RFC-792
The following additional codes are hereby defined:
6 = destination network unknown
7 = destination host unknown
8 = source host isolated
9 = communication with destination network
administratively prohibited
10 = communication with destination host
administratively prohibited
11 = network unreachable for type of service
12 = host unreachable for type of service
A host SHOULD generate Destination Unreachable messages with
code:
2(Protocol Unreachable), when the designated transport
protocol is not supported; or
3(Port Unreachable), when the designated transport
protocol (e.g., UDP) is unable to demultiplex the
datagram but has no protocol mechanism to inform the
sender.
A Destination Unreachable message that is received MUST be
reported to the transport layer. The transport layer SHOULD
use the information appropriately; for example, see Sections
4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol
that has its own mechanism for notifying the sender that a
port is unreachable (e.g., TCP, which sends RST segments)
MUST nevertheless accept an ICMP Port Unreachable for the
same purpose.
Again in (experimental) RFC2498 (IPPM Metrics for Measuring Connectivity):
[...]
6.6.5. Specific methodology for TCP:
A TCP-port-N1-port-N2 methodology sends TCP SYN packets with source
port N1 and dest port N2 at address A2. Network traffic incoming to
A1 is interpreted as follows:
[...]
+An ICMP port-unreachable from A2 to A1 indicates temporal
connectivity between the addresses (and again a *lack* of service
connectivity for TCP-port-N1-port-N2). {Comment: TCP
implementations generally do not need to send ICMP port-
unreachable messages because a separate mechanism is available
(sending a RST). However, RFC 1122 states that a TCP receiving an
ICMP port-unreachable MUST treat it the same as the equivalent
transport-level mechanism (for TCP, a RST).}
/Niels Chr.
--
Niels Christian Bank-Pedersen, NCB1-RIPE.
Network Manager, Tele Danmark NET, IP-section.
"Hey, are any of you guys out there actually *using* RFC 2549?"
/Jesper
--
Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456
Work:Network manager @ AS3292 (Tele Danmark DataNetworks)
Private: Geek@ 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: React to ICMP administratively prohibited ?
On Sat, Nov 18, 2000 at 06:36:32PM +0100, Jesper Skriver wrote:
I'll see if I can get code together which will do this.
I've now got this working (diff attached), it was actually quite
simple when I got a grip on what was going on in sys/netinet/, I'm
gratefull for comments.
Now I need to get this under the control of a sysctl, 'man 3 sysctl'
gives some information on how to read the setting of a sysctl, in
sys/netinet/ip_icmp.c I see how some of the others was implemented,
but should I put this here ?
static int drop_unreachable = 1;
SYSCTL_INT(_net_inet_icmp, OID_AUTO, drop_unreachable, CTLFLAG_RW,
drop_unreachable, 0, "");
/Jesper
--
Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456
Work:Network manager @ AS3292 (Tele Danmark DataNetworks)
Private: Geek@ 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.
diff -u -r sys/netinet.old/ip_icmp.c sys/netinet/ip_icmp.c
--- sys/netinet.old/ip_icmp.c Thu Nov 2 10:46:23 2000
+++ sys/netinet/ip_icmp.c Sun Nov 19 21:49:27 2000
@@ -328,6 +328,9 @@
case ICMP_UNREACH_NET_UNKNOWN:
case ICMP_UNREACH_NET_PROHIB:
+ code = PRC_UNREACH_PORT;
+ break;
+
case ICMP_UNREACH_TOSNET:
code = PRC_UNREACH_NET;
break;
@@ -335,11 +338,17 @@
case ICMP_UNREACH_HOST_UNKNOWN:
case ICMP_UNREACH_ISOLATED:
case ICMP_UNREACH_HOST_PROHIB:
+ code = PRC_UNREACH_PORT;
+ break;
+
case ICMP_UNREACH_TOSHOST:
code = PRC_UNREACH_HOST;
break;
case ICMP_UNREACH_FILTER_PROHIB:
+ code = PRC_UNREACH_PORT;
+ break;
+
case ICMP_UNREACH_HOST_PRECEDENCE:
case ICMP_UNREACH_PRECEDENCE_CUTOFF:
code = PRC_UNREACH_PORT;
diff -u -r sys/netinet.old/tcp_subr.c sys/netinet/tcp_subr.c
--- sys/netinet.old/tcp_subr.c Fri Oct 27 13:45:41 2000
+++ sys/netinet/tcp_subr.c Sun Nov 19 21:17:40 2000
@@ -961,6 +961,8 @@
if (cmd == PRC_QUENCH)
notify = tcp_quench;
+ else if ((cmd == PRC_UNREACH_PORT) (ip))
+ notify = tcp_drop_syn_sent;
else if (cmd == PRC_MSGSIZE)
notify = tcp_mtudisc;
else if (!PRC_IS_REDIRECT(cmd)
@@ -1071,6 +1073,20 @@
if (tp)
tp-snd_cwnd = tp-t_maxseg;
+}
+
+/*
+ * When a ICMP unreachable is recieved, drop the
+ * TCP connection, but only if in SYN SENT
+ */
+void
+tcp_drop_syn_sent(inp, errno)
+ struct inpcb *inp;
+ int errno;
+{
+ struct tcpcb *tp = intotcpcb(inp);
+ if((tp) (tp-t_state == TCPS_SYN_SENT))
+ tcp_drop(tp, errno);
}
/*
diff -u -r sys/netinet.old/tcp_var.h sys/netinet/tcp_var.h
--- sys/netinet.old/tcp_var.h Sat Jul 22 01:26:37 2000
+++ sys/netinet/tcp_var.h Sun Nov 19 21:17:55 2000
@@ -387,6 +387,7 @@
voidtcp_input __P((struct mbuf *, int, int));
voidtcp_mss __P((struct tcpcb *, int));
int tcp_mssopt __P((struct tcpcb *));
+voidtcp_drop_syn_sent __P((struct inpcb *, int));
voidtcp_mtudisc __P((struct inpcb *, int));
struct tcpcb *
tcp_newtcpcb __P((struct inpcb *));
Re: React to ICMP administratively prohibited ?
On Sun, Nov 19, 2000 at 04:03:04PM -0500, Louis A. Mamakos wrote: This patch seems like it will do the wrong thing for ICMP messages that are associated with non-TCP packets. It looks like ICMP unreachable messages for UDP packets will never get delivered to UDP sockets. Yep - I've come to think of this too, I think I'll make it behave like before for non-TCP packets, or do you have a better idea ? /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek@ 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: React to ICMP administratively prohibited ?
On Sun, Nov 19, 2000 at 10:04:51PM +0100, Jesper Skriver wrote:
On Sun, Nov 19, 2000 at 04:03:04PM -0500, Louis A. Mamakos wrote:
This patch seems like it will do the wrong thing for ICMP messages that
are associated with non-TCP packets. It looks like ICMP unreachable
messages for UDP packets will never get delivered to UDP sockets.
Yep - I've come to think of this too, I think I'll make it behave like
before for non-TCP packets, or do you have a better idea ?
New version attached, this time I check that it's a ICMP unreachable for
a TCP packet, if not this code behaves like the current code.
I still need some hints on the sysctl stuff.
/Jesper
--
Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456
Work:Network manager @ AS3292 (Tele Danmark DataNetworks)
Private: Geek@ 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.
diff -u -r sys/netinet.old/ip_icmp.c sys/netinet/ip_icmp.c
--- sys/netinet.old/ip_icmp.c Thu Nov 2 10:46:23 2000
+++ sys/netinet/ip_icmp.c Sun Nov 19 22:08:52 2000
@@ -328,6 +328,11 @@
case ICMP_UNREACH_NET_UNKNOWN:
case ICMP_UNREACH_NET_PROHIB:
+ if (icp-icmp_ip.ip_p == IPPROTO_TCP) {
+ code = PRC_UNREACH_PORT;
+ break;
+ }
+
case ICMP_UNREACH_TOSNET:
code = PRC_UNREACH_NET;
break;
@@ -335,11 +340,21 @@
case ICMP_UNREACH_HOST_UNKNOWN:
case ICMP_UNREACH_ISOLATED:
case ICMP_UNREACH_HOST_PROHIB:
+ if (icp-icmp_ip.ip_p == IPPROTO_TCP) {
+ code = PRC_UNREACH_PORT;
+ break;
+ }
+
case ICMP_UNREACH_TOSHOST:
code = PRC_UNREACH_HOST;
break;
case ICMP_UNREACH_FILTER_PROHIB:
+ if (icp-icmp_ip.ip_p == IPPROTO_TCP) {
+ code = PRC_UNREACH_PORT;
+ break;
+ }
+
case ICMP_UNREACH_HOST_PRECEDENCE:
case ICMP_UNREACH_PRECEDENCE_CUTOFF:
code = PRC_UNREACH_PORT;
diff -u -r sys/netinet.old/tcp_subr.c sys/netinet/tcp_subr.c
--- sys/netinet.old/tcp_subr.c Fri Oct 27 13:45:41 2000
+++ sys/netinet/tcp_subr.c Sun Nov 19 21:17:40 2000
@@ -961,6 +961,8 @@
if (cmd == PRC_QUENCH)
notify = tcp_quench;
+ else if ((cmd == PRC_UNREACH_PORT) (ip))
+ notify = tcp_drop_syn_sent;
else if (cmd == PRC_MSGSIZE)
notify = tcp_mtudisc;
else if (!PRC_IS_REDIRECT(cmd)
@@ -1071,6 +1073,20 @@
if (tp)
tp-snd_cwnd = tp-t_maxseg;
+}
+
+/*
+ * When a ICMP unreachable is recieved, drop the
+ * TCP connection, but only if in SYN SENT
+ */
+void
+tcp_drop_syn_sent(inp, errno)
+ struct inpcb *inp;
+ int errno;
+{
+ struct tcpcb *tp = intotcpcb(inp);
+ if((tp) (tp-t_state == TCPS_SYN_SENT))
+ tcp_drop(tp, errno);
}
/*
diff -u -r sys/netinet.old/tcp_var.h sys/netinet/tcp_var.h
--- sys/netinet.old/tcp_var.h Sat Jul 22 01:26:37 2000
+++ sys/netinet/tcp_var.h Sun Nov 19 21:17:55 2000
@@ -387,6 +387,7 @@
voidtcp_input __P((struct mbuf *, int, int));
voidtcp_mss __P((struct tcpcb *, int));
int tcp_mssopt __P((struct tcpcb *));
+voidtcp_drop_syn_sent __P((struct inpcb *, int));
voidtcp_mtudisc __P((struct inpcb *, int));
struct tcpcb *
tcp_newtcpcb __P((struct inpcb *));
Re: React to ICMP administratively prohibited ?
On Fri, Nov 17, 2000 at 02:29:04PM -0800, Alfred Perlstein wrote: * Jesper Skriver [EMAIL PROTECTED] [001117 12:11] wrote: [snip] This timeout could be avoided if the sending mail server reacted to the 'ICMP administratively prohibited' they got from our router. [snip] $ telnet nemo.dyndns.dk 25 Trying 193.89.247.125... telnet: Unable to connect to remote host: No route to host $ uname -a Linux xyz.dk 2.0.32 #1 Wed Nov 19 00:46:45 EST 1997 i586 unknown Wouldn't it be a idea to implement a similar behaviour in FreeBSD ? Probably not, what if one started a stream of spoofed ICMP lying about the state of the route between the two machines? I have the impression that the Linux box wouldn't be able to connect because of this behavior. Correct, a attacker could in theory make sure we couldn't connect to a given remote box, but as I see it, it's mostly in teory. We could only react to this if we had a TCP session where we was waiting for a SYN/ACK from this specific host, this only leaves a very narrow window for a attacker to abuse, as he had to know both destination and time. Do you agree ? /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek@ 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: React to ICMP administratively prohibited ?
On Sat, Nov 18, 2000 at 10:19:01AM +0200, John Hay wrote: I'm currently looking at how various operating systems react to a 'ICMP administratively prohibited'. My motivation is setup's where access to the primary mailserver is blocked by filters (usually to block open relay's), and all mail has to go via the backup MX, a example from a customer of ours. jesper@freesbee$ host -t mx nemo.dyndns.dk nemo.dyndns.dk mail is handled (pri=10) by nemo.dyndns.dk nemo.dyndns.dk mail is handled (pri=20) by backup-mx.post.tele.dk Here we block access to tcp/25 on nemo.dyndns.dk (a ADSL users), but provide a backup MX for him to use, but when a mailserver wants to send mail to him, they will experience a timeout before sending the mail to backup-mx.post.tele.dk, which can send the mail onwards to nemo.dyndns.dk. You can also solve the problem another way. You can remove the MX for the customer machine, so that your backup-mx is the prefered MX for his mail. Then on backup-mx you can add a mailertable entry to direct the mail to his machine. Something like: nemo.dyndns.dksmtp:[nemo.dyndns.dk] I know, but this require per-domain/user configuration on backup-mx, something we want to avoid at any cost, now you're going to ask how we make sure backup-mx is not a open relay. This is ensured by a patch(*) I wrote for postfix, from sample-smtpd.cf # permit_auth_mx_backup: accept mail if all ip address(es) of the primary MX is # within $auth_mx_backup_networks, See auth_mx_backup_networks # # The auth_mx_backup_networks parameter specifies a list of networks # where Postfix will act as a backup MX host if the primary MX is # within these networks, and permit_auth_mx_backup is configured. # # The list is used by the anti-UCE software. See permit_auth_mx_backup # in the sample-smtpd.cf file. This way you don't have to worry how someone else's machine is going to handle those icmp packets. Your solution is a good one, if the product has a margin that allow for user specific configuration on the backup-mx, but in this case it's a ADSL product for home users, with a very little margin ... *) http://freesbee.wheel.dk/~jesper/permit_auth_mx_backup.20001030.diff See the postfix.users archive for history (the above patch is the same, only relative to 20001030 instead of 2531. http://x71.deja.com/[ST_rn=ps]/getdoc.xp?AN=648703086CONTEXT=974559861.626524165hitnum=26 /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek@ 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: React to ICMP administratively prohibited ?
On Sat, Nov 18, 2000 at 03:18:36PM -0600, Mike Silbersack wrote: On Sat, 18 Nov 2000, Jesper Skriver wrote: or just stop filtering totally. Which is not a option in this case, and in the real world it's that uncommon. I'll see if I can get code together which will do this. If we leave this off by default, would people object to putting in this functionality ? /Jesper What's the point? If people complain about a badly setup MX behind a firewall, are you going to respond and tell them to flip a sysctl? My motivation is primarily to get the code working, and perhaps in the future get it enabled by default. But until then tell people that a sysctl can get this behaviour. This isn't a case of interoperability with a common TCP stack which needs to be lived with. It's a case of something that is broken even with the suggested "fix". I wouldn't call it broken, why should the routers bother to send a ICMP access prohibited (or any of the other unreachables) if nobody cares anyway. My approach is a bit more pragmatic, and as I can see it, the chance that a attacker can abuse this seems very slim. The correct thing to do in this situation is to configure sendmail properly so that the MX silliness isn't needed. Using a static mail routing from a public known MX to the real mailserver is certainly a better solution if the same people control both, but in this case it's not like that. Let me explain in a bit more detail. We have lots of ADSL users (potentially hundreds of thousands), lots of these have open relays(*) that relay via our mailservers, making our mailservers open for spammers to use. The best solution we have been able to find, was the filters that block access to tcp/25 except from the backup-mx host, this eliminated the open relays once and for all, with very little work. We have no knowledge of which domains the users have (and this also changes all the time), and the price structure doesn't leave room for the hazzle of maintaining (and supporting) such static mail routing table, it's also significantly easier for the users to understand why they should configure xyz.dk. IN MX 10 xyz.dk. xyz.dk. IN MX 20 backup-mx.post.tele.dk. than xyz.dk. IN MX 10 backup-mx.post.tele.dk. And then do what ever to get the static mail routing configured. *) Often a simple "gateway" like WinGate or similar with by default seems to give this "functionality" :-( /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek@ 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: bridging
On Thu, Jul 06, 2000 at 12:13:07PM -0400, Nick Evans wrote: Correct me if I am wrong, but isn't bridging of two interfaces supposed to make a duplicate of the traffic from one onto another? Why is it then that on the second interface I bridge to I only see broadcast and multicast packets? I have fxp0 and fxp1 acting as a bridge, fxp0 sees all kinds of http traffic, napster, IM, etc. but fxp1 sees only multi/broadcast packets. Bridging will only bridge unicast packet's who's destination MAC adress is on the other side of the bridge. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek@ 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: vinum raid5 panics
On Tue, Apr 18, 2000 at 09:32:34PM +0200, Soren Schmidt wrote: It seems Chad David wrote: I just put together a 5 disk raid5 system using vinum on 4.0 from last Wed., and I am experiencing random panics. I can force the panic by working on the filesystem, but sometimes just having it mounted kills the machine. I compiled a debug kernel, and got a crash dump, but I am not an expert at debugging crash dumps, so any advice would be appreciated. Instead of dumping out fifty pages of kernel and hardware config could anyone who is working on this let me know what would be helpful... I bet you see the same problem as others do In my book vinum on 4.0 is plain broken. RAID5 has problems, I have no problems with RAID0, RAID1 or RAID0+1 ... BTW do you have a fxp netcard pr chance ?? I do. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: desire for ftp.internat.freebsd.org mirror
On Thu, Apr 06, 2000 at 11:39:03AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], "David O'Brien" writes: Access to ftp.internat.freebsd.org from the USA (and presumably elsewhere) is an abomination. Isn't there *anyone* with an permanate FTP server that could officially mirror the crypto bits from ftp.internat.freebsd.org? I may be able to arrange a server here in Denmark with a 10-20 Mbit upstream. If the amount of data is not huge, we can put it on ftp.dk.FreeBSD.org ... /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek@ 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: Mirror requirements
On Thu, Mar 30, 2000 at 09:42:42AM -0500, Patrick Gardella wrote: Lloyd Rennie wrote: I sent this to -questions, but have received no reply. Sorry to bug y'all, but... What are the hardware and bandwidth requirements to maintain a full FreeBSD mirror site? Having asked this before, I can try to answer it... Hardware: Disk space to hold the parts you want to mirror. Are you looking to be just an FTP mirror, a WWW mirror (about 8 megs), a CVSUP mirror, or some combination of all of these? I would say that a safe bet would be an 8 gig HD for all of them. I keep a partial ftp mirror, and it barely fits 20 GB ... /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek@ 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: BSD VS BDS
On Tue, Mar 28, 2000 at 12:11:28AM -0800, Brooks Davis wrote: On Tue, Mar 28, 2000 at 09:39:11AM +0200, Konrad Heuer wrote: The most important strength of NetBSD is its availability on many different hardware platforms. If you plan to set up your servers on Intel or DECalpha software, FreeBSD might do better for you. For example, FreeBSD supports multi-processor systems, NetBSD does not. The FreeBSD install program is more user-friendly. Just FYI, NetBSD does now have early SMP support. Initial x86 SMP code was commited Feb 22. Obviously, you probably don't want to go running a high-availibility server application on SMP code that's only a month old, but it's coming along. I was under the assumption that NetBSD's SMP code only initializes the second CPU, but never actually uses it for anything ... /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek@ 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: SYM driver -- where to find?
On Sat, Feb 26, 2000 at 08:59:36AM -0500, Marc Nicholas wrote: Sorry for the lameness of this question...but where can I find the Symbios driver for FreeBSD developed by Gerrard Roudier? I'm having some issues with a Symbios controller that I suspect may be the fault of the NCR driver and not the controller itself. It's in 4.0-CURRENT ... /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek@ 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: Running unattended (ifo FFS thread)
On Sun, Nov 07, 1999 at 04:57:54PM +0100, Dag-Erling Smorgrav wrote: Kevin Day [EMAIL PROTECTED] writes: The problem is that 'fsck -py' ignores the 'p' and will fsck every time, even if it's unneeded. This takes ages for me. I believe I submitted a PR with a 'fix' to fsck. 'fsck -p || fsck -y' should do the trick. What about at rc.conf knob, that make /etc/rc use this instead of the normal fsck -p ?? This could be useful for servers at remote sites. Should I submit a PR with a diff ? /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) 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: mrtg,FreeBSD, asus p2b temperature
On Mon, Sep 27, 1999 at 02:03:35AM -0400, Dan Moschuk wrote: | Does anybody have any tips for using the above combination for graphing temperatures? | | Leif As far as I know, MRTG is only able to fetch data from SNMP MIBs. Which, in order to get the information you're looking for, two things have to happen. You need to first have the kernel fetch that information from the motherboard, and then some userland program to return it in the form of an SNMP response. So, unless you are prepared to dust off that C compiler, you're out of luck. In the past I've used a syntax like Target[abc]: `cat file` or Target[abc]: `program` Where the program has output like (or the file contains) First number\n Second number\n \n \n /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) 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: Postfix license update.
On Thu, Jul 01, 1999 at 01:27:38PM +0100, Dominic Mitchell wrote: Just to let you all know, it appears that the termination clause has been dropped, but it appears to have gained a gpl-like must make source available clause. http://msgs.securepoint.com/cgi-bin/get/postfix9906/103.html (and where I found it) http://www.lwn.net/1999/0701/a/postfix.html This has been discussed at the postfix-us...@postfix.org mailing list, just download the newest version, and you will see it .. /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) 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 majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Anybody using the Efficient Networks ATM PCI adapter?
On Thu, Jun 24, 1999 at 06:39:07PM -0700, Jaye Mathisen wrote: I see it's supported, but I'm curious if anybody is using it. If so, I'd like to ask a few questions off-line of somebody... Soren S. Jorvang so...@t.dk is working on a NetBSD driver for the ATM25 version ... he claims it should be relative easy to bring it over to FreeBSD when it's ready. /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) 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 majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
