RE: Some performance measurements on the FreeBSD network stack
Hi, On Tue, 24 Apr 2012, 17:40-, Li, Qing wrote: > Yup, all good points. In fact we have considered all of these while doing > the work. In case you haven't seen it already, we did write about these > issues in our paper and how we tried to address those, flow-table was one > of the solutions. > > http://dl.acm.org/citation.cfm?id=1592641 Is this article available for those without ACM subscription? -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
bin/121359
The following reply was made to PR bin/121359; it has been noted by GNATS.
From: Maxim Konovalov
To: bug-follo...@freebsd.org
Cc:
Subject: bin/121359
Date: Fri, 29 Jul 2011 12:53:19 +0400 (MSD)
Try the following patch (ported from OpenBSD):
Index: systems.c
===
--- systems.c (revision 224489)
+++ systems.c (working copy)
@@ -64,9 +64,12 @@
fclose(fp);
}
-/* Move string from ``from'' to ``to'', interpreting ``~'' and $ */
+/*
+ * Move string from ``from'' to ``to'', interpreting ``~'' and $
+ * Returns NULL if string expansion failed due to lack of buffer space.
+ */
const char *
-InterpretArg(const char *from, char *to)
+InterpretArg(const char *from, char *to, size_t tosiz)
{
char *ptr, *startto, *endto;
struct passwd *pwd;
@@ -76,12 +79,14 @@
instring = 0;
startto = to;
- endto = to + LINE_LEN - 1;
+ endto = to + tosiz - 1;
while(issep(*from))
from++;
while (*from != '\0') {
+if (to >= endto)
+ return NULL;
switch (*from) {
case '"':
instring = !instring;
@@ -97,6 +102,8 @@
*to++ = '\\'; /* Pass the escapes on, maybe skipping \# */
break;
}
+if (to >= endto)
+ return NULL;
*to++ = *from++;
break;
case '$':
@@ -108,7 +115,7 @@
if (ptr) {
len = ptr - from - 2;
if (endto - to < (int)len )
- len = endto - to;
+ return NULL;
if (len) {
strncpy(to, from+2, len);
to[len] = '\0';
@@ -127,9 +134,13 @@
*ptr++ = *from;
*ptr = '\0';
}
+if (to >= endto)
+ return NULL;
if (*to == '\0')
*to++ = '$';
else if ((env = getenv(to)) != NULL) {
+ if (endto - to < (int)strlen(env))
+return NULL;
strncpy(to, env, endto - to);
*endto = '\0';
to += strlen(to);
@@ -142,19 +153,24 @@
if (len == 0)
pwd = getpwuid(ID0realuid());
else {
+ if (endto - to < (int)len)
+return NULL;
strncpy(to, from, len);
to[len] = '\0';
pwd = getpwnam(to);
}
+if (to >= endto)
+ return NULL;
if (pwd == NULL)
*to++ = '~';
else {
+ if (endto - to < (int)strlen(pwd->pw_dir))
+return NULL;
strncpy(to, pwd->pw_dir, endto - to);
*endto = '\0';
to += strlen(to);
from += len;
}
-endpwent();
break;
default:
@@ -179,12 +195,16 @@
#define CTRL_INCLUDE (1)
static int
-DecodeCtrlCommand(char *line, char *arg)
+DecodeCtrlCommand(char *line, char *arg, size_t argsiz)
{
const char *end;
if (!strncasecmp(line, "include", 7) && issep(line[7])) {
-end = InterpretArg(line+8, arg);
+end = InterpretArg(line+8, arg, argsiz);
+if (end == NULL) {
+ log_Printf(LogWARN, "Failed to expand command '%s': too long for the
destination buffer\n", line);
+ return CTRL_UNKNOWN;
+}
if (*end && *end != '#')
log_Printf(LogWARN, "usage: !include filename\n");
else
@@ -218,7 +238,6 @@
userok = 1;
break;
}
- endpwent();
return 0;
}
@@ -353,7 +372,7 @@
break;
case '!':
- switch (DecodeCtrlCommand(cp+1, arg)) {
+ switch (DecodeCtrlCommand(cp+1, arg, LINE_LEN)) {
case CTRL_INCLUDE:
log_Printf(LogCOMMAND, "%s: Including \"%s\"\n", filename, arg);
n = ReadSystem(bundle, name, arg, prompt, cx, how);
Index: systems.h
===
--- systems.h (revision 224489)
+++ systems.h (working copy)
@@ -40,4 +40,4 @@
extern void CloseSecret(FILE *);
extern int AllowUsers(struct cmdargs const *);
extern int AllowModes(struct cmdargs const *);
-extern const char *InterpretArg(const char *, char *);
+extern const char *InterpretArg(const char *, char *, size_t);
Index: command.c
===
--- command.c (revision 224489)
+++ command.c (working copy)
@@ -1139,7 +1134,11 @@
{
char buff2[LINE_LEN-offset];
- InterpretArg(buff, buff2);
+ if (InterpretArg(buff, buff2, sizeof buff2) == NULL) {
+log_Printf(LogWARN, "Failed to expand command '%s': too long for the
destination buffer\n", buff);
Re: kern/108211: [netinet] potentially a bug for inet_aton in sys/netinet/libalias/alias_proxy.c
Synopsis: [netinet] potentially a bug for inet_aton in sys/netinet/libalias/alias_proxy.c State-Changed-From-To: open->patched State-Changed-By: maxim State-Changed-When: Mon Apr 30 20:22:26 UTC 2007 State-Changed-Why: Fixed in HEAD. Thanks! Responsible-Changed-From-To: freebsd-net->maxim Responsible-Changed-By: maxim Responsible-Changed-When: Mon Apr 30 20:22:26 UTC 2007 Responsible-Changed-Why: MFC reminder. http://www.freebsd.org/cgi/query-pr.cgi?pr=108211 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/113457: [ipv6] deadlock occurs if a tunnel goes down while there are tcp6 connections opened
Synopsis: [ipv6] deadlock occurs if a tunnel goes down while there are tcp6 connections opened State-Changed-From-To: open->closed State-Changed-By: maxim State-Changed-When: Sun Jun 10 10:04:13 UTC 2007 State-Changed-Why: The submitter reports he can't reproduce the problem any more. http://www.freebsd.org/cgi/query-pr.cgi?pr=113457 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp connections hanging
On Sun, 17 Jun 2007, 11:38-0600, M. Warner Losh wrote: > OK. I'm getting very frustrated with my TCP connections hanging. It > happens when I log into remote sites, when I try to encode dvds, etc. > It is driving me nuts. This is with current from today. Current from > 5 or 6 weeks ago doesn't seem to be bothered by this issue. > > Has anybody else seen it? Is there a fix being tested? I can trigger > it trivially here... > Try to turn net.inet.tcp.rfc1323 off. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Issue with huge numbers of connections
On Sun, 17 Jun 2007, 13:02-0600, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Joe Holden <[EMAIL PROTECTED]> writes: > : M. Warner Losh wrote: > : > Greetings, > : > > : > I have a friend who is having problems with a service he's running. > : > He gets billions and billions of connections to this service a day. > : > Somewhere between 10^8 and 10^9 connections, he notices that his > : > servers lose the ability to accept new connections. These are TCP > : > connections. > : > > : > This is with FreeBSD 6.1R. My first question is: does anybody know if > : > the fixes to -current/7.0 have fixed this? Is there a fix that can be > : > back ported? He's currently working around the problem by having a > : > number of different machines that reboot in a round robin fashion, but > : > would like a better solution. > : > > : > Warner > : > ___ > : Warner, if he hasn't done so already, have you suggested tweaking the > : sysctl variables, such as: > : kern.maxfilesperproc > : kern.ipc.nmbclusters > : kern.maxprocperuid > : kern.maxfiles > : kern.ipc.somaxconn > : kern.maxvnodes > : > : Tweaking those may help, or he may just be exhausting available > : resources, IIRC its limited to 65k connections per interface, someone > : correct me if I am wrong. > > Here's the bug report I got: > > There is still a vague problem with the FreeBSD network interface -- > especially the part that handles TCP. Something strange happens after > about a week or so (after handling about 10^8 or 10^9 > connections). The system becomes unreachable for TCP connections. I > have fixed this problem by having all of the FreeBSD systems reboot > automatically once a week using a cron job. I have not been able to > isolate this issue, but I suspect that there is some kind of problem > with the error handling and some resource gets depleted slowly. I > realize that this is pretty vague, but I have not been able to find > out what actually happens in this case. > > I believe that each connection lasts on the order of tens or > hundreds milliseconds, given what I know about the systems in place. > My earlier rephrase omitted a few key points. I suggested that he > try to use a newer version of FreeBSD, but since these are a > production system, he's hesitant to mess with them... > > Doing the math on 10^9 connections in a week translates to ~1650/s, > so we'd expect there are on the order of 100-200 connections steady > state at any time. I suspect that the peak load may be up to 100 > times that, which is still only 2 connections. The hangs don't > seem to hang at a peak, but randomly. > > Given all that, I'm not sure which of the above to try. > There are several obvious sysctls can affect: net.inet.ip.portrange.randomized, net.inet.ip.portrange.*. We definitly need more debug info: vmstat -zm, netstat -anp tcp, netstat -m, sysctl net.inet from his system. It would be nice if he gives a shell to the problem box. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: checking SO_ACCEPTFILTER with netstat(1)/sockstat(1)
On Fri, 20 Jul 2007, 11:37-0400, Brian A. Seklecki wrote: > > Neither appear to support extracting the setsockopt(2) list. lsof(8) to the > rescue: > > $ sudo lsof -T f | grep -i ACCEPTF | more > > httpd 38396 root 3u IPv6 0xc2824378 0t0 TCP *:http > (SO=ACCEPTCONN,ACCEPTFILTER,KEEPALIVE,PQLEN=0,QLEN=0,QLIM= > > 128,RCVBUF=262144,REUSEADDR,SNDBUF=262144 > TF=MSS=1024,NODELAY,REQ_SCALE,REQ_TSTMP) > > A little bit more definitive than "Oh hey apache stopped complaining." > > > Any other way? > I think lsof(8) just parses net.inet.tcp.pcblist OID. You could look at struct xtcpcb definition and extract xtcpcb.xt_socket.so_options from the above sysctl. HTH. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: syncookie in 6.x and 7.x
On Thu, 16 Aug 2007, 18:24+0400, Igor Sysoev wrote: > During testing 7.0-CURRENT I have found that it always sends syncookies > while on early FreeBSD versions "netstat -s -p tcp" always shows: > > 0 cookies sent > 0 cookies received > > I have looked sources and found that in early versions the sent counter > was simply not incremented at all. The patch attached. > [...] The patch has beed committed to RELENG_6. Thanks! -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: syncookie in 6.x and 7.x
On Thu, 16 Aug 2007, 18:24+0400, Igor Sysoev wrote: > During testing 7.0-CURRENT I have found that it always sends syncookies > while on early FreeBSD versions "netstat -s -p tcp" always shows: > > 0 cookies sent > 0 cookies received > > I have looked sources and found that in early versions the sent counter > was simply not incremented at all. The patch attached. > > After the patch has been applied I have found that 6 always sends > syncookies too, however, 6 unlike 7 never receives them. Why ? > Mine does: $ netstat -sp tcp | grep cook 51588 cookies sent 25 cookies received $ uname -r 6.2-STABLE -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: connect() returns EADDRINUSE during massive host->host conn rate
On Fri, 30 Nov 2007, 19:26+0900, Adrian Chadd wrote: > On 30/11/2007, Jan Srzednicki <[EMAIL PROTECTED]> wrote: > > > Most of the relevant sockets (that is, between the two host > > mentioned) are in the ESTABLISHED state (200-400 of those). Only > > 20-40 are in TIME_WAIT state (these tend to be from a more > > ephemeric POP3 service). Most of the EADDRINUSE happen for the > > IMAP4 service. > > I'd probably start by patching the places in the tcp code > (src/sys/netinet/tcp_usrreq.c) which returns this error > (Its returned in other places but that seems to me to be the most > likely from your description.) > > Insert some code to print out information about the current socket and > the "oinp" value returned from in_pcbconnect_setup() (if this is the > place where the error occured.) > > Finding out more about the socket thats been created and what its > clashing with might help. I'd do it myself but I'm not sure how to > duplicate the issue. > Have you tried to turn net.inet.ip.portrange.randomized off? -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/netinet tcp_syncache.c
[...] > > I'm not generally opposed to security improvements that only affect edge > > cases... but being unable to connect is not an edge case! > > Fully agreed. I'll reopen the PR and follow up with the originator > to do some further analysis. All operating system he cites that were > unable to connect correctly send timestamps and do not stop after > the SYN phase. So there must be something else at play here. Have > you received or heart of any *other* reports that may be related to > the timestamp check? > I saw this with my adsl router. Happy to test patches. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/netinet tcp_syncache.c
On Thu, 24 Jan 2008, 13:52+0100, Andre Oppermann wrote: > Maxim Konovalov wrote: > > [...] > > > > I'm not generally opposed to security improvements that only affect edge > > > > cases... but being unable to connect is not an edge case! > > > Fully agreed. I'll reopen the PR and follow up with the originator > > > to do some further analysis. All operating system he cites that were > > > unable to connect correctly send timestamps and do not stop after > > > the SYN phase. So there must be something else at play here. Have > > > you received or heart of any *other* reports that may be related to > > > the timestamp check? > > > > > I saw this with my adsl router. Happy to test patches. > > Please provide a tcpdump of a connection that failed before. It'll > show the problem even though it doesn't cause an abort. Was the > problem you saw with communication through the adsl router, or when > you connected to the adsl router itself (configuration menu, etc)? > The latter. Turning rfc1323 off solved the problem. It takes some time to obtain the dump -- I need to downgrade the system. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/netinet tcp_syncache.c
> > The latter. Turning rfc1323 off solved the problem. > > > > It takes some time to obtain the dump -- I need to downgrade the > > system. > > That is not necessary. A tcpdump from current is fine. > OK, later this evening (UTC+3). -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/netinet tcp_syncache.c
On Thu, 24 Jan 2008, 17:20+0300, Maxim Konovalov wrote: > > > The latter. Turning rfc1323 off solved the problem. > > > > > > It takes some time to obtain the dump -- I need to downgrade the > > > system. > > > > That is not necessary. A tcpdump from current is fine. > > > OK, later this evening (UTC+3). > http://maxim.int.ru/stuff/adsl.dmp.gz 192.168.1.1 -- adsl box 192.168.1.250 -- FreeBSD -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/netinet tcp_syncache.c
> > http://maxim.int.ru/stuff/adsl.dmp.gz > > > > 192.168.1.1 -- adsl box > > 192.168.1.250 -- FreeBSD > > The trace looks perfectly fine with regard to timestamps. They are > sent and properly reflected by the adsl box. Everything else looks > fine too. No anomalies seen. > > The syncache check for timestamps wouldn't be triggered anyway > because it only applies to incoming connections. Not segments in > general. Connections initiated by the FreeBSD box never go through > syncache. > > To track down the problem you saw back then, which is very probably > unrelated to the syncache issue, I would need a trace of a failed > connection. For that you need to downgrade. If you can find time > for the downgrade I'm happy to find the root cause. > I find a kernel from September sitting in /boot. There are two new dumps now: http://maxim.int.ru/stuff/adsl.failed.dmp.gz The adsl router displays login page but never returns the second page. http://maxim.int.ru/stuff/adsl.rfc1323=0.dmp.gz This one works. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/netinet tcp_syncache.c
[...] > Who's fault is it? Clearly the adsl modem. It's tcp is utterly > broken. Should FreeBSD work around it? In this case I don't think > so. Normally yes if it is an edge case in a specification or some > generally made mistake. This is not the case with the adsl modem. > It's really broken and in complete disregard of even the basic > standards. The vendor should fix it, not us work around it. > It used to work for years and works now. I see no point to make FreeBSD to not work with countless devices around the world. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New preview patch for ipfw to pfil_hooks conversion
Hi Andre, On Mon, 21 Jun 2004, 23:36+0200, Andre Oppermann wrote: > Here is the next preview patch for the ipfw to pfil_hooks conversion: > > http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff > > This patch significantly cleans up ip_input.c and ip_output.c. > > The following is included in this patch: > > o Remove all ipfw related cruft from ip_input() and ip_output() > o New ip_fw_pfil.c file which contains all ipfw/pfil_hooks logic > > o ipfw firewalling, divert and dummynet works fine > > o ipfw forward is not yet implemented again (comes next) > o ipfw layer2 is not yet implemented again (comes next) > > o ip_reass() is a self-contained function now (external code only relocated) > > o All IP Options related functions of ip_input/ip_output are moved into > their > own ip_options.[ch] file to have them together in one place > > o Some other small work in progress Is it possible to split that ~100KB patch in a logic chunks? One for phil_hook, one for ip_pcbopt, one for ip_reass etc. Much easier to review and commit them later. > Consider this a FYI. It is very much a WIP at the moment. I want > to get this into the tree in before 5.3 code freeze. In fact, our real world tests shown the current -CURRENT comparing to RELENG_5_2 is in a very bad shape. Is it really worth to commit that mostly cleanup code before say 6-CURRENT with a chance to destabilizate -CURRENT a bit more? -- Maxim Konovalov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New preview patch for ipfw to pfil_hooks conversion
On Tue, 22 Jun 2004, 11:23+0200, Dag-Erling Sm?rgrav wrote: > Maxim Konovalov <[EMAIL PROTECTED]> writes: > > In fact, our real world tests shown the current -CURRENT comparing to > > RELENG_5_2 is in a very bad shape. > > You'll have to substantiate that. All *my* real world tests show that > -CURRENT is a lot more stable and functional than RELENG_5_2. Yesterday -CURRENT leaks kernel memory very quickly and panics after 10 - 15 mins up. Machine is 2x3GHz Xeon, 4GB RAM, ~5000 httpd/ftpd tcp sessions, 300-400Mbps output, ~50TB output in a day. The same config (kernel, sysctl's, loader tunables, hardware) works well with RELENG_5_2. -- Maxim Konovalov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New preview patch for ipfw to pfil_hooks conversion
On Tue, 22 Jun 2004, 02:06-0700, Luigi Rizzo wrote: > On Tue, Jun 22, 2004 at 12:15:21PM +0400, Maxim Konovalov wrote: > ... > > > Consider this a FYI. It is very much a WIP at the moment. I want > > > to get this into the tree in before 5.3 code freeze. > > > > In fact, our real world tests shown the current -CURRENT comparing to > > RELENG_5_2 is in a very bad shape. Is it really worth to commit that > > mostly cleanup code before say 6-CURRENT with a chance to > > of course it is! i also do not follow the reasoning -- given that it is > cleaning up code, it is only welcome at any stage except perhaps > in code freeze. My concern is bugs. Especially in cleanup code, especially in ip_pcbopt and ip_reass. > plus, is the 'bad shape' related at all to what andre posted ? 'bad shape' is related to 5-CURRENT we are trying to make -STABLE. -- Maxim Konovalov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New preview patch for ipfw to pfil_hooks conversion
On Tue, 22 Jun 2004, 11:49+0200, Dag-Erling Sm?rgrav wrote: > Maxim Konovalov <[EMAIL PROTECTED]> writes: > > Yesterday -CURRENT leaks kernel memory very quickly and panics after > > 10 - 15 mins up. > > Nope. That bug was introduced on June 9th, almost two weeks ago, and Nope :-) $ ident /usr/src-5-current/sys/kern/uipc_syscalls.c /usr/src-5-current/sys/kern/uipc_syscalls.c: $FreeBSD: src/sys/kern/uipc_syscalls.c,v 1.194 2004/06/19 03:23:14 rwatson Exp $ We have a fixed version. -- Maxim Konovalov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New preview patch for ipfw to pfil_hooks conversion
On Tue, 22 Jun 2004, 13:38+0200, Andre Oppermann wrote: > Maxim Konovalov wrote: > > > > Hi Andre, > > > > On Mon, 21 Jun 2004, 23:36+0200, Andre Oppermann wrote: > > > > > Here is the next preview patch for the ipfw to pfil_hooks conversion: > > > > > > http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff > > > > > > This patch significantly cleans up ip_input.c and ip_output.c. > > > > Is it possible to split that ~100KB patch in a logic chunks? One for > > phil_hook, one for ip_pcbopt, one for ip_reass etc. Much easier to > > review and commit them later. > > Of course it will be split up. I haven't done this because this is > only a preview patch of work in progress. Please HEADSUP us before commit or drop me a note, I am willing to review reass/ip options code as I spent a lot of hours parsing it. As a side note, what is "#define MAX_IPOPTLEN40" in ip_options.h for? There is one in ip_var.h. -- Maxim Konovalov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: TCP SACK backport to -STABLE
On Wed, 25 Aug 2004, 06:06+0200, Oldach, Helge wrote: > So please go ahead, give Marko that bit and let him commit this decent work! Please don't touch RELENG_4. > Helge > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Julian Elischer > > Sent: Wednesday, August 25, 2004 12:15 AM > > To: Marko Zec > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: Re: TCP SACK backport to -STABLE > > > > > > You do know don't you, that if you continue to do these > > things, you will > > be punnished by > > getting a CVS commit bit..? > > > > > > Marko Zec wrote: > > > > >I've prepared a more or less blind backport of the TCP SACK > > code which was > > >recently introduced in -CURRENT. Didn't put the patch > > through lots of > > >testing, but it just seems to work... The patch is > > available from the URL > > >bellow and should apply cleanly against both 4.10-RELEASE > > and -STABLE. > > > > > >http://tel.fer.hr/zec/BSD/4.10-sack.diff > > > > > >Cheers, > > > > > >Marko > > >___ > > >[EMAIL PROTECTED] mailing list > > >http://lists.freebsd.org/mailman/listinfo/freebsd-net > > >To unsubscribe, send any mail to > > "[EMAIL PROTECTED]" > > > > > > > > > > ___ > > [EMAIL PROTECTED] mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to > > "[EMAIL PROTECTED]" > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Maxim Konovalov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/73129: [patch] IPFW misbehaviour in RELENG_5
On Sat, 4 Dec 2004, 21:37+0100, Andre Oppermann wrote: [...] > > Investigating pre-PFIL_HOOKS ipfw I have not found any analog of > > this check. These checks do break some useful functionality: > > > > 1) policy routing of hosts from connected networks > > 2) policy routing of locally originated traffic > > > > The second one is used very widely. When you have lines to two > > ISPs and run natd for both of them, you policy route nated packets > > to them. > > I know. On the other hand having these checks avoids breaking responses > from the host doing the policy routing towards hosts on connected networks. > > In my case I had a problem where the MTU of the policy-routing target > interface was lower than 1500 but the ICMP fragmentation needed packets > never made it back to the real host; they were forwarded to the policy > destination. > > This is how I came to this check. It is more correct but indeed breaks > forwarding packets that were targeted at an IP address configured on a > local interface. This is an unintended side effect but I haven't found > a nice solution to work around that. I'm not entirely sure what the > best way is to handle this and it's also the reason why I haven't changed > it so far. > > If you have suggestions I'm all ears. But think through all cases at least > twice, there are some nice traps. Fixing one end without breaking another > one is hard. IMHO restoring the historic behaviour (even broken in some respects) is the best thing we can do at the moment. > > P.S. kern/73129, kern/73910, kern/71910 -- Maxim Konovalov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0 link_state
On Thu, 16 Dec 2004, 19:25-0500, Josh Kayse wrote: > I was working on some test machines and using ifstated which uses the > KQUEUE event to register changes in link state. I noticed that > ifstated did register any events having to do with the em interfaces. > Looking through the code, it doesn't appear to support the KQUEUE > events. Am I correct in saying that? Correct. From kqueue.2: : The EVFILT_NETDEV filter is currently only implemented for devices : that use the miibus(4) driver for LINKUP and LINKDOWN operations. : Therefore, it will not work with many non-ethernet devices. -- Maxim Konovalov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Alternate port randomization approaches
Hi Mike, On Sat, 18 Dec 2004, 04:03-0600, Mike Silbersack wrote: [...] > Although this isn't a perfect fix, I think that it should be > acceptable for the vast majority of systems, and I'd like to get it > in before 4.11-release ships. To be conservative, I'll probably > choose a value like 5, which should be fine for most systems out > there. Super specialized users will always be able to lower it to > 0. Can we leave it zero by default? I affraid this patch won't get much testing before 4.11-REL. The super specialized users will always be able to set net.inet.ip.portrange.randomized whatever they want to. The next thing I am worry about - some users already have net.inet.ip.portrange.randomized=1 in their /etc/sysctl.conf and now we are going to change a meaning of this sysctl. Can we garantee there are no any side effects with this setting? I failed to find the documentation part of your patch also :-) -- Maxim Konovalov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dingo and PerForce
On Mon, 20 Dec 2004, 16:01+1030, Wilkinson, Alex wrote: > 0n Sun, Dec 19, 2004 at 02:50:09PM +0100, Andre Oppermann wrote: > > >> now a dingo branch, named "dingo". The dingo branch contains > >> all of src, not just sys, as I suspect there are userland bits > >> we'll want to do. I know I'll be doing userland things. > >> Please make your own sub-branch off of dingo. For example, > >> here is mine (gnn_dingo): > > What is dingo ? http://www.freebsd.org/projects/dingo/ The first link on google. -- Maxim Konovalov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Update: Alternate port randomization approaches
On Wed, 29 Dec 2004, 03:02-0600, Mike Silbersack wrote: > On Sat, 18 Dec 2004, Mike Silbersack wrote: > > > There have been a few reports by users of front end web proxies and other > > systems under FreeBSD that port randomization causes them problems under > > load. This seems to be due to a combination of port randomization and > > rapid connections to the same host causing ports to be recycled before > > the ISN has advanced past the end of the previous connection, thereby > > causing the TIME_WAIT socket on the receiving end to ignore the new SYN. > > Based on testing done by Igor Sysoev, I've found that my original patch is > insufficient; even as little as one randomizaion per second can cause problems > for some users. As a result, I've created the attached patch (versions for > both 6.x and 4.x are included). It implements a relatively simple algorithm: > Port randomization is turned disable once the connection rate goes above 20 > connections per second, and it is not reenabled until the connection rate > falls below 20 cps for 5 seconds straight. > > This appears to work for Igor, and it seems safe enough to commit before > 4.11-RC2. But, if possible, I'd like a few more sets of eyes to doublecheck > the concept and code; please take a look at it if you have a chance. Again, it's not clear for me why we don't follow our usual deveplopment cycle here: commit & test in HEAD and then MFC to STABLE? -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/73129: [patch] IPFW misbehaviour in RELENG_5
On Sat, 11 Dec 2004, 11:58+0100, Andre Oppermann wrote: > Edwin Groothuis wrote: > > > > On Sun, Dec 05, 2004 at 01:14:49AM +0300, Gleb Smirnoff wrote: > > > On Sun, Dec 05, 2004 at 12:53:52AM +0300, Maxim Konovalov wrote: > > > M> IMHO restoring the historic behaviour (even broken in some respects) > > > M> is the best thing we can do at the moment. > > > > > > + my vote. > > > > Mine too. > > I'll change it shortly. Knock-knock, b/b home? :-) -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ttl-exceeded sourced by arrival interface ?
On Sun, 16 Jan 2005, 02:47+0100, Julien Lesaint wrote: > Hi, > > This is a followup to the original post from James Jun, on Dec, 2003. > http://lists.freebsd.org/mailman/htdig/freebsd-net/2003-December/002114.html > > Quick reminder: in the case the route to the packet's source is not the > interface this packet arrived on, do we have a way to source ICMP errors > (ttl-exceeded) with the original interface's IP address ? > > Currently the box is sending ttl-exceeded with the IP address of the > interface the route to the sender is pointing at. No need to explain why > such a feature would be useful - primarily for traceroute comprehension > & routing troubleshooting, rather than for some cosmetic purposes. Does net.inet.icmp.reply_src sysctl help? -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vlans changed?
On Thu, 20 Jan 2005, 10:33-, Robert Watson wrote: > > On Wed, 19 Jan 2005, Charlie Schluting wrote: > > > Now, in 5.3, the only thing I can get working is to configure the em0 > > int with the IP, and set the trunk to have the native vlan corresponding > > to that IP. Weird. > > > > Also, is there a way to stop em(4) from stripping dot1q tags in > > hardware? I'd like to see them with tcpdump. What kind of a performance > > hit does this involve? > > Try "ifconfig em0 -vlanhwtag" and see if that helps. If not, take a look Yep, it works for Alex (CC'ed), thanks for the tip. > in if_em.c:em_setup_interface(), and you'll see two lines like this: > > #if __FreeBSD_version >= 50 > ifp->if_capabilities |= IFCAP_VLAN_HWTAGGING | IFCAP_VLAN_MTU; > ifp->if_capenable |= IFCAP_VLAN_HWTAGGING | IFCAP_VLAN_MTU; > #endif > > Delete the contents "|FCAP_VLAN_HWTAGGING |" from each line, and that > should disable support for hardware vlan tagging and stripping in the > driver. There are several bugs relating to the handling of hardware vlan > tagging and promiscuous mode in both if_re and if_em. I had hoped to have > a chance to resolve them over the past couple of months but have not as > yet been able to do so. I measured a small performance hit last time I > tried disabling the hardware tagging, perhaps a couple of percent, but > mileage may vary -- for in-bound packets, there's a small amount > additional work, but for outgoing packets you may see an extra memory > allocation for each encapsulated packet (it depends a bit on what you > send). If this appears to work properly for you, we should probably > commit the change so that what's in the tree works properly, even if it's > slightly slower. IMO this is a good idea. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/73129: [patch] IPFW misbehaviour in RELENG_5
Andre, Is your silence is an approval to commit a diff in kern/73129? On Wed, 12 Jan 2005, 13:26+0300, Maxim Konovalov wrote: > On Sat, 11 Dec 2004, 11:58+0100, Andre Oppermann wrote: > > > Edwin Groothuis wrote: > > > > > > On Sun, Dec 05, 2004 at 01:14:49AM +0300, Gleb Smirnoff wrote: > > > > On Sun, Dec 05, 2004 at 12:53:52AM +0300, Maxim Konovalov wrote: > > > > M> IMHO restoring the historic behaviour (even broken in some respects) > > > > M> is the best thing we can do at the moment. > > > > > > > > + my vote. > > > > > > Mine too. > > > > I'll change it shortly. > > Knock-knock, b/b home? :-) > > -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kern/73129 and 5.3-STABLE
On Tue, 22 Feb 2005, 10:59-0500, David G. Andersen wrote: > On Wed, Feb 09, 2005 at 06:33:11PM +0100, Andre Oppermann scribed: > > "David G. Andersen" wrote: > > > > > > The last messages I saw in the archives about kern/73129 indicated > > > that it was going to be fixed "shortly" > > > > > > (73129 is the "IPFW misbehavior in RELENG_5 thread" -- it's no longer > > > possible to use ipfw fwd to perform policy routing). > > > > > > > Sorry, it'll be fixed in 5.4-RELEASE. I have made up my mind how to > > fix it the most correct way. > > Just a ping on this one - I've received several emails from > people off the list asking if I'd found a fix for the problem. > It seems like it would be grand if you could commit your fix > to 5-STABLE instead of waiting for 5.4-RELEASE. Andre fixed this in HEAD: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1086361+0+current/cvs-all -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP window scale option setting?
On Fri, 4 Mar 2005, 08:47-0500, lbland wrote: > hi- > > In section 2.5 of the Stevens book it says "we wil see how to effect this > [window scale] option with SO_RCVBUF socket option (Section 7.5)". > > But, when I get to Section 7.5 it doesn't say anything about it that I can > find. I searched the whole book, and then googled and then grep'd the header > files to hack it. I see some related macros, but nothing definitive. I can't > find enough to figure it out. It seems I can use setsockopt() to implicitly > maybe or maybe not define it, but then I have no way of checking to make sure > it stuck during the initial negotiation. > > How do I get the current TCP window scale setting? > > How do I set the TCP window scale setting? man 4 tcp, sysctl net.inet.tcp.rfc1323 -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upgrading to 4.10-STABLE
On Wed, 16 Mar 2005, 17:16+0300, dima wrote: > > Hi all, > > > > I am trying to upgrade from 4.10-RELEASE to 4.10-STABLE and I have gone > > through the following steps; > > > > 1. make buildworld > > 2. make buildkernel KERNCONF=MYKERN > > 3. make installkernel KERNCONF=MYKERN > > 4. booted into single user mode and did, mount -u /, mount -a > > 4a. mergemaster -p ;) 0a. cvsup. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: transparent bridge and ARP proxy confusion
[...] > On host 192.168.0.2, the tcpdump output: > > 00:10:53.445868 0:2:b3:da:50:ba Broadcast arp 60: > arp who-has 192.168.0.2 tell 192.168.0.6 > 00:10:53.445888 0:e:c:68:e3:94 0:2:b3:da:50:ba arp 42: > arp reply 192.168.0.2 is-at 0:e:c:68:e3:94 > 00:10:53.446615 0:2:b3:da:50:bb 0:e:c:68:e3:94 ip 98: > 192.168.0.6 > 192.168.0.2: icmp: echo request > 00:10:53.446634 0:e:c:68:e3:94 0:2:b3:da:50:ba ip 98: > 192.168.0.2 > 192.168.0.6: icmp: echo reply > 00:10:58.442471 0:e:c:68:e3:94 0:2:b3:da:50:ba arp 42: > arp who-has 192.168.0.6 tell 192.168.0.2 > 00:10:58.442925 0:2:b3:da:50:bb 0:e:c:68:e3:94 arp 60: > arp reply 192.168.0.6 is-at 0:2:b3:da:50:bb What's the behaviour is observed with TCP or UDP? Is it the same? -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Difficulties with tcpdrop on FreeBsd 5.3
On Tue, 22 Mar 2005, 14:08+0200, Sergey wrote: > Hello all, i have a question: > > OS: FreeBSD 5.3 > > How to install tcpdrop from /usr/src/usr.sbin/tcpdrop/ > > when i do make, i receive error: > > tcpdrop.c:43: error: `TCPCTL_DROP' undeclared (first use in this function) > tcpdrop.c:43: error: (Each undeclared identifier is reported only once > tcpdrop.c:43: error: for each function it appears in.) > *** Error code 1 > > How to enable TCPCTL_DROP syscall !? The upgrade procedure is described quite well in the handbook and at the end of /usr/src/UPDATING. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lots VLANs caouses ngctl to fail
On Wed, 13 Apr 2005, 11:36+0400, Nikolay Arhangelskiy wrote: > Hello freebsd-net, > > I need to operate with hundreds VLANs on FreeBSD box (5.3). > Using small script I create 250 VLANs, exec "ngctl list" - no > problem, ngctl lists all 250 VLANs. > After creating another 250 VLANs ngctl start to fail with message: > > ngctl: send msg: No buffer space available > > Is there are any limitations in ngctl on objects count? > Or any kernel side limitations? Increase net.graph.recvspace and net.graph.maxdgram. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: netstat errors after upgrading 4.9 -> 5.3
On Sun, 1 May 2005, 01:08-0700, Tomasz Konefal wrote: > Eric W. Bates wrote: > > [sigh] I have created the same problem on 2 machines. > > > > After an upgrade from 4.x to 5.3-p10 netstat will no longer display the > > routing table: > > > > ** [EMAIL PROTECTED] ** ~ ** Fri Apr 29 16:59:37 > > # netstat -nr > > netstat: kvm not available > > Routing tables > > rt_tables: symbol not in namelist > > > > During the upgrade, I deleted all of /usr/src/*. And followed the rest of > > the procedures outlined in /usr/src/UPGRADING. I have also deleted /kernel* > > and /modules* (random thot that perhaps the wrong kvm's were being loaded). > > > > As far as I can tell, the netstat dump of the routing tables is the only > > failure. > > i have these exact same symptoms on a box i recently upgraded from 5.2.1 to > 5.4-RC3. admittedly, i don't know whether netstat worked on 5.2.1, but that > was a fresh install with only the security updates applied. IIRC you need mem_load="YES" io_load="YES" in /boot/loader.conf or the appropriate devices compiled in your kernel. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and the Rose Attack / NewDawn
[...] > So, test out my attached patch with varying settings of > maxfragspersecond and see if it makes any difference for you. [...] diff -u -r /usr/src/sys.old/netinet/ip_var.h /usr/src/sys/netinet/ip_var.h --- /usr/src/sys.old/netinet/ip_var.h Sun Apr 17 18:05:06 2005 +++ /usr/src/sys/netinet/ip_var.h Thu May 12 21:16:47 2005 @@ -61,6 +61,8 @@ struct mbuf *ipq_frags; /* to ip headers of fragments */ struct in_addr ipq_src,ipq_dst; u_char ipq_nfrags; /* # frags in this packet */ + u_short ipq_len;/* length of final packet */ + u_short ipq_curlen; /* how much we've gotten so far */ struct label *ipq_label;/* MAC label */ }; #endif /* _KERNEL */ %%% Am I right the above delta is a letfover from Suleiman's work and it's not needed at all? -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: **net** Re: Outbound TCP issue, potentially related to'FreeBSD-SA-05:08.kmem [REVISED]'
[...] > net.inet.ip.portrange.randomized: 1 > net.inet.ip.portrange.randomcps: 10 > net.inet.ip.portrange.randomtime: 45 > > Although I'm not familiar with what this /should/ be, my guts says 10 > seems sort of low. > > Also, was this only implemented in 4.11? (Since we started seeing this > while running 4.9 still.) > > http://www.freebsd.org/releases/4.11R/relnotes-i386.html > > We'll give this a shot though to see if it helps either way. These sysctls are in 4.11 only and 4.9 has a broken random port allocation algorithm. Please turn it off as Mike suggests and report results back. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and the Rose Attack / NewDawn
> I attempted to apply the patch, but I think the date on my in_pcb.c is > incorrect. What do I do to correct?: > # ls -al /usr/src/sys/netinet/in_pcb.c > -rw-r--r-- 1 root wheel 32712 Mar 28 06:29 /usr/src/sys/netinet/in_pcb.c > GandalfBSD# patch < ip_maxfragspersecond.patch > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -- > |diff -u -r /usr/src/sys.old/netinet/in_pcb.c /usr/src/sys/netinet/in_pcb.c > |--- /usr/src/sys.old/netinet/in_pcb.c Sun Apr 17 18:05:05 2005 > |+++ /usr/src/sys/netinet/in_pcb.c Thu May 12 21:47:39 2005 > -- > File to patch: ^C# > # Test cd /usr/src && patch -C -p0 < /path/to/ip_maxfragspersecond.patch and apply cd /usr/src && patch -C < /path/to/ip_maxfragspersecond.patch -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: **net** Re: Outbound TCP issue, potentially related to'FreeBSD-SA-05:08.kmem [REVISED]'
[...] > Hm, it's not port randomization then. I guess you have found a new > glitch, but I don't have any idea what would have caused the > problem. Maxim, any ideas? You're good at finding my bugs. :) I have 4.9 system with all recent SA patches applied and going to reproduce the problem in a couple of hours. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and the Rose Attack / NewDawn
On Fri, 13 May 2005, 20:21+0400, Maxim Konovalov wrote: > > I attempted to apply the patch, but I think the date on my in_pcb.c is > > incorrect. What do I do to correct?: > > # ls -al /usr/src/sys/netinet/in_pcb.c > > -rw-r--r-- 1 root wheel 32712 Mar 28 06:29 /usr/src/sys/netinet/in_pcb.c > > GandalfBSD# patch < ip_maxfragspersecond.patch > > Hmm... Looks like a unified diff to me... > > The text leading up to this was: > > -- > > |diff -u -r /usr/src/sys.old/netinet/in_pcb.c /usr/src/sys/netinet/in_pcb.c > > |--- /usr/src/sys.old/netinet/in_pcb.c Sun Apr 17 18:05:05 2005 > > |+++ /usr/src/sys/netinet/in_pcb.c Thu May 12 21:47:39 2005 > > -- > > File to patch: ^C# > > # > > Test > > cd /usr/src && patch -C -p0 < /path/to/ip_maxfragspersecond.patch > > and apply > > cd /usr/src && patch -C < /path/to/ip_maxfragspersecond.patch Err, and apply: cd /usr/src && patch -p0 http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: **net** Re: Outbound TCP issue, potentially related to'FreeBSD-SA-05:08.kmem [REVISED]'
On Fri, 13 May 2005, 10:36-0600, Matt Ruzicka wrote: > Thank you both very much for all the help. > > Incidentally those systems are now running 4.11 (patched today for htt). > > They are primarily web servers running apache 1.3.33 with customer as well > as company cgi's running on them, but are also running proftpd. > > Let me know if I can get you any system reading to show traffic and such > if that will help. while : do nc -z 195.128.64.6 80 || echo fail done 2>&1 | grep -v succeed running on 4.9-RELEASE-p17 for an hour shows nothing. I'll try the same test on fresh RELENG_4 but it takes time to build it, my test box is very slow. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: **net** Re: Outbound TCP issue, potentially related to'FreeBSD-SA-05:08.kmem [REVISED]'
On Fri, 13 May 2005, 12:58-0600, Matt Ruzicka wrote: > Yes, it still does. And actually the script Maxim attached to his last > email (using our IP's) has an interesting side effect of causing the > connections to fail. > > It doesn't fail right away, but within a few moments. > > -->./netcat-test 2005/05/13 12:46:51 > fail > fail > fail > fail > ... Please run netstat -an | grep -c TIME_WAIT when fails occur. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: **net** Re: Outbound TCP issue, potentially related to'FreeBSD-SA-05:08.kmem [REVISED]'
On Fri, 13 May 2005, 23:09+0400, Maxim Konovalov wrote: > On Fri, 13 May 2005, 12:58-0600, Matt Ruzicka wrote: > > > Yes, it still does. And actually the script Maxim attached to his last > > email (using our IP's) has an interesting side effect of causing the > > connections to fail. > > > > It doesn't fail right away, but within a few moments. > > > > -->./netcat-test 2005/05/13 12:46:51 > > fail > > fail > > fail > > fail > > ... > > Please run > > netstat -an | grep -c TIME_WAIT > > when fails occur. and vmstat -z | grep -i sock -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: **net** Re: Outbound TCP issue, potentially related to'FreeBSD-SA-05:08.kmem [REVISED]'
[...] > When I check the vmstat while getting errors from the netcat script I get > this. > > -->vmstat -z | grep -i sock 2005/05/13 13:33:20 > socket: 224,16424, 16438, 0, 1150867 Limit -^ Current ---^ > Here is my vmstat -z in a "normal" state. > > ITEMSIZE LIMITUSEDFREE REQUESTS [...] > socket: 224,16424, 3621, 12817, 1167053 [...] > And during the failures.. > > ITEMSIZE LIMITUSEDFREE REQUESTS [...] > socket: 224,16424, 16430, 8, 1201620 [...] > Am I pretty much just looking at a tuning issue at this point I assume? 1) Use a persistent connection if possible. 2) /etc/sysctl.conf: net.inet.tcp.msl="5000" net.inet.ip.portrange.last="5" perhaps /boot/loader.conf: kern.ipc.maxsockets="32768" -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bridge on WiFi cards strange work
What does sysctl net.inet.ip.check_interface say? Does switching it off helps? -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/81813: [ PATCH ] ICMP_UNREACH_NEEDFRAG with unspecified icmp_nextmtu are ignored
The following reply was made to PR kern/81813; it has been noted by GNATS. From: Maxim Konovalov <[EMAIL PROTECTED]> To: Dan Lukes <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: kern/81813: [ PATCH ] ICMP_UNREACH_NEEDFRAG with unspecified icmp_nextmtu are ignored Date: Mon, 6 Jun 2005 21:19:03 +0400 (MSD) Hi Dan, We have a bit different code in HEAD and it seems for me it works correctly with zero icmp_nextmtu. All we need is to ask Andre to merge his work to RELENG_5. I'd prepare a patch if you have chance to test. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tftpd blksize option for stock tftpd
On Wed, 8 Jun 2005, 10:38+0200, Jose M Rodriguez wrote: > Hi, > > I ports PR bin/67550 time ago, with minor fixes to tftpd protocol impl. > and support for blksize option. > > Can someone review this before RELENG_6? Tested here with pxelinux > clients. I'm slowly working on merging blocksize and timeout options (RFC 2347 - 2349) from NetBSD. I don't finish my work before RELENG_6 definitly. http://maxim.int.ru/stuff/netbsd.tftp.diff -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: setsockopt() can not remove the accept filter
k 9 - getsockopt() after listen() setsockopt() "
+ errx(-1, "not ok 10 - getsockopt() after listen() setsockopt() "
"failed with %d (%s)", errno, strerror(errno));
if (len != sizeof(afa))
- errx(-1, "not ok 9 - getsockopt() after setsockopet() after "
+ errx(-1, "not ok 10 - getsockopt() after setsockopet() after "
"listen() returned wrong size (got %d expected %d)", len,
sizeof(afa));
if (strcmp(afa.af_name, ACCF_NAME) != 0)
- errx(-1, "not ok 9 - getsockopt() after setsockopt() after "
+ errx(-1, "not ok 10 - getsockopt() after setsockopt() after "
"listen() mismatch (got %s expected %s)", afa.af_name,
ACCF_NAME);
- printf("ok 9 - getsockopt\n");
+ printf("ok 10 - getsockopt\n");
+
+ /*
+* Step 10: Remove accept filter. After removing the accept filter
+* getsockopt() should fail with EINVAL.
+*/
+ ret = setsockopt(lso, SOL_SOCKET, SO_ACCEPTFILTER, NULL, 0);
+ if (ret != 0)
+ errx(-1, "not ok 11 - setsockopt() after listen() "
+ "failed with %d (%s)", errno, strerror(errno));
+ bzero(&afa, sizeof(afa));
+ len = sizeof(afa);
+ ret = getsockopt(lso, SOL_SOCKET, SO_ACCEPTFILTER, &afa, &len);
+ if (ret == 0)
+ errx(-1, "not ok 11 - getsockopt() after removing "
+ "the accept filter returns valid accept filter %s",
+ afa.af_name);
+ if (errno != EINVAL)
+ errx(-1, "not ok 11 - getsockopt() after removing the accept"
+ "filter failed with %d (%s)", errno, strerror(errno));
+ printf("ok 11 - setsockopt\n");
close(lso);
return (0);
%%%
--
Maxim Konovalov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: setsockopt() can not remove the accept filter
On Sat, 11 Jun 2005, 02:36-0700, Alfred Perlstein wrote: > Looks cool. Can you commit it? Or should I? I'll commit and handle MFC. Thanks for review Alfred. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: setsockopt() can not remove the accept filter
Igor,
On Sat, 11 Jun 2005, 02:12+0400, Igor Sysoev wrote:
> Hi,
>
> man setsockopt(2) states that "passing in an optval of NULL will remove
> the filter", however, setsockopt() always return EINVAL in this case,
> because do_setopt_accept_filter() removes the filter if sopt == NULL, but
> not if sopt->val == NULL. The fix is easy:
>
> -if (sopt == NULL) {
> +if (sopt == NULL || sopt->val == NULL) {
I committed fixes for this and related bug and will MFC them in two
weeks. Thanks!
--
Maxim Konovalov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: www user than root
[...] > You could do something like this in FreeBSD 5-STABLE by hacking the > in_pcbbind_setup() function in src/sys/netinet/in_pcb.c to not just > call suser_cred(), but to instead perform a group check, by calling > groupmember(some_privileged_socket_group, cred). mac_portacl(4) -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: very busy ftpd
On Tue, 9 Aug 2005, 15:49-0400, Mikhail Teterin wrote: > Hi! > > I just noticed, that uploading a file over a LANG (at around > 5.7Mb/s) resulted in around 25% CPU consumption by the ftpd. > > I think, that's unusual for a Pentium4 -- what is the process doing? Check the client does not use ascii mode when uploading (getc() vs read()). -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: very busy ftpd
On Wed, 10 Aug 2005, 00:40-0400, Mikhail Teterin wrote:
> > > I just noticed, that uploading a file over a LANG (at around
> > > 5.7Mb/s) resulted in around 25% CPU consumption by the ftpd.
> > >
> > > I think, that's unusual for a Pentium4 -- what is the process doing?
> >
> > Check the client does not use ascii mode when uploading (getc() vs
> > read()).
>
> That's quite possible, indeed. I wouldn't put it past some users --
> some still use the ancient ftp-clients, which default to text-mode
> transfers.
>
> Is there any way to disable this mode on the server, perhaps? Even
> if it violates the protocol :-/
A dirty hack:
Index: ftpcmd.y
===
RCS file: /home/ncvs/src/libexec/ftpd/ftpcmd.y,v
retrieving revision 1.64
diff -u -r1.64 ftpcmd.y
--- ftpcmd.y18 Nov 2004 13:46:29 - 1.64
+++ ftpcmd.y10 Aug 2005 08:23:09 -
@@ -379,6 +379,9 @@
switch (cmd_type) {
case TYPE_A:
+ reply(504, "Type A not implemented.");
+ break;
+#if 0
if (cmd_form == FORM_N) {
reply(200, "Type set to A.");
type = cmd_type;
@@ -386,7 +389,7 @@
} else
reply(504, "Form must be N.");
break;
-
+#endif
case TYPE_E:
reply(504, "Type E not implemented.");
break;
%%%
--
Maxim Konovalov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixed Dest Port for traceroute(8)
[...] > Index: traceroute.c > === > RCS file: /ncvs/freebsd/src/contrib/traceroute/traceroute.c,v > retrieving revision 1.27 > diff -u -r1.27 traceroute.c > --- traceroute.c 26 Aug 2005 18:08:24 - 1.27 > +++ traceroute.c 23 Sep 2005 17:47:45 - [...] > @@ -521,13 +522,17 @@ > prog = argv[0]; > > opterr = 0; > - while ((op = getopt(argc, argv, "dFInrSvxf:g:i:M:m:P:p:q:s:t:w:z:")) != > EOF) > + while ((op = getopt(argc, argv, "edFInrSvxf:g:i:M:m:P:p:q:s:t:w:z:")) > != EOF) Better to keep the keys sorted alphabetically. I.e. "deFI..". Need to update usage() as well. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How connect 2 PC with ath in hostap mode ?
On Fri, 30 Sep 2005, 10:10+0400, Andrey Smagin wrote: > Hi ALL, > > People please say it possible under FreeBSD ? > Any body have sucess stories about it ? > What manual I must read to do it ? :) Mm, let me think... man ath, "EXAMPLES"? -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: named in a sand box.
Hello, On Fri, 15 Dec 2000, Peter Brezny wrote: > I have a nomenclature ignorance when it comes to the term sandbox. > > When someone says, "named runs in a sandbox on my machine." > > Do they mean > > a) named runs under an unpriviliged user > or > b) named runs in a chrooted environment > or > c) both > > ? *I* mean "both". http://www.psionic.com/papers/dns/dns-openbsd/ HTH > In the /etc/namedb/named.conf it says that freebsd runs bind in a sandbox > and refers to the named flags in rc.conf, and when you look at those flags > in /etc/defults/named.conf all you see is the -u and -g options for the > flags, NOT the -t option for running in a chrooted environemnt. > > This led me to believe that 'sandbox' means unpriviliged user. But when i > posed a related question on -questions, someone told me that sandbox = > chrooted environment. > > I also want to know, if you are running named under an unpriviliged user, is > it worth the extra trouble to run it chrooted? > > Thanks for your help. > > Peter Brezny > SysAdmin Services Inc. - - maxim -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Looking for tiny DNS server
Hello, On Mon, 18 Dec 2000, Wes Peters wrote: > I need a tiny DNS server I can hack up. When our router/firewall/gateway is > in "first birthday" mode, it doesn't yet have a connection to the internet. > We'd like to run a DNS server on the box that resolves ALL DNS A requests > from the internal LAN to the internal address of our box until we have the > public interface up. At this time, we'll configured named and kill the tiny > DNS server. > > If you know of such a server available under a reasonable license, or know > of some clever named hacks that will allow me to do the same, I'm all ears. > Or SMTP ports, I guess. Take a look at /usr/ports/net/pdnsd HTH - - maxim -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Sendmail outgoing bind() fails on PPP
Hello, On Thu, 26 Apr 2001, Sean Farley wrote: > I previously posted this on comp.mail.sendmail and freebsd-questions. > After no answer and some extra testing, I believe this probably belongs > here. > > > > I need some help debugging a problem I am having with setting up Sendmail. > Previously, I have been using Exim, but I have decided to try my hand with > a different MTA. :) > > Here is the error I just cannot seem to get around (with indenting): > > Apr 21 16:10:14 gw sendmail[1985]: starting daemon (8.11.2): > SMTP+queueing@00:30:00 > Apr 21 16:10:15 gw sendmail[1986]: f3LK0XL00702: SYSERR(root): > makeconnection: cannot bind socket [216.140.158.72]: > Invalid argument > Apr 21 16:10:15 gw sendmail[1986]: f3LK0XL00702: to<[EMAIL PROTECTED]>, > delay1:09:42, xdelay0:00:01, maileresmtp, priR80326, > relaymail.blackhat.net. [216.140.158.10], dsn4.0.0, > stat=Deferred: Invalid argument > > My setup consists of FreeBSD-4.2, Sendmail v8.11.2, a multi-home system > with a cable modem, analog modem, and a LAN. > > I only wish it to receive on the LAN (192.168.1.0) and the analog modem > (216.140.158.72). This is easy to change (DAEMON_OPTIONS), but I just > can't get confCLIENT_OPTIONS to work. From looking at sendmail.cf, I can > see that it is being set: > > # SMTP client options > O ClientPortOptions=Family=inet, Addr=216.140.158.72 > > Here are my files, interfaces, and routing tables. I have Exim working > with this, but I would like to get sendmail running. Also, I use IP > Filter to actually route the packets from the cable modem over to the > analog modem, but this is not the problem. > > > sendmail.mc: > divert(-1) > # Lots of comments. :) > divert(0)dnl > VERSIONID(`@(#)freebsd.mc $Revision: 1.4.2.1 $') > OSTYPE(bsd4.4) > DOMAIN(generic) > FEATURE(relay_entire_domain) > FEATURE(`dnsbl') > FEATURE(`always_add_domain') > > define(`confCLIENT_OPTIONS', `Addr=216.140.158.72') > define(`confNO_RCPT_ACTION', `add-to-undisclosed') > define(`confPRIVACY_FLAGS', `authwarnings,novrfy') > define(`confDONT_PROBE_INTERFACES', `true') > MODIFY_MAILER_FLAGS(`LOCAL', `+S') > > dnl Mailers. > MAILER(local) > MAILER(smtp) > > > ifconfig -a: > vx0: flags=8843 mtu 1500 > inet6 fe80::220:afff:fef0:e85d%vx0 prefixlen 64 scopeid 0x1 > inet 66.25.132.129 netmask 0xfc00 broadcast 255.255.255.255 > ether 00:20:af:f0:e8:5d > ed0: flags=8843 mtu 1500 > inet 192.168.1.2 netmask 0xff00 broadcast 192.168.1.255 > inet6 fe80::200:c0ff:fec2:cfdd%ed0 prefixlen 64 scopeid 0x2 > inet6 fec0::1:200:c0ff:fec2:cfdd prefixlen 64 > inet6 fec0:0:0:1:: prefixlen 64 anycast > ether 00:00:c0:c2:cf:dd > faith0: flags=8041 mtu 1500 > inet6 fe80::220:afff:fef0:e85d%faith0 prefixlen 64 scopeid 0x3 > gif0: flags=8010 mtu 1280 > gif1: flags=8010 mtu 1280 > gif2: flags=8010 mtu 1280 > gif3: flags=8010 mtu 1280 > lo0: flags=8049 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff00 > ppp0: flags=8010 mtu 1500 > stf0: flags1 mtu 1280 > tun0: flags=8051 mtu 1500 > inet6 fe80::220:afff:fef0:e85d%tun0 --> :: prefixlen 64 scopeid 0xb > inet 216.140.158.72 --> 216.140.158.15 netmask 0xff00 > Opened by PID 139 > Well, I have had the same problem. The solution was in removing IPv6 support. I have not done any futher investigations. HTH - -maxim -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Sendmail outgoing bind() fails on PPP
Hello, On Fri, 27 Apr 2001 [EMAIL PROTECTED] wrote: > >Well, I have had the same problem. The solution was in removing IPv6 > >support. I have not done any futher investigations. > > please file a bug report to sendmail.org. It seems Sean Farley has already done the patch. Thank you Sean. > itojun - -maxim -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: arp X moved from Y to Z messages
Hello,
On Tue, 18 Sep 2001, Matthew Luckie wrote:
> Hi there
>
> At work there are several freebsd machines that route packets through a
> "load balanced" or "redundant" router configuration.
> The gateway's IP address actually refers to two different machines.
> Naturally the gateway is used quite a bit, and the syslog fills up with "arp
> X moved from Y to Z on fxp0" messages.
>
> I'm guessing that not many people would have this problem.
> Below is a patch that I have found useful for these machines.
> I'm aware that there are security considerations with this patch; by default
> the sysctl is not activated.
There *is* a sysctl for it:
$ sysctl net.link.ether.inet.log_arp_wrong_iface=0
> I'm not subscribed to the list, CC me on any responses please.
>
> Matthew
>
> --- if_ether.c.orig Tue Sep 18 13:56:16 2001
> +++ if_ether.c Tue Sep 18 14:27:46 2001
> @@ -502,6 +502,12 @@
> &log_arp_wrong_iface, 0,
> "log arp packets arriving on the wrong interface");
>
> +static int log_arp_moved = 1;
> +
> +SYSCTL_INT(_net_link_ether_inet, OID_AUTO, log_arp_moved, CTLFLAG_RW,
> + &log_arp_moved, 0,
> + "log arp moved");
> +
> static void
> in_arpinput(m)
> struct mbuf *m;
> @@ -586,12 +592,13 @@
> }
> if (sdl->sdl_alen &&
> bcmp((caddr_t)ea->arp_sha, LLADDR(sdl), sdl->sdl_alen))
> {
> - if (rt->rt_expire)
> + if (rt->rt_expire) {
> + if(log_arp_moved)
> log(LOG_INFO, "arp: %s moved from %6D to %6D on
> %s%d\n",
> inet_ntoa(isaddr), (u_char *)LLADDR(sdl),
> ":",
> ea->arp_sha, ":",
> ac->ac_if.if_name, ac->ac_if.if_unit);
> - else {
> + } else {
> log(LOG_ERR,
> "arp: %6D attempts to modify permanent entry
> for %s on %s%d\n",
> ea->arp_sha, ":", inet_ntoa(isaddr),
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
>
>
--
Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer
phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: arp X moved from Y to Z messages
Oh, i am sorry, i was wrong, net.link.ether.inet.log_arp_wrong_iface
is for another problem.
On Tue, 18 Sep 2001, Maxim Konovalov wrote:
>
> Hello,
>
> On Tue, 18 Sep 2001, Matthew Luckie wrote:
>
> > Hi there
> >
> > At work there are several freebsd machines that route packets through a
> > "load balanced" or "redundant" router configuration.
> > The gateway's IP address actually refers to two different machines.
> > Naturally the gateway is used quite a bit, and the syslog fills up with "arp
> > X moved from Y to Z on fxp0" messages.
> >
> > I'm guessing that not many people would have this problem.
> > Below is a patch that I have found useful for these machines.
> > I'm aware that there are security considerations with this patch; by default
> > the sysctl is not activated.
>
> There *is* a sysctl for it:
>
> $ sysctl net.link.ether.inet.log_arp_wrong_iface=0
>
> > I'm not subscribed to the list, CC me on any responses please.
> >
> > Matthew
> >
> > --- if_ether.c.orig Tue Sep 18 13:56:16 2001
> > +++ if_ether.c Tue Sep 18 14:27:46 2001
> > @@ -502,6 +502,12 @@
> > &log_arp_wrong_iface, 0,
> > "log arp packets arriving on the wrong interface");
> >
> > +static int log_arp_moved = 1;
> > +
> > +SYSCTL_INT(_net_link_ether_inet, OID_AUTO, log_arp_moved, CTLFLAG_RW,
> > + &log_arp_moved, 0,
> > + "log arp moved");
> > +
> > static void
> > in_arpinput(m)
> > struct mbuf *m;
> > @@ -586,12 +592,13 @@
> > }
> > if (sdl->sdl_alen &&
> > bcmp((caddr_t)ea->arp_sha, LLADDR(sdl), sdl->sdl_alen))
> > {
> > - if (rt->rt_expire)
> > + if (rt->rt_expire) {
> > + if(log_arp_moved)
> > log(LOG_INFO, "arp: %s moved from %6D to %6D on
> > %s%d\n",
> > inet_ntoa(isaddr), (u_char *)LLADDR(sdl),
> > ":",
> > ea->arp_sha, ":",
> > ac->ac_if.if_name, ac->ac_if.if_unit);
> > - else {
> > + } else {
> > log(LOG_ERR,
> > "arp: %6D attempts to modify permanent entry
> > for %s on %s%d\n",
> > ea->arp_sha, ":", inet_ntoa(isaddr),
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-net" in the body of the message
> >
> >
>
>
--
Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer
phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: HEADS-UP: net polling code now in STABLE.
Hi Luigi, On Mon, 3 Dec 2001, Luigi Rizzo wrote: > [Bcc to -stable because of relevance there] > > With the approval of the release engineer, a revised version of > the network polling code is now in STABLE. It would be great if > you could try it out and send feedback, so we con sort out issues > (if any) before the release of 4.5. > > Do not be afraid to upgrade, because unless you explicitly enable > the new code with the kernel option mentioned below, your kernel > will not be affected by the patch. > > The code is only for i386 architecture, non-SMP (it would be rather > useless on SMP boxes, anyways). Devices supported so far are "dc", > "fxp" and "sis". I can patch more drivers if you ask, but you need > to test the patches yourself because i do not have access to other > 100M and 1G cards (except perhaps "xl"). We have a very busy ftp server with xl card where we can test the code. So it would be great if you adopt the pathces for xl. Thank you! > [As a side note -- there have been significant performance improvement > changes to the "dc" and "sis" drivers recently, so if you have one > of these two cards, it might be worthwhile to upgrade]. > > The commit message follows. Have fun. > > cheers > luigi > [ commit message ] - -maxim -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: log_in_vain
Hello, On Thu, 6 Dec 2001, Paul Chvostek wrote: > > For the fun of it, I turned on log_in_vain. And I'm seeing *lots* of > stuff one might expect (port scans, Nimda poking at my mail server, > SMTP to the web server, etc). But I'm also seeing stuff I don't expect, > primarily in the areas of DNS and localhost traffic. For example: > > Dec 6 08:15:39 schplict /kernel: Connection attempt to UDP 216.126.86.8:1262 from >216.126.86.2:53 > > and > > Dec 6 08:35:37 haggis /kernel: Connection attempt to UDP 216.126.86.9:1044 from >216.126.86.2:53 > > and > > Dec 6 08:34:44 haggis /kernel: Connection attempt to UDP 127.0.0.1:512 from >127.0.0.1:1054 > Dec 6 08:34:44 haggis /kernel: Connection attempt to UDP 127.0.0.1:512 from >127.0.0.1:1058 > Dec 6 08:34:44 haggis /kernel: Connection attempt to UDP 127.0.0.1:512 from >127.0.0.1:1063 > Dec 6 08:34:45 haggis /kernel: Connection attempt to UDP 127.0.0.1:512 from >127.0.0.1:1067 > > The host at 216.126.86.2 is the first nameserver in the resolv.conf of > the both haggis and schplict. It looks to me as if the name server is > sending responses back to DNS queries which for some reason haven't > waited around. because of request timeout. > And as far as I know I'm not running biff on haggis. The frequency of > the hits makes it look as if it's running something every time ... > something ... gets launched. But biff's not in any .profile, .cshrc or > .login. So I'm left scratching my head. man 8 mail.local will help. > Can anybody shed some light on this? -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Processing IP options reveals IPSTEALH router
Hello Yar, On 18:19+0300, Dec 19, 2001, Yar Tikhiy wrote: > Hi there, > > I ran into an absolutely clear, but year-old PR pointing out that > a router in the IPSTEALTH mode will reveal itself when processing > IP options: kern/23123. > > The fix proposed seems clean and right to me: don't do IP options > at all when in the IPSTEALTH mode. Does anyone have objections? > If no, I'll commit the fix. > First of all we should decide what IPSTEALTH is for. Is it just a Ruslan's net.inet.ip.decttl or it should really stealth the fact of the routing? If the latter how do we behave in source routing case? -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Processing IP options reveals IPSTEALH router
On 19:49+0300, Dec 19, 2001, Yar Tikhiy wrote: > On Wed, Dec 19, 2001 at 07:23:55PM +0300, Maxim Konovalov wrote: > > > > > I ran into an absolutely clear, but year-old PR pointing out that > > > a router in the IPSTEALTH mode will reveal itself when processing > > > IP options: kern/23123. > > > > > > The fix proposed seems clean and right to me: don't do IP options > > > at all when in the IPSTEALTH mode. Does anyone have objections? > > > If no, I'll commit the fix. > > > > First of all we should decide what IPSTEALTH is for. Is it just a > > Ruslan's net.inet.ip.decttl or it should really stealth the fact of > > the routing? If the latter how do we behave in source routing case? > > Are there any reasons for a router not to decrement IP TTL besides > trying to stay invisible to a third party? imho there are not. I've asked because ru's net.inet.ip.decttl means "do not decrement TTL" but not "hide the fact of the routing". > As for source routing, I believe a stealthy router should just drop > such packets as though it were a host. Of course, source-routed > packets destined for the router itself should be accepted. So there are three IPSTEALTH cases: 1/ the dst address is not ours, net.inet.ip.sourceroute=0, net.inet.ip.forwarding=1: process ip options by ip_dooptions(). 2/ the dst address is ours: process ip options by ip_dooptions(), 3/ in other cases do not process ip options. By the way, is it correct to forward the packet with incorrect ip options? Now we do not. -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IP options (was: Processing IP options reveals IPSTEALH router)
Morning, On 00:35+0300, Dec 20, 2001, Yar Tikhiy wrote: > On Wed, Dec 19, 2001 at 08:54:50PM +0300, Maxim Konovalov wrote: > > > > By the way, is it correct to forward the packet with incorrect ip > > options? Now we do not. > > No RFC seems to specify that particularly. However, RFC 1812 reads > in general: > >(1) A router MUST verify the IP header, as described in section >[5.2.2], before performing any actions based on the contents of >the header. This allows the router to detect and discard bad >packets before the expenditure of other resources. > > Meanwhile more IP option issues came to my attention... > > Neither RFC 791 nor RFC 1122 nor RFC 1812 specify the following: > if a source-routed IP packet reachs the end of its route, but its > destination address doesn't match a current host/router, whether > the packet should be discarded, sent forth through usual routing > or accepted as destined for this host? FreeBSD will route such a > packet as usual. Stevens, TCP Ill. vII, p.257 says: "If the destination address of the packet does not match one of the local addresses and the option is a strict source routing (IPOPT_SSRR), an ICMP source route failure error is sent. If a local address isn't listed in the route, the previous system sent the packet to the wrong host. This isn't an error for a loose source route (IPOPT_LSRR); it means IP must forward the packet toward the destionation." That is what ip_input does near the line 1193. > Then, a FreeBSD host (net.inet.ip.forwarding=0) will respond with > Source Route Failed ICMPs to source-routed IP packets if source > route processing is prohibited using net.inet.ip.sourceroute or > net.inet.ip.accept_sourceroute. To my mind, it may be deduced > from RFC 1122 that a host must stay silent in this case... -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IP options (was: Processing IP options reveals IPSTEALH router)
Hi, Yar,
On 19:12+0300, Dec 21, 2001, Yar Tikhiy wrote:
> On Thu, Dec 20, 2001 at 01:24:48AM +0300, Maxim Konovalov wrote:
> >
> > > Neither RFC 791 nor RFC 1122 nor RFC 1812 specify the following:
> > > if a source-routed IP packet reachs the end of its route, but its
> > > destination address doesn't match a current host/router, whether
> > > the packet should be discarded, sent forth through usual routing
> > > or accepted as destined for this host? FreeBSD will route such a
> > > packet as usual.
> >
> > Stevens, TCP Ill. vII, p.257 says:
> >
> > "If the destination address of the packet does not match one of the
> > local addresses and the option is a strict source routing
> > (IPOPT_SSRR), an ICMP source route failure error is sent. If a local
> > address isn't listed in the route, the previous system sent the packet
> > to the wrong host. This isn't an error for a loose source route
> > (IPOPT_LSRR); it means IP must forward the packet toward the
> > destionation."
> >
> > That is what ip_input does near the line 1193.
>
> Oops, it appeared that I misunderstood the way the source route
> record worked. FreeBSD does it right, except for a host (ipforwarding=0)
> replying with error ICMP on some source route attempts.
> What about the following small change?
>
> --- /usr/src/sys/netinet.orig/ip_input.c Fri Dec 7 00:54:48 2001
> +++ netinet/ip_input.cFri Dec 21 19:08:56 2001
> @@ -1212,13 +1212,13 @@
> ia = (struct in_ifaddr *)
> ifa_ifwithaddr((struct sockaddr *)&ipaddr);
> if (ia == 0) {
> + if (!ip_dosourceroute)
> + goto nosourcerouting;
Nice catch.
> if (opt == IPOPT_SSRR) {
> type = ICMP_UNREACH;
> code = ICMP_UNREACH_SRCFAIL;
> goto bad;
> }
> - if (!ip_dosourceroute)
> - goto nosourcerouting;
> /*
>* Loose routing, and not at next destination
>* yet; nothing to do except forward.
> @@ -1231,18 +1231,19 @@
>* End of source route. Should be for us.
>*/
> if (!ip_acceptsourceroute)
> - goto nosourcerouting;
> + goto logandsendicmp;
> save_rte(cp, ip->ip_src);
> break;
> }
>
> if (!ip_dosourceroute) {
> +nosourcerouting:
I do not agree here. As far as I understand when we recieve a SSRR
packet and there are no our addresses in the source routing addresses
list we have to send ICPM_UNREACH to the sender regardless of
net.inet.ip.forwarding.
> if (ipforwarding) {
> char buf[16]; /* aaa.bbb.ccc.ddd\0 */
> /*
>* Acting as a router, so generate ICMP
>*/
> -nosourcerouting:
> +logandsendicmp:
> strcpy(buf, inet_ntoa(ip->ip_dst));
> log(LOG_WARNING,
> "attempted source route from %s to %s\n",
>
>
Btw, there are many compares like
cnt < IPOPT_OLEN + sizeof(*cp)
in ip_doiptions(). IMHO more strict to compare agains IPOPT_MIN
because multibyte ip options length cannot be less then four bytes. Am
I wrong?
--
Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer
phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Processing IP options reveals IPSTEALH router
Hello, On 18:51+0300, Dec 21, 2001, Yar Tikhiy wrote: > On Wed, Dec 19, 2001 at 08:54:50PM +0300, Maxim Konovalov wrote: > > On 19:49+0300, Dec 19, 2001, Yar Tikhiy wrote: > > > > > As for source routing, I believe a stealthy router should just drop > > > such packets as though it were a host. Of course, source-routed > > > packets destined for the router itself should be accepted. > > > > So there are three IPSTEALTH cases: > > > > 1/ the dst address is not ours, net.inet.ip.sourceroute=0, > > net.inet.ip.forwarding=1: process ip options by ip_dooptions(). > > > > 2/ the dst address is ours: process ip options by ip_dooptions(), > > > > 3/ in other cases do not process ip options. > > I made a patch that adds the "stealthy IP options feature". > Honestly, now I'm afraid it's "much ado about nothing", given how > clumsy solution is needed for such a small problem. Even the way > of ignoring IP options completely when doing IPSTEALTH looks way > better... IMHO it is not a good idea to forward a packet with possible incorrect ip options. The patch looks OK for me. -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: TCP Connections to a Broadcast Address
On 04:28-0800, Feb 23, 2002, Crist J. Clark wrote: > On Sat, Feb 23, 2002 at 01:50:33PM +0200, Ruslan Ermilov wrote: > [snip] > > > Nice catch! > > Igor M Podlesny <[EMAIL PROTECTED]>, PR misc/35022, caught it. I just > analyzed it. Isn't kern/19722 about the same bug? > [snip] maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: mbuf chain
[...] > I don't believe that mbuf fragments have any relationship to IP > fragmentation. > > And while you mention it, the IP fragmentation handling code is another > place where we need to add mbuf merging/chaining. > > I've been thinking about this, actually. How many IP fragments will a > packet ever truly have? If you assume a 1500 byte ethernet packet broken > into 200 byte chunks, that's < 8. If you break a jumbo frame into 1500 > byte packets, that's < 7. Can there be any normal use of fragmentation > that would produce more than 10 or so fragments? Also, will overlapping > fragments really ever be seen, or can we just assume that's a sign of > abuse? > > Sorry for the sudden change of direction for this thread, I've been > pondering how to improve our resistance to mbuf exhaustion through ip > frags. There is net.inet.ip.maxfragpackets but IMHO net.inet.ip.maxfragperpacket will be useful too. -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: UNKNOWN IP OPTION emergency
On 19:00+0400, Sep 26, 2002, soheil h wrote: > > Dear All > > as in stevens' Tcp/Ip illustrated says when a router see an unknown option > it must silently ignore it but when i put an option by type 253 len 12 and > 10 byte of data > some router on my path drop it Do Not Crosspost (r) and Show Your Code (tm) -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
patch for review, misc/42121, incorrect IPOPT_TS processing
Hello -net, misc/42121 has a detailed problem description, fix is obvious. Here is a patch: Index: ip_input.c === RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.210 diff -u -r1.210 ip_input.c --- ip_input.c 28 Sep 2002 17:15:25 - 1.210 +++ ip_input.c 7 Oct 2002 14:04:06 - @@ -1405,6 +1405,7 @@ (void)memcpy(sin, &IA_SIN(ia)->sin_addr, sizeof(struct in_addr)); cp[IPOPT_OFFSET] += sizeof(struct in_addr); + off += sizeof(struct in_addr); break; case IPOPT_TS_PRESPEC: @@ -1418,6 +1419,7 @@ if (ifa_ifwithaddr((SA)&ipaddr) == 0) continue; cp[IPOPT_OFFSET] += sizeof(struct in_addr); + off += sizeof(struct in_addr); break; default: %%% Any objections? -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RFR: ping(8) patches: do not fragment, TOS, maximum payload
options |= F_SO_DONTROUTE;
break;
case 's': /* size of packet to send */
- if (uid) {
- errno = EPERM;
- err(EX_NOPERM, "-s flag");
- }
ultmp = strtoul(optarg, &ep, 0);
- if (ultmp > MAXPAYLOAD)
- errx(EX_USAGE,
- "packet size too large: %lu > %u",
- ultmp, MAXPAYLOAD);
if (*ep || ep == optarg)
errx(EX_USAGE, "invalid packet size: `%s'",
optarg);
+ if (uid != 0 && ultmp > DEFDATALEN) {
+ errno = EPERM;
+ err(EX_NOPERM,
+ "packet size too large: %lu > %u",
+ ultmp, DEFDATALEN);
+ }
datalen = ultmp;
break;
case 'S':
@@ -418,6 +416,12 @@
usage();
target = argv[optind];
+ maxpayload = IP_MAXPACKET - sizeof(struct ip) - MINICMPLEN;
+ if (options & F_RROUTE)
+ maxpayload -= MAX_IPOPTLEN;
+ if (datalen > maxpayload)
+ errx(EX_USAGE, "packet size too large: %lu > %u", datalen,
+ maxpayload);
if (source) {
bzero((char *)&sin, sizeof(sin));
sin.sin_family = AF_INET;
@@ -1476,7 +1480,7 @@
&pat[13], &pat[14], &pat[15]);
if (ii > 0)
- for (kk = 0; kk <= MAXPAYLOAD - (PHDR_LEN + ii); kk += ii)
+ for (kk = 0; kk <= maxpayload - (PHDR_LEN + ii); kk += ii)
for (jj = 0; jj < ii; ++jj)
bp[jj + kk] = pat[jj];
if (!(options & F_QUIET)) {
Index: ping.8
===
RCS file: /home/maxim/cvs/ping/ping.8,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ping.8 15 Oct 2002 12:04:10 - 1.2
+++ ping.8 15 Oct 2002 12:04:59 - 1.3
@@ -235,7 +235,7 @@
with the 8 bytes of
.Tn ICMP
header data.
-Only the super-user may use this option.
+Only the super-user may specify values more then default.
.It Fl S Ar src_addr
Use the following IP address as the source address in outgoing packets.
On hosts with more than one IP address, this option can be used to
%%%
Thank you very much.
--
Maxim Konovalov, MAcomnet, Internet Dept., system engineer
phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: BUG: ip_output.c FreeBSD 4.11
On Wed, 14 Dec 2005, 14:43+0100, Lars Erik Gullerud wrote: > On Tue, 13 Dec 2005, Kris Kennaway wrote: > > > On Tue, Dec 13, 2005 at 04:32:10PM -0800, Jack Vogel wrote: > > > On 12/13/05, Kris Kennaway <[EMAIL PROTECTED]> wrote: > > > > On Tue, Dec 13, 2005 at 01:37:31PM -0800, Doug Barton wrote: > > > > > Mihail Balikov wrote: > > > > > > Hello, > > > > > > > > > > > > In FreeBSD 4.x in ip_output.c in part for ipfw local forwarding > > > > > > there's typo > > > > > > that will cause kernel panic: > > > > > > > > > > If you haven't already, this should be filed as a problem report. > > > > > > > > I don't know that there's a lot of point since 4.11 is in "legacy" > > > > mode and few developers still use it. > > > > > > The humorous thing is that althought I'm sure its true "few developers" > > > still use it, in places where it has actual commercial use, they are > > > still > > > using 4.x in large numbers. > > > > > > So bottom line... there is value in bugs being noted and filed :) > > > > Sure, I guess..as long as there aren't unrealistic expectations about > > someone fixing it. > > The original mail contained the patch that fixes the problem if I'm > not mistaken, so I guess the only expectations here are that someone > goes and commits it if the OP creates a PR with the patch... Which > shouldn't really be too unrealistic, should it? For the record: Gleb has fixed the issue a couple of days ago before you started this discussion :-) -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: requests for mbufs denied increasing
On Wed, 31 May 2006, 10:29-0300, Alexandre Biancalana wrote:
> Hi list,
>
>I've a NFS/FTP server used as backup server, receiving few
> connections with high volume of data (100GB/Day). During this period
> the "requests for mbufs denied (mbufs/clusters/mbuf+clusters)" of
> netstat -m is increasing constantly, now is:
[...]
Try patch Robert Watson committed to HEAD ten days ago:
Index: sys/vm/uma_core.c
===
RCS file: /home/ncvs/src/sys/vm/uma_core.c,v
retrieving revision 1.136
retrieving revision 1.137
diff -u -p -r1.136 -r1.137
--- sys/vm/uma_core.c 11 Feb 2006 19:20:56 - 1.136
+++ sys/vm/uma_core.c 21 May 2006 23:25:32 - 1.137
@@ -2413,8 +2413,7 @@ zfree_start:
* If nothing else caught this, we'll just do an internal free.
*/
zfree_internal:
- uma_zfree_internal(zone, item, udata, SKIP_DTOR, ZFREE_STATFAIL |
- ZFREE_STATFREE);
+ uma_zfree_internal(zone, item, udata, SKIP_DTOR, ZFREE_STATFREE);
return;
}
%%%
--
Maxim Konovalov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: requests for mbufs denied increasing
On Wed, 31 May 2006, 15:21-0300, Alexandre Biancalana wrote: > Thanks for all replies ! > > After apply the patch, I must rebuild just the kernel... right ?! Correct. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic from osendmsg() (Re: panic: m_prepend: MH_ALIGN not PKTHDR mbuf)
Hi Kris, On Sun, 4 Jun 2006, 20:41-0400, Kris Kennaway wrote: > On Tue, May 23, 2006 at 09:58:26PM -0400, Kris Kennaway wrote: > > I got this panic as a non-privileged user running the stress2 test > > component that does random syscalls: > > > > panic: m_prepend: MH_ALIGN not PKTHDR mbuf > > cpuid = 1 > > KDB: enter: panic > > [thread pid 15370 tid 100536 ] > > Stopped at kdb_enter+0x32: leave > > db> wh > > Tracing pid 15370 tid 100536 td 0xc5561000 > > kdb_enter(c073c6b2,1,c0741b31,eced5be0,c5561000) at kdb_enter+0x32 > > panic(c0741b31,c07199c6,2,0,e) at panic+0x1b1 > > m_prepend(c4dc0300,c,2,e,eced5c58) at m_prepend+0xd8 > > sendit(eced5c58,7cd3a4b7,eced5c54,28,c4beb1a0) at sendit+0x1a4 > > osendmsg(c5561000,eced5d04,c,445,3) at osendmsg+0x89 > > Anyone looking at this? It seems that the osendmsg() compatibility > syscall can be easily used to cause this panic. It panics at KASSERT which appeared in rev. 1.181 mbuf.h: % revision 1.181 % date: 2005/11/18 14:40:43; author: andre; state: Exp; lines: +8 -0 % Add KASSERTs to M_ALIGN() and MH_ALIGN() to prevent usage on wrong % mbuf types. % % Sponsored by: TCP/IP Optimization Fundraise 2005 COMPAT_OLDSOCK code in sendit() tries to prepend a control data mbuf to sockargs mbuf which is !M_PKTHDR and could be !M_EXT. There are two options: 1. Backout KASSERTS. 2. Fix m_prepend() so it won't call MH_ALIGN for an mbuf without M_PKTHDR/M_EXT stuff. I think this is a resonable w/o and shouldn't break anything (it passed my tests at least): Index: uipc_mbuf.c === RCS file: /home/ncvs/src/sys/kern/uipc_mbuf.c,v retrieving revision 1.165 diff -u -p -r1.165 uipc_mbuf.c --- uipc_mbuf.c 15 Mar 2006 21:11:11 - 1.165 +++ uipc_mbuf.c 6 Jun 2006 21:09:57 - @@ -496,7 +496,7 @@ m_prepend(struct mbuf *m, int len, int h M_MOVE_PKTHDR(mn, m); mn->m_next = m; m = mn; - if (len < MHLEN) + if (m->m_flags & M_PKTHDR && len < MHLEN) MH_ALIGN(m, len); m->m_len = len; return (m); %%% I CC'ed Andre. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Netconfig
On Wed, 28 Jun 2006, 15:23-0700, Julian Elischer wrote: > what the [EMAIL PROTECTED] is a Netconfig database and why do I suddenly need > one? > no such animal in 4.x etc. man 5 netconfig, portmap(8) in RELENG_4 vs rpcbind(3,8) in RELENG_5,6 and HEAD. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tftpd not working when net.inet.udp.blackhole=1
Hello, On Mon, 3 Jul 2006, 18:41+0300, Nikolay Pavlov wrote: > Hi folks. > I have a strange problem with tftpd when using sysctl > net.inet.udp.blackhole=1 It's not working with this variable enabled. > > I use tftp to upload images from my routers. Here is details of the > problem: > > OS FreeBSD 6.0-RELEASE-p6 > > [EMAIL PROTECTED]:~/projects/route_tools# sysctl net.inet.udp.blackhole=1 > net.inet.udp.blackhole: 0 -> 1 > > [EMAIL PROTECTED] running-conf tftp XX.XX.48.25 > XX.XX.51.194.runcfg.new > TFTP session timed out > Error - can't upload running-config to TFTP server. [...] Nice question indeed. I spent 20 minutes trying to get wtf is going on. There are several moments: a) I guess you are running stock tftpd from inetd i.e. tftpd -s /tftproot. In that case tftpd chroots to /tftproot. b) tftpd wants to resolve a peer ip address but there is no /etc/resolv.conf in its new root directory so it asks 127.0.0.1 for resolve. c) net.inet.udp.blackhole=1 forces the kernel just drop tftpd DNS requests. d) From this point several timing issues starts: tftpd still trying to resolve a client ip address, then gives up but now client gives up. I see several solutions: a) Don't use chroot. In general this is not good from security point of view. b) Run a named @127.0.0.1. c) Put a valid resolv.conf to /tftpboot/etc/. d) Don't use net.inet.udp.blackhole=1. HTH. -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with uipc_mbuf.c
On Tue, 29 Aug 2006, 17:15+0200, Andre Oppermann wrote:
> John-Mark Gurney wrote:
> > Randall Stewart wrote this message on Mon, Aug 28, 2006 at 17:04 -0400:
> > > atomic_fetchadd_int(m->m_ext.ref_cnt, -1) == 0) {
> > ^
> >
> > This should be 1 not 0.. as apparently fetchadd_int returns the
> > old value (at least that's what atomic(9) says), which means that
> > if we ever race on this comparision, we won't free though we
> > should of...
> >
> > if we look at refcount.h, it does:
> > return (atomic_fetchadd_int(count, -1) == 1);
> >
> > which release a reference and apparently returns true if it needs to
> > be free'd...
> >
> > Though the wierd part is that andre, "fixed" it to be 0 in 1.157:
> > Fix a logic error introduced with mandatory mbuf cluster
> > refcounting and freeing of mbufs+clusters back to the packet zone.
>
> Honestly I'm a bit confused myself now and have to dig up things from
> when I did the change. However I'm certain there was a problem and the
> commit fixed it in some way (not necessarily the correct way). Before
> the 'fix' there were some larger leaks going on.
So what's the conclusion? Perhaps it's worth to add an XXX comment in
meantime.
--
Maxim Konovalov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Automatic TCP send and receive socket buffer sizing
[...] > Any tests and test reports are very welcome. I saw a question asked several times but no answer: what happens with the sockets when you explicitly call setsockopt() to set a socket buffer size? Is automatic buffer sizing enabled for them? -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Automatic TCP send and receive socket buffer sizing
On Wed, 13 Dec 2006, 13:43+0100, Andre Oppermann wrote: > Maxim Konovalov wrote: > > [...] > > > Any tests and test reports are very welcome. > > > > I saw a question asked several times but no answer: what happens with > > the sockets when you explicitly call setsockopt() to set a socket > > buffer size? Is automatic buffer sizing enabled for them? > > No. In that case automatic socket buffer sizing gets disabled. Good, thanks! -- Maxim Konovalov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bin/110933: [traceroute] minimal wait time should be 1 sec, not 2
Hi, Are there any ideas why traceroute requires waittime >=2 seconds? The only place it used is select(2) timeout. -- Maxim Konovalov -- Forwarded message -- Date: Tue, 27 Mar 2007 19:44:54 +0400 (MSD) From: Dmitry Marakasov <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: bin/110933: [traceroute][patch] minimal wait time should be 1 sec, not 2 Resent-Date: Tue, 27 Mar 2007 15:50:09 GMT Resent-From: [EMAIL PROTECTED] (GNATS Filer) Resent-To: [EMAIL PROTECTED] [...] In traceroute utility, minimal time to wait for reply is 2 seconds. That's annoying, because system administrators often need traceroute to skip hosts that do not respond faster, but when specifying obvious wait time as 1 sec, they get an error. I see no reason for minimal wait time to be 2 sec, the patch attached lowers limit to well expected 1 second. >How-To-Repeat: 1) traceroute -w1 somehost traceroute: wait time must be > 1 2) ?! >Fix: --- traceroute.patch begins here --- --- src/contrib/traceroute/traceroute.c.origTue Mar 27 19:34:53 2007 +++ src/contrib/traceroute/traceroute.c Tue Mar 27 19:35:00 2007 @@ -608,7 +608,7 @@ case 'w': waittime = str2val(optarg, "wait time", - 2, 24 * 60 * 60); + 1, 24 * 60 * 60); break; case 'z': --- traceroute.patch ends here --- >Release-Note: >Audit-Trail: >Unformatted: ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: forwarded message on Source Quench Packets.
On 09:27+0300, Nov 12, 2002, Mike Silbersack wrote: > > (redirected to -net so others can review this) > > I can see how these source quench messages would cause problems if a DoS > is being routed through a FreeBSD router, and I think that your patch > makes sense. Are there any objections to me committing this in a few > days? Shouldn't we call m_freem(mcopy) before return? Here is an updated diff, a comment was stolen from NetBSD. Index: sys/netinet/ip_input.c === RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.215 diff -u -r1.215 ip_input.c --- sys/netinet/ip_input.c 20 Oct 2002 22:52:06 - 1.215 +++ sys/netinet/ip_input.c 12 Nov 2002 09:51:48 - @@ -1970,9 +1970,14 @@ break; case ENOBUFS: - type = ICMP_SOURCEQUENCH; - code = 0; - break; + /* +* A router should not generate ICMP_SOURCEQUENCH as +* required in RFC1812 Requirements for IP Version 4 Routers. +* Source quench could be a big problem under DoS attacks, +* or if the underlying interface is rate-limited. +*/ + m_freem(mcopy); + return; case EACCES:/* ipfw denied packet */ m_freem(mcopy); %%% > Mike "Silby" Silbersack > > On Mon, 11 Nov 2002, David Gilbert wrote: > > > I normally wouldn't forward something to such a big list, but this has > > real implications (and was part of a nast DOS against dsl.ca last > > week). The patch for FreeBSD (netbsd code is quoted) is trivial: > > > > --- /sys/netinet/ip_input.c Thu Oct 17 08:29:53 2002 > > +++ ip_input.c Mon Nov 11 15:15:31 2002 > > @@ -1822,9 +1822,7 @@ > > break; > > > > case ENOBUFS: > > - type = ICMP_SOURCEQUENCH; > > - code = 0; > > - break; > > + return; > > > > case EACCES:/* ipfw denied packet */ > > m_freem(mcopy); > > > > I'm submitting a PR now. > > > > For discussion: source quenches probably shouldn't be generated > > anyways, but this patch also doesn't generate the source quench if > > we're the target machine. It's probably good to go straight ahead > > with this. IIRC, tcp_input.c also can generate a source quench > > ... > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > > -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:maxim@;macomnet.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ip_input.c => sockaddr_in ipaddr
On 17:07+0300, Nov 25, 2002, Mihail Balikov wrote: > > Hello, > In -stable ip_input.c is defined global "sockaddr_in ipaddr", but this is > variable is used only in ip_dooptions(), is it correct? It was moved to ip_dooptions() in rev. 1.203 ip_input.c in -current. Ask Luigi Rizzo <[EMAIL PROTECTED]> about MFC. -- Maxim Konovalov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: BUG, sppp, FreeBSD 5.x 6.x
On 18:38+0300, Feb 14, 2003, Roman Kurakin wrote: > Roman Kurakin wrote: Fixed in rev. 1.99 src/sys/net/if_spppsubr.c, will MFC the fix before RELENG_4. Thanks! [...] -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: BUG, sppp, FreeBSD 5.x 6.x
On 16:45+0300, Feb 17, 2003, Maxim Konovalov wrote: > On 18:38+0300, Feb 14, 2003, Roman Kurakin wrote: > > > Roman Kurakin wrote: > > Fixed in rev. 1.99 src/sys/net/if_spppsubr.c, will MFC the fix before > RELENG_4. Thanks! Grrr, before 4.8-RELEASE. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Trouble with wi (prism2.5_pci) in bridge
On 22:07+0400, Mar 31, 2003, Oleg Borowkov wrote: > Hi! > > Help me with config bridge - FreeBSD 4.8 Release: > > # ifconfig > wi0: flags=8943 mtu 1500 > inet 192.168.10.1 netmask 0xff00 broadcast 192.168.10.255 > ether 00:60:b3:6a:6a:0d > media: IEEE 802.11 Wireless Ethernet autoselect > status: associated > ssid test 1:test > stationname "FreeBSD WaveLAN/IEEE node" > channel 1 authmode OPEN powersavemode OFF powersavesleep 100 > wepmode OFF weptxkey 1 > ed0: flags=8843 mtu 1500 > ether 00:c0:df:fa:cd:7c > > > sysctl net.link.ether.bridge_cfg=wi0,ed0 > sysctl net.link.ether.bridge=1 > sysctl net.inet.ip.forwarding=1 > > all work fine, but birdging don't work :-(( > how i can debug bridge? s/#define DEB(x)/#define DEB(x) x/ in sys/net/bridge.c, recompile and reload bridge.ko. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: limiting connections per IP w/FreeBSD ftpd?
On 09:25-0400, May 30, 2003, Andrew Gallatin wrote: > > At my company, some bonehead (not sure if it was maliciousness or just > a stupid customer), opened 60 simultaneous connections to our ftp > server and totally swamped our T1.This is the second or third time > this has happened recently. > > So I'm looking for some way to limit the number of connections per-IP. > I understand this may be bad for sites behind NAT boxes, or for > multiuser systems, and I don't want to start a thread debating its > merits. > > I'd like to avoid downgrading to one of the swiss-army knife ftpds > that always seems to have a vulnerability in the headlines, but I > don't have time to hack FreeBSD ftpd myself. > > So: Does anybody have patches to allow FreeBSD's ftpd to limit > connections per IP? Or am I stuck with proftpd or wuftpd a) run ftpd from inetd -s, man inetd; b) ipfw2 limit src-addr, man ipfw. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with bridge 802.1q frames
:48.770633 arp who-has 192.168.3.100 (2e:2f:30:31:32:33) tell 192.168.3.15
> 15:22:49.781246 arp who-has 192.168.3.100 (2e:2f:30:31:32:33) tell 192.168.3.15
Try this hack and let me know if it works for you. Thanks!
Index: if_ethersubr.c
===
RCS file: /home/ncvs/src/sys/net/if_ethersubr.c,v
retrieving revision 1.147
diff -u -r1.147 if_ethersubr.c
--- if_ethersubr.c 5 May 2003 09:15:50 - 1.147
+++ if_ethersubr.c 20 May 2003 15:06:50 -
@@ -625,6 +625,7 @@
if (rule) /* packet was already bridged */
goto post_stats;
+#if 0
if (!(BDG_ACTIVE(ifp))) {
/*
* Discard packet if upper layers shouldn't see it because it
@@ -641,6 +642,7 @@
return;
}
}
+#endif
/* Discard packet if interface is not up */
if ((ifp->if_flags & IFF_UP) == 0) {
%%%
--
Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLAN/Bridge No response from trunk Interface
Hello,
On Fri, 20 Jun 2003, 11:39-0300, Han Hwei Woo wrote:
> Here's the network I'm trying to setup
>
> 192.168.0.3192.168.0.1192.168.0.2
> OpenBSD | vlan0><--- vlan0 | FreeBSD | em0 ---><--- em0 | Windows 2000
>
> with net.link.ether.bridge_cfg: vlan0,em0
>
> If I try to ping the FreeBSD machine from OpenBSD, arp requests are
> sent out, and they are seen on both of the FreeBSD machine's
> interfaces. However, no arp response is generated.
>
> So, I enter in the arp entries myself.
>
> Once I do that, when I again try to ping the FreeBSD host from
> OpenBSD, the ping requests are seen on both the FreeBSD interfaces.
> However, no response is generated.
>
> If I instead try to ping the OpenBSD machine from FreeBSD, the ping
> requests get to the OpenBSD machine, and the OpenBSD replies, and
> both the FreeBSD interfaces receive the reply, according to tcpdump.
> However, the ping program does not receive them.
>
>
> I also tried this setup:
>
> 192.168.0.3192.168.0.1192.168.0.2
> OpenBSD | vlan0><--- vlan0 | FreeBSD | vlan1 ---><--- vlan0 | Windows 2000
>
> with net.link.ether.bridge_cfg: vlan0,vlan1
>
> And the same problem occurs. I have also tried with different
> network cards as the parent interface of vlan0 on FreeBSD
> (fxp0,dc0).
1) Please try a hack below;
2) Don't use bridge.ko, it is semi-broken, compile the bridging code
in kernel instead (options BRIDGE);
3) sysctl net.inet.ip.check_interface=0 is mandatory in some
topologies.
Index: if_ethersubr.c
===
RCS file: /home/ncvs/src/sys/net/if_ethersubr.c,v
retrieving revision 1.147
diff -u -r1.147 if_ethersubr.c
--- if_ethersubr.c 5 May 2003 09:15:50 - 1.147
+++ if_ethersubr.c 20 May 2003 15:06:50 -
@@ -625,6 +625,7 @@
if (rule) /* packet was already bridged */
goto post_stats;
+#if 0
if (!(BDG_ACTIVE(ifp))) {
/*
* Discard packet if upper layers shouldn't see it because it
@@ -641,6 +642,7 @@
return;
}
}
+#endif
/* Discard packet if interface is not up */
if ((ifp->if_flags & IFF_UP) == 0) {
%%%
--
Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Suggesting for fixing VLAN bridging the right way
Hi Doug, Your analysis is correct (kern/46961), I am slowly working on the fix but no ETA. It seems NetBSD recently has fixed a similar issue, haven't checked this fact yet, just saw a promising commit log in if_ethersubr.c. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: splx() bug in ip_dummynet?
On Thu, 24 Jul 2003, 11:31-0400, Don Bowman wrote: > From: Don Bowman [mailto:[EMAIL PROTECTED] > > ... > > I believe this patch will correct the issue. > > Index: ip_dummynet.c [...] Yes, it looks correct. I will commit it as soon as I get your PR. Thanks! -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bridging in FreeBSD without one side being blocked?
Hello Will, On Sun, 10 Aug 2003, 23:52-0700, Will Andrews wrote: > Hello (please cc: me as I am not subscribed, thanks), > > I was wondering if anyone has managed to set up bridge in such a > way that hosts on both sides will be able to access the machine > doing the bridging. The reason I need this is because I need to > join two media types (10baseT/100baseTX and 1000baseSX), and both > sides of the bridge need access to the machine in question. I'd > prefer to do it like this instead of buying another switch with > the necessary media ports or a media converter just for this. > > As far as I can tell, it does not seem like FreeBSD's BRIDGE is > capable of doing this sort of thing. Does someone know if > > ng_bridge can do it, or if it could be made to with some slight > modifications? I could not find any documentation about someone > that has done something like this. > > I should note.. later I may add an Atheros card to the bridge, > configured in 802.11a host AP mode. Same conditions apply. :) > > Seems to me that if a packet is destined for an IP associated > with any of the bridge's child interfaces, the code should > recognize that the packet can be delivered directly to it, as > opposed to simply dropping it. First, there is a bug in bridge code when it is loaded as module. Use static compiled bridge instead. Second, if your NICs in a bridge cluster have different if_hwassist checksum capabilities, you hit another bug. Third, if you use vlan(4) there is a bug with bridging them too. Forth, you have to turn net.inet.ip.check_interface off (sysctl net.inet.ip.check_interface=0). I have a gross hack http://people.freebsd.org/~maxim/diff/bridge.diff to work around all these bugs but I still can't figure how to fix them properly. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFR: bridge locking
[ CC: trimmed ] On Wed, 20 Aug 2003, 14:52-0300, Daniel C. Sobral wrote: [...] > If you get bridge to send/receive packets to/from vlan interfaces > attached to them, I'll be forever grateful. > > I've been trying to configure a setup where a firewall is connected to > redundant switches, but no solution I found could handle the vlan > attachments. :-( http://people.freebsd.org/~maxim/diff/bridge.diff Let me know if it helps. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFR: bridge locking
On Thu, 21 Aug 2003, 09:21-0300, Daniel C. Sobral wrote: > Maxim Konovalov wrote: > > [ CC: trimmed ] > > > > On Wed, 20 Aug 2003, 14:52-0300, Daniel C. Sobral wrote: > > > > [...] > > > >>If you get bridge to send/receive packets to/from vlan interfaces > >>attached to them, I'll be forever grateful. > >> > >>I've been trying to configure a setup where a firewall is connected to > >>redundant switches, but no solution I found could handle the vlan > >>attachments. :-( > > > > > > http://people.freebsd.org/~maxim/diff/bridge.diff > > > > Let me know if it helps. > > It didn't. > > The test I'm doing is the following: > > kldload bridge > sysctl net.link.ether.bridge=1 > sysctl net.link.ether.bridge_cfg="fxp1 fxp3" > ifconfig fxp1 up > ifconfig fxp3 up > ifconfig vlan0 create > ifconfig vlan0 vlan 999 vlandev fxp1 > ifconfig vlan0 200.220.254.190/26 sysctl net.link.ether.bridge_cfg="vlan0 fxp3" -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw parsing bug
On Thu, 28 Aug 2003, 23:01+0300, Petri Helenius wrote:
>
> ipfw seems to have developed a bug lately on 5-CURRENT;
> # ipfw add 2042 allow tcp from 0.0.0.0/0 to me
> 42
> 02042 allow tcp from me to me dst-port 42
>
> It used to work that 0.0.0.0/0 was "any" instead of "me". Last I checked
> the notation is also widely used in networking gear for default route which
> is a "catch any" definition.
Known ipfw2 bug. Try this:
Index: ipfw2.c
===
RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v
retrieving revision 1.38
diff -u -r1.38 ipfw2.c
--- ipfw2.c 21 Jul 2003 09:56:05 - 1.38
+++ ipfw2.c 28 Jul 2003 15:51:26 -
@@ -2046,7 +2046,7 @@
errx(EX_DATAERR, "not any never matches");
}
/* else do nothing and skip this entry */
- continue;
+ return;
}
/* A single IP can be stored in an optimized format */
if (d[1] == IP_MASK_ALL && av == NULL && len == 0) {
%%%
--
Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
