s 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
T
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
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
Res
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://ww
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
y.
>
> 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]"
f(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/
ooked 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
-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]"
nding 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
tem 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
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
> > 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 even
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 tc
o 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 ma
e 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 devic
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-CURRE
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
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.
> >
>
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,
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:
>
>To unsubscribe, send any mail to
> > "[EMAIL PROTECTED]"
> > >
> > >
> >
> > ___
> > [EMAIL PROTECTED] mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe,
nd 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]"
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]"
th 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]"
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://ww
nd 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 follo
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 his
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-
ercent, 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,
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: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
ine 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
___
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]"
2471 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 w
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
ting 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 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 appropri
gth 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?
n 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]"
et/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
produce 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]"
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/
'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]"
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 maili
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
> > co
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]"
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]"
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
rking 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.freeb
sockopt() 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
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.fre
opt == 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
[...]
> 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
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]"
,7 @@
} else
reply(504, "Form must be N.");
break;
-
+#endif
case TYPE_E:
rgv, "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.freebs
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&qu
omeone 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
--
M
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:
> 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
>
e 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
gt;ac_if.if_unit);
> - else {
> + } else {
> log(LOG_ERR,
> "arp: %6D attempts to modify permanent entry
> for %s on %s%d\n",
> ea->arp_sh
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 mach
vers 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 (
.. 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
ing? 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
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
&
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 parti
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
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
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 Unsu
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
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
paddr) == 0)
continue;
cp[IPOPT_OFFSET] += sizeof(struct in_addr);
+ off += sizeof(struct in_addr);
break;
default:
%%%
Any objections?
--
Maxim Konovalov, MAcomnet, Internet De
on 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
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 p
ernal:
- 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
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
en < 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]"
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
ives 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
_
y (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]"
[...]
> 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 Konova
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 explicit
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
s 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
> > ...
sk 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
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 "uns
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 Konova
: 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(
pd 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]"
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))) {
/*
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
/*
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 PROT
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!
--
Ma
f_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
edundant 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 l
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
}
/* 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 P
1 - 100 of 116 matches
Mail list logo
