From owner-freebsd-net@FreeBSD.ORG Sun May 30 08:05:52 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94ADF1065672; Sun, 30 May 2010 08:05:52 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 987C38FC12; Sun, 30 May 2010 08:05:51 +0000 (UTC) Received: by fxm5 with SMTP id 5so1420302fxm.13 for ; Sun, 30 May 2010 01:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=AznhJTisRLZ/ysxxf7xXKYC1RAtsJMCDrhlHzNPgrUg=; b=DDZyT7mlm248LrJyKT3lS/uw4Au6G4RdJnnFnt/P4qPwMtGg3DwrBWMDMJDCxyxRQn qQw4Oc2w+IGl20Tgsk9vyfVv0EoPwu67JDP0V+rypqPSerxXTzScl8ZZwtkfdtdvYtD9 oZZ0x8pws0mRSOZCSCoIYz5oeMyjf2/vtUp4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=g86hY+vIXBMmomL+zm14rULBxh/+Vu/KJIf/Zcit1IqvFR7hUgQsLG8HBsiK1Aw5NP hCF8YrJ4T+41y1xLlls7+HL6rA7sIpp/mnTLEtky0DgsSqgFZJFmVNU9/os6+ZzJ9Om8 ir4QPTdNpvkpY4qnOEwfb6tAG2tn0DixIbNLg= Received: by 10.223.31.136 with SMTP id y8mr3412811fac.19.1275206750336; Sun, 30 May 2010 01:05:50 -0700 (PDT) Received: from localhost ([95.69.167.97]) by mx.google.com with ESMTPS id y12sm28152916faj.17.2010.05.30.01.05.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 30 May 2010 01:05:48 -0700 (PDT) From: Mikolaj Golub To: freebsd-net@FreeBSD.org References: <201005280440.o4S4e3sM052201@freefall.freebsd.org> <86mxvkqsvq.fsf@zhuzha.ua1> Date: Sun, 30 May 2010 11:05:45 +0300 In-Reply-To: <86mxvkqsvq.fsf@zhuzha.ua1> (Mikolaj Golub's message of "Fri, 28 May 2010 12:26:33 +0300") Message-ID: <86eigt4xwm.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: "Robert N. M. Watson" , "Lavrentiev, Anton \(NIH/NLM/NCBI\) \[C\]" , bug-followup@FreeBSD.org Subject: Re: kern/146845: [libc] close(2) returns error 54 (connection reset by peer) wrongly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 May 2010 08:05:52 -0000 --=-=-= On Fri, 28 May 2010 04:40:03 GMT Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: > IMHO, it is not, unfortunately, a solution: it seems to clear ECONNRESET > blindly and w/o distinguishing the situation when the remote end closes the > connection prematurely (i.e. before acknowledging all data written from the > local end) -- and that qualifies for the true "connection reset by peer" > from close()... I did some experiments the results I would like to share here. The idea is following: the client sends data in one write() more then a win, while the server closes the connection without reading (sending RST on close). I also played with LINGER option. I have managed to get ECONNRESET only on write(), if the server sends RST before the client calls write(). In all other cases write()/close() returned without error. See the attachment for details. So I think that with the workaround (ignore ECONNRESET returned by sodisconnect() in soclose()) we would not make the situation worse (while it fixed the issue with applications getting unexpectedly ECONNRESET after shutdown()/close() sequence). -- Mikolaj Golub --=-=-= Content-Type: application/octet-stream Content-Disposition: attachment; filename=test_tcp_close.c Content-Transfer-Encoding: base64 I2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lzL3NvY2tldC5oPgojaW5jbHVkZSA8 bmV0aW5ldC9pbi5oPgojaW5jbHVkZSA8c2lnbmFsLmg+CiNpbmNsdWRlIDxzdGRpby5oPgojaW5j bHVkZSA8c3RyaW5nLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHVuaXN0ZC5oPgoj aW5jbHVkZSA8ZXJyLmg+CgojZGVmaW5lIEJVRlNJWkUJNDA5NjAwCiNkZWZpbmUgUE9SVAkyMzQ4 MQojZGVmaW5lIFNMRUVQMQkwCiNkZWZpbmUgU0xFRVAyCTEKI3VuZGVmIExJTkdFUl9JTl9DTElF TlQKI3VuZGVmIExJTkdFUl9JTl9TRVJWRVIKCmludAptYWluKGludCBhcmdjLCBjaGFyICoqYXJn dikKewoJc3RydWN0IHNvY2thZGRyX2luIHNpbjsKCWludCBsaXN0ZW5mZCwgY29ubmZkLCBwaWQ7 CgljaGFyIGJ1ZltCVUZTSVpFXTsKI2lmZGVmIExJTkdFUl9JTl9DTElFTlQKCXN0cnVjdCBsaW5n ZXIgbGluZzsKI2Vsc2UKI2lmZGVmIExJTkdFUl9JTl9TRVJWRVIKCXN0cnVjdCBsaW5nZXIgbGlu ZzsKI2VuZGlmCiNlbmRpZiAvKiBMSU5HRVJfSU5fQ0xJRU5UIHx8IExJTkdFUl9JTl9TRVJWRVIg Ki8KCQoJaWYgKChsaXN0ZW5mZCA9IHNvY2tldChBRl9JTkVULCBTT0NLX1NUUkVBTSwgMCkpIDwg MCkKCQllcnIoMSwgInNvY2tldCBlcnJvciIpOwoJbWVtc2V0KCZzaW4sIDAsIHNpemVvZihzaW4p KTsKCXNpbi5zaW5fZmFtaWx5ID0gQUZfSU5FVDsKCXNpbi5zaW5fcG9ydCA9IGh0b25zKFBPUlQp OwoJaWYgKGJpbmQobGlzdGVuZmQsIChzdHJ1Y3Qgc29ja2FkZHIgKikgJnNpbiwKCQkgc2l6ZW9m KHNpbikpIDwgMCkKCQllcnIoMSwgImJpbmQgZXJyb3IiKTsKCWlmIChsaXN0ZW4obGlzdGVuZmQs IDEwMjQpIDwgMCkKCQllcnIoMSwgImxpc3RlbiBlcnJvciIpOwoJcGlkID0gZm9yaygpOwoJaWYg KHBpZCA9PSAtMSkKCQllcnIoMSwgImZvcmsgZXJyb3IiKTsKCWlmIChwaWQgIT0gMCkgewoJCWNs b3NlKGxpc3RlbmZkKTsKCQlzbGVlcCgxKTsKCQlpZiAoKGNvbm5mZCA9IHNvY2tldChBRl9JTkVU LCBTT0NLX1NUUkVBTSwgMCkpIDwgMCkgewoJCQkodm9pZClraWxsKHBpZCwgU0lHVEVSTSk7CgkJ CWVycigxLCAicGFyZW50OiBzb2NrZXQgZXJyb3IiKTsKCQl9CgkJaWYgKGNvbm5lY3QoY29ubmZk LCAoc3RydWN0IHNvY2thZGRyICopJnNpbiwKCQkJICAgIHNpemVvZihzaW4pKSA8IDApIHsKCQkJ KHZvaWQpa2lsbChwaWQsIFNJR1RFUk0pOwoJCQllcnIoMSwgInBhcmVudDogY29ubmVjdCBlcnJv ciIpOwoJCX0KI2lmZGVmIExJTkdFUl9JTl9DTElFTlQKCQlsaW5nLmxfb25vZmYgPSAxOwoJCWxp bmcubF9saW5nZXIgPSAxMDsKCQlpZiAoc2V0c29ja29wdChjb25uZmQsIFNPTF9TT0NLRVQsIFNP X0xJTkdFUiwKCQkJICAgICAgICZsaW5nLCBzaXplb2YobGluZykpIDwgMCkKCQkJZXJyKDEsICJw YXJlbnQ6IHNldHNvY2tvcHQgZXJyb3IiKTsKI2VuZGlmIC8qIExJTkdFUl9JTl9DTElFTlQgKi8K CQlzbGVlcChTTEVFUDEpOwoJCWlmICh3cml0ZShjb25uZmQsIGJ1ZiwgQlVGU0laRSkgPCAwKSB7 CgkJCSh2b2lkKWtpbGwocGlkLCBTSUdURVJNKTsKCQkJZXJyKDEsICJwYXJlbnQ6IHdyaXRlIGVy cm9yIik7CgkJfQoJCWlmIChjbG9zZShjb25uZmQpIDwgMCkgewoJCQkodm9pZClraWxsKHBpZCwg U0lHVEVSTSk7CgkJCWVycigxLCAicGFyZW50OiBjbG9zZSBlcnJvciIpOwoJCX0KCX0gZWxzZSB7 CgkJaWYgKChjb25uZmQgPSBhY2NlcHQobGlzdGVuZmQsIChzdHJ1Y3Qgc29ja2FkZHIgKilOVUxM LAoJCQkJICAgICBOVUxMKSkgPCAwKQoJCQllcnIoMSwgImNoaWxkOiBhY2NlcHQgZXJyb3IiKTsK I2lmZGVmIExJTkdFUl9JTl9TRVJWRVIJCQoJCS8qCgkJICogU2VuZCBSU1Qgb24gY2xvc2UuCgkJ ICovCgkJbGluZy5sX29ub2ZmID0gMTsKCQlsaW5nLmxfbGluZ2VyID0gMDsJCQoJCWlmIChzZXRz b2Nrb3B0KGNvbm5mZCwgU09MX1NPQ0tFVCwgU09fTElOR0VSLAoJCQkgICAgICAgJmxpbmcsIHNp emVvZihsaW5nKSkgPCAwKQoJCQllcnIoMSwgImNoaWxkOiBzZXRzb2Nrb3B0IGVycm9yIik7CiNl bmRpZiAvKiBMSU5HRVJfSU5fU0VSVkVSICovCgkJc2xlZXAoU0xFRVAyKTsKCQlpZiAoY2xvc2Uo Y29ubmZkKSA8IDApCgkJCWVycigxLCAiY2hpbGQ6IGNsb3NlIGVycm9yIik7Cgl9CglleGl0KDAp Owp9CgojaWYgMAoKU0xFRVAxID0gMDsgU0xFRVAyID0gMDogTElOR0VSX0lOX1NFUlZFUjogcGFy ZW50OiB3cml0ZSBlcnJvcjogQ29ubmVjdGlvbiByZXNldCBieSBwZWVyCjAwOjAwOjAwLjAwMDAw MCBJUCAxMjcuMC4wLjEuMjM4NTEgPiAxMjcuMC4wLjEuMjM0ODE6IEZsYWdzIFtTXSwgc2VxIDMy MzM3NjU5OTMsIHdpbiA2NTUzNSwgb3B0aW9ucyBbbXNzIDE2MzQ0LG5vcCx3c2NhbGUgMyxzYWNr T0ssVFMgdmFsIDI4NjA1OCBlY3IgMF0sIGxlbmd0aCAwCjAwOjAwOjAwLjAwMDA0NCBJUCAxMjcu MC4wLjEuMjM0ODEgPiAxMjcuMC4wLjEuMjM4NTE6IEZsYWdzIFtTLl0sIHNlcSA5MTcwNDkwODcs IGFjayAzMjMzNzY1OTk0LCB3aW4gNjU1MzUsIG9wdGlvbnMgW21zcyAxNjM0NCxub3Asd3NjYWxl IDMsc2Fja09LLFRTIHZhbCAzNDkwMDg1MDA0IGVjciAyODYwNThdLCBsZW5ndGggMAowMDowMDow MC4wMDAwMzQgSVAgMTI3LjAuMC4xLjIzODUxID4gMTI3LjAuMC4xLjIzNDgxOiBGbGFncyBbLl0s IGFjayAxLCB3aW4gODk2MCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgMjg2MDU4IGVjciAzNDkw MDg1MDA0XSwgbGVuZ3RoIDAKMDA6MDA6MDAuMDAwMTkxIElQIDEyNy4wLjAuMS4yMzQ4MSA+IDEy Ny4wLjAuMS4yMzg1MTogRmxhZ3MgW1IuXSwgc2VxIDEsIGFjayAxLCB3aW4gODk2MCwgb3B0aW9u cyBbbm9wLG5vcCxUUyB2YWwgMzQ5MDA4NTAwNCBlY3IgMjg2MDU4XSwgbGVuZ3RoIDAKClNMRUVQ MSA9IDE7IFNMRUVQMiA9IDA6IExJTkdFUl9JTl9TRVJWRVI6IG5vIGVycm9yCjAwOjAwOjAwLjAw MDAwMCBJUCAxMjcuMC4wLjEuMjc1NTggPiAxMjcuMC4wLjEuMjM0ODE6IEZsYWdzIFtTXSwgc2Vx IDQwNDIwNjA4MjEsIHdpbiA2NTUzNSwgb3B0aW9ucyBbbXNzIDE2MzQ0LG5vcCx3c2NhbGUgMyxz YWNrT0ssVFMgdmFsIDI5MTQ2NSBlY3IgMF0sIGxlbmd0aCAwCjAwOjAwOjAwLjAwMDA0MiBJUCAx MjcuMC4wLjEuMjM0ODEgPiAxMjcuMC4wLjEuMjc1NTg6IEZsYWdzIFtTLl0sIHNlcSAyNzg5MzQy NTc3LCBhY2sgNDA0MjA2MDgyMiwgd2luIDY1NTM1LCBvcHRpb25zIFttc3MgMTYzNDQsbm9wLHdz Y2FsZSAzLHNhY2tPSyxUUyB2YWwgMTk1OTQxNzYxMSBlY3IgMjkxNDY1XSwgbGVuZ3RoIDAKMDA6 MDA6MDAuMDAwMDM0IElQIDEyNy4wLjAuMS4yNzU1OCA+IDEyNy4wLjAuMS4yMzQ4MTogRmxhZ3Mg Wy5dLCBhY2sgMSwgd2luIDg5NjAsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFsIDI5MTQ2NSBlY3Ig MTk1OTQxNzYxMV0sIGxlbmd0aCAwCjAwOjAwOjAwLjAwMDE3MyBJUCAxMjcuMC4wLjEuMjM0ODEg PiAxMjcuMC4wLjEuMjc1NTg6IEZsYWdzIFtSLl0sIHNlcSAxLCBhY2sgMSwgd2luIDg5NjAsIG9w dGlvbnMgW25vcCxub3AsVFMgdmFsIDE5NTk0MTc2MTEgZWNyIDI5MTQ2NV0sIGxlbmd0aCAwCgpT TEVFUDEgPSAwOyBTTEVFUDIgPSAxOiBMSU5HRVJfSU5fU0VSVkVSOiBubyBlcnJvcgowMDowMDow MC4wMDAwMDAgSVAgMTI3LjAuMC4xLjY0MTg0ID4gMTI3LjAuMC4xLjIzNDgxOiBGbGFncyBbU10s IHNlcSA3MzU3NjE0MTEsIHdpbiA2NTUzNSwgb3B0aW9ucyBbbXNzIDE2MzQ0LG5vcCx3c2NhbGUg MyxzYWNrT0ssVFMgdmFsIDI5OTc5MiBlY3IgMF0sIGxlbmd0aCAwCjAwOjAwOjAwLjAwMDA0OSBJ UCAxMjcuMC4wLjEuMjM0ODEgPiAxMjcuMC4wLjEuNjQxODQ6IEZsYWdzIFtTLl0sIHNlcSAxNzYx NzY4MDU1LCBhY2sgNzM1NzYxNDEyLCB3aW4gNjU1MzUsIG9wdGlvbnMgW21zcyAxNjM0NCxub3As d3NjYWxlIDMsc2Fja09LLFRTIHZhbCAxMTgyMDg5NjY3IGVjciAyOTk3OTJdLCBsZW5ndGggMAow MDowMDowMC4wMDAwMzUgSVAgMTI3LjAuMC4xLjY0MTg0ID4gMTI3LjAuMC4xLjIzNDgxOiBGbGFn cyBbLl0sIGFjayAxLCB3aW4gODk2MCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgMjk5NzkyIGVj ciAxMTgyMDg5NjY3XSwgbGVuZ3RoIDAKMDA6MDA6MDAuMDAwMjIyIElQIDEyNy4wLjAuMS42NDE4 NCA+IDEyNy4wLjAuMS4yMzQ4MTogRmxhZ3MgWy5dLCBhY2sgMSwgd2luIDg5NjAsIG9wdGlvbnMg W25vcCxub3AsVFMgdmFsIDI5OTc5MiBlY3IgMTE4MjA4OTY2N10sIGxlbmd0aCAxNDMzNgowMDow MDowMC4wOTkzOTYgSVAgMTI3LjAuMC4xLjIzNDgxID4gMTI3LjAuMC4xLjY0MTg0OiBGbGFncyBb Ll0sIGFjayAxNDMzNywgd2luIDcxNjgsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFsIDExODIwODk2 NzcgZWNyIDI5OTc5Ml0sIGxlbmd0aCAwCjAwOjAwOjAwLjAwMDA0NyBJUCAxMjcuMC4wLjEuNjQx ODQgPiAxMjcuMC4wLjEuMjM0ODE6IEZsYWdzIFsuXSwgYWNrIDEsIHdpbiA4OTYwLCBvcHRpb25z IFtub3Asbm9wLFRTIHZhbCAyOTk4MDIgZWNyIDExODIwODk2NzddLCBsZW5ndGggMTQzMzYKMDA6 MDA6MDAuMDAwMDE0IElQIDEyNy4wLjAuMS42NDE4NCA+IDEyNy4wLjAuMS4yMzQ4MTogRmxhZ3Mg W1AuXSwgYWNrIDEsIHdpbiA4OTYwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAyOTk4MDIgZWNy IDExODIwODk2NzddLCBsZW5ndGggMTQzMzYKMDA6MDA6MDAuMDAwMDQ3IElQIDEyNy4wLjAuMS4y MzQ4MSA+IDEyNy4wLjAuMS42NDE4NDogRmxhZ3MgWy5dLCBhY2sgNDMwMDksIHdpbiAzNTg0LCBv cHRpb25zIFtub3Asbm9wLFRTIHZhbCAxMTgyMDg5Njc3IGVjciAyOTk4MDJdLCBsZW5ndGggMAow MDowMDowMC4wMDAxMTUgSVAgMTI3LjAuMC4xLjY0MTg0ID4gMTI3LjAuMC4xLjIzNDgxOiBGbGFn cyBbUC5dLCBhY2sgMSwgd2luIDg5NjAsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFsIDI5OTgwMiBl Y3IgMTE4MjA4OTY3N10sIGxlbmd0aCAxNDMzNgowMDowMDowMC4wMDAxNTUgSVAgMTI3LjAuMC4x LjY0MTg0ID4gMTI3LjAuMC4xLjIzNDgxOiBGbGFncyBbLl0sIGFjayAxLCB3aW4gODk2MCwgb3B0 aW9ucyBbbm9wLG5vcCxUUyB2YWwgMjk5ODAyIGVjciAxMTgyMDg5Njc3XSwgbGVuZ3RoIDE0MzM2 CjAwOjAwOjAwLjAwMDAxOSBJUCAxMjcuMC4wLjEuMjM0ODEgPiAxMjcuMC4wLjEuNjQxODQ6IEZs YWdzIFsuXSwgYWNrIDcxNjgxLCB3aW4gMCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgMTE4MjA4 OTY3NyBlY3IgMjk5ODAyXSwgbGVuZ3RoIDAKMDA6MDA6MDAuOTA5NjQ4IElQIDEyNy4wLjAuMS4y MzQ4MSA+IDEyNy4wLjAuMS42NDE4NDogRmxhZ3MgW1IuXSwgc2VxIDEsIGFjayA3MTY4MSwgd2lu IDAsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFsIDExODIwODk3NjggZWNyIDI5OTgwMl0sIGxlbmd0 aCAwCgpTTEVFUDEgPSAwOyBTTEVFUDIgPSAxOiBMSU5HRVJfSU5fU0VSVkVSOiBMSU5HRVJfSU5f Q0xJRU5UOiBubyBlcnJvcgowMDowMDowMC4wMDAwMDAgSVAgMTI3LjAuMC4xLjYyNTM1ID4gMTI3 LjAuMC4xLjIzNDgxOiBGbGFncyBbU10sIHNlcSAyNDE2MzExNjU4LCB3aW4gNjU1MzUsIG9wdGlv bnMgW21zcyAxNjM0NCxub3Asd3NjYWxlIDMsc2Fja09LLFRTIHZhbCAzMDU1NjcgZWNyIDBdLCBs ZW5ndGggMAowMDowMDowMC4wMDAwNjMgSVAgMTI3LjAuMC4xLjIzNDgxID4gMTI3LjAuMC4xLjYy NTM1OiBGbGFncyBbUy5dLCBzZXEgNzIzMjQxMDczLCBhY2sgMjQxNjMxMTY1OSwgd2luIDY1NTM1 LCBvcHRpb25zIFttc3MgMTYzNDQsbm9wLHdzY2FsZSAzLHNhY2tPSyxUUyB2YWwgOTUzNDY0Mjkg ZWNyIDMwNTU2N10sIGxlbmd0aCAwCjAwOjAwOjAwLjAwMDAzMyBJUCAxMjcuMC4wLjEuNjI1MzUg PiAxMjcuMC4wLjEuMjM0ODE6IEZsYWdzIFsuXSwgYWNrIDEsIHdpbiA4OTYwLCBvcHRpb25zIFtu b3Asbm9wLFRTIHZhbCAzMDU1NjcgZWNyIDk1MzQ2NDI5XSwgbGVuZ3RoIDAKMDA6MDA6MDAuMDAw MjY2IElQIDEyNy4wLjAuMS42MjUzNSA+IDEyNy4wLjAuMS4yMzQ4MTogRmxhZ3MgWy5dLCBhY2sg MSwgd2luIDg5NjAsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFsIDMwNTU2NyBlY3IgOTUzNDY0Mjld LCBsZW5ndGggMTQzMzYKMDA6MDA6MDAuMDAwMDE5IElQIDEyNy4wLjAuMS42MjUzNSA+IDEyNy4w LjAuMS4yMzQ4MTogRmxhZ3MgWy5dLCBhY2sgMSwgd2luIDg5NjAsIG9wdGlvbnMgW25vcCxub3As VFMgdmFsIDMwNTU2NyBlY3IgOTUzNDY0MjldLCBsZW5ndGggMTQzMzYKMDA6MDA6MDAuMDAwMDE1 IElQIDEyNy4wLjAuMS42MjUzNSA+IDEyNy4wLjAuMS4yMzQ4MTogRmxhZ3MgW1AuXSwgYWNrIDEs IHdpbiA4OTYwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAzMDU1NjcgZWNyIDk1MzQ2NDI5XSwg bGVuZ3RoIDE0MzM2CjAwOjAwOjAwLjAwMDAwNCBJUCAxMjcuMC4wLjEuMjM0ODEgPiAxMjcuMC4w LjEuNjI1MzU6IEZsYWdzIFsuXSwgYWNrIDI4NjczLCB3aW4gNTM3Niwgb3B0aW9ucyBbbm9wLG5v cCxUUyB2YWwgOTUzNDY0MjkgZWNyIDMwNTU2N10sIGxlbmd0aCAwCjAwOjAwOjAwLjAwMDE3OSBJ UCAxMjcuMC4wLjEuNjI1MzUgPiAxMjcuMC4wLjEuMjM0ODE6IEZsYWdzIFsuXSwgYWNrIDEsIHdp biA4OTYwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAzMDU1NjcgZWNyIDk1MzQ2NDI5XSwgbGVu Z3RoIDE0MzM2CjAwOjAwOjAwLjAwMDAxNSBJUCAxMjcuMC4wLjEuNjI1MzUgPiAxMjcuMC4wLjEu MjM0ODE6IEZsYWdzIFsuXSwgYWNrIDEsIHdpbiA4OTYwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZh bCAzMDU1NjcgZWNyIDk1MzQ2NDI5XSwgbGVuZ3RoIDE0MzM2CjAwOjAwOjAwLjAwMDAwOCBJUCAx MjcuMC4wLjEuMjM0ODEgPiAxMjcuMC4wLjEuNjI1MzU6IEZsYWdzIFsuXSwgYWNrIDU3MzQ1LCB3 aW4gMTc5Miwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgOTUzNDY0MjkgZWNyIDMwNTU2N10sIGxl bmd0aCAwCjAwOjAwOjAwLjA5OTMxNyBJUCAxMjcuMC4wLjEuMjM0ODEgPiAxMjcuMC4wLjEuNjI1 MzU6IEZsYWdzIFsuXSwgYWNrIDcxNjgxLCB3aW4gMCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwg OTUzNDY0MzkgZWNyIDMwNTU2N10sIGxlbmd0aCAwCjAwOjAwOjAwLjkxMDAzOSBJUCAxMjcuMC4w LjEuMjM0ODEgPiAxMjcuMC4wLjEuNjI1MzU6IEZsYWdzIFtSLl0sIHNlcSAxLCBhY2sgNzE2ODEs IHdpbiAwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCA5NTM0NjUzMCBlY3IgMzA1NTY3XSwgbGVu Z3RoIDAKClNMRUVQMSA9IDA7IFNMRUVQMiA9IDE6IExJTkdFUl9JTl9DTElFTlQ6IG5vIGVycm9y CjAwOjAwOjAwLjAwMDAwMCBJUCAxMjcuMC4wLjEuNTIyMzIgPiAxMjcuMC4wLjEuMjM0ODE6IEZs YWdzIFtTXSwgc2VxIDgzNzc0ODQyOSwgd2luIDY1NTM1LCBvcHRpb25zIFttc3MgMTYzNDQsbm9w LHdzY2FsZSAzLHNhY2tPSyxUUyB2YWwgMzA5NjM5IGVjciAwXSwgbGVuZ3RoIDAKMDA6MDA6MDAu MDAwMDQ0IElQIDEyNy4wLjAuMS4yMzQ4MSA+IDEyNy4wLjAuMS41MjIzMjogRmxhZ3MgW1MuXSwg c2VxIDEyNjE2MTQ3MDcsIGFjayA4Mzc3NDg0MzAsIHdpbiA2NTUzNSwgb3B0aW9ucyBbbXNzIDE2 MzQ0LG5vcCx3c2NhbGUgMyxzYWNrT0ssVFMgdmFsIDMxMjYxMDY5NTcgZWNyIDMwOTYzOV0sIGxl bmd0aCAwCjAwOjAwOjAwLjAwMDAzNCBJUCAxMjcuMC4wLjEuNTIyMzIgPiAxMjcuMC4wLjEuMjM0 ODE6IEZsYWdzIFsuXSwgYWNrIDEsIHdpbiA4OTYwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAz MDk2MzkgZWNyIDMxMjYxMDY5NTddLCBsZW5ndGggMAowMDowMDowMC4wMDAyNDkgSVAgMTI3LjAu MC4xLjUyMjMyID4gMTI3LjAuMC4xLjIzNDgxOiBGbGFncyBbLl0sIGFjayAxLCB3aW4gODk2MCwg b3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgMzA5NjM5IGVjciAzMTI2MTA2OTU3XSwgbGVuZ3RoIDE0 MzM2CjAwOjAwOjAwLjAwMDAxOCBJUCAxMjcuMC4wLjEuNTIyMzIgPiAxMjcuMC4wLjEuMjM0ODE6 IEZsYWdzIFsuXSwgYWNrIDEsIHdpbiA4OTYwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAzMDk2 MzkgZWNyIDMxMjYxMDY5NTddLCBsZW5ndGggMTQzMzYKMDA6MDA6MDAuMDAwMDE5IElQIDEyNy4w LjAuMS4yMzQ4MSA+IDEyNy4wLjAuMS41MjIzMjogRmxhZ3MgWy5dLCBhY2sgMjg2NzMsIHdpbiA1 Mzc2LCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAzMTI2MTA2OTU3IGVjciAzMDk2MzldLCBsZW5n dGggMAowMDowMDowMC4wMDAwMjggSVAgMTI3LjAuMC4xLjUyMjMyID4gMTI3LjAuMC4xLjIzNDgx OiBGbGFncyBbUC5dLCBhY2sgMSwgd2luIDg5NjAsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFsIDMw OTYzOSBlY3IgMzEyNjEwNjk1N10sIGxlbmd0aCAxNDMzNgowMDowMDowMC4wMDAxNDMgSVAgMTI3 LjAuMC4xLjUyMjMyID4gMTI3LjAuMC4xLjIzNDgxOiBGbGFncyBbLl0sIGFjayAxLCB3aW4gODk2 MCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgMzA5NjM5IGVjciAzMTI2MTA2OTU3XSwgbGVuZ3Ro IDE0MzM2CjAwOjAwOjAwLjAwMDAxNSBJUCAxMjcuMC4wLjEuNTIyMzIgPiAxMjcuMC4wLjEuMjM0 ODE6IEZsYWdzIFsuXSwgYWNrIDEsIHdpbiA4OTYwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAz MDk2MzkgZWNyIDMxMjYxMDY5NTddLCBsZW5ndGggMTQzMzYKMDA6MDA6MDAuMDAwMDA3IElQIDEy Ny4wLjAuMS4yMzQ4MSA+IDEyNy4wLjAuMS41MjIzMjogRmxhZ3MgWy5dLCBhY2sgNTczNDUsIHdp biAxNzkyLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAzMTI2MTA2OTU3IGVjciAzMDk2MzldLCBs ZW5ndGggMAowMDowMDowMC4wOTkzNzEgSVAgMTI3LjAuMC4xLjIzNDgxID4gMTI3LjAuMC4xLjUy MjMyOiBGbGFncyBbLl0sIGFjayA3MTY4MSwgd2luIDAsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFs IDMxMjYxMDY5NjcgZWNyIDMwOTYzOV0sIGxlbmd0aCAwCjAwOjAwOjAwLjkxMDExNCBJUCAxMjcu MC4wLjEuMjM0ODEgPiAxMjcuMC4wLjEuNTIyMzI6IEZsYWdzIFtGLl0sIHNlcSAxLCBhY2sgNzE2 ODEsIHdpbiA4OTYwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAzMTI2MTA3MDU4IGVjciAzMDk2 MzldLCBsZW5ndGggMAowMDowMDowMC4wMDAwNDQgSVAgMTI3LjAuMC4xLjUyMjMyID4gMTI3LjAu MC4xLjIzNDgxOiBGbGFncyBbLl0sIGFjayAyLCB3aW4gODk2MCwgb3B0aW9ucyBbbm9wLG5vcCxU UyB2YWwgMzA5NzQwIGVjciAzMTI2MTA3MDU4XSwgbGVuZ3RoIDE0MzM2CjAwOjAwOjAwLjAwMDAx NCBJUCAxMjcuMC4wLjEuNTIyMzIgPiAxMjcuMC4wLjEuMjM0ODE6IEZsYWdzIFsuXSwgYWNrIDIs IHdpbiA4OTYwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAzMDk3NDAgZWNyIDMxMjYxMDcwNThd LCBsZW5ndGggMTQzMzYKMDA6MDA6MDAuMDAwMDM1IElQIDEyNy4wLjAuMS4yMzQ4MSA+IDEyNy4w LjAuMS41MjIzMjogRmxhZ3MgW1JdLCBzZXEgMTI2MTYxNDcwOSwgd2luIDAsIGxlbmd0aCAwCjAw OjAwOjAwLjAwMDAxOSBJUCAxMjcuMC4wLjEuMjM0ODEgPiAxMjcuMC4wLjEuNTIyMzI6IEZsYWdz IFtSXSwgc2VxIDEyNjE2MTQ3MDksIHdpbiAwLCBsZW5ndGggMAoKU0xFRVAxID0gMDsgU0xFRVAy ID0gMTogbm8gZXJyb3IKMDA6MDA6MDAuMDAwMDAwIElQIDEyNy4wLjAuMS4yNTg2NSA+IDEyNy4w LjAuMS4yMzQ4MTogRmxhZ3MgW1NdLCBzZXEgMzg2MzE4NzEwLCB3aW4gNjU1MzUsIG9wdGlvbnMg W21zcyAxNjM0NCxub3Asd3NjYWxlIDMsc2Fja09LLFRTIHZhbCAzMTM4MjggZWNyIDBdLCBsZW5n dGggMAowMDowMDowMC4wMDAwNDggSVAgMTI3LjAuMC4xLjIzNDgxID4gMTI3LjAuMC4xLjI1ODY1 OiBGbGFncyBbUy5dLCBzZXEgMzAxMjQ5NTk5OSwgYWNrIDM4NjMxODcxMSwgd2luIDY1NTM1LCBv cHRpb25zIFttc3MgMTYzNDQsbm9wLHdzY2FsZSAzLHNhY2tPSyxUUyB2YWwgNjI5MTQ1NDkwIGVj ciAzMTM4MjhdLCBsZW5ndGggMAowMDowMDowMC4wMDAwMzQgSVAgMTI3LjAuMC4xLjI1ODY1ID4g MTI3LjAuMC4xLjIzNDgxOiBGbGFncyBbLl0sIGFjayAxLCB3aW4gODk2MCwgb3B0aW9ucyBbbm9w LG5vcCxUUyB2YWwgMzEzODI4IGVjciA2MjkxNDU0OTBdLCBsZW5ndGggMAowMDowMDowMC4wMDAy MTkgSVAgMTI3LjAuMC4xLjI1ODY1ID4gMTI3LjAuMC4xLjIzNDgxOiBGbGFncyBbLl0sIGFjayAx LCB3aW4gODk2MCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgMzEzODI4IGVjciA2MjkxNDU0OTBd LCBsZW5ndGggMTQzMzYKMDA6MDA6MDAuMDAwMDE3IElQIDEyNy4wLjAuMS4yNTg2NSA+IDEyNy4w LjAuMS4yMzQ4MTogRmxhZ3MgWy5dLCBhY2sgMSwgd2luIDg5NjAsIG9wdGlvbnMgW25vcCxub3As VFMgdmFsIDMxMzgyOCBlY3IgNjI5MTQ1NDkwXSwgbGVuZ3RoIDE0MzM2CjAwOjAwOjAwLjAwMDAx NSBJUCAxMjcuMC4wLjEuMjU4NjUgPiAxMjcuMC4wLjEuMjM0ODE6IEZsYWdzIFtQLl0sIGFjayAx LCB3aW4gODk2MCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgMzEzODI4IGVjciA2MjkxNDU0OTBd LCBsZW5ndGggMTQzMzYKMDA6MDA6MDAuMDAwMDA1IElQIDEyNy4wLjAuMS4yMzQ4MSA+IDEyNy4w LjAuMS4yNTg2NTogRmxhZ3MgWy5dLCBhY2sgMjg2NzMsIHdpbiA1Mzc2LCBvcHRpb25zIFtub3As bm9wLFRTIHZhbCA2MjkxNDU0OTAgZWNyIDMxMzgyOF0sIGxlbmd0aCAwCjAwOjAwOjAwLjAwMDE3 NSBJUCAxMjcuMC4wLjEuMjU4NjUgPiAxMjcuMC4wLjEuMjM0ODE6IEZsYWdzIFsuXSwgYWNrIDEs IHdpbiA4OTYwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAzMTM4MjggZWNyIDYyOTE0NTQ5MF0s IGxlbmd0aCAxNDMzNgowMDowMDowMC4wMDAwMTYgSVAgMTI3LjAuMC4xLjI1ODY1ID4gMTI3LjAu MC4xLjIzNDgxOiBGbGFncyBbLl0sIGFjayAxLCB3aW4gODk2MCwgb3B0aW9ucyBbbm9wLG5vcCxU UyB2YWwgMzEzODI4IGVjciA2MjkxNDU0OTBdLCBsZW5ndGggMTQzMzYKMDA6MDA6MDAuMDAwMDA3 IElQIDEyNy4wLjAuMS4yMzQ4MSA+IDEyNy4wLjAuMS4yNTg2NTogRmxhZ3MgWy5dLCBhY2sgNTcz NDUsIHdpbiAxNzkyLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCA2MjkxNDU0OTAgZWNyIDMxMzgy OF0sIGxlbmd0aCAwCjAwOjAwOjAwLjA5OTM5NCBJUCAxMjcuMC4wLjEuMjM0ODEgPiAxMjcuMC4w LjEuMjU4NjU6IEZsYWdzIFsuXSwgYWNrIDcxNjgxLCB3aW4gMCwgb3B0aW9ucyBbbm9wLG5vcCxU UyB2YWwgNjI5MTQ1NTAwIGVjciAzMTM4MjhdLCBsZW5ndGggMAowMDowMDowMC45MTAxMzUgSVAg MTI3LjAuMC4xLjIzNDgxID4gMTI3LjAuMC4xLjI1ODY1OiBGbGFncyBbRi5dLCBzZXEgMSwgYWNr IDcxNjgxLCB3aW4gODk2MCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgNjI5MTQ1NTkxIGVjciAz MTM4MjhdLCBsZW5ndGggMAowMDowMDowMC4wMDAwNjkgSVAgMTI3LjAuMC4xLjI1ODY1ID4gMTI3 LjAuMC4xLjIzNDgxOiBGbGFncyBbLl0sIGFjayAyLCB3aW4gODk2MCwgb3B0aW9ucyBbbm9wLG5v cCxUUyB2YWwgMzEzOTI5IGVjciA2MjkxNDU1OTFdLCBsZW5ndGggMTQzMzYKMDA6MDA6MDAuMDAw MDE0IElQIDEyNy4wLjAuMS4yNTg2NSA+IDEyNy4wLjAuMS4yMzQ4MTogRmxhZ3MgWy5dLCBhY2sg Miwgd2luIDg5NjAsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFsIDMxMzkyOSBlY3IgNjI5MTQ1NTkx XSwgbGVuZ3RoIDE0MzM2CjAwOjAwOjAwLjAwMDAzNSBJUCAxMjcuMC4wLjEuMjM0ODEgPiAxMjcu MC4wLjEuMjU4NjU6IEZsYWdzIFtSXSwgc2VxIDMwMTI0OTYwMDEsIHdpbiAwLCBsZW5ndGggMAow MDowMDowMC4wMDAwMTkgSVAgMTI3LjAuMC4xLjIzNDgxID4gMTI3LjAuMC4xLjI1ODY1OiBGbGFn cyBbUl0sIHNlcSAzMDEyNDk2MDAxLCB3aW4gMCwgbGVuZ3RoIDAKCQkgICAgCiNlbmRpZiAvKiAw ICovCg== --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Sun May 30 08:10:10 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DD37106566B for ; Sun, 30 May 2010 08:10:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1BE628FC0A for ; Sun, 30 May 2010 08:10:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4U8A99l004951 for ; Sun, 30 May 2010 08:10:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4U8A9fm004950; Sun, 30 May 2010 08:10:09 GMT (envelope-from gnats) Date: Sun, 30 May 2010 08:10:09 GMT Message-Id: <201005300810.o4U8A9fm004950@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Mikolaj Golub Cc: Subject: Re: kern/146845: [libc] close(2) returns error 54 (connection reset by peer) wrongly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mikolaj Golub List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 May 2010 08:10:10 -0000 The following reply was made to PR kern/146845; it has been noted by GNATS. From: Mikolaj Golub To: freebsd-net@FreeBSD.org Cc: "Lavrentiev\, Anton \(NIH\/NLM\/NCBI\) \[C\]" , "Robert N. M. Watson" , bug-followup@FreeBSD.org Subject: Re: kern/146845: [libc] close(2) returns error 54 (connection reset by peer) wrongly Date: Sun, 30 May 2010 11:05:45 +0300 --=-=-= On Fri, 28 May 2010 04:40:03 GMT Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: > IMHO, it is not, unfortunately, a solution: it seems to clear ECONNRESET > blindly and w/o distinguishing the situation when the remote end closes the > connection prematurely (i.e. before acknowledging all data written from the > local end) -- and that qualifies for the true "connection reset by peer" > from close()... I did some experiments the results I would like to share here. The idea is following: the client sends data in one write() more then a win, while the server closes the connection without reading (sending RST on close). I also played with LINGER option. I have managed to get ECONNRESET only on write(), if the server sends RST before the client calls write(). In all other cases write()/close() returned without error. See the attachment for details. So I think that with the workaround (ignore ECONNRESET returned by sodisconnect() in soclose()) we would not make the situation worse (while it fixed the issue with applications getting unexpectedly ECONNRESET after shutdown()/close() sequence). -- Mikolaj Golub --=-=-= Content-Type: application/octet-stream Content-Disposition: attachment; filename=test_tcp_close.c Content-Transfer-Encoding: base64 I2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lzL3NvY2tldC5oPgojaW5jbHVkZSA8 bmV0aW5ldC9pbi5oPgojaW5jbHVkZSA8c2lnbmFsLmg+CiNpbmNsdWRlIDxzdGRpby5oPgojaW5j bHVkZSA8c3RyaW5nLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHVuaXN0ZC5oPgoj aW5jbHVkZSA8ZXJyLmg+CgojZGVmaW5lIEJVRlNJWkUJNDA5NjAwCiNkZWZpbmUgUE9SVAkyMzQ4 MQojZGVmaW5lIFNMRUVQMQkwCiNkZWZpbmUgU0xFRVAyCTEKI3VuZGVmIExJTkdFUl9JTl9DTElF TlQKI3VuZGVmIExJTkdFUl9JTl9TRVJWRVIKCmludAptYWluKGludCBhcmdjLCBjaGFyICoqYXJn dikKewoJc3RydWN0IHNvY2thZGRyX2luIHNpbjsKCWludCBsaXN0ZW5mZCwgY29ubmZkLCBwaWQ7 CgljaGFyIGJ1ZltCVUZTSVpFXTsKI2lmZGVmIExJTkdFUl9JTl9DTElFTlQKCXN0cnVjdCBsaW5n ZXIgbGluZzsKI2Vsc2UKI2lmZGVmIExJTkdFUl9JTl9TRVJWRVIKCXN0cnVjdCBsaW5nZXIgbGlu ZzsKI2VuZGlmCiNlbmRpZiAvKiBMSU5HRVJfSU5fQ0xJRU5UIHx8IExJTkdFUl9JTl9TRVJWRVIg Ki8KCQoJaWYgKChsaXN0ZW5mZCA9IHNvY2tldChBRl9JTkVULCBTT0NLX1NUUkVBTSwgMCkpIDwg MCkKCQllcnIoMSwgInNvY2tldCBlcnJvciIpOwoJbWVtc2V0KCZzaW4sIDAsIHNpemVvZihzaW4p KTsKCXNpbi5zaW5fZmFtaWx5ID0gQUZfSU5FVDsKCXNpbi5zaW5fcG9ydCA9IGh0b25zKFBPUlQp OwoJaWYgKGJpbmQobGlzdGVuZmQsIChzdHJ1Y3Qgc29ja2FkZHIgKikgJnNpbiwKCQkgc2l6ZW9m KHNpbikpIDwgMCkKCQllcnIoMSwgImJpbmQgZXJyb3IiKTsKCWlmIChsaXN0ZW4obGlzdGVuZmQs IDEwMjQpIDwgMCkKCQllcnIoMSwgImxpc3RlbiBlcnJvciIpOwoJcGlkID0gZm9yaygpOwoJaWYg KHBpZCA9PSAtMSkKCQllcnIoMSwgImZvcmsgZXJyb3IiKTsKCWlmIChwaWQgIT0gMCkgewoJCWNs b3NlKGxpc3RlbmZkKTsKCQlzbGVlcCgxKTsKCQlpZiAoKGNvbm5mZCA9IHNvY2tldChBRl9JTkVU LCBTT0NLX1NUUkVBTSwgMCkpIDwgMCkgewoJCQkodm9pZClraWxsKHBpZCwgU0lHVEVSTSk7CgkJ CWVycigxLCAicGFyZW50OiBzb2NrZXQgZXJyb3IiKTsKCQl9CgkJaWYgKGNvbm5lY3QoY29ubmZk LCAoc3RydWN0IHNvY2thZGRyICopJnNpbiwKCQkJICAgIHNpemVvZihzaW4pKSA8IDApIHsKCQkJ KHZvaWQpa2lsbChwaWQsIFNJR1RFUk0pOwoJCQllcnIoMSwgInBhcmVudDogY29ubmVjdCBlcnJv ciIpOwoJCX0KI2lmZGVmIExJTkdFUl9JTl9DTElFTlQKCQlsaW5nLmxfb25vZmYgPSAxOwoJCWxp bmcubF9saW5nZXIgPSAxMDsKCQlpZiAoc2V0c29ja29wdChjb25uZmQsIFNPTF9TT0NLRVQsIFNP X0xJTkdFUiwKCQkJICAgICAgICZsaW5nLCBzaXplb2YobGluZykpIDwgMCkKCQkJZXJyKDEsICJw YXJlbnQ6IHNldHNvY2tvcHQgZXJyb3IiKTsKI2VuZGlmIC8qIExJTkdFUl9JTl9DTElFTlQgKi8K CQlzbGVlcChTTEVFUDEpOwoJCWlmICh3cml0ZShjb25uZmQsIGJ1ZiwgQlVGU0laRSkgPCAwKSB7 CgkJCSh2b2lkKWtpbGwocGlkLCBTSUdURVJNKTsKCQkJZXJyKDEsICJwYXJlbnQ6IHdyaXRlIGVy cm9yIik7CgkJfQoJCWlmIChjbG9zZShjb25uZmQpIDwgMCkgewoJCQkodm9pZClraWxsKHBpZCwg U0lHVEVSTSk7CgkJCWVycigxLCAicGFyZW50OiBjbG9zZSBlcnJvciIpOwoJCX0KCX0gZWxzZSB7 CgkJaWYgKChjb25uZmQgPSBhY2NlcHQobGlzdGVuZmQsIChzdHJ1Y3Qgc29ja2FkZHIgKilOVUxM LAoJCQkJICAgICBOVUxMKSkgPCAwKQoJCQllcnIoMSwgImNoaWxkOiBhY2NlcHQgZXJyb3IiKTsK I2lmZGVmIExJTkdFUl9JTl9TRVJWRVIJCQoJCS8qCgkJICogU2VuZCBSU1Qgb24gY2xvc2UuCgkJ ICovCgkJbGluZy5sX29ub2ZmID0gMTsKCQlsaW5nLmxfbGluZ2VyID0gMDsJCQoJCWlmIChzZXRz b2Nrb3B0KGNvbm5mZCwgU09MX1NPQ0tFVCwgU09fTElOR0VSLAoJCQkgICAgICAgJmxpbmcsIHNp emVvZihsaW5nKSkgPCAwKQoJCQllcnIoMSwgImNoaWxkOiBzZXRzb2Nrb3B0IGVycm9yIik7CiNl bmRpZiAvKiBMSU5HRVJfSU5fU0VSVkVSICovCgkJc2xlZXAoU0xFRVAyKTsKCQlpZiAoY2xvc2Uo Y29ubmZkKSA8IDApCgkJCWVycigxLCAiY2hpbGQ6IGNsb3NlIGVycm9yIik7Cgl9CglleGl0KDAp Owp9CgojaWYgMAoKU0xFRVAxID0gMDsgU0xFRVAyID0gMDogTElOR0VSX0lOX1NFUlZFUjogcGFy ZW50OiB3cml0ZSBlcnJvcjogQ29ubmVjdGlvbiByZXNldCBieSBwZWVyCjAwOjAwOjAwLjAwMDAw MCBJUCAxMjcuMC4wLjEuMjM4NTEgPiAxMjcuMC4wLjEuMjM0ODE6IEZsYWdzIFtTXSwgc2VxIDMy MzM3NjU5OTMsIHdpbiA2NTUzNSwgb3B0aW9ucyBbbXNzIDE2MzQ0LG5vcCx3c2NhbGUgMyxzYWNr T0ssVFMgdmFsIDI4NjA1OCBlY3IgMF0sIGxlbmd0aCAwCjAwOjAwOjAwLjAwMDA0NCBJUCAxMjcu MC4wLjEuMjM0ODEgPiAxMjcuMC4wLjEuMjM4NTE6IEZsYWdzIFtTLl0sIHNlcSA5MTcwNDkwODcs IGFjayAzMjMzNzY1OTk0LCB3aW4gNjU1MzUsIG9wdGlvbnMgW21zcyAxNjM0NCxub3Asd3NjYWxl IDMsc2Fja09LLFRTIHZhbCAzNDkwMDg1MDA0IGVjciAyODYwNThdLCBsZW5ndGggMAowMDowMDow MC4wMDAwMzQgSVAgMTI3LjAuMC4xLjIzODUxID4gMTI3LjAuMC4xLjIzNDgxOiBGbGFncyBbLl0s IGFjayAxLCB3aW4gODk2MCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgMjg2MDU4IGVjciAzNDkw MDg1MDA0XSwgbGVuZ3RoIDAKMDA6MDA6MDAuMDAwMTkxIElQIDEyNy4wLjAuMS4yMzQ4MSA+IDEy Ny4wLjAuMS4yMzg1MTogRmxhZ3MgW1IuXSwgc2VxIDEsIGFjayAxLCB3aW4gODk2MCwgb3B0aW9u cyBbbm9wLG5vcCxUUyB2YWwgMzQ5MDA4NTAwNCBlY3IgMjg2MDU4XSwgbGVuZ3RoIDAKClNMRUVQ MSA9IDE7IFNMRUVQMiA9IDA6IExJTkdFUl9JTl9TRVJWRVI6IG5vIGVycm9yCjAwOjAwOjAwLjAw MDAwMCBJUCAxMjcuMC4wLjEuMjc1NTggPiAxMjcuMC4wLjEuMjM0ODE6IEZsYWdzIFtTXSwgc2Vx IDQwNDIwNjA4MjEsIHdpbiA2NTUzNSwgb3B0aW9ucyBbbXNzIDE2MzQ0LG5vcCx3c2NhbGUgMyxz YWNrT0ssVFMgdmFsIDI5MTQ2NSBlY3IgMF0sIGxlbmd0aCAwCjAwOjAwOjAwLjAwMDA0MiBJUCAx MjcuMC4wLjEuMjM0ODEgPiAxMjcuMC4wLjEuMjc1NTg6IEZsYWdzIFtTLl0sIHNlcSAyNzg5MzQy NTc3LCBhY2sgNDA0MjA2MDgyMiwgd2luIDY1NTM1LCBvcHRpb25zIFttc3MgMTYzNDQsbm9wLHdz Y2FsZSAzLHNhY2tPSyxUUyB2YWwgMTk1OTQxNzYxMSBlY3IgMjkxNDY1XSwgbGVuZ3RoIDAKMDA6 MDA6MDAuMDAwMDM0IElQIDEyNy4wLjAuMS4yNzU1OCA+IDEyNy4wLjAuMS4yMzQ4MTogRmxhZ3Mg Wy5dLCBhY2sgMSwgd2luIDg5NjAsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFsIDI5MTQ2NSBlY3Ig MTk1OTQxNzYxMV0sIGxlbmd0aCAwCjAwOjAwOjAwLjAwMDE3MyBJUCAxMjcuMC4wLjEuMjM0ODEg PiAxMjcuMC4wLjEuMjc1NTg6IEZsYWdzIFtSLl0sIHNlcSAxLCBhY2sgMSwgd2luIDg5NjAsIG9w dGlvbnMgW25vcCxub3AsVFMgdmFsIDE5NTk0MTc2MTEgZWNyIDI5MTQ2NV0sIGxlbmd0aCAwCgpT TEVFUDEgPSAwOyBTTEVFUDIgPSAxOiBMSU5HRVJfSU5fU0VSVkVSOiBubyBlcnJvcgowMDowMDow MC4wMDAwMDAgSVAgMTI3LjAuMC4xLjY0MTg0ID4gMTI3LjAuMC4xLjIzNDgxOiBGbGFncyBbU10s IHNlcSA3MzU3NjE0MTEsIHdpbiA2NTUzNSwgb3B0aW9ucyBbbXNzIDE2MzQ0LG5vcCx3c2NhbGUg MyxzYWNrT0ssVFMgdmFsIDI5OTc5MiBlY3IgMF0sIGxlbmd0aCAwCjAwOjAwOjAwLjAwMDA0OSBJ UCAxMjcuMC4wLjEuMjM0ODEgPiAxMjcuMC4wLjEuNjQxODQ6IEZsYWdzIFtTLl0sIHNlcSAxNzYx NzY4MDU1LCBhY2sgNzM1NzYxNDEyLCB3aW4gNjU1MzUsIG9wdGlvbnMgW21zcyAxNjM0NCxub3As d3NjYWxlIDMsc2Fja09LLFRTIHZhbCAxMTgyMDg5NjY3IGVjciAyOTk3OTJdLCBsZW5ndGggMAow MDowMDowMC4wMDAwMzUgSVAgMTI3LjAuMC4xLjY0MTg0ID4gMTI3LjAuMC4xLjIzNDgxOiBGbGFn cyBbLl0sIGFjayAxLCB3aW4gODk2MCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgMjk5NzkyIGVj ciAxMTgyMDg5NjY3XSwgbGVuZ3RoIDAKMDA6MDA6MDAuMDAwMjIyIElQIDEyNy4wLjAuMS42NDE4 NCA+IDEyNy4wLjAuMS4yMzQ4MTogRmxhZ3MgWy5dLCBhY2sgMSwgd2luIDg5NjAsIG9wdGlvbnMg W25vcCxub3AsVFMgdmFsIDI5OTc5MiBlY3IgMTE4MjA4OTY2N10sIGxlbmd0aCAxNDMzNgowMDow MDowMC4wOTkzOTYgSVAgMTI3LjAuMC4xLjIzNDgxID4gMTI3LjAuMC4xLjY0MTg0OiBGbGFncyBb Ll0sIGFjayAxNDMzNywgd2luIDcxNjgsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFsIDExODIwODk2 NzcgZWNyIDI5OTc5Ml0sIGxlbmd0aCAwCjAwOjAwOjAwLjAwMDA0NyBJUCAxMjcuMC4wLjEuNjQx ODQgPiAxMjcuMC4wLjEuMjM0ODE6IEZsYWdzIFsuXSwgYWNrIDEsIHdpbiA4OTYwLCBvcHRpb25z IFtub3Asbm9wLFRTIHZhbCAyOTk4MDIgZWNyIDExODIwODk2NzddLCBsZW5ndGggMTQzMzYKMDA6 MDA6MDAuMDAwMDE0IElQIDEyNy4wLjAuMS42NDE4NCA+IDEyNy4wLjAuMS4yMzQ4MTogRmxhZ3Mg W1AuXSwgYWNrIDEsIHdpbiA4OTYwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAyOTk4MDIgZWNy IDExODIwODk2NzddLCBsZW5ndGggMTQzMzYKMDA6MDA6MDAuMDAwMDQ3IElQIDEyNy4wLjAuMS4y MzQ4MSA+IDEyNy4wLjAuMS42NDE4NDogRmxhZ3MgWy5dLCBhY2sgNDMwMDksIHdpbiAzNTg0LCBv cHRpb25zIFtub3Asbm9wLFRTIHZhbCAxMTgyMDg5Njc3IGVjciAyOTk4MDJdLCBsZW5ndGggMAow MDowMDowMC4wMDAxMTUgSVAgMTI3LjAuMC4xLjY0MTg0ID4gMTI3LjAuMC4xLjIzNDgxOiBGbGFn cyBbUC5dLCBhY2sgMSwgd2luIDg5NjAsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFsIDI5OTgwMiBl Y3IgMTE4MjA4OTY3N10sIGxlbmd0aCAxNDMzNgowMDowMDowMC4wMDAxNTUgSVAgMTI3LjAuMC4x LjY0MTg0ID4gMTI3LjAuMC4xLjIzNDgxOiBGbGFncyBbLl0sIGFjayAxLCB3aW4gODk2MCwgb3B0 aW9ucyBbbm9wLG5vcCxUUyB2YWwgMjk5ODAyIGVjciAxMTgyMDg5Njc3XSwgbGVuZ3RoIDE0MzM2 CjAwOjAwOjAwLjAwMDAxOSBJUCAxMjcuMC4wLjEuMjM0ODEgPiAxMjcuMC4wLjEuNjQxODQ6IEZs YWdzIFsuXSwgYWNrIDcxNjgxLCB3aW4gMCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgMTE4MjA4 OTY3NyBlY3IgMjk5ODAyXSwgbGVuZ3RoIDAKMDA6MDA6MDAuOTA5NjQ4IElQIDEyNy4wLjAuMS4y MzQ4MSA+IDEyNy4wLjAuMS42NDE4NDogRmxhZ3MgW1IuXSwgc2VxIDEsIGFjayA3MTY4MSwgd2lu IDAsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFsIDExODIwODk3NjggZWNyIDI5OTgwMl0sIGxlbmd0 aCAwCgpTTEVFUDEgPSAwOyBTTEVFUDIgPSAxOiBMSU5HRVJfSU5fU0VSVkVSOiBMSU5HRVJfSU5f Q0xJRU5UOiBubyBlcnJvcgowMDowMDowMC4wMDAwMDAgSVAgMTI3LjAuMC4xLjYyNTM1ID4gMTI3 LjAuMC4xLjIzNDgxOiBGbGFncyBbU10sIHNlcSAyNDE2MzExNjU4LCB3aW4gNjU1MzUsIG9wdGlv bnMgW21zcyAxNjM0NCxub3Asd3NjYWxlIDMsc2Fja09LLFRTIHZhbCAzMDU1NjcgZWNyIDBdLCBs ZW5ndGggMAowMDowMDowMC4wMDAwNjMgSVAgMTI3LjAuMC4xLjIzNDgxID4gMTI3LjAuMC4xLjYy NTM1OiBGbGFncyBbUy5dLCBzZXEgNzIzMjQxMDczLCBhY2sgMjQxNjMxMTY1OSwgd2luIDY1NTM1 LCBvcHRpb25zIFttc3MgMTYzNDQsbm9wLHdzY2FsZSAzLHNhY2tPSyxUUyB2YWwgOTUzNDY0Mjkg ZWNyIDMwNTU2N10sIGxlbmd0aCAwCjAwOjAwOjAwLjAwMDAzMyBJUCAxMjcuMC4wLjEuNjI1MzUg PiAxMjcuMC4wLjEuMjM0ODE6IEZsYWdzIFsuXSwgYWNrIDEsIHdpbiA4OTYwLCBvcHRpb25zIFtu b3Asbm9wLFRTIHZhbCAzMDU1NjcgZWNyIDk1MzQ2NDI5XSwgbGVuZ3RoIDAKMDA6MDA6MDAuMDAw MjY2IElQIDEyNy4wLjAuMS42MjUzNSA+IDEyNy4wLjAuMS4yMzQ4MTogRmxhZ3MgWy5dLCBhY2sg MSwgd2luIDg5NjAsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFsIDMwNTU2NyBlY3IgOTUzNDY0Mjld LCBsZW5ndGggMTQzMzYKMDA6MDA6MDAuMDAwMDE5IElQIDEyNy4wLjAuMS42MjUzNSA+IDEyNy4w LjAuMS4yMzQ4MTogRmxhZ3MgWy5dLCBhY2sgMSwgd2luIDg5NjAsIG9wdGlvbnMgW25vcCxub3As VFMgdmFsIDMwNTU2NyBlY3IgOTUzNDY0MjldLCBsZW5ndGggMTQzMzYKMDA6MDA6MDAuMDAwMDE1 IElQIDEyNy4wLjAuMS42MjUzNSA+IDEyNy4wLjAuMS4yMzQ4MTogRmxhZ3MgW1AuXSwgYWNrIDEs IHdpbiA4OTYwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAzMDU1NjcgZWNyIDk1MzQ2NDI5XSwg bGVuZ3RoIDE0MzM2CjAwOjAwOjAwLjAwMDAwNCBJUCAxMjcuMC4wLjEuMjM0ODEgPiAxMjcuMC4w LjEuNjI1MzU6IEZsYWdzIFsuXSwgYWNrIDI4NjczLCB3aW4gNTM3Niwgb3B0aW9ucyBbbm9wLG5v cCxUUyB2YWwgOTUzNDY0MjkgZWNyIDMwNTU2N10sIGxlbmd0aCAwCjAwOjAwOjAwLjAwMDE3OSBJ UCAxMjcuMC4wLjEuNjI1MzUgPiAxMjcuMC4wLjEuMjM0ODE6IEZsYWdzIFsuXSwgYWNrIDEsIHdp biA4OTYwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAzMDU1NjcgZWNyIDk1MzQ2NDI5XSwgbGVu Z3RoIDE0MzM2CjAwOjAwOjAwLjAwMDAxNSBJUCAxMjcuMC4wLjEuNjI1MzUgPiAxMjcuMC4wLjEu MjM0ODE6IEZsYWdzIFsuXSwgYWNrIDEsIHdpbiA4OTYwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZh bCAzMDU1NjcgZWNyIDk1MzQ2NDI5XSwgbGVuZ3RoIDE0MzM2CjAwOjAwOjAwLjAwMDAwOCBJUCAx MjcuMC4wLjEuMjM0ODEgPiAxMjcuMC4wLjEuNjI1MzU6IEZsYWdzIFsuXSwgYWNrIDU3MzQ1LCB3 aW4gMTc5Miwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgOTUzNDY0MjkgZWNyIDMwNTU2N10sIGxl bmd0aCAwCjAwOjAwOjAwLjA5OTMxNyBJUCAxMjcuMC4wLjEuMjM0ODEgPiAxMjcuMC4wLjEuNjI1 MzU6IEZsYWdzIFsuXSwgYWNrIDcxNjgxLCB3aW4gMCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwg OTUzNDY0MzkgZWNyIDMwNTU2N10sIGxlbmd0aCAwCjAwOjAwOjAwLjkxMDAzOSBJUCAxMjcuMC4w LjEuMjM0ODEgPiAxMjcuMC4wLjEuNjI1MzU6IEZsYWdzIFtSLl0sIHNlcSAxLCBhY2sgNzE2ODEs IHdpbiAwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCA5NTM0NjUzMCBlY3IgMzA1NTY3XSwgbGVu Z3RoIDAKClNMRUVQMSA9IDA7IFNMRUVQMiA9IDE6IExJTkdFUl9JTl9DTElFTlQ6IG5vIGVycm9y CjAwOjAwOjAwLjAwMDAwMCBJUCAxMjcuMC4wLjEuNTIyMzIgPiAxMjcuMC4wLjEuMjM0ODE6IEZs YWdzIFtTXSwgc2VxIDgzNzc0ODQyOSwgd2luIDY1NTM1LCBvcHRpb25zIFttc3MgMTYzNDQsbm9w LHdzY2FsZSAzLHNhY2tPSyxUUyB2YWwgMzA5NjM5IGVjciAwXSwgbGVuZ3RoIDAKMDA6MDA6MDAu MDAwMDQ0IElQIDEyNy4wLjAuMS4yMzQ4MSA+IDEyNy4wLjAuMS41MjIzMjogRmxhZ3MgW1MuXSwg c2VxIDEyNjE2MTQ3MDcsIGFjayA4Mzc3NDg0MzAsIHdpbiA2NTUzNSwgb3B0aW9ucyBbbXNzIDE2 MzQ0LG5vcCx3c2NhbGUgMyxzYWNrT0ssVFMgdmFsIDMxMjYxMDY5NTcgZWNyIDMwOTYzOV0sIGxl bmd0aCAwCjAwOjAwOjAwLjAwMDAzNCBJUCAxMjcuMC4wLjEuNTIyMzIgPiAxMjcuMC4wLjEuMjM0 ODE6IEZsYWdzIFsuXSwgYWNrIDEsIHdpbiA4OTYwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAz MDk2MzkgZWNyIDMxMjYxMDY5NTddLCBsZW5ndGggMAowMDowMDowMC4wMDAyNDkgSVAgMTI3LjAu MC4xLjUyMjMyID4gMTI3LjAuMC4xLjIzNDgxOiBGbGFncyBbLl0sIGFjayAxLCB3aW4gODk2MCwg b3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgMzA5NjM5IGVjciAzMTI2MTA2OTU3XSwgbGVuZ3RoIDE0 MzM2CjAwOjAwOjAwLjAwMDAxOCBJUCAxMjcuMC4wLjEuNTIyMzIgPiAxMjcuMC4wLjEuMjM0ODE6 IEZsYWdzIFsuXSwgYWNrIDEsIHdpbiA4OTYwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAzMDk2 MzkgZWNyIDMxMjYxMDY5NTddLCBsZW5ndGggMTQzMzYKMDA6MDA6MDAuMDAwMDE5IElQIDEyNy4w LjAuMS4yMzQ4MSA+IDEyNy4wLjAuMS41MjIzMjogRmxhZ3MgWy5dLCBhY2sgMjg2NzMsIHdpbiA1 Mzc2LCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAzMTI2MTA2OTU3IGVjciAzMDk2MzldLCBsZW5n dGggMAowMDowMDowMC4wMDAwMjggSVAgMTI3LjAuMC4xLjUyMjMyID4gMTI3LjAuMC4xLjIzNDgx OiBGbGFncyBbUC5dLCBhY2sgMSwgd2luIDg5NjAsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFsIDMw OTYzOSBlY3IgMzEyNjEwNjk1N10sIGxlbmd0aCAxNDMzNgowMDowMDowMC4wMDAxNDMgSVAgMTI3 LjAuMC4xLjUyMjMyID4gMTI3LjAuMC4xLjIzNDgxOiBGbGFncyBbLl0sIGFjayAxLCB3aW4gODk2 MCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgMzA5NjM5IGVjciAzMTI2MTA2OTU3XSwgbGVuZ3Ro IDE0MzM2CjAwOjAwOjAwLjAwMDAxNSBJUCAxMjcuMC4wLjEuNTIyMzIgPiAxMjcuMC4wLjEuMjM0 ODE6IEZsYWdzIFsuXSwgYWNrIDEsIHdpbiA4OTYwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAz MDk2MzkgZWNyIDMxMjYxMDY5NTddLCBsZW5ndGggMTQzMzYKMDA6MDA6MDAuMDAwMDA3IElQIDEy Ny4wLjAuMS4yMzQ4MSA+IDEyNy4wLjAuMS41MjIzMjogRmxhZ3MgWy5dLCBhY2sgNTczNDUsIHdp biAxNzkyLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAzMTI2MTA2OTU3IGVjciAzMDk2MzldLCBs ZW5ndGggMAowMDowMDowMC4wOTkzNzEgSVAgMTI3LjAuMC4xLjIzNDgxID4gMTI3LjAuMC4xLjUy MjMyOiBGbGFncyBbLl0sIGFjayA3MTY4MSwgd2luIDAsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFs IDMxMjYxMDY5NjcgZWNyIDMwOTYzOV0sIGxlbmd0aCAwCjAwOjAwOjAwLjkxMDExNCBJUCAxMjcu MC4wLjEuMjM0ODEgPiAxMjcuMC4wLjEuNTIyMzI6IEZsYWdzIFtGLl0sIHNlcSAxLCBhY2sgNzE2 ODEsIHdpbiA4OTYwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAzMTI2MTA3MDU4IGVjciAzMDk2 MzldLCBsZW5ndGggMAowMDowMDowMC4wMDAwNDQgSVAgMTI3LjAuMC4xLjUyMjMyID4gMTI3LjAu MC4xLjIzNDgxOiBGbGFncyBbLl0sIGFjayAyLCB3aW4gODk2MCwgb3B0aW9ucyBbbm9wLG5vcCxU UyB2YWwgMzA5NzQwIGVjciAzMTI2MTA3MDU4XSwgbGVuZ3RoIDE0MzM2CjAwOjAwOjAwLjAwMDAx NCBJUCAxMjcuMC4wLjEuNTIyMzIgPiAxMjcuMC4wLjEuMjM0ODE6IEZsYWdzIFsuXSwgYWNrIDIs IHdpbiA4OTYwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAzMDk3NDAgZWNyIDMxMjYxMDcwNThd LCBsZW5ndGggMTQzMzYKMDA6MDA6MDAuMDAwMDM1IElQIDEyNy4wLjAuMS4yMzQ4MSA+IDEyNy4w LjAuMS41MjIzMjogRmxhZ3MgW1JdLCBzZXEgMTI2MTYxNDcwOSwgd2luIDAsIGxlbmd0aCAwCjAw OjAwOjAwLjAwMDAxOSBJUCAxMjcuMC4wLjEuMjM0ODEgPiAxMjcuMC4wLjEuNTIyMzI6IEZsYWdz IFtSXSwgc2VxIDEyNjE2MTQ3MDksIHdpbiAwLCBsZW5ndGggMAoKU0xFRVAxID0gMDsgU0xFRVAy ID0gMTogbm8gZXJyb3IKMDA6MDA6MDAuMDAwMDAwIElQIDEyNy4wLjAuMS4yNTg2NSA+IDEyNy4w LjAuMS4yMzQ4MTogRmxhZ3MgW1NdLCBzZXEgMzg2MzE4NzEwLCB3aW4gNjU1MzUsIG9wdGlvbnMg W21zcyAxNjM0NCxub3Asd3NjYWxlIDMsc2Fja09LLFRTIHZhbCAzMTM4MjggZWNyIDBdLCBsZW5n dGggMAowMDowMDowMC4wMDAwNDggSVAgMTI3LjAuMC4xLjIzNDgxID4gMTI3LjAuMC4xLjI1ODY1 OiBGbGFncyBbUy5dLCBzZXEgMzAxMjQ5NTk5OSwgYWNrIDM4NjMxODcxMSwgd2luIDY1NTM1LCBv cHRpb25zIFttc3MgMTYzNDQsbm9wLHdzY2FsZSAzLHNhY2tPSyxUUyB2YWwgNjI5MTQ1NDkwIGVj ciAzMTM4MjhdLCBsZW5ndGggMAowMDowMDowMC4wMDAwMzQgSVAgMTI3LjAuMC4xLjI1ODY1ID4g MTI3LjAuMC4xLjIzNDgxOiBGbGFncyBbLl0sIGFjayAxLCB3aW4gODk2MCwgb3B0aW9ucyBbbm9w LG5vcCxUUyB2YWwgMzEzODI4IGVjciA2MjkxNDU0OTBdLCBsZW5ndGggMAowMDowMDowMC4wMDAy MTkgSVAgMTI3LjAuMC4xLjI1ODY1ID4gMTI3LjAuMC4xLjIzNDgxOiBGbGFncyBbLl0sIGFjayAx LCB3aW4gODk2MCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgMzEzODI4IGVjciA2MjkxNDU0OTBd LCBsZW5ndGggMTQzMzYKMDA6MDA6MDAuMDAwMDE3IElQIDEyNy4wLjAuMS4yNTg2NSA+IDEyNy4w LjAuMS4yMzQ4MTogRmxhZ3MgWy5dLCBhY2sgMSwgd2luIDg5NjAsIG9wdGlvbnMgW25vcCxub3As VFMgdmFsIDMxMzgyOCBlY3IgNjI5MTQ1NDkwXSwgbGVuZ3RoIDE0MzM2CjAwOjAwOjAwLjAwMDAx NSBJUCAxMjcuMC4wLjEuMjU4NjUgPiAxMjcuMC4wLjEuMjM0ODE6IEZsYWdzIFtQLl0sIGFjayAx LCB3aW4gODk2MCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgMzEzODI4IGVjciA2MjkxNDU0OTBd LCBsZW5ndGggMTQzMzYKMDA6MDA6MDAuMDAwMDA1IElQIDEyNy4wLjAuMS4yMzQ4MSA+IDEyNy4w LjAuMS4yNTg2NTogRmxhZ3MgWy5dLCBhY2sgMjg2NzMsIHdpbiA1Mzc2LCBvcHRpb25zIFtub3As bm9wLFRTIHZhbCA2MjkxNDU0OTAgZWNyIDMxMzgyOF0sIGxlbmd0aCAwCjAwOjAwOjAwLjAwMDE3 NSBJUCAxMjcuMC4wLjEuMjU4NjUgPiAxMjcuMC4wLjEuMjM0ODE6IEZsYWdzIFsuXSwgYWNrIDEs IHdpbiA4OTYwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAzMTM4MjggZWNyIDYyOTE0NTQ5MF0s IGxlbmd0aCAxNDMzNgowMDowMDowMC4wMDAwMTYgSVAgMTI3LjAuMC4xLjI1ODY1ID4gMTI3LjAu MC4xLjIzNDgxOiBGbGFncyBbLl0sIGFjayAxLCB3aW4gODk2MCwgb3B0aW9ucyBbbm9wLG5vcCxU UyB2YWwgMzEzODI4IGVjciA2MjkxNDU0OTBdLCBsZW5ndGggMTQzMzYKMDA6MDA6MDAuMDAwMDA3 IElQIDEyNy4wLjAuMS4yMzQ4MSA+IDEyNy4wLjAuMS4yNTg2NTogRmxhZ3MgWy5dLCBhY2sgNTcz NDUsIHdpbiAxNzkyLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCA2MjkxNDU0OTAgZWNyIDMxMzgy OF0sIGxlbmd0aCAwCjAwOjAwOjAwLjA5OTM5NCBJUCAxMjcuMC4wLjEuMjM0ODEgPiAxMjcuMC4w LjEuMjU4NjU6IEZsYWdzIFsuXSwgYWNrIDcxNjgxLCB3aW4gMCwgb3B0aW9ucyBbbm9wLG5vcCxU UyB2YWwgNjI5MTQ1NTAwIGVjciAzMTM4MjhdLCBsZW5ndGggMAowMDowMDowMC45MTAxMzUgSVAg MTI3LjAuMC4xLjIzNDgxID4gMTI3LjAuMC4xLjI1ODY1OiBGbGFncyBbRi5dLCBzZXEgMSwgYWNr IDcxNjgxLCB3aW4gODk2MCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgNjI5MTQ1NTkxIGVjciAz MTM4MjhdLCBsZW5ndGggMAowMDowMDowMC4wMDAwNjkgSVAgMTI3LjAuMC4xLjI1ODY1ID4gMTI3 LjAuMC4xLjIzNDgxOiBGbGFncyBbLl0sIGFjayAyLCB3aW4gODk2MCwgb3B0aW9ucyBbbm9wLG5v cCxUUyB2YWwgMzEzOTI5IGVjciA2MjkxNDU1OTFdLCBsZW5ndGggMTQzMzYKMDA6MDA6MDAuMDAw MDE0IElQIDEyNy4wLjAuMS4yNTg2NSA+IDEyNy4wLjAuMS4yMzQ4MTogRmxhZ3MgWy5dLCBhY2sg Miwgd2luIDg5NjAsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFsIDMxMzkyOSBlY3IgNjI5MTQ1NTkx XSwgbGVuZ3RoIDE0MzM2CjAwOjAwOjAwLjAwMDAzNSBJUCAxMjcuMC4wLjEuMjM0ODEgPiAxMjcu MC4wLjEuMjU4NjU6IEZsYWdzIFtSXSwgc2VxIDMwMTI0OTYwMDEsIHdpbiAwLCBsZW5ndGggMAow MDowMDowMC4wMDAwMTkgSVAgMTI3LjAuMC4xLjIzNDgxID4gMTI3LjAuMC4xLjI1ODY1OiBGbGFn cyBbUl0sIHNlcSAzMDEyNDk2MDAxLCB3aW4gMCwgbGVuZ3RoIDAKCQkgICAgCiNlbmRpZiAvKiAw ICovCg== --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Mon May 31 05:11:57 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76DBF106568B; Mon, 31 May 2010 05:11:57 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4E02E8FC13; Mon, 31 May 2010 05:11:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4V5Bv0W072172; Mon, 31 May 2010 05:11:57 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4V5Buu1072168; Mon, 31 May 2010 05:11:56 GMT (envelope-from linimon) Date: Mon, 31 May 2010 05:11:56 GMT Message-Id: <201005310511.o4V5Buu1072168@freefall.freebsd.org> To: josemi@freebsd.jazztel.es, linimon@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/147191: [ppp] Problems with ppp -nat [pppoe], ipfw, dummynet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 05:11:57 -0000 Synopsis: [ppp] Problems with ppp -nat [pppoe], ipfw, dummynet State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Mon May 31 05:11:38 UTC 2010 State-Changed-Why: Closed at submitter's request. http://www.freebsd.org/cgi/query-pr.cgi?pr=147191 From owner-freebsd-net@FreeBSD.ORG Mon May 31 06:03:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E1CA106564A; Mon, 31 May 2010 06:03:25 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mail.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with ESMTP id F2E498FC12; Mon, 31 May 2010 06:03:24 +0000 (UTC) Received: from localhost (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id 24B7897781; Mon, 31 May 2010 08:03:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from mail.zirakzigil.org ([192.168.1.2]) by localhost (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id 1kCUlKqGrOia; Mon, 31 May 2010 08:03:20 +0200 (CEST) Received: from [192.168.229.30] (unknown [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id 58ED997776; Mon, 31 May 2010 08:03:20 +0200 (CEST) Message-ID: <4C03511D.6070807@zirakzigil.org> Date: Mon, 31 May 2010 08:03:09 +0200 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Max Laier References: <4BFF589F.2050102@zirakzigil.org> <201005281320.51027.max@love2party.net> In-Reply-To: <201005281320.51027.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: PF + BRIDGE still causes system freezing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 06:03:25 -0000 Max Laier wrote: > On Friday 28 May 2010 07:46:07 Giulio Ferro wrote: > >> Months ago I reported a system freezing whenever bridge was used >> with pf. This still happens now in 8.1 prerelease: after several minutes >> to hours >> that the bridge is active the system becomes unresponsive. >> > > as I told you last time your reported this problem: you need to simplify your > setup in order to track down the problem. For all I know, you have created a > routing or ethernet loop that is the cause of your problems. Unless you can > provide a simple setup that can be reproduced, you have to track down the > issue yourself - sorry. > > Max > Ok, I've moved the vpn-bridging service to a server without pf, and now it seems to work correctly. I maintain that this issue would need to look into, anyway... I don't think that a system freezing is acceptable, even when the administrator makes some configuration mistakes: the o.s. should complain about "routing or ethernet loop", without leaving him wondering... (how can I find them, anyway?) Thanks for your help. From owner-freebsd-net@FreeBSD.ORG Mon May 31 08:32:18 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0D40106567F for ; Mon, 31 May 2010 08:32:18 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id C6FBA8FC12 for ; Mon, 31 May 2010 08:32:18 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta13.emeryville.ca.mail.comcast.net with comcast id Q8YJ1e0021smiN4AD8YJVc; Mon, 31 May 2010 08:32:18 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta20.emeryville.ca.mail.comcast.net with comcast id Q8YH1e0033S48mS8g8YHzB; Mon, 31 May 2010 08:32:18 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 3C54E9B418; Mon, 31 May 2010 01:32:17 -0700 (PDT) Date: Mon, 31 May 2010 01:32:17 -0700 From: Jeremy Chadwick To: Giulio Ferro Message-ID: <20100531083217.GA74108@icarus.home.lan> References: <4BFF589F.2050102@zirakzigil.org> <201005281320.51027.max@love2party.net> <4C03511D.6070807@zirakzigil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C03511D.6070807@zirakzigil.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Max Laier , freebsd-stable@freebsd.org, freebsd-net@freebsd.org Subject: Re: PF + BRIDGE still causes system freezing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 08:32:19 -0000 On Mon, May 31, 2010 at 08:03:09AM +0200, Giulio Ferro wrote: > Max Laier wrote: > >On Friday 28 May 2010 07:46:07 Giulio Ferro wrote: > >>Months ago I reported a system freezing whenever bridge was used > >>with pf. This still happens now in 8.1 prerelease: after several minutes > >>to hours > >>that the bridge is active the system becomes unresponsive. > > > >as I told you last time your reported this problem: you need to > >simplify your setup in order to track down the problem. For all I > >know, you have created a routing or ethernet loop that is the > >cause of your problems. Unless you can provide a simple setup > >that can be reproduced, you have to track down the issue yourself > >- sorry. > > > >Max > > Ok, I've moved the vpn-bridging service to a server without pf, and now > it seems to work correctly. > > I maintain that this issue would need to look into, anyway... > I don't think that a system freezing is acceptable, even when the > administrator > makes some configuration mistakes: the o.s. should complain about > "routing or ethernet loop", without leaving him wondering... We don't know if physical cabling loops are the problem here, but I'll chime in with my two cents regardless. If you're prone to making cabling mistakes that result in layer 2 loops in your network, you should consider using protocols like spanning tree[1] on your switches. Be aware that STP induces a lot of other problems and complexities which very likely *will* be seen as issues within the OS (such as physical Ethernet link not coming up quickly, taking instead maybe 60-120 full seconds). I believe there are extension protocols that address this (such as RSTP). If you're actually using FreeBSD as a "smart switch", then there may be some spanning tree software that works on FreeBSD. I'm not familiar with this setup or what software may be available. The majority of folks connect their FreeBSD machines to a switch, and those switches can handle STP. [1]: http://en.wikipedia.org/wiki/Spanning_tree_protocol -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-net@FreeBSD.ORG Mon May 31 11:07:01 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E907106566B for ; Mon, 31 May 2010 11:07:01 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3B4928FC0A for ; Mon, 31 May 2010 11:07:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4VB71WB046064 for ; Mon, 31 May 2010 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4VB70sp046062 for freebsd-net@FreeBSD.org; Mon, 31 May 2010 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 31 May 2010 11:07:00 GMT Message-Id: <201005311107.o4VB70sp046062@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 11:07:01 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/147155 net [ip6] setfb not work with ipv6 o kern/146909 net [rue] rue(4) does not detect OQO model01 network contr o kern/146845 net [libc] close(2) returns error 54 (connection reset by o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146628 net [tcp] [patch] TCP does not clear DF when MTU is below o kern/146539 net [arp] arp pub not working properly o kern/146534 net [icmp6] wrong source address in echo reply o kern/146517 net [ath] [wlan] device timeouts for ath wlan device on re o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146263 net [em] [panic] Panic in em(4) SIOCADDMULTI/em_set_multi/ o kern/146250 net [netinet] [patch] Races on interface alias removal o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145918 net [ae] After spontaneous ae0 "watchdog timeout", "stray o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145777 net [wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net [lagg] Stops working lagg between two servers. o kern/145621 net [bge] [panic] bge watchdog timeout --resetting -> cras o kern/145462 net [netgraph] [patch] panic kernel when ng_ipfw send ip p o kern/144987 net [wpi] [panic] injecting packets with wlaninject using o kern/144898 net [wpi] [panic] wpi panics system o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o kern/144777 net [arp] proxyarp broken in 8.0 [regression] o kern/144755 net [iwi] [panic] iwi panic when issuing /etc/rc.d/netif r o kern/144724 net [bwn] if_bwn does not pass traffic when in PIO mode o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144680 net [em] em(4) problem with dual-port adapter o kern/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to o kern/144561 net [ixgbe] [patch] ixgbe driver errors o kern/144529 net [sctp] sctp over ipv6 appears to not calculate checksu o kern/144505 net [bwn] [patch] Error in macro CALC_COEFF2. f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144206 net Marvell Yukon NIC not working under FreeBSD o kern/144000 net [tcp] setting TCP_MAXSEG by setsockopt() does not seem o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] allow Atheros watchdog timeout to be tun o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143595 net [wpi] [panic] Creating virtual interface over wpi0 in o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143573 net [em] em(4) NIC crashes intermittently o kern/143285 net [em] [regression] jumbo frames broken in 8.0 o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142907 net [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142766 net [ipw] [regression] ipw(4) with Intel PRO/wireless 2100 o kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142019 net [em] em needs "ifconfig em0 down up" when link was gon o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 o kern/141843 net [em] [vlan] Intel txcsum and assigned vlan invoke wron o kern/141777 net [rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141720 net [sctp] [lor] [hang] sctp-create vs. sctp-it causes sys o kern/141698 net [sctp] [panic] Own lock on stcb at return from input o kern/141697 net [sctp] [panic] lock (sleep mutex) sctp-tcb not locked o kern/141696 net [rum] [panic] rum(4)+ vimage = kernel panic o kern/141695 net [sctp] [panic] kernel page fault with non-sleepable lo o kern/141314 net Network Performance has decreased by 30% [regression] o kern/141285 net [em] hangs down/up intel nic during creating vlan o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault o kern/140778 net [em] randomly panic in vlan/em o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140728 net [em] [patch] Fast irq registration in em driver o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140647 net [em] [patch] e1000 driver does not correctly handle mu o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140597 net [netinet] [patch] implement Lost Retransmission Detect o kern/140567 net [ath] [patch] ath is not worked on my notebook PC o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140326 net [em] em0: watchdog timeout when communicating to windo o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/140051 net [bce] [arp] ARP not sent through Bridge Firewall with o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o kern/138694 net [bge] FreeBSD 6.3 release does not recognize Broadcom o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138660 net [igb] igb driver troubles in 8.0-BETA4 o kern/138652 net [tcp] TCP window scaling value calculated incorrectly? o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o bin/82185 net [patch] ndp(8) can delete the incorrect entry s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 430 problems total. From owner-freebsd-net@FreeBSD.ORG Mon May 31 11:51:38 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25565106564A for ; Mon, 31 May 2010 11:51:38 +0000 (UTC) (envelope-from sean@gothic.net.au) Received: from visi.gothic.net.au (visi.gothic.net.au [115.64.131.102]) by mx1.freebsd.org (Postfix) with ESMTP id B431A8FC21 for ; Mon, 31 May 2010 11:51:37 +0000 (UTC) Received: from visi.gothic.net.au (localhost [127.0.0.1]) by visi.gothic.net.au (Postfix) with ESMTP id AB4144C78D; Mon, 31 May 2010 21:34:39 +1000 (EST) X-Virus-Scanned: amavisd-new at gothic.net.au Received: from localhost ([127.0.0.1]) by visi.gothic.net.au (visi.gothic.net.au [127.0.0.1]) (amavisd-new, port 10026) with SMTP id kPgR4c5Yf1xK; Mon, 31 May 2010 21:34:35 +1000 (EST) Received: from eee904 (dhcp181.gothic.net.au [10.168.1.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sean) by visi.gothic.net.au (Postfix) with ESMTPSA id E4C854C779; Mon, 31 May 2010 21:34:34 +1000 (EST) Date: Mon, 31 May 2010 21:34:34 +1000 From: Sean To: Jeremy Chadwick Message-Id: <20100531213434.5fff3c67.sean@gothic.net.au> In-Reply-To: <20100531083217.GA74108@icarus.home.lan> References: <4BFF589F.2050102@zirakzigil.org> <201005281320.51027.max@love2party.net> <4C03511D.6070807@zirakzigil.org> <20100531083217.GA74108@icarus.home.lan> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Max Laier , Giulio Ferro , freebsd-stable@freebsd.org, freebsd-net@freebsd.org Subject: Re: PF + BRIDGE still causes system freezing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 11:51:38 -0000 On Mon, 31 May 2010 01:32:17 -0700 Jeremy Chadwick wrote: > If you're actually using FreeBSD as a "smart switch", then there may > be some spanning tree software that works on FreeBSD. I'm not > familiar with this setup or what software may be available. The > majority of folks connect their FreeBSD machines to a switch, and > those switches can handle STP. if_bridge supports RSTP if bridgestp is loaded. man 4 if_bridge -- Sean Winn sean@gothic.net.au From owner-freebsd-net@FreeBSD.ORG Mon May 31 17:47:19 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 307F8106567B for ; Mon, 31 May 2010 17:47:19 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mx1.freebsd.org (Postfix) with ESMTP id A06A58FC24 for ; Mon, 31 May 2010 17:47:18 +0000 (UTC) Received: from vampire.homelinux.org (dslb-088-066-034-186.pools.arcor-ip.net [88.66.34.186]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0LqY9V-1OwJaU3U0n-00eTNs; Mon, 31 May 2010 19:47:15 +0200 Received: (qmail 96386 invoked from network); 31 May 2010 17:47:15 -0000 Received: from f8x64.laiers.local (192.168.4.188) by mx.laiers.local with SMTP; 31 May 2010 17:47:15 -0000 From: Max Laier Organization: FreeBSD To: Giulio Ferro Date: Mon, 31 May 2010 19:47:14 +0200 User-Agent: KMail/1.13.3 (FreeBSD/8.0-RELEASE-p2; KDE/4.4.3; amd64; ; ) References: <4BFF589F.2050102@zirakzigil.org> <201005281320.51027.max@love2party.net> <4C03511D.6070807@zirakzigil.org> In-Reply-To: <4C03511D.6070807@zirakzigil.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005311947.14984.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18DpS/BWEdagVFY2WnAEkpHJ1KljQjs9ItOqEh EqlI/llQrA5/OI+BQAkWUaL77bEmPHEPWPMV2s8pCC6mRnQhuQ I0Y0CgE0Jxibn5sGFJuLw== Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: PF + BRIDGE still causes system freezing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 17:47:19 -0000 On Monday 31 May 2010 08:03:09 Giulio Ferro wrote: > Max Laier wrote: > > On Friday 28 May 2010 07:46:07 Giulio Ferro wrote: > >> Months ago I reported a system freezing whenever bridge was used > >> with pf. This still happens now in 8.1 prerelease: after several minutes > >> to hours > >> that the bridge is active the system becomes unresponsive. > > > > as I told you last time your reported this problem: you need to simplify > > your setup in order to track down the problem. For all I know, you have > > created a routing or ethernet loop that is the cause of your problems. > > Unless you can provide a simple setup that can be reproduced, you have > > to track down the issue yourself - sorry. > > > > Max > > Ok, I've moved the vpn-bridging service to a server without pf, and now > it seems to work correctly. Glad to hear. I would, however, still like to know the *details* of your setup so I can *reproduce* the problem. Without proper configuration details, all I - or anyone - can do is guess. The information you provided so far is not very helpful in this regard. > I maintain that this issue would need to look into, anyway... Yes ... but unless the issue can be reproduced in a controlled environment, it's next to impossible to do so. > I don't think that a system freezing is acceptable, even when the > administrator > makes some configuration mistakes: the o.s. should complain about > "routing or ethernet loop", without leaving him wondering... I'm afraid in this regard we (or any other o.s. for that matter) are just rope vendors. Network configuration is complicated business. The more components you throw in the mix, the easier it gets to hang yourself in the ensuing web. Sorry I can't be of more help, but again: without details about your setup, everything is just guesswork! Max From owner-freebsd-net@FreeBSD.ORG Mon May 31 18:20:03 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE2C11065674 for ; Mon, 31 May 2010 18:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C3F908FC1F for ; Mon, 31 May 2010 18:20:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4VIK3SY021577 for ; Mon, 31 May 2010 18:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4VIK3q8021574; Mon, 31 May 2010 18:20:03 GMT (envelope-from gnats) Date: Mon, 31 May 2010 18:20:03 GMT Message-Id: <201005311820.o4VIK3q8021574@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Alex Kozlov Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Kozlov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 18:20:04 -0000 The following reply was made to PR kern/146517; it has been noted by GNATS. From: Alex Kozlov To: bug-followup@FreeBSD.org, vince@unsane.co.uk, rpaulo@freebsd.org, spam@rm-rf.kiev.ua Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. Date: Mon, 31 May 2010 21:12:20 +0300 Hi I confirm this. Atheros 9280, work fine with 8.0R usb stick, timeout after few pings with 8.1-BETA1. I can try to find a particular commit, that causes this regression, if its help. -- Adios From owner-freebsd-net@FreeBSD.ORG Mon May 31 19:30:04 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 603FE106564A for ; Mon, 31 May 2010 19:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3596F8FC17 for ; Mon, 31 May 2010 19:30:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4VJU47c080532 for ; Mon, 31 May 2010 19:30:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4VJU4LU080527; Mon, 31 May 2010 19:30:04 GMT (envelope-from gnats) Date: Mon, 31 May 2010 19:30:04 GMT Message-Id: <201005311930.o4VJU4LU080527@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Rui Paulo Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rui Paulo List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 19:30:04 -0000 The following reply was made to PR kern/146517; it has been noted by GNATS. From: Rui Paulo To: Alex Kozlov Cc: bug-followup@FreeBSD.org, vince@unsane.co.uk Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. Date: Mon, 31 May 2010 20:01:21 +0100 On 31 May 2010, at 19:12, Alex Kozlov wrote: > Hi > > I confirm this. Atheros 9280, work fine with 8.0R usb stick, > timeout after few pings with 8.1-BETA1. > I can try to find a particular commit, that causes this > regression, if its help. Yes, please. Regards, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Mon May 31 21:57:43 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 613CA1065675 for ; Mon, 31 May 2010 21:57:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 30DB58FC15 for ; Mon, 31 May 2010 21:57:42 +0000 (UTC) Received: by pxi7 with SMTP id 7so2108518pxi.13 for ; Mon, 31 May 2010 14:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=/spbjdWZavwmBI4/5p5uk9Xujfen2v2fy+f4moKUBlY=; b=PNnBijzExiTJFbrsgwSkKJe+tKIAA4Pn4paTHtyXJS2ZfRsWIuvJPeWwTVe55b9SrK T3fifbLO/VE7vI/7OhLN//sAtVzGd6YiZd0mIRaAZv6SSs+dAoJab8F0Pd9+NpqF9OaX jTNWuRKFkozfN7jQy6tQVNTiJ7paVbqkMgiOI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=nuvjOS8ShjXPwE2zqutnZT1FWFWSK9shJyVsb9b++/lI80RacLfjq9lAgdkv9ur4IN vYlNnSXKPC2Mv3KU9zurLz9y7+erykCXh8X+tYbhSzHOj/canBWPsBy7KpWVhaTFesv1 JbNR/NZGJO87O26z3+wxF0cFz+qSkGsHVxDoo= Received: by 10.114.54.11 with SMTP id c11mr4059941waa.133.1275343062440; Mon, 31 May 2010 14:57:42 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id n29sm53137959wae.16.2010.05.31.14.57.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 31 May 2010 14:57:41 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 31 May 2010 14:57:17 -0700 From: Pyun YongHyeon Date: Mon, 31 May 2010 14:57:17 -0700 To: Data Smith Message-ID: <20100531215717.GC1577@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: nic driver problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 21:57:43 -0000 On Sat, May 29, 2010 at 02:07:34PM +0300, Data Smith wrote: > Hello, I have to install Silan SC92031 driver for my nic to work. It is an > RTL8139D chiped nic (intex), I got it with a cd with drivers but the freebsd > driver is not working (latest version suported: FreeBSD 5). I am new to > compiling the kernel so I don't want to do that. Can someone tell me how to > compile, install the boot module and configure this nic on FreeBSD 8.0 ? > Show me the output of both "pciconf -lcbv" and dmesg(8). From owner-freebsd-net@FreeBSD.ORG Mon May 31 22:32:30 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E95771065675 for ; Mon, 31 May 2010 22:32:30 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id B740E8FC19 for ; Mon, 31 May 2010 22:32:30 +0000 (UTC) Received: by pwj1 with SMTP id 1so299651pwj.13 for ; Mon, 31 May 2010 15:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=bLeZ2If9u71HsC9LeNeENPi1Yms/j1Hb5IPMXzFIACk=; b=ZnHSVY5pM8Y/gsFql/vkLBdhF0y1JqFxsEhr+lnUHmnFU0SKRNF/djPyW4JYxRuJwE Do6JNQJdH7ZsWiSpOmFkwQirm40GKWQxnyRg2u2phDnhS2vz0iZHP63ge9Azl6KOgPfg xmE4Mehpr2amg/No7b/wjWTuuhsA41l5G9QSw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=dGc6rRa2qkuU118vPw2KvnB8fyQ+k3u/Vet2ZiUjt67H9L3ylaQztnmEHrK8MtaAsn E7386Z1IlQe8Oun/9bMXYkX4/xDf9N9KYgcyX+5PU6jSSUZaZpCNq8mQQ3FzKYll3P6i RzPawafvvb3MgfjtvfG2dar+FbmjZqtofmPi4= Received: by 10.114.18.7 with SMTP id 7mr4078389war.127.1275345149907; Mon, 31 May 2010 15:32:29 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id r20sm53355916wam.17.2010.05.31.15.32.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 31 May 2010 15:32:28 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 31 May 2010 15:32:04 -0700 From: Pyun YongHyeon Date: Mon, 31 May 2010 15:32:04 -0700 To: Perevalov Sergey Message-ID: <20100531223204.GE1577@michelle.cdnetworks.com> References: <4BE44E2D.6060907@gmail.com> <20100507210516.GI14801@michelle.cdnetworks.com> <4C01760E.2080403@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C01760E.2080403@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [axe][ue0] Device send packets but any host in network can not receive any packet from it. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 22:32:31 -0000 On Sun, May 30, 2010 at 01:16:14AM +0500, Perevalov Sergey wrote: > Pyun YongHyeon, I am really sorry, I have found you message in my spam > folder:-( > And immediately I did by your instructions. > I connected 2 Freebsd 8.0 hosts by one cable, and started tcpdump > -evvvvvvi rl0/ue0. > > So, 192.168.2.15 is receiver (rl0) log: http://pastebin.com/pZ5udweh > > 192.168.2.16 is sender (ue0) log: http://pastebin.com/BEDwUWBe > It seems both ends does not see any frames at all. I thought axe(4) sent wrong ethernet address to the other end but tcpdump output you posted makes me wonder cabling issue. I'm not sure whether rgephy(4) used in axe(4) can handle automatic MDI/MDIX crossover but rlphy(4) surely lacks the capability. Can you retest it with crossover cable instead of straight UTP cable? Also your tcpdump seems to indicate both hosts are trying to send packets. This makes it hard to know which part of NIC is not working. Send ICMP echo request on one host(e.g. ping(8)) and capture traffic on both sender and receiver side and post the result again. > Thank you for your help! > > > > On 08.05.2010 02:05, Pyun YongHyeon wrote: > >On Fri, May 07, 2010 at 10:30:21PM +0500, Perevalov Sergey wrote: > > > >>Hi guys. I am beginner in FreeBSD. And I got problem with my Gigabit > >>usb to ethernet adapter with AX88178 chipset. It works in windows very > >>well but doesn't work in FreeBSD 8.0. tcpdump shows log with received > >>and sent packets, but any host in network doesn't receive them from it. > >>I checked it with 2 FreeBSD hosts connected directly by cable. Can you, > >>guys, advice to me something to fix or to find reason of this issue? > >>I started thread on freebsd forums( > >>http://forums.freebsd.org/showthread.php?t=13649 ) and also reported > >>about problem ( http://www.freebsd.org/cgi/query-pr.cgi?pr=146153 ). > >> > >> > >It seems the PR shows tcpdump output on sender side(axe(4) > >host 192.168.2.22). Would you capture the traffic on receiver side > >(host 192.168.2.7) and post the result? Note, please use direct > >cable to connect both systems and use option -e to capture traffic > >on host 192.168.2.7. For instance, use > >#ifconfig -envvvvvvi nic0 > >on receiver side. > > > >Also check whether the receiver agrees on the resolved speed/duplex > >of established link. For your case, host 192.168.2.7 should show > >100baseTX, full-duplex. > > > > > >>Here some information: > >> > >>dmesg: > >>ugen4.2: at usbus4 > >>axe0: on usbus4 > >>axe0: PHYADDR 0xe0:0x02 > >>miibus0: on axe0 > >>rgephy0: PHY 2 on miibus0 > >>rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > >>1000baseT-FDX, auto > >>ue0: on axe0 > >>ue0: Ethernet address: 00:0e:c6:88:09:4e > >> > >>usbconfig: > >>laptop# usbconfig > >>ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL > >>(12Mbps) pwr=ON > >>ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL > >>(12Mbps) pwr=ON > >>ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL > >>(12Mbps) pwr=ON > >>ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL > >>(12Mbps) pwr=ON > >>ugen4.1: at usbus4, cfg=0 md=HOST spd=HIGH > >>(480Mbps) pwr=ON > >>ugen4.2: at usbus4, cfg=0 md=HOST > >>spd=HIGH (480Mbps) pwr=ON > >>ugen0.2: at usbus0, cfg=0 md=HOST spd=LOW > >>(1.5Mbps) pwr=ON > >> > >>ifconfig: > >>ue0: flags=8843 metric 0 mtu 1500 > >>ether 00:0e:c6:88:09:4e > >>inet 192.168.2.22 netmask 0xffffff00 broadcast 192.168.2.255 > >>media: Ethernet autoselect (100baseTX) > >>status: active > >> > >>Thank you for you help! > >> > > > > > -- > Regards, Sergey. > From owner-freebsd-net@FreeBSD.ORG Tue Jun 1 00:04:08 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05B1B1065674; Tue, 1 Jun 2010 00:04:08 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D14BC8FC18; Tue, 1 Jun 2010 00:04:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o51047Ma021436; Tue, 1 Jun 2010 00:04:07 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o51047uu021432; Tue, 1 Jun 2010 00:04:07 GMT (envelope-from yongari) Date: Tue, 1 Jun 2010 00:04:07 GMT Message-Id: <201006010004.o51047uu021432@freefall.freebsd.org> To: toidin@gmail.com, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/138694: [bge] FreeBSD 6.3 release does not recognize Broadcom BCM5709C card on IBM X3550 M2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 00:04:08 -0000 Synopsis: [bge] FreeBSD 6.3 release does not recognize Broadcom BCM5709C card on IBM X3550 M2 State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Tue Jun 1 00:03:11 UTC 2010 State-Changed-Why: I believe this controller should be supported by bce(4). Are you still having problems on more recent FreeBSD release? Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Jun 1 00:03:11 UTC 2010 Responsible-Changed-Why: Track. http://www.freebsd.org/cgi/query-pr.cgi?pr=138694 From owner-freebsd-net@FreeBSD.ORG Tue Jun 1 00:19:40 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CFB41065677; Tue, 1 Jun 2010 00:19:40 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6DBF58FC1A; Tue, 1 Jun 2010 00:19:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o510JehF030962; Tue, 1 Jun 2010 00:19:40 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o510JdrB030958; Tue, 1 Jun 2010 00:19:39 GMT (envelope-from yongari) Date: Tue, 1 Jun 2010 00:19:39 GMT Message-Id: <201006010019.o510JdrB030958@freefall.freebsd.org> To: freebsd-pr@spamblows.org, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/137279: [bge] [panic] Page fault (fatal trap 12) NFS server w/Broadcom BCM5704 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 00:19:40 -0000 Synopsis: [bge] [panic] Page fault (fatal trap 12) NFS server w/Broadcom BCM5704 State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Tue Jun 1 00:18:43 UTC 2010 State-Changed-Why: I'm not sure you're hitting the same issue I'm trying to solve for a while but would you try the patch at the following URL? http://people.freebsd.org/~yongari/bge/bge.rx.patch2 Before applying the patch above, you have to use latest bge(4) in stable/8 or stable/7. Due to newly added APIs I think the latest bge(4) may not build on 8.0-RELEASE so you have to use stable/8 (e.g 8.1-PRERELEASE) in order to test the patch. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Jun 1 00:18:43 UTC 2010 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=137279 From owner-freebsd-net@FreeBSD.ORG Tue Jun 1 15:02:28 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C9B4106567B for ; Tue, 1 Jun 2010 15:02:28 +0000 (UTC) (envelope-from ferdinand.goldmann@jku.at) Received: from emailsecure.uni-linz.ac.at (emailsecure.uni-linz.ac.at [140.78.3.66]) by mx1.freebsd.org (Postfix) with ESMTP id 32C078FC18 for ; Tue, 1 Jun 2010 15:02:26 +0000 (UTC) Received: from dyn-ant74.edvz.uni-linz.ac.at (dyn-ant74.edvz.uni-linz.ac.at [140.78.6.74]) by emailsecure.uni-linz.ac.at (Postfix) with ESMTPSA id 7F7C4B819 for ; Tue, 1 Jun 2010 17:02:25 +0200 (CEST) Message-ID: <4C052101.8080404@jku.at> Date: Tue, 01 Jun 2010 17:02:25 +0200 From: Ferdinand Goldmann Organization: Johannes Kepler University Linz - Information Management User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: carp + carpdev option? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 15:02:28 -0000 Greetings! It seems that this question has been asked several times before ... It looks like there is no carpdev option in 7.x :-( Having this options should bring several advantages: - One would only have to use a single public IP address (the carp interface), and would be able to configure the physical parent interface with a private IP address for management purposes only. - One would not have to fiddle around with application configuration, like telling Squid to use the IP address of the carp interface as sender IP (and not the IP of the parent interface ...) Is there any hope this option gets ported to FreeBSD? Maybe in 8.x? TIA, Ferdinand Goldmann -- >> Ferdinand Goldmann >> Johannes Kepler University Linz - Server Systems/Information Management >> Mail: Ferdinand.Goldmann@jku.at Phone: 00437024689398 Fax: 00437024689397 From owner-freebsd-net@FreeBSD.ORG Tue Jun 1 16:34:31 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BD3A1065678 for ; Tue, 1 Jun 2010 16:34:31 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.freebsd.org (Postfix) with ESMTP id 1725D8FC15 for ; Tue, 1 Jun 2010 16:34:30 +0000 (UTC) Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by hub.org (Postfix) with ESMTP id 4C16D345590C; Tue, 1 Jun 2010 13:34:30 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 03463-05; Tue, 1 Jun 2010 16:34:30 +0000 (UTC) Received: by hub.org (Postfix, from userid 1002) id 0E6C534558ED; Tue, 1 Jun 2010 13:34:30 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by hub.org (Postfix) with ESMTP id 0DFE934558D5; Tue, 1 Jun 2010 13:34:30 -0300 (ADT) Date: Tue, 1 Jun 2010 13:34:30 -0300 (ADT) From: "Marc G. Fournier" To: Joe Greco In-Reply-To: <201006011558.o51FwRcQ014493@aurora.sol.net> Message-ID: References: <201006011558.o51FwRcQ014493@aurora.sol.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, quagga-users@lists.quagga.net, boris@tagnet.ru Subject: Re: [quagga-users 11570] Re: quagga:zebra errors on FreeBSD 6.x ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 16:34:31 -0000 [+freebsd-net,+quagga port maintainer] Two questions ... 1. Is 8.x any better at this? 2. Any idea where the 'gross patch' is? On Tue, 1 Jun 2010, Joe Greco wrote: >> Other then appropriate interface/IP on the 7-STABLE boxes, the 7-STABLE >> boxes all work fine ... is there an issue with em/fxp devices and zebra? >> Or am I overlooking something in my config? > > It doesn't "work fine" on 7-STABLE, be warned. It's just more subtly > busted. > > I spent a little time trying to figure out whether it was FreeBSD or > Quagga that was busted, and my conclusion that it was a little bit of > both. Changes made to the multicast code in FreeBSD seem to be the > root cause; the multicast maintainer for FreeBSD doesn't seem to have > much interest in this, or at least that was my impression, and queries > on the Quagga list haven't had much result either. > > There's a patch floating around that everyone agrees is a gross hack > and "isn't correct but seems to work." > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] then I > won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) > With 24 million small businesses in the US alone, that's way too many apples. > _______________________________________________ > Quagga-users mailing list > Quagga-users@lists.quagga.net > http://lists.quagga.net/mailman/listinfo/quagga-users > ---- Marc G. Fournier Hub.Org Hosting Solutions S.A. scrappy@hub.org http://www.hub.org Yahoo:yscrappy Skype: hub.org ICQ:7615664 MSN:scrappy@hub.org From owner-freebsd-net@FreeBSD.ORG Tue Jun 1 16:37:02 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BCBD1065675 for ; Tue, 1 Jun 2010 16:37:02 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id D27FC8FC18 for ; Tue, 1 Jun 2010 16:37:01 +0000 (UTC) Received: by yxg6 with SMTP id 6so136257yxg.13 for ; Tue, 01 Jun 2010 09:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=LWU/UfkZbX6QkivCYRxarUBY8WOiwzd5P12LYtLFLM4=; b=I+5UUnhB4jr8ulAshphJmTQBZmu6+C/tU/wxlzQQchpNKAGWZFMmJCSwQGHR3RinsK mzqZTk938a0oGcVpRrxbIGTTK+/+yDCHcgqwkpz/8gaT/ETgw5g7XYEkJ6S5EnjZXkAr ztUVc/T1MvMBBYEdyQAF+Z720ls5QyVrfrBPg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=lLO08jJOoa4rZD29c9/5/YV61Gnz4WEDpu52hzwg8DkqE8z+zMs713CP3DOC1fxJsu /tEAV/NMhWF3bLG83EjCxmAwnvsj018cF4dxiUrpxt/abcX014k3FVaiD6RBUbg/tgL4 RFZWJOOmMKiv16afpWxTnORIVwqGIAlIOxlYQ= MIME-Version: 1.0 Received: by 10.231.185.6 with SMTP id cm6mr8051348ibb.72.1275410220401; Tue, 01 Jun 2010 09:37:00 -0700 (PDT) Received: by 10.231.36.194 with HTTP; Tue, 1 Jun 2010 09:37:00 -0700 (PDT) In-Reply-To: <4C052101.8080404@jku.at> References: <4C052101.8080404@jku.at> Date: Tue, 1 Jun 2010 09:37:00 -0700 Message-ID: From: Freddie Cash To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: carp + carpdev option? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 16:37:02 -0000 On Tue, Jun 1, 2010 at 8:02 AM, Ferdinand Goldmann < ferdinand.goldmann@jku.at> wrote: > It seems that this question has been asked several times before ... > It looks like there is no carpdev option in 7.x :-( > > Having this options should bring several advantages: > - One would only have to use a single public IP address (the carp > interface), > and would be able to configure the physical parent interface with a > private > IP address for management purposes only. > > - One would not have to fiddle around with application configuration, like > telling Squid to use the IP address of the carp interface as sender IP > (and not the IP of the parent interface ...) > > Is there any hope this option gets ported to FreeBSD? Maybe in 8.x? > Max L. (can't remember how to spell his last name) had some patches available for 7.x to enable carpdev support. I did some testing of them back then and they worked .... so long as the IPs/devices were all added in the exact same order on all interfaces. The CARP hashes wouldn't match if anything was different between interfaces. If you didn't use multiple IPs on the CARP devices, they worked perfectly. The patches were never imported to the source tree, though. I agree. It would be nice to have carpdev support in FreeBSD, as it makes things cleaner. And it lines up with vlan(4), lagg(4), and if_bridge(4) where you can specify devices and not have to rely on IPs/subnets. Here's hoping that it gets added in some future update of pf/carp from OpenBSD. :) It's the final missing link in our dreams of redundant firewalls/routers and storage servers. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Tue Jun 1 18:32:40 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF2EB106566B for ; Tue, 1 Jun 2010 18:32:40 +0000 (UTC) (envelope-from perevalov84@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id A83578FC20 for ; Tue, 1 Jun 2010 18:32:40 +0000 (UTC) Received: by pxi7 with SMTP id 7so2680899pxi.13 for ; Tue, 01 Jun 2010 11:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=J5EKZIDbAsQa4+gO61hagb0e+J0+NkHr6sPYVxyTGds=; b=E957UGg3za88cQv71PCHN6BosqwYDLK2z8Tl0RxXMgYsF8sYOsj0XpLp0YAgMoxknB OXmxsrv26GAMGC/XqJ2mB7mKffXzELGrla96NmeLDFnBIqpN8pIOabloL7tYiPUQ5y5i uPh72XS0zE1g7bBVbY5SqoWWtg8JW7wCc5N24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=FYKUXhU8kKD2UgXy4afFp4T8biac0H+07b2DtU7gzDQMQWsCrHG8/KxmhCG4t24SGj +qDnsagqzxldm9zr+57uPDKhPVGZCK+o8t/53vnByCFhmkjtkeZi+tRZuZc4v3MEQIK4 R/XUc9sbmDWsNk+fNhHz5rrI3eVNZarbRewwo= Received: by 10.114.187.30 with SMTP id k30mr5341818waf.187.1275417145616; Tue, 01 Jun 2010 11:32:25 -0700 (PDT) Received: from [192.168.2.2] ([95.58.61.195]) by mx.google.com with ESMTPS id b6sm61488719wam.9.2010.06.01.11.32.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Jun 2010 11:32:23 -0700 (PDT) Message-ID: <4C0551F1.2010609@gmail.com> Date: Tue, 01 Jun 2010 23:31:13 +0500 From: Perevalov Sergey User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100506 Thunderbird/3.0.4 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4BE44E2D.6060907@gmail.com> <20100507210516.GI14801@michelle.cdnetworks.com> <4C01760E.2080403@gmail.com> <20100531223204.GE1577@michelle.cdnetworks.com> In-Reply-To: <20100531223204.GE1577@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: [axe][ue0] Device send packets but any host in network can not receive any packet from it. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 18:32:41 -0000 Hi! I tried it with crossover cable but results was the same bad. Then set debug flag hw.usb.axe.debug: to 15, and started ping -f from ue0. And in /var/log/messages I found these strings: Jun 1 22:28:34 laptop kernel: axe_bulk_read_callback:842: bulk read error, USB_ERR_CANCELLED Jun 1 22:28:35 laptop kernel: axe_bulk_write_callback:870: transfer complete Jun 1 22:29:12 laptop kernel: axe_bulk_write_callback:941: transfer error, USB_ERR_TIMEOUT Jun 1 22:29:51 laptop last message repeated 4 times Jun 1 22:31:40 laptop last message repeated 11 times Then i googled it and found this http://www.mail-archive.com/freebsd-usb@freebsd.org/msg04388.html the problem is described definitely like mine. I read all thread and found the patch usb2_ethernet.patch2, but I havn't found sys/dev/usb2/ethernet/usb2_ethernet.c file for patch. how can I try to apply this patch to my system? http://www.mail-archive.com/freebsd-usb@freebsd.org/msg04403.html Thank you very mach for your help! // // On 01.06.2010 03:32, Pyun YongHyeon wrote: > On Sun, May 30, 2010 at 01:16:14AM +0500, Perevalov Sergey wrote: > >> Pyun YongHyeon, I am really sorry, I have found you message in my spam >> folder:-( >> And immediately I did by your instructions. >> I connected 2 Freebsd 8.0 hosts by one cable, and started tcpdump >> -evvvvvvi rl0/ue0. >> >> So, 192.168.2.15 is receiver (rl0) log: http://pastebin.com/pZ5udweh >> >> 192.168.2.16 is sender (ue0) log: http://pastebin.com/BEDwUWBe >> >> > It seems both ends does not see any frames at all. I thought axe(4) > sent wrong ethernet address to the other end but tcpdump output you > posted makes me wonder cabling issue. I'm not sure whether > rgephy(4) used in axe(4) can handle automatic MDI/MDIX crossover > but rlphy(4) surely lacks the capability. Can you retest it with > crossover cable instead of straight UTP cable? > Also your tcpdump seems to indicate both hosts are trying to send > packets. This makes it hard to know which part of NIC is not > working. Send ICMP echo request on one host(e.g. ping(8)) and > capture traffic on both sender and receiver side and post the > result again. > > >> Thank you for your help! >> >> >> >> On 08.05.2010 02:05, Pyun YongHyeon wrote: >> >>> On Fri, May 07, 2010 at 10:30:21PM +0500, Perevalov Sergey wrote: >>> >>> >>>> Hi guys. I am beginner in FreeBSD. And I got problem with my Gigabit >>>> usb to ethernet adapter with AX88178 chipset. It works in windows very >>>> well but doesn't work in FreeBSD 8.0. tcpdump shows log with received >>>> and sent packets, but any host in network doesn't receive them from it. >>>> I checked it with 2 FreeBSD hosts connected directly by cable. Can you, >>>> guys, advice to me something to fix or to find reason of this issue? >>>> I started thread on freebsd forums( >>>> http://forums.freebsd.org/showthread.php?t=13649 ) and also reported >>>> about problem ( http://www.freebsd.org/cgi/query-pr.cgi?pr=146153 ). >>>> >>>> >>>> >>> It seems the PR shows tcpdump output on sender side(axe(4) >>> host 192.168.2.22). Would you capture the traffic on receiver side >>> (host 192.168.2.7) and post the result? Note, please use direct >>> cable to connect both systems and use option -e to capture traffic >>> on host 192.168.2.7. For instance, use >>> #ifconfig -envvvvvvi nic0 >>> on receiver side. >>> >>> Also check whether the receiver agrees on the resolved speed/duplex >>> of established link. For your case, host 192.168.2.7 should show >>> 100baseTX, full-duplex. >>> >>> >>> >>>> Here some information: >>>> >>>> dmesg: >>>> ugen4.2: at usbus4 >>>> axe0: on usbus4 >>>> axe0: PHYADDR 0xe0:0x02 >>>> miibus0: on axe0 >>>> rgephy0: PHY 2 on miibus0 >>>> rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >>>> 1000baseT-FDX, auto >>>> ue0: on axe0 >>>> ue0: Ethernet address: 00:0e:c6:88:09:4e >>>> >>>> usbconfig: >>>> laptop# usbconfig >>>> ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL >>>> (12Mbps) pwr=ON >>>> ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL >>>> (12Mbps) pwr=ON >>>> ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL >>>> (12Mbps) pwr=ON >>>> ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL >>>> (12Mbps) pwr=ON >>>> ugen4.1: at usbus4, cfg=0 md=HOST spd=HIGH >>>> (480Mbps) pwr=ON >>>> ugen4.2: at usbus4, cfg=0 md=HOST >>>> spd=HIGH (480Mbps) pwr=ON >>>> ugen0.2: at usbus0, cfg=0 md=HOST spd=LOW >>>> (1.5Mbps) pwr=ON >>>> >>>> ifconfig: >>>> ue0: flags=8843 metric 0 mtu 1500 >>>> ether 00:0e:c6:88:09:4e >>>> inet 192.168.2.22 netmask 0xffffff00 broadcast 192.168.2.255 >>>> media: Ethernet autoselect (100baseTX) >>>> status: active >>>> >>>> Thank you for you help! >>>> >>>> >>> >>> >> >> -- >> Regards, Sergey. >> >> > -- Regards, Sergey. From owner-freebsd-net@FreeBSD.ORG Tue Jun 1 22:25:10 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3671C106566B for ; Tue, 1 Jun 2010 22:25:10 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 035E18FC1A for ; Tue, 1 Jun 2010 22:25:09 +0000 (UTC) Received: by pva18 with SMTP id 18so539300pva.13 for ; Tue, 01 Jun 2010 15:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=6stdbE5BxqC0nG13Ja7Ce+MkpOzE5QxQKAzFQnmfkeg=; b=myCr4QFrY9aS3lUlfFX+YmqplNvewOI+veDjTwKdJNsO0IDiWwEXOqDEFw9/xjJMoX E+b5c8L4rU8X5ft/c0NrYqqiwNKUFW+xuiWhGIqGe/BDToscsqNetdOkeqb8r8U+A/fb QZS1vkSr24jOWUtL1hOK7MqBZ99LWxJ5tFsj8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=g6NVgGgQ+/kcTEaeMiGY5G3in3InnKM9lbiGA57Rv7CYS9WkHYKHfql9WGuu/kBBHb c+KbIeDKgq38B0K7x6QQN8/i80fOCUBtug6fQvOUtcr3cy8hn2zXvHbYhRjgG9yr4qO7 StLMdl3za3ZzfZDjshlgAb1NzyJ1beGpFjZG4= Received: by 10.114.4.14 with SMTP id 14mr5730772wad.121.1275431109262; Tue, 01 Jun 2010 15:25:09 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id d16sm63038658wam.12.2010.06.01.15.25.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Jun 2010 15:25:07 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 1 Jun 2010 15:24:44 -0700 From: Pyun YongHyeon Date: Tue, 1 Jun 2010 15:24:44 -0700 To: Perevalov Sergey Message-ID: <20100601222444.GH1577@michelle.cdnetworks.com> References: <4BE44E2D.6060907@gmail.com> <20100507210516.GI14801@michelle.cdnetworks.com> <4C01760E.2080403@gmail.com> <20100531223204.GE1577@michelle.cdnetworks.com> <4C0551F1.2010609@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C0551F1.2010609@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [axe][ue0] Device send packets but any host in network can not receive any packet from it. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 22:25:10 -0000 On Tue, Jun 01, 2010 at 11:31:13PM +0500, Perevalov Sergey wrote: > Hi! > I tried it with crossover cable but results was the same bad. Then set > debug flag hw.usb.axe.debug: to 15, and started ping -f from ue0. > And in /var/log/messages I found these strings: > > Jun 1 22:28:34 laptop kernel: axe_bulk_read_callback:842: bulk read > error, USB_ERR_CANCELLED > Jun 1 22:28:35 laptop kernel: axe_bulk_write_callback:870: transfer > complete > Jun 1 22:29:12 laptop kernel: axe_bulk_write_callback:941: transfer > error, USB_ERR_TIMEOUT > Jun 1 22:29:51 laptop last message repeated 4 times > Jun 1 22:31:40 laptop last message repeated 11 times > > Then i googled it and found this > http://www.mail-archive.com/freebsd-usb@freebsd.org/msg04388.html > the problem is described definitely like mine. > I read all thread and found the patch usb2_ethernet.patch2, but I havn't > found > sys/dev/usb2/ethernet/usb2_ethernet.c file for patch. > > how can I try to apply this patch to my system? > http://www.mail-archive.com/freebsd-usb@freebsd.org/msg04403.html > I believe the bug in the thread was fixed long time ago. If you're using 8.0-RELEASE, try latest stable/8 or 8.1-PRERELEASE and see whether axe(4) works or not. From owner-freebsd-net@FreeBSD.ORG Tue Jun 1 22:38:14 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A09591065679; Tue, 1 Jun 2010 22:38:14 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4A3488FC24; Tue, 1 Jun 2010 22:38:13 +0000 (UTC) Received: by vws10 with SMTP id 10so3980128vws.13 for ; Tue, 01 Jun 2010 15:38:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.59.74 with SMTP id k10mr5024105vch.119.1275430016739; Tue, 01 Jun 2010 15:06:56 -0700 (PDT) Sender: andy@fud.org.nz Received: by 10.220.165.74 with HTTP; Tue, 1 Jun 2010 15:06:56 -0700 (PDT) Date: Wed, 2 Jun 2010 10:06:56 +1200 X-Google-Sender-Auth: IHuSMOzdb0Bfut5JJ-wdgphBLPg Message-ID: From: Andrew Thompson To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: qingli@freebsd.org Subject: Link state changes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 22:38:14 -0000 > Revision 205024 - (annotate) > Thu Mar 11 17:56:46 2010 UTC (2 months, 3 weeks ago) by qingli > > The if_tap interface is of IFT_ETHERNET type, but it > does not set or update the if_link_state variable. > As such RT_LINK_IS_UP() fails for the if_tap interface. > > Also, the RT_LINK_IS_UP() needs to bypass all loopback > interfaces because loopback interfaces are considered > up logically as long as the system is running. > > This patch fixes the above issues by setting and updating > the if_link_state variable when the tap interface is > opened or closed respectively. Similary approach is > already done in the if_tun device. This is also a problem for bridge(4) and possibly ef(4), edesc(4) and epair(4). Should the same change be applied to them? Andrew From owner-freebsd-net@FreeBSD.ORG Wed Jun 2 00:50:04 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08EE0106564A for ; Wed, 2 Jun 2010 00:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EAC1C8FC0C for ; Wed, 2 Jun 2010 00:50:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o520o3e1030805 for ; Wed, 2 Jun 2010 00:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o520o32E030803; Wed, 2 Jun 2010 00:50:03 GMT (envelope-from gnats) Date: Wed, 2 Jun 2010 00:50:03 GMT Message-Id: <201006020050.o520o32E030803@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Jose M Rodriguez Cc: Subject: Re: kern/147191: [ppp] Problems with ppp -nat [pppoe], ipfw, dummynet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jose M Rodriguez List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 00:50:04 -0000 The following reply was made to PR kern/147191; it has been noted by GNATS. From: Jose M Rodriguez To: bug-followup@FreeBSD.org, josemi@freebsd.jazztel.es Cc: Subject: Re: kern/147191: [ppp] Problems with ppp -nat [pppoe], ipfw, dummynet Date: Wed, 02 Jun 2010 02:37:20 +0200 This is a multi-part message in MIME format. --------------080505020803060701030501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Seems that this must be reopen. After redo the rules to work with one_pass=0, problems of all sort still alive. - ppp nat seems to consume all translated traffic 'in to out', with or without one_pass set. but traffic 'out to in' hit ipfw rules following specs - after changing to mpd5 + natd, problems are even more strange, and firewall mostly works only if local net traffic is done LAST and not FIRST. But some NATed apps fails (jdownloader, bitcomet file donloader), while others works (firefox and his file downloader) My vote is for some problem with libalias. At the moment, I MUST put the sharper FIRST, catching the traffic coming from local net. I'm very busy now, but can go over this again after 2 weeks. Attached rc.firewall mostly working with mpd5 + natd as reference --------------080505020803060701030501 Content-Type: text/plain; name="rc.firewall.router.1" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rc.firewall.router.1" #!/bin/sh - # Copyright (c) 1996 Poul-Henning Kamp # All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright # notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright # notice, this list of conditions and the following disclaimer in the # documentation and/or other materials provided with the distribution. # # THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE # ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # # $FreeBSD: src/etc/rc.firewall,v 1.60.2.3 2010/04/14 15:03:58 ume Exp $ # # $Log$ # # Setup system for ipfw(4) firewall service on AHS router # # Configuration: # firewall_resetports: # List of TCP ports reset on incoming # firewall_myservices: # List of TCP ports on which this host offers services. # firewall_myudpports: # List of UDP ports on which this host offers services. # firewall_logdeny: # Boolean (YES/NO) specifying if the default denied packets should be # logged (in /var/log/security). # firewall_nologports: # List of TCP/UDP ports for which denied incoming packets are not logged. # firewall_oif: # Outside IPv4 network interface, default to tun0. # firewall_iifaces: # Inside network interface list. # firewall_net_${iface} # IPv4 network definition for each of the previous interfaces. # firewall_p2p_${iface} # List of address ports for opened TCP/UDP ports on ${iface} # firewall_p2p_uids # List of uids of p2p daemons running on me # predefined firewall_resetports="53,113,135-139,445" firewall_p2p_uids="mlnet transmission" for u in ${firewall_p2p_uids}; do eval ${u}_enable="NO" done mpd_enable="NO" # Suck in the configuration variables. if [ -z "${source_rc_confs_defined}" ]; then if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf source_rc_confs elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi fi . /etc/rc.subr . /etc/network.subr afexists inet6 ipv6_available=$? # macros fwcmd="/sbin/ipfw" ifaces=${firewall_iifaces} if checkyesno mpd_enable ; then oif=${firewall_oif-ng0} else oif=${firewall_oif-tun0} fi log="" # Set quiet mode if requested checkyesno firewall_quiet && fwcmd="${fwcmd} -q" # Flush out the list before we begin. ${fwcmd} -f flush # setup loopback ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 ${fwcmd} add 300 deny all from 127.0.0.0/8 to any # setup ipv6 mandatory if [ $ipv6_available -ne 0 ]; then ${fwcmd} add 400 deny all from any to ::1 ${fwcmd} add 500 deny all from ::1 to any # DAD ${fwcmd} add pass ipv6-icmp from :: to ff02::/16 # RS, RA, NS, NA, redirect... ${fwcmd} add pass ipv6-icmp from fe80::/1o to fe80::/10 ${fwcmd} add pass ipv6-icmp from fe80::/1o to ff02::/16 # IMCPv6 destination unreachable, NS, NA, toobig ${fwcmd} add pass ipv6-icmp from any to any icmp6 types 1,2,135,136 fi # setup tables ${fwcmd} table all flush astable=1 astn=1 asln=2 aspn=3 asipv4=4 ascle=5 asmcast=6 # rfc 1912 local net ${fwcmd} table ${astable} add 0.0.0.0/8 ${asln} # this network ${fwcmd} table ${astable} add 127.0.0.0/8 ${asln} # local net ${fwcmd} table ${astable} add 255.0.0.0/8 ${asln} # local net # rfc 1918 private nets ${fwcmd} table ${astable} add 10.0.0.0/8 ${aspn} # private net ${fwcmd} table ${astable} add 172.16.0.0/12 ${aspn} # private net ${fwcmd} table ${astable} add 192.168.0.0/16 ${aspn} # private net # Link-local/APIPA (RFCs 3330 and 3927) ${fwcmd} table ${astable} add 169.254.0.0/16 ${aspn} # link-local/APIPA # TEST-NET-[1-3] for Documentation (RFC 5737) ${fwcmd} table ${astable} add 192.0.0.0/24 ${astn} # IETF net ${fwcmd} table ${astable} add 192.0.2.0/24 ${astn} # test net ${fwcmd} table ${astable} add 198.51.100.0/24 ${astn} # test net ${fwcmd} table ${astable} add 203.0.113.0/24 ${astn} # test net # Router Benchmark Testing (RFC 3330) ${fwcmd} table ${astable} add 198.18.0.0/15 ${astn} # router benchmark # IANA Reserved - Old Class E Space ${fwcmd} table ${astable} add 240.0.0.0/5 ${ascle} # old CLASS E ${fwcmd} table ${astable} add 248.0.0.0/6 ${ascle} # old CLASS E ${fwcmd} table ${astable} add 252.0.0.0/7 ${ascle} # old CLASS E ${fwcmd} table ${astable} add 254.0.0.0/8 ${ascle} # old CLASS E # Multicast ${fwcmd} table ${astable} add 224.0.0.0/3 ${asmcast} # other #${fwcmd} table ${astable} add 1.0.0.0/8 ${asipv4} # APNIC ${fwcmd} table ${astable} add 1.0.0.0/13 ${asipv4} ${fwcmd} table ${astable} add 1.8.0.0/16 ${asipv4} ${fwcmd} table ${astable} add 1.10.0.0/16 ${asipv4} ${fwcmd} table ${astable} add 1.20.0.0/16 ${asipv4} ${fwcmd} table ${astable} add 1.32.0.0/16 ${asipv4} ${fwcmd} table ${astable} add 1.37.0.0/16 ${asipv4} ${fwcmd} table ${astable} add 1.187.0.0/16 ${asipv4} ${fwcmd} table ${astable} add 5.0.0.0/8 ${asipv4} # Un. hamachi ${fwcmd} table ${astable} add 23.0.0.0/8 ${asipv4} # Un. bogon #${fwcmd} table ${astable} add 31.0.0.0/8 ${asipv4} # bogon/RIPE ${fwcmd} table ${astable} add 31.0.0.0/16 ${asipv4} ${fwcmd} table ${astable} add 31.1.0.0/21 ${asipv4} ${fwcmd} table ${astable} add 31.1.24.0/24 ${asipv4} ${fwcmd} table ${astable} add 36.0.0.0/7 ${asipv4} # bogon ${fwcmd} table ${astable} add 39.0.0.0/8 ${asipv4} # bogon ${fwcmd} table ${astable} add 42.0.0.0/8 ${asipv4} # bogon ${fwcmd} table ${astable} add 49.0.0.0/8 ${asipv4} # bogon ${fwcmd} table ${astable} add 100.0.0.0/6 ${asipv4} # bogon ${fwcmd} table ${astable} add 104.0.0.0/7 ${asipv4} # bogon ${fwcmd} table ${astable} add 106.0.0.0/8 ${asipv4} # bogon ${fwcmd} table ${astable} add 128.0.0.0/16 ${asipv4} # ARIN, rfc 3300? ${fwcmd} table ${astable} add 128.66.0.0/16 ${asipv4} # ARIN? ${fwcmd} table ${astable} add 177.0.0.0/8 ${asipv4} ${fwcmd} table ${astable} add 179.0.0.0/8 ${asipv4} ${fwcmd} table ${astable} add 181.0.0.0/8 ${asipv4} ${fwcmd} table ${astable} add 185.0.0.0/8 ${asipv4} #${fwcmd} table ${astable} add 191.255.0.0/16 ${asipv4} # LACNIC #${fwcmd} table ${astable} add 192.0.0.0/19 ${asipv4} # ARIN ${fwcmd} table ${astable} add 192.0.48.0/20 ${asipv4} # ARIN ${fwcmd} table ${astable} add 192.0.64.0/18 ${asipv4} # ARIN ${fwcmd} table ${astable} add 192.0.128.0/17 ${asipv4} # ARIN #${fwcmd} table ${astable} add 197.0.0.0/8 ${asipv4} # AfriNIC ${fwcmd} table ${astable} add 204.152.64.0/23 ${asipv4} # dummynet if checkyesno dummynet_enable ; then outp=1 ufq=2 ufr=8000 fq=3 fr=8400 nq=4 nr=8800 lq=5 lr=9200 ulq=6 ulr=9400 # tags, scheds, ... p2p=1 sched=1 # sysctl sysctl net.inet.ip.fw.one_pass=0 >/dev/null sysctl net.inet.ip.fw.verbose=0 >/dev/null sysctl net.inet.ip.dummynet.io_fast=1 >/dev/null # queues ${fwcmd} pipe ${outp} config bw ${firewall_outbw-0} \ burst ${firewall_out_burst-29840} ${fwcmd} queue ${ufq} config pipe ${outp} \ weight ${firewall_ufast_weight-100} queue 90 ${fwcmd} queue ${fq} config pipe ${outp} \ weight ${firewall_fast_weight-75} ${fwcmd} queue ${nq} config pipe ${outp} \ weight ${firewall_weight-40} ${fwcmd} queue ${lq} config pipe ${outp} \ weight ${firewall_lo_weight-25} ${fwcmd} queue ${ulq} config pipe ${outp} \ weight ${firewall_ulow_weight-1} ${fwcmd} sched ${sched} config type ${firewall_sched_type-QFQ} fi # RULES # # Danger Will Robinson. # Seems that on FreeBSD 8.1 you can't pass traffic in to be forwarded, or # queue/divert/outgoing rules can't see it. Strange. # #pass DHCP requests for if in $(list_net_interfaces dhcp) ; do ${fwcmd} add pass udp from any 67 to any 68 recv ${if} ${fwcmd} add pass udp from any 68 to any 67 xmit ${if} done #local nets for iif in ${ifaces}; do # pass dhcpv4 traffic from/to our server if checkyesno dhcpd_enable; then ${fwcmd} add pass udp from any 68 to any 67 recv ${iif} ${fwcmd} add pass udp from any 67 to any 68 xmit ${iif} fi # Locat net anti-spoofing eval netif_net=\$firewall_net_${iif} if [ -n "${netif_net}" ]; then ${fwcmd} add deny all from any to not ${netif_net} xmit ${iif} ${fwcmd} add deny all from not ${netif_net} to any recv ${iif} fi done # Deny TCP fragments (use PATH mtu), allow rest ${fwcmd} add deny tcp from any to any frag # anti spoofing ${fwcmd} add deny all from table\(${astable}\) to any recv ${oif} ${fwcmd} add deny all from any to table\(${astable}\) xmit ${oif} # Well Known traffic not allowed: domain, smb, ... ${fwcmd} add reset tcp from any to any ${firewall_resetports} via ${oif} ${fwcmd} add reset tcp from any ${firewall_resetports} to any via ${oif} # Outgoing queues if checkyesno dummynet_enable ; then # Don't queue not outgoing traffic ${fwcmd} add skipto 10000 all from any to any in ${fwcmd} add skipto 30000 all from any to any not via ${oif} # ultra low / low for u in ${firewall_p2p_uids}; do if checkyesno ${u}_enable ; then ${fwcmd} add skipto ${lr} tcp from any to any \ uid ${u} established ${fwcmd} add skipto ${ulr} tcp from any to any \ uid ${u} setup ${fwcmd} add skipto ${ulr} udp from any to any \ uid ${u} fi done for iif in ${ifaces} ; do eval netif_p2p=\$firewall_p2p_${iif} set ${netif_p2p} while [ $# -ge 2 ]; do ${fwcmd} add skipto ${lr} tcp from $1 $2 to any established ${fwcmd} add skipto ${ulr} tcp from $1 $2 to any setup ${fwcmd} add skipto ${ulr} udp from $1 $2 to any shift ; shift done done # ultra fast ${fwcmd} add skipto ${ufr} tcp from any to any \ iptos lowdelay ${fwcmd} add skipto ${ufr} tcp from any to any \ tcpdatalen 0 established ${fwcmd} add skipto ${ufr} udp from me to any 53,123 # fast ${fwcmd} add skipto ${fr} tcp from any to any setup ${fwcmd} add skipto ${fr} tcp from any to any 22,443,2222 \ established # rest is normal ${fwcmd} add skipto ${nr} all from any to any # queues # ultra fast ${fwcmd} add ${ufr} queue ${ufq} all from any to any ${fwcmd} add skipto 30000 all from any to any # fast ${fwcmd} add ${fr} queue ${fq} all from any to any ${fwcmd} add skipto 30000 all from any to any # normal ${fwcmd} add ${nr} queue ${nq} all from any to any ${fwcmd} add skipto 30000 all from any to any # low ${fwcmd} add ${lr} queue ${lq} all from any to any ${fwcmd} add skipto 30000 all from any to any # ultra low ${fwcmd} add ${ulr} queue ${ulq} all from any to any ${fwcmd} add skipto 30000 all from any to any fi # incoming traffic ${fwcmd} add 10000 skipto 30000 all from any to any not via ${oif} # Open ports for port in ${firewall_myservices} ; do ${fwcmd} add pass tcp from any to me ${port} setup done for port in ${firewall_myudpports} ; do ${fwcmd} add pass udp from any to me ${port} done for user in ${firewall_p2p_uids}; do if checkyesno ${user}_enable ; then ${fwcmd} add pass tcp from any to me setup uid ${user} ${fwcmd} add pass udp from any to me uid ${user} fi done # Noise from routers ${fwcmd} add deny udp from any to any 520 recv ${oif} #setup natd ${fwcmd} add 30000 count all from any to any case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then ${fwcmd} add divert natd ip4 from any to any via ${natd_interface} fi ;; esac case ${firewall_nat_enable} in [Yy][Ee][Ss]) if [ -n "${firewall_nat_interface}" ]; then firewall_nat_flags="${firewall_nat_interface} ${firewall_nat_flags}" if echo "${firewall_nat_interface}" | \ grep -q -E '^[0-9]+(\.[0-9]+){0,3}$'; then firewall_nat_flags="ip ${firewall_nat_flags}" else firewall_nat_flags="if ${firewall_nat_flags}" fi ${fwcmd} nat 123 config log ${firewall_nat_flags} ${fwcmd} add nat 123 ip4 from any to any \ via ${firewall_nat_interface} fi ;; esac # Allow no TCP fragments ${fwcmd} add pass all from any to any frag # Allow packets for which a state has been built. ${fwcmd} add check-state # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established # icmp traffic # Allow "mandatory" ICMP in. ${fwcmd} add pass icmp from any to any icmptype 3,4,11 # Some servers will ping the IP while trying to decide ${fwcmd} add pass icmp from any to any icmptype 8 # pass outgoing traffic ${fwcmd} add pass tcp from any to any xmit ${oif} setup ${fwcmd} add pass udp from any to any xmit ${oif} keep-state ${fwcmd} add pass icmp from any to any xmit ${oif} keep-state # incoming from outside ${fwcmd} add skipto 60000 all from any to any not recv ${oif} # Open ports for iif in ${ifaces} ; do eval netif_p2p=\$firewall_p2p_${iif} set ${netif_p2p} while [ $# -ge 2 ]; do ${fwcmd} add pass tcp from any to $1 $2 setup ${fwcmd} add pass udp from any to $1 $2 shift ; shift done done # Drop packets to ports where we don't want logging for i in ${firewall_nologports} ; do ${fwcmd} add deny { tcp or udp } from any to any $i done # http connection teardowns ${fwcmd} add reset tcp from any 80,443 to any 1024-65535 # Deny and (if wanted) log the rest unconditionally. if checkyesno firewall_logdeny ; then log="log logamount 500" sysctl net.inet.ip.fw.verbose=1 >/dev/null fi ${fwcmd} add deny $log ip from any to any # Now it's safe to do local nets in ${fwcmd} add 60000 count all from any to any for iif in ${ifaces}; do # pass all traffic via the internal net eval netif_net=\$firewall_net_${iif} if [ -n "${netif_net}" ]; then ${fwcmd} add pass all from any to any via ${iif} else ${fwcmd} add pass all from any to any via ${iif} verrevpath fi done --------------080505020803060701030501-- From owner-freebsd-net@FreeBSD.ORG Wed Jun 2 02:40:04 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3583C106566B for ; Wed, 2 Jun 2010 02:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 240468FC0C for ; Wed, 2 Jun 2010 02:40:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o522e3rd024509 for ; Wed, 2 Jun 2010 02:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o522e3sU024508; Wed, 2 Jun 2010 02:40:03 GMT (envelope-from gnats) Date: Wed, 2 Jun 2010 02:40:03 GMT Message-Id: <201006020240.o522e3sU024508@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Jose M Rodriguez Cc: Subject: Re: kern/147191: [ppp] Problems with ppp -nat [pppoe], ipfw, dummynet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jose M Rodriguez List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 02:40:04 -0000 The following reply was made to PR kern/147191; it has been noted by GNATS. From: Jose M Rodriguez To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/147191: [ppp] Problems with ppp -nat [pppoe], ipfw, dummynet Date: Wed, 02 Jun 2010 04:31:49 +0200 This is a multi-part message in MIME format. --------------090100060803090709040905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit El 02/06/2010 2:37, Jose M Rodriguez escribió: > Seems that this must be reopen. > ... Seems this one worked, but I don't remember this last time I use ipfw on FreeBSD-7 --------------090100060803090709040905 Content-Type: text/plain; name="rc.firewall.router.4" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rc.firewall.router.4" #!/bin/sh - # Copyright (c) 1996 Poul-Henning Kamp # All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright # notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright # notice, this list of conditions and the following disclaimer in the # documentation and/or other materials provided with the distribution. # # THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE # ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # # $FreeBSD: src/etc/rc.firewall,v 1.60.2.3 2010/04/14 15:03:58 ume Exp $ # # $Log$ # # Setup system for ipfw(4) firewall service on AHS router # # Configuration: # firewall_resetports: # List of TCP ports reset on incoming # firewall_myservices: # List of TCP ports on which this host offers services. # firewall_myudpports: # List of UDP ports on which this host offers services. # firewall_logdeny: # Boolean (YES/NO) specifying if the default denied packets should be # logged (in /var/log/security). # firewall_nologports: # List of TCP/UDP ports for which denied incoming packets are not logged. # firewall_oif: # Outside IPv4 network interface, default to tun0. # firewall_iifaces: # Inside network interface list. # firewall_net_${iface} # IPv4 network definition for each of the previous interfaces. # firewall_p2p_${iface} # List of address ports for opened TCP/UDP ports on ${iface} # firewall_p2p_uids # List of uids of p2p daemons running on me # predefined firewall_resetports="53,113,135-139,445" firewall_p2p_uids="mlnet transmission" for u in ${firewall_p2p_uids}; do eval ${u}_enable="NO" done mpd_enable="NO" # Suck in the configuration variables. if [ -z "${source_rc_confs_defined}" ]; then if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf source_rc_confs elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi fi . /etc/rc.subr . /etc/network.subr afexists inet6 ipv6_available=$? # macros fwcmd="/sbin/ipfw" ifaces=${firewall_iifaces} if checkyesno mpd_enable ; then oif=${firewall_oif-ng0} else oif=${firewall_oif-tun0} fi log="" # Set quiet mode if requested checkyesno firewall_quiet && fwcmd="${fwcmd} -q" # Flush out the list before we begin. ${fwcmd} -f flush # setup loopback ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 ${fwcmd} add 300 deny all from 127.0.0.0/8 to any # setup ipv6 mandatory if [ $ipv6_available -ne 0 ]; then ${fwcmd} add 400 deny all from any to ::1 ${fwcmd} add 500 deny all from ::1 to any # DAD ${fwcmd} add pass ipv6-icmp from :: to ff02::/16 # RS, RA, NS, NA, redirect... ${fwcmd} add pass ipv6-icmp from fe80::/1o to fe80::/10 ${fwcmd} add pass ipv6-icmp from fe80::/1o to ff02::/16 # IMCPv6 destination unreachable, NS, NA, toobig ${fwcmd} add pass ipv6-icmp from any to any icmp6 types 1,2,135,136 fi # setup tables ${fwcmd} table all flush astable=1 astn=1 asln=2 aspn=3 asipv4=4 ascle=5 asmcast=6 # rfc 1912 local net ${fwcmd} table ${astable} add 0.0.0.0/8 ${asln} # this network ${fwcmd} table ${astable} add 127.0.0.0/8 ${asln} # local net ${fwcmd} table ${astable} add 255.0.0.0/8 ${asln} # local net # rfc 1918 private nets ${fwcmd} table ${astable} add 10.0.0.0/8 ${aspn} # private net ${fwcmd} table ${astable} add 172.16.0.0/12 ${aspn} # private net ${fwcmd} table ${astable} add 192.168.0.0/16 ${aspn} # private net # Link-local/APIPA (RFCs 3330 and 3927) ${fwcmd} table ${astable} add 169.254.0.0/16 ${aspn} # link-local/APIPA # TEST-NET-[1-3] for Documentation (RFC 5737) ${fwcmd} table ${astable} add 192.0.0.0/24 ${astn} # IETF net ${fwcmd} table ${astable} add 192.0.2.0/24 ${astn} # test net ${fwcmd} table ${astable} add 198.51.100.0/24 ${astn} # test net ${fwcmd} table ${astable} add 203.0.113.0/24 ${astn} # test net # Router Benchmark Testing (RFC 3330) ${fwcmd} table ${astable} add 198.18.0.0/15 ${astn} # router benchmark # IANA Reserved - Old Class E Space ${fwcmd} table ${astable} add 240.0.0.0/5 ${ascle} # old CLASS E ${fwcmd} table ${astable} add 248.0.0.0/6 ${ascle} # old CLASS E ${fwcmd} table ${astable} add 252.0.0.0/7 ${ascle} # old CLASS E ${fwcmd} table ${astable} add 254.0.0.0/8 ${ascle} # old CLASS E # Multicast ${fwcmd} table ${astable} add 224.0.0.0/3 ${asmcast} # other #${fwcmd} table ${astable} add 1.0.0.0/8 ${asipv4} # APNIC ${fwcmd} table ${astable} add 1.0.0.0/13 ${asipv4} ${fwcmd} table ${astable} add 1.8.0.0/16 ${asipv4} ${fwcmd} table ${astable} add 1.10.0.0/16 ${asipv4} ${fwcmd} table ${astable} add 1.20.0.0/16 ${asipv4} ${fwcmd} table ${astable} add 1.32.0.0/16 ${asipv4} ${fwcmd} table ${astable} add 1.37.0.0/16 ${asipv4} ${fwcmd} table ${astable} add 1.187.0.0/16 ${asipv4} ${fwcmd} table ${astable} add 5.0.0.0/8 ${asipv4} # Un. hamachi ${fwcmd} table ${astable} add 23.0.0.0/8 ${asipv4} # Un. bogon #${fwcmd} table ${astable} add 31.0.0.0/8 ${asipv4} # bogon/RIPE ${fwcmd} table ${astable} add 31.0.0.0/16 ${asipv4} ${fwcmd} table ${astable} add 31.1.0.0/21 ${asipv4} ${fwcmd} table ${astable} add 31.1.24.0/24 ${asipv4} ${fwcmd} table ${astable} add 36.0.0.0/7 ${asipv4} # bogon ${fwcmd} table ${astable} add 39.0.0.0/8 ${asipv4} # bogon ${fwcmd} table ${astable} add 42.0.0.0/8 ${asipv4} # bogon ${fwcmd} table ${astable} add 49.0.0.0/8 ${asipv4} # bogon ${fwcmd} table ${astable} add 100.0.0.0/6 ${asipv4} # bogon ${fwcmd} table ${astable} add 104.0.0.0/7 ${asipv4} # bogon ${fwcmd} table ${astable} add 106.0.0.0/8 ${asipv4} # bogon ${fwcmd} table ${astable} add 128.0.0.0/16 ${asipv4} # ARIN, rfc 3300? ${fwcmd} table ${astable} add 128.66.0.0/16 ${asipv4} # ARIN? ${fwcmd} table ${astable} add 177.0.0.0/8 ${asipv4} ${fwcmd} table ${astable} add 179.0.0.0/8 ${asipv4} ${fwcmd} table ${astable} add 181.0.0.0/8 ${asipv4} ${fwcmd} table ${astable} add 185.0.0.0/8 ${asipv4} #${fwcmd} table ${astable} add 191.255.0.0/16 ${asipv4} # LACNIC #${fwcmd} table ${astable} add 192.0.0.0/19 ${asipv4} # ARIN ${fwcmd} table ${astable} add 192.0.48.0/20 ${asipv4} # ARIN ${fwcmd} table ${astable} add 192.0.64.0/18 ${asipv4} # ARIN ${fwcmd} table ${astable} add 192.0.128.0/17 ${asipv4} # ARIN #${fwcmd} table ${astable} add 197.0.0.0/8 ${asipv4} # AfriNIC ${fwcmd} table ${astable} add 204.152.64.0/23 ${asipv4} # dummynet if checkyesno dummynet_enable ; then outp=1 ufq=2 ufr=8000 fq=3 fr=8400 nq=4 nr=8800 lq=5 lr=9200 ulq=6 ulr=9400 # tags, scheds, ... p2p=1 sched=1 # sysctl sysctl net.inet.ip.fw.one_pass=0 >/dev/null sysctl net.inet.ip.fw.verbose=0 >/dev/null sysctl net.inet.ip.dummynet.io_fast=1 >/dev/null # queues ${fwcmd} pipe ${outp} config bw ${firewall_outbw-0} \ burst ${firewall_out_burst-29840} ${fwcmd} queue ${ufq} config pipe ${outp} \ weight ${firewall_ufast_weight-100} queue 90 ${fwcmd} queue ${fq} config pipe ${outp} \ weight ${firewall_fast_weight-75} ${fwcmd} queue ${nq} config pipe ${outp} \ weight ${firewall_weight-40} ${fwcmd} queue ${lq} config pipe ${outp} \ weight ${firewall_lo_weight-25} ${fwcmd} queue ${ulq} config pipe ${outp} \ weight ${firewall_ulow_weight-1} ${fwcmd} sched ${sched} config type ${firewall_sched_type-QFQ} fi # RULES # # Danger Will Robinson. # Seems that on FreeBSD 8.1 you can't pass traffic in to be forwarded, or # queue/divert/outgoing rules can't see it. Strange. # #pass DHCP requests for if in $(list_net_interfaces dhcp) ; do ${fwcmd} add pass udp from any 67 to any 68 recv ${if} ${fwcmd} add pass udp from any 68 to any 67 xmit ${if} done #local nets for iif in ${ifaces}; do # pass dhcpv4 traffic from/to our server if checkyesno dhcpd_enable; then ${fwcmd} add pass udp from any 68 to any 67 recv ${iif} ${fwcmd} add pass udp from any 67 to any 68 xmit ${iif} fi # Locat net anti-spoofing eval netif_net=\$firewall_net_${iif} if [ -n "${netif_net}" ]; then ${fwcmd} add deny all from any to not ${netif_net} xmit ${iif} ${fwcmd} add deny all from not ${netif_net} to any recv ${iif} fi done # Deny TCP fragments (use PATH mtu), allow rest ${fwcmd} add deny tcp from any to any frag # anti spoofing ${fwcmd} add deny all from table\(${astable}\) to any recv ${oif} ${fwcmd} add deny all from any to table\(${astable}\) xmit ${oif} # Well Known traffic not allowed: domain, smb, ... ${fwcmd} add reset tcp from any to any ${firewall_resetports} via ${oif} ${fwcmd} add reset tcp from any ${firewall_resetports} to any via ${oif} # Outgoing queues if checkyesno dummynet_enable ; then # incoming traffic first, ultra low/low for iif in ${ifaces} ; do eval netif_p2p=\$firewall_p2p_${iif} set ${netif_p2p} while [ $# -ge 2 ]; do ${fwcmd} add skipto ${lr} tcp from $1 $2 to not me established ${fwcmd} add skipto ${ulr} tcp from $1 $2 to not me setup ${fwcmd} add skipto ${ulr} udp from $1 $2 to not me shift ; shift done ${fwcmd} add skipto ${nr} all from any to not me recv ${iif} done # Don't queue not outgoing traffic ${fwcmd} add skipto 10000 all from any to any in ${fwcmd} add skipto 30000 all from any to any not via ${oif} # ultra low / low for u in ${firewall_p2p_uids}; do if checkyesno ${u}_enable ; then ${fwcmd} add skipto ${lr} tcp from any to any \ uid ${u} established ${fwcmd} add skipto ${ulr} tcp from any to any \ uid ${u} setup ${fwcmd} add skipto ${ulr} udp from any to any \ uid ${u} fi done # ultra fast ${fwcmd} add skipto ${ufr} tcp from any to any \ iptos lowdelay ${fwcmd} add skipto ${ufr} tcp from any to any \ tcpdatalen 0 established ${fwcmd} add skipto ${ufr} udp from me to any 53,123 # fast ${fwcmd} add skipto ${fr} tcp from any to any setup ${fwcmd} add skipto ${fr} tcp from any to any 22,443,2222 \ established # rest is normal ${fwcmd} add skipto ${nr} all from any to any # queues # ultra fast ${fwcmd} add ${ufr} queue ${ufq} all from any to any ${fwcmd} add skipto 30000 all from any to any # fast ${fwcmd} add ${fr} queue ${fq} all from any to any ${fwcmd} add skipto 30000 all from any to any # normal ${fwcmd} add ${nr} queue ${nq} all from any to any ${fwcmd} add skipto 30000 all from any to any # low ${fwcmd} add ${lr} queue ${lq} all from any to any ${fwcmd} add skipto 30000 all from any to any # ultra low ${fwcmd} add ${ulr} queue ${ulq} all from any to any ${fwcmd} add skipto 30000 all from any to any fi # incoming traffic, from iif not for me ${fwcmd} add 10000 skipto 20000 all from any to any not via ${oif} # Open ports for port in ${firewall_myservices} ; do ${fwcmd} add pass tcp from any to me ${port} setup done for port in ${firewall_myudpports} ; do ${fwcmd} add pass udp from any to me ${port} done for user in ${firewall_p2p_uids}; do if checkyesno ${user}_enable ; then ${fwcmd} add pass tcp from any to me setup uid ${user} ${fwcmd} add pass udp from any to me uid ${user} fi done # Noise from routers ${fwcmd} add deny udp from any to any 520 recv ${oif} #setup natd ${fwcmd} add 30000 count all from any to any case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then ${fwcmd} add divert natd ip4 from any to any via ${natd_interface} fi ;; esac case ${firewall_nat_enable} in [Yy][Ee][Ss]) if [ -n "${firewall_nat_interface}" ]; then firewall_nat_flags="${firewall_nat_interface} ${firewall_nat_flags}" if echo "${firewall_nat_interface}" | \ grep -q -E '^[0-9]+(\.[0-9]+){0,3}$'; then firewall_nat_flags="ip ${firewall_nat_flags}" else firewall_nat_flags="if ${firewall_nat_flags}" fi ${fwcmd} nat 123 config log ${firewall_nat_flags} ${fwcmd} add nat 123 ip4 from any to any \ via ${firewall_nat_interface} fi ;; esac # Allow no TCP fragments ${fwcmd} add pass all from any to any frag # Allow packets for which a state has been built. ${fwcmd} add check-state # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established # icmp traffic # Allow "mandatory" ICMP in. ${fwcmd} add pass icmp from any to any icmptype 3,4,11 # Some servers will ping the IP while trying to decide ${fwcmd} add pass icmp from any to any icmptype 8 # pass outgoing traffic ${fwcmd} add pass tcp from any to any xmit ${oif} setup ${fwcmd} add pass udp from any to any xmit ${oif} keep-state ${fwcmd} add pass icmp from any to any xmit ${oif} keep-state # incoming from outside ${fwcmd} add skipto 60000 all from any to any not recv ${oif} # Open ports for iif in ${ifaces} ; do eval netif_p2p=\$firewall_p2p_${iif} set ${netif_p2p} while [ $# -ge 2 ]; do ${fwcmd} add pass tcp from any to $1 $2 setup ${fwcmd} add pass udp from any to $1 $2 shift ; shift done done # Drop packets to ports where we don't want logging for i in ${firewall_nologports} ; do ${fwcmd} add deny { tcp or udp } from any to any $i done # http connection teardowns ${fwcmd} add reset tcp from any 80,443 to any 1024-65535 # Deny and (if wanted) log the rest unconditionally. if checkyesno firewall_logdeny ; then log="log logamount 500" sysctl net.inet.ip.fw.verbose=1 >/dev/null fi ${fwcmd} add deny $log ip from any to any # Now it's safe to do local nets in ${fwcmd} add 60000 count all from any to any for iif in ${ifaces}; do # pass all traffic via the internal net eval netif_net=\$firewall_net_${iif} if [ -n "${netif_net}" ]; then ${fwcmd} add pass all from any to any via ${iif} else ${fwcmd} add pass all from any to any via ${iif} verrevpath fi done --------------090100060803090709040905-- From owner-freebsd-net@FreeBSD.ORG Wed Jun 2 03:51:45 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F41E106566B; Wed, 2 Jun 2010 03:51:45 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 990298FC08; Wed, 2 Jun 2010 03:51:44 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 88C18A55D9C; Wed, 2 Jun 2010 11:51:33 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id 3XIdDL-IRA-M; Wed, 2 Jun 2010 11:51:27 +0800 (CST) Received: from quakelee-work (unknown [219.142.100.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 079C0A5643C; Wed, 2 Jun 2010 11:51:27 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=geekcn.org; c=nofws; q=dns; h=content-type:to:subject:references:date:cc:mime-version: content-transfer-encoding:from:organization:message-id:in-reply-to:user-agent; b=tzwqh1HiCY41o66QYLx4k0hs+C4kn7ed4KOdtDQh82tY53xSfw0LJtzzPaDMggFTo iGjbTb7EoK/Zz4ryKxeUA== Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "freebsd-stable@freebsd.org" References: Date: Wed, 02 Jun 2010 11:51:26 +0800 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Chao Shin" Organization: GeekCN Message-ID: In-Reply-To: User-Agent: Opera Mail/10.51 (Win32) Cc: "freebsd-net@freebsd.org" Subject: Re: panic: rtqkill route really not free on freebsd 8.0-release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 03:51:45 -0000 I worte: > Hi all, > > I have four heavy load mysql database servers which system is 8.0-release > got "panic: rtqkill route really not free" this week. We have a gateway > set up by OpenBSD have a icmp route redirect function between two > subnets, > I suspect the FreeBSD panic at trying to delete routes sent from that > gateway. > > So I set sysctl net.inet.icmp.drop_redirect=1, no more panic in past 24 > hours. > I guess maybe miss some locks or wrong delete route path in 8.0-release. > > Did any one meet this problem before? > After four days research we think the problem is between function in_matroute and in_rtqkill. This two functions' conflicted at processing RTPRF_OURS flag routes. In my opinion, it is a design problem, so I have no idea about how to resolve it. The simple way I think is change the panic assert in in_rtqkill, treat it as a normal state not assert a panic. -- The Power to Serve From owner-freebsd-net@FreeBSD.ORG Wed Jun 2 07:21:06 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F7B6106566C; Wed, 2 Jun 2010 07:21:06 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DB9088FC1E; Wed, 2 Jun 2010 07:21:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o527L5n0082650; Wed, 2 Jun 2010 07:21:05 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o527L5Td082646; Wed, 2 Jun 2010 07:21:05 GMT (envelope-from linimon) Date: Wed, 2 Jun 2010 07:21:05 GMT Message-Id: <201006020721.o527L5Td082646@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/147307: [gre] gre(4) interface is created with flag RUNNING missing during the boot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 07:21:06 -0000 Old Synopsis: gre(4) interface is created with flag RUNNING missing during the boot New Synopsis: [gre] gre(4) interface is created with flag RUNNING missing during the boot Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jun 2 07:20:48 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=147307 From owner-freebsd-net@FreeBSD.ORG Wed Jun 2 13:55:15 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33F0D106566B for ; Wed, 2 Jun 2010 13:55:15 +0000 (UTC) (envelope-from ferdinand.goldmann@jku.at) Received: from emailsecure.uni-linz.ac.at (emailsecure.uni-linz.ac.at [140.78.3.66]) by mx1.freebsd.org (Postfix) with ESMTP id E7D518FC18 for ; Wed, 2 Jun 2010 13:55:14 +0000 (UTC) Received: from dyn-ant77.edvz.uni-linz.ac.at (dyn-ant77.edvz.uni-linz.ac.at [140.78.6.77]) by emailsecure.uni-linz.ac.at (Postfix) with ESMTPSA id D88D5B907 for ; Wed, 2 Jun 2010 15:55:13 +0200 (CEST) Message-ID: <4C0662C1.9020500@jku.at> Date: Wed, 02 Jun 2010 15:55:13 +0200 From: Ferdinand Goldmann Organization: Johannes Kepler University Linz - Information Management User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4C052101.8080404@jku.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: carp + carpdev option? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 13:55:15 -0000 On 01.06.10 18:37, Freddie Cash wrote: > Here's hoping that it gets added in some future update of pf/carp from > OpenBSD. :) It's the final missing link in our dreams of redundant > firewalls/routers and storage servers. Well, I'm hoping that, too. If there are any patches to be tested, I would be willing to help out. Having the carpdev feature would be great. Regards, Ferdinand Goldmann -- >> Ferdinand Goldmann >> Johannes Kepler University Linz - Server Systems/Information Management >> Mail: Ferdinand.Goldmann@jku.at Phone: 00437024689398 Fax: 00437024689397 From owner-freebsd-net@FreeBSD.ORG Wed Jun 2 23:01:55 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 593541065673 for ; Wed, 2 Jun 2010 23:01:55 +0000 (UTC) (envelope-from gnn@freebsd.org) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 328488FC17 for ; Wed, 2 Jun 2010 23:01:55 +0000 (UTC) Received: from smtp.hudson-trading.com ([209.249.190.9] helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OJw7n-0004gR-5t for net@freebsd.org; Wed, 02 Jun 2010 18:09:23 -0400 From: George Neville-Neil Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Jun 2010 18:09:22 -0400 Message-Id: <0BC7AD09-B627-4F6A-AD93-B7E794A78CA2@freebsd.org> To: net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freebsd.org X-Source: X-Source-Args: X-Source-Dir: Cc: Subject: A slight change to tcpip_fillheaders... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 23:01:55 -0000 Howdy, A while back another src developer mentioned that he had gotten better = performance by changing tcpip_fillheaders() in the following way: Index: tcp_subr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- tcp_subr.c (revision 209083) +++ tcp_subr.c (working copy) @@ -392,28 +392,19 @@ struct ip *ip; =20 ip =3D (struct ip *)ip_ptr; + bzero(ip, sizeof(*ip)); ip->ip_v =3D IPVERSION; ip->ip_hl =3D 5; ip->ip_tos =3D inp->inp_ip_tos; - ip->ip_len =3D 0; - ip->ip_id =3D 0; - ip->ip_off =3D 0; ip->ip_ttl =3D inp->inp_ip_ttl; - ip->ip_sum =3D 0; ip->ip_p =3D IPPROTO_TCP; ip->ip_src =3D inp->inp_laddr; ip->ip_dst =3D inp->inp_faddr; } + bzero(th, sizeof(*th)); th->th_sport =3D inp->inp_lport; th->th_dport =3D inp->inp_fport; - th->th_seq =3D 0; - th->th_ack =3D 0; - th->th_x2 =3D 0; th->th_off =3D 5; - th->th_flags =3D 0; - th->th_win =3D 0; - th->th_urp =3D 0; - th->th_sum =3D 0; /* in_pseudo() is called later = for ipv4 */ } =20 /* I have tried this change with NetPIPE (NPtcp -b 100000) on a pair of = machines using Intel igb devices and found that it provides no improvement, but I am wondering if other people want = to try this and see if it improves throughput at all. I was testing this on a Nehalem = class machine, not sure if it might help on other architectures. Best, George From owner-freebsd-net@FreeBSD.ORG Wed Jun 2 23:10:29 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48265106566B for ; Wed, 2 Jun 2010 23:10:29 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id DBF7A8FC2E for ; Wed, 2 Jun 2010 23:10:28 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id CC47FA551C0; Thu, 3 Jun 2010 07:10:27 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id hxh2-KUj4I+t; Thu, 3 Jun 2010 07:10:20 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 8A5E5A55185; Thu, 3 Jun 2010 07:10:19 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:references:in-reply-to:x-enigmail-version:openpgp: content-type:content-transfer-encoding; b=nEVN6nlLye8jmlxAcGFcLa943IEbee2G2G5OVcjZrHlvzbYlMp6Y4mUgLZCq9PXQ+ ugMYn0EZjHrAK1J5+W9ig== Message-ID: <4C06E4D7.5020301@delphij.net> Date: Wed, 02 Jun 2010 16:10:15 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100408 Thunderbird/3.0.4 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <0BC7AD09-B627-4F6A-AD93-B7E794A78CA2@freebsd.org> In-Reply-To: <0BC7AD09-B627-4F6A-AD93-B7E794A78CA2@freebsd.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: A slight change to tcpip_fillheaders... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 23:10:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010/06/02 15:09, George Neville-Neil wrote: > Howdy, > > A while back another src developer mentioned that he had gotten better performance by changing > tcpip_fillheaders() in the following way: [...] > I have tried this change with NetPIPE (NPtcp -b 100000) on a pair of machines using Intel igb devices and found > that it provides no improvement, but I am wondering if other people want to try this and > see if it improves throughput at all. I was testing this on a Nehalem class machine, not sure if it > might help on other architectures. I'd for this change if it doesn't cause performance regression :) Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBCAAGBQJMBuTXAAoJEATO+BI/yjfBj20H/iET4oZ6HrLpVcOea05yHfEd JdWdRXT8Ti4IVKhRN+6VsKWpQ0RxLEzi51YShQ/zNpqwDTF9hWiTMxKZh//90EyW GRxOPNKI94R/mo1uEDBIpPNZBvxn1cUy9Y+Q+A+P5kY6DK7L2+LVYRTk3UxO+gM4 jXUloDQQwg52o+nmgjE332ucMM2+r5ikDazoagDGsn6uIlSj0vhEsBxKtcU46M2w lLcdSVXs5hw9cX52o1JvNlyAejCHWKnp45PFqrPMCA+4TR2+Mr+kVgjjjoY4/aTz 38XyUxF3e921zh5kgdFrf8Fox8Aac+mpc9UYEoDQ/TU7TnUY5Rsz10SfZl2WPRo= =/aoI -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Jun 3 01:12:27 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33DBD106566B; Thu, 3 Jun 2010 01:12:27 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0C1978FC13; Thu, 3 Jun 2010 01:12:27 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o531CQna046761; Thu, 3 Jun 2010 01:12:26 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o531CQvW046757; Thu, 3 Jun 2010 01:12:26 GMT (envelope-from linimon) Date: Thu, 3 Jun 2010 01:12:26 GMT Message-Id: <201006030112.o531CQvW046757@freefall.freebsd.org> To: emz@norma.perm.ru, linimon@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/147307: [gre] gre(4) interface is created with flag RUNNING missing during the boot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 01:12:27 -0000 Synopsis: [gre] gre(4) interface is created with flag RUNNING missing during the boot State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Thu Jun 3 01:12:07 UTC 2010 State-Changed-Why: Duplicate of kern/138407. http://www.freebsd.org/cgi/query-pr.cgi?pr=147307 From owner-freebsd-net@FreeBSD.ORG Thu Jun 3 03:18:52 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA3C41065670; Thu, 3 Jun 2010 03:18:52 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 817838FC0A; Thu, 3 Jun 2010 03:18:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o533Iq4V051972; Thu, 3 Jun 2010 03:18:52 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o533IqQZ051968; Thu, 3 Jun 2010 03:18:52 GMT (envelope-from linimon) Date: Thu, 3 Jun 2010 03:18:52 GMT Message-Id: <201006030318.o533IqQZ051968@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/147352: [netinet] [patch] replace printf() with log() for "Limiting ..." X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 03:18:52 -0000 Old Synopsis: [net] [patch] replace printf() with log() for "Limiting ..." New Synopsis: [netinet] [patch] replace printf() with log() for "Limiting ..." Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jun 3 03:18:35 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=147352 From owner-freebsd-net@FreeBSD.ORG Thu Jun 3 06:40:03 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C779106567B for ; Thu, 3 Jun 2010 06:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 217F58FC39 for ; Thu, 3 Jun 2010 06:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o536e2Td032301 for ; Thu, 3 Jun 2010 06:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o536e2Og032300; Thu, 3 Jun 2010 06:40:02 GMT (envelope-from gnats) Date: Thu, 3 Jun 2010 06:40:02 GMT Message-Id: <201006030640.o536e2Og032300@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Remko Lodder Cc: Subject: Re: kern/138407: [gre] gre(4) interface does not come up after reboot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Remko Lodder List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 06:40:03 -0000 The following reply was made to PR kern/138407; it has been noted by GNATS. From: Remko Lodder To: bug-followup@FreeBSD.org, nkritsky@mail.ru Cc: Subject: Re: kern/138407: [gre] gre(4) interface does not come up after reboot Date: Thu, 3 Jun 2010 08:12:10 +0200 For what it's worth, I have been bitten by this as well. -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Thu Jun 3 07:16:33 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF060106567A for ; Thu, 3 Jun 2010 07:16:32 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 4AE088FC20 for ; Thu, 3 Jun 2010 07:16:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o537FvdQ039302; Thu, 3 Jun 2010 17:15:58 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 3 Jun 2010 17:15:57 +1000 (EST) From: Ian Smith To: Jose M Rodriguez In-Reply-To: <201006020240.o522e3sU024508@freefall.freebsd.org> Message-ID: <20100603154510.T27982@sola.nimnet.asn.au> References: <201006020240.o522e3sU024508@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1579116833-1275549357=:27982" Cc: freebsd-net@freebsd.org Subject: Re: kern/147191: [ppp] Problems with ppp -nat [pppoe], ipfw, dummynet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 07:16:33 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1579116833-1275549357=:27982 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 2 Jun 2010, Jose M Rodriguez wrote: > The following reply was made to PR kern/147191; it has been noted by GNATS. > > From: Jose M Rodriguez > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/147191: [ppp] Problems with ppp -nat [pppoe], ipfw, dummynet > Date: Wed, 02 Jun 2010 04:31:49 +0200 [..] > El 02/06/2010 2:37, Jose M Rodriguez escribió: > > Seems that this must be reopen. > > ... > Seems this one worked, but I don't remember this last time I use ipfw on > FreeBSD-7 > [..] > Content-Disposition: attachment; > filename="rc.firewall.router.4" > > #!/bin/sh - > # Copyright (c) 1996 Poul-Henning Kamp > # All rights reserved. [..] > # $FreeBSD: src/etc/rc.firewall,v 1.60.2.3 2010/04/14 15:03:58 ume Exp $ I had to do a 'diff -uw rc.firewall.1.60.2.3 rc.firewall.router.4' (and before that, vs your previous rc.firewall.router.1) to follow what was going on here; you've added some 'interesting' stuff (esp dummynet), but I think your main problem is the placement of the NAT rule, where you've merged it into what is otherwise based on the 'workstation' ruleset. Refer to the standard rc.firewall 'simple' ruleset: note carefully that there the NAT diversion occurs between two sets of anti-spoofing rules, such that we have, in effect, for both inbound and outbound packets: 1) deny all from any to $RFC1918_etc_nets via ${oif} 2) # perform NAT (by natd or ipfw nat) 3) deny all from $RFC1918_etc_nets to any via ${oif} You've used a table for these nets, great, but in the following rules you are doing step (3) _before_ doing NAT, likely blocking some packets before they've been mapped to your outside IP address. I think this may be why you then had to handle local net traffic later, and also that this will affect your shaping rules similarly, as you mentioned earlier. I believe julian@ first proposed changing rc.firewall to use a table with two rules rather than bunches of individual rules, here: http://lists.freebsd.org/pipermail/freebsd-ipfw/2008-November/003661.html but you'll notice he maintained the correct positioning of these rules. You have: > # rfc 1912 local net > ${fwcmd} table ${astable} add 0.0.0.0/8 ${asln} # this network > ${fwcmd} table ${astable} add 127.0.0.0/8 ${asln} # local net > ${fwcmd} table ${astable} add 255.0.0.0/8 ${asln} # local net > # rfc 1918 private nets > ${fwcmd} table ${astable} add 10.0.0.0/8 ${aspn} # private net > ${fwcmd} table ${astable} add 172.16.0.0/12 ${aspn} # private net > ${fwcmd} table ${astable} add 192.168.0.0/16 ${aspn} # private net etc, then .. > # anti spoofing > ${fwcmd} add deny all from table\(${astable}\) to any recv ${oif} > ${fwcmd} add deny all from any to table\(${astable}\) xmit ${oif} but only later, after all your dummynet rules, do you either skipto 30000, or skipto your queue rules then skipto 30000, where you at last perform the NAT translation, which should already have been done. Further, your anti-spoofing rules, the second of which should be before doing NAT but the first _after_ doing NAT, are one case where using 'via' rather than recv/xmit is appropriate, as you want to block these nets on egress from your router as well as on ingress, right? I suspect that if you weave your NAT diversion into the right place (sooner) and place the anti-spoofing rules properly either side, things should work more as you expect. Maybe add some more temporary logging rules to check what's happening before and after NAT mapping? cheers, Ian --0-1579116833-1275549357=:27982-- From owner-freebsd-net@FreeBSD.ORG Thu Jun 3 08:45:27 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9C44106567C for ; Thu, 3 Jun 2010 08:45:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 539538FC1E for ; Thu, 3 Jun 2010 08:45:27 +0000 (UTC) Received: from c122-106-160-243.carlnfd1.nsw.optusnet.com.au (c122-106-160-243.carlnfd1.nsw.optusnet.com.au [122.106.160.243]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o538jNrp011537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jun 2010 18:45:25 +1000 Date: Thu, 3 Jun 2010 18:45:22 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: George Neville-Neil In-Reply-To: <0BC7AD09-B627-4F6A-AD93-B7E794A78CA2@freebsd.org> Message-ID: <20100603181439.Q27699@delplex.bde.org> References: <0BC7AD09-B627-4F6A-AD93-B7E794A78CA2@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@freebsd.org Subject: Re: A slight change to tcpip_fillheaders... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 08:45:27 -0000 On Wed, 2 Jun 2010, George Neville-Neil wrote: > A while back another src developer mentioned that he had gotten better performance by changing > tcpip_fillheaders() in the following way: It's unlikely to make any significant or even measurable difference, but... I got apparent large (up to 20%) timing improvments in networking by similar changes (mostly going the other way and avoiding and/or bzero()), but further investigation showed that the improvements were very mysterious and mostly unrelated to my code changes -- equal improvements could be obtained by adding padding or reducing code size in unrelated code. This might be explained by thrashing or avoiding thrashing of cache(s), but the effect was too large to easily explain, and too mysterious to easily obtain or avoid. > Index: tcp_subr.c > =================================================================== > --- tcp_subr.c (revision 209083) > +++ tcp_subr.c (working copy) > @@ -392,28 +392,19 @@ > struct ip *ip; > > ip = (struct ip *)ip_ptr; > + bzero(ip, sizeof(*ip)); > ip->ip_v = IPVERSION; > ip->ip_hl = 5; > ip->ip_tos = inp->inp_ip_tos; > - ip->ip_len = 0; > - ip->ip_id = 0; > - ip->ip_off = 0; > ip->ip_ttl = inp->inp_ip_ttl; > - ip->ip_sum = 0; > ip->ip_p = IPPROTO_TCP; > ip->ip_src = inp->inp_laddr; > ip->ip_dst = inp->inp_faddr; > } > + bzero(th, sizeof(*th)); > th->th_sport = inp->inp_lport; > th->th_dport = inp->inp_fport; > - th->th_seq = 0; > - th->th_ack = 0; > - th->th_x2 = 0; > th->th_off = 5; > - th->th_flags = 0; > - th->th_win = 0; > - th->th_urp = 0; > - th->th_sum = 0; /* in_pseudo() is called later for ipv4 */ > } > > /* The version with bzero() is a small or null pessimization assuming that the compiler is infinitiely smart. If all the fields are initialized by both versions, then the result is the same, so the compiler may produce the same code for each. The version with bzero() obvious initializes all the fields, but might not. Howver, bzero() is extern in FreeBSD, and gcc doesn't attempt optimizations like inlining it despite it being extern, so the version with bzero() is fundamentally slower in theory. My changes initially involved implementing all bzero() with small fixed size using __builtin_memset(). gcc will inline these, hopefully using writes of a register or immediate constant value of 0. Many i386 versions of gcc are stupid about this and use the slow i386 string instructions instead, but most use separate writes of 0 if the length is small, and I try to choose the small size so small that the separate writes are used. For the version with the explicit separate writes of 0, many of the fields are smaller than the register size, but none are volatile so the compiler is free to combine the writes. gcc does optimizations like this. I don't know if it actually does them all or if it is inhibited by the writes of nonzero for a few fields (C requires write ordering to appear to be strict, but hopefully there aren't any aliasing problems in the above which require it to actually be strict). > I have tried this change with NetPIPE (NPtcp -b 100000) on a pair of machines using Intel igb devices and found > that it provides no improvement, but I am wondering if other people want to try this and > see if it improves throughput at all. I was testing this on a Nehalem class machine, not sure if it > might help on other architectures. And don't forget, for such a change to be good, it needs to be good on most supported machines and not too bad on other supported machines. This is especially hard to even test for changes related to memory and caches. Bruce From owner-freebsd-net@FreeBSD.ORG Thu Jun 3 12:42:20 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF0F41065672 for ; Thu, 3 Jun 2010 12:42:20 +0000 (UTC) (envelope-from sneginha@vmware.com) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [65.115.85.73]) by mx1.freebsd.org (Postfix) with ESMTP id 9309B8FC0A for ; Thu, 3 Jun 2010 12:42:20 +0000 (UTC) Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 10C055A002 for ; Thu, 3 Jun 2010 05:22:47 -0700 (PDT) Received: from pa-excaht04.vmware.com (pa-excaht04.vmware.com [10.113.81.155]) by mailhost3.vmware.com (Postfix) with ESMTP id 074C1CD94C for ; Thu, 3 Jun 2010 05:22:47 -0700 (PDT) Received: from EXCH-MBX-2.vmware.com ([10.113.81.224]) by pa-excaht04.vmware.com ([10.113.81.155]) with mapi; Thu, 3 Jun 2010 05:22:47 -0700 From: Srinivas Neginhal To: "freebsd-net@freebsd.org" Date: Thu, 3 Jun 2010 05:22:45 -0700 Thread-Topic: Question on ACKs on out-of-window packets Thread-Index: AQHLAxd4oJyqXEltG0m8g+eI0DpQJQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Question on ACKs on out-of-window packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 12:42:20 -0000 Hi, I had a question on how the current tcp_input()/tcp_do_segment() code = handles ACKs on out-of-window packets. Specifically, The code to handle packets which fall entirely to the le= ft of the window. Here is the scenario I am analyzing right now. 1. Client has sent out a window worth of data to the server and is waiting = for acks, it can't send any more data. 2. The server is also sending data to the client. 3. The client has received everything the server had to send and has sent s= ent an ack for the last byte. 4. Further, for what ever reason the ACK the client sent to the server take= s longer than usual time to get to the server. 5. The server decides to retransmit earlier packets. And it starts way back= . 6. It retransmits an old packet but now piggybacks an ACK for all the data = the client sent the server. Now, say, this old packet has the following attributes Sequence number: 100000=20 Acknowledgement number : 300000 Packet Len: 1448 bytes. Say the client has the following=20 rcv_nxt: 105000. wl1: 104000. This entire packet falls to the left of the receive window. The ack on this= packet would be processed but the window update won't happen. Now at the same time if the server receives and processes the latest ACK th= e client sent in step 3 above (for 105000), it would stop all retransmissio= n. The server has no more data to send to the client.=20 Also, since the server has already sent an ACK for all the data the client = sent it, it won't send a pure ACK either. The client would be stuck with a snd_wnd of 0. At the least, wouldn't this trigger unnecessary window probes? In my particular case, the persist timer has not been triggered either sinc= e tcp_output() never got called. Solaris seems to have changed their window update code=20 http://blogs.sun.com/kcpoon/entry/solaris_tcp_window_update This is not really as per the RFC but would fix the problem I am dealing wi= th. Any thoughts? Regards, Srinivas From owner-freebsd-net@FreeBSD.ORG Thu Jun 3 12:53:03 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 337401065676 for ; Thu, 3 Jun 2010 12:53:03 +0000 (UTC) (envelope-from alteriks@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id BD8738FC1D for ; Thu, 3 Jun 2010 12:53:01 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so823768fgb.13 for ; Thu, 03 Jun 2010 05:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=WuMzGwPQydAFqeFhKtuNbFL279mkMl27GljSh3MnJ4U=; b=xY6V59x9pezpF7bZem3b9wpQL0SiGgAUjZuMXpmVh9ZEqx4BzJRDEkGtbz0Bp8dySR b2RkVvbpce8YewA29RBq1V9RTWGtnUAeDqNpADp2kb8sbaJQK8ieX7cvpce+RIsyCfu8 uwPOrNeu1OYUSw+28CCY1L6as2DCrJ/EaCQC4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=YNc4uTnYKjwDS2mZ7br8FI7AAiizBAosS9Arx2N8DZJjcS4HmHIUomT72Rw7hsmD76 VNNpWpIcZUt1MMP/29r3NmnzYwuWKm50c9CIcvhR718pyL8wgZx/E0UPVQVFdb1vnmv6 BWgx06SkQ1rOjX/ARdVzmb6IdO2+D4LzwEA0Q= Received: by 10.239.148.8 with SMTP id d8mr138211hbb.144.1275567898133; Thu, 03 Jun 2010 05:24:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.161.146 with HTTP; Thu, 3 Jun 2010 05:24:38 -0700 (PDT) From: Krzysztof Dajka Date: Thu, 3 Jun 2010 14:24:38 +0200 Message-ID: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Is enabling jumbo frames on RTL8111C possible? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 12:53:03 -0000 Hi, I'm trying to enable jumbo frames on my re0 NIC. I tried: # ifconfig re0 mtu 1600 ifconfig: ioctl (set mtu): Invalid argument I have found in /usr/src/sys/dev/re/if_re.c /* * These controllers support jumbo frame but it seems * that enabling it requires touching additional magic * registers. Depending on MAC revisions some * controllers need to disable checksum offload. So * disable jumbo frame until I have better idea what * it really requires to make it support. * RTL8168C/CP : supports up to 6KB jumbo frame. * RTL8111C/CP : supports up to 9KB jumbo frame. */ pciconf -lv shows: re0@pci0:2:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' class = network subclass = ethernet Do I need to set some quirks in boot process to enable jumbo frames, or it cannot be done because it's not implemented in the driver. I tried setting larger mtu than 1500 on Debian Squeeze and it worked well, so definitely my chip supports jumbo frames From owner-freebsd-net@FreeBSD.ORG Thu Jun 3 13:52:16 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1D0D1065674 for ; Thu, 3 Jun 2010 13:52:15 +0000 (UTC) (envelope-from perevalov84@gmail.com) Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by mx1.freebsd.org (Postfix) with ESMTP id BF6C18FC12 for ; Thu, 3 Jun 2010 13:52:15 +0000 (UTC) Received: by pzk5 with SMTP id 5so37275pzk.14 for ; Thu, 03 Jun 2010 06:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=1RXojfJLQ+/Qy6ejRhU/ZISDHVJ1o40WygbHRHcZ87M=; b=tDsVp+jDvs981+kMwmIaERgXgXY3wV/nrEbbneqr/N35VDYlTfKmIn6wghKjCQh3AX 6LVx07pd0/fYmox9JXtcYSYZQT4x0/omrI6MeWNELDdHyBqrnkaeiwzPhNU7XBAEAlRD zS3zG9qwUxVtuvGs+xshB52fxVJQhVcSt1m3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=At30uSzIDK8AbX+84KBqX8NUisnPB6MFFoC43jrzC4zwWELxQN1O4NtFGVPkxJEYr0 4G7TrLm6SF4vYYo1p1B4bAViTsrvKJ15VsYtc20EvcIqEIQeUoZnMrH4YUA68VyDDhvi XDldqhimcjCjAsHPozaHPuUmnwUK2G4Fdshw4= Received: by 10.140.248.10 with SMTP id v10mr8146549rvh.245.1275573135033; Thu, 03 Jun 2010 06:52:15 -0700 (PDT) Received: from [192.168.2.2] ([92.47.64.220]) by mx.google.com with ESMTPS id q10sm1225381rvp.8.2010.06.03.06.52.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Jun 2010 06:52:13 -0700 (PDT) Message-ID: <4C07B344.4060805@gmail.com> Date: Thu, 03 Jun 2010 18:51:00 +0500 From: Perevalov Sergey User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100506 Thunderbird/3.0.4 MIME-Version: 1.0 To: pyunyh@gmail.com, freebsd-net@freebsd.org References: <4BE44E2D.6060907@gmail.com> <20100507210516.GI14801@michelle.cdnetworks.com> <4C01760E.2080403@gmail.com> <20100531223204.GE1577@michelle.cdnetworks.com> <4C0551F1.2010609@gmail.com> <20100601222444.GH1577@michelle.cdnetworks.com> In-Reply-To: <20100601222444.GH1577@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: [axe][ue0] Device send packets but any host in network can not receive any packet from it. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 13:52:16 -0000 On 02.06.2010 03:24, Pyun YongHyeon wrote: > On Tue, Jun 01, 2010 at 11:31:13PM +0500, Perevalov Sergey wrote: > >> Hi! >> I tried it with crossover cable but results was the same bad. Then set >> debug flag hw.usb.axe.debug: to 15, and started ping -f from ue0. >> And in /var/log/messages I found these strings: >> >> Jun 1 22:28:34 laptop kernel: axe_bulk_read_callback:842: bulk read >> error, USB_ERR_CANCELLED >> Jun 1 22:28:35 laptop kernel: axe_bulk_write_callback:870: transfer >> complete >> Jun 1 22:29:12 laptop kernel: axe_bulk_write_callback:941: transfer >> error, USB_ERR_TIMEOUT >> Jun 1 22:29:51 laptop last message repeated 4 times >> Jun 1 22:31:40 laptop last message repeated 11 times >> >> Then i googled it and found this >> http://www.mail-archive.com/freebsd-usb@freebsd.org/msg04388.html >> the problem is described definitely like mine. >> I read all thread and found the patch usb2_ethernet.patch2, but I havn't >> found >> sys/dev/usb2/ethernet/usb2_ethernet.c file for patch. >> >> how can I try to apply this patch to my system? >> http://www.mail-archive.com/freebsd-usb@freebsd.org/msg04403.html >> >> > I believe the bug in the thread was fixed long time ago. > If you're using 8.0-RELEASE, try latest stable/8 or > 8.1-PRERELEASE and see whether axe(4) works or not. > > I have just finished testing device on my updated freebsd: FreeBSD homeserv 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #0: Thu Jun 3 17:22:44 UTC 2010 user@homeserv:/usr/obj/usr/src/sys/GENERIC i386 And it still shows the same problem when I try to ping -f any host from ue0: Jun 3 18:29:40 homeserv kernel: ue0: link state changed to UP Jun 3 18:29:42 homeserv kernel: axe_bulk_write_callback: transfer complete Jun 3 18:29:42 homeserv last message repeated 21 times Jun 3 18:29:52 homeserv kernel: axe_bulk_write_callback: transfer error, USB_ERR_TIMEOUT Jun 3 18:30:21 homeserv last message repeated 3 times -- Regards, Sergey. From owner-freebsd-net@FreeBSD.ORG Thu Jun 3 14:31:57 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DBF11065670 for ; Thu, 3 Jun 2010 14:31:57 +0000 (UTC) (envelope-from gnn@freebsd.org) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 301F18FC0A for ; Thu, 3 Jun 2010 14:31:56 +0000 (UTC) Received: from smtp.hudson-trading.com ([209.249.190.9] helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OKBSd-0000Nw-MO; Thu, 03 Jun 2010 10:31:55 -0400 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: George Neville-Neil In-Reply-To: <20100603181439.Q27699@delplex.bde.org> Date: Thu, 3 Jun 2010 10:31:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <54198502-A432-4FA7-9176-0AB85D809597@freebsd.org> References: <0BC7AD09-B627-4F6A-AD93-B7E794A78CA2@freebsd.org> <20100603181439.Q27699@delplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.1078) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freebsd.org X-Source: X-Source-Args: X-Source-Dir: Cc: net@freebsd.org Subject: Re: A slight change to tcpip_fillheaders... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 14:31:57 -0000 On Jun 3, 2010, at 04:45 , Bruce Evans wrote: >=20 > On Wed, 2 Jun 2010, George Neville-Neil wrote: >=20 >> A while back another src developer mentioned that he had gotten = better performance by changing >> tcpip_fillheaders() in the following way: >=20 > It's unlikely to make any significant or even measurable difference, > but... I got apparent large (up to 20%) timing improvments in = networking > by similar changes (mostly going the other way and avoiding and/or > bzero()), but further investigation showed that the improvements were > very mysterious and mostly unrelated to my code changes -- equal > improvements could be obtained by adding padding or reducing code size > in unrelated code. This might be explained by thrashing or avoiding > thrashing of cache(s), but the effect was too large to easily explain, > and too mysterious to easily obtain or avoid. >=20 >> Index: tcp_subr.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- tcp_subr.c (revision 209083) >> +++ tcp_subr.c (working copy) >> @@ -392,28 +392,19 @@ >> struct ip *ip; >>=20 >> ip =3D (struct ip *)ip_ptr; >> + bzero(ip, sizeof(*ip)); >> ip->ip_v =3D IPVERSION; >> ip->ip_hl =3D 5; >> ip->ip_tos =3D inp->inp_ip_tos; >> - ip->ip_len =3D 0; >> - ip->ip_id =3D 0; >> - ip->ip_off =3D 0; >> ip->ip_ttl =3D inp->inp_ip_ttl; >> - ip->ip_sum =3D 0; >> ip->ip_p =3D IPPROTO_TCP; >> ip->ip_src =3D inp->inp_laddr; >> ip->ip_dst =3D inp->inp_faddr; >> } >> + bzero(th, sizeof(*th)); >> th->th_sport =3D inp->inp_lport; >> th->th_dport =3D inp->inp_fport; >> - th->th_seq =3D 0; >> - th->th_ack =3D 0; >> - th->th_x2 =3D 0; >> th->th_off =3D 5; >> - th->th_flags =3D 0; >> - th->th_win =3D 0; >> - th->th_urp =3D 0; >> - th->th_sum =3D 0; /* in_pseudo() is called later = for ipv4 */ >> } >>=20 >> /* >=20 > The version with bzero() is a small or null pessimization assuming > that the compiler is infinitiely smart. If all the fields are = initialized > by both versions, then the result is the same, so the compiler may > produce the same code for each. The version with bzero() obvious > initializes all the fields, but might not. Howver, bzero() is extern > in FreeBSD, and gcc doesn't attempt optimizations like inlining it > despite it being extern, so the version with bzero() is fundamentally > slower in theory. My changes initially involved implementing all > bzero() with small fixed size using __builtin_memset(). gcc will > inline these, hopefully using writes of a register or immediate = constant > value of 0. Many i386 versions of gcc are stupid about this and use > the slow i386 string instructions instead, but most use separate = writes > of 0 if the length is small, and I try to choose the small size so > small that the separate writes are used. For the version with the > explicit separate writes of 0, many of the fields are smaller than > the register size, but none are volatile so the compiler is free to > combine the writes. gcc does optimizations like this. I don't know > if it actually does them all or if it is inhibited by the writes of > nonzero for a few fields (C requires write ordering to appear to be > strict, but hopefully there aren't any aliasing problems in the above > which require it to actually be strict). >=20 >> I have tried this change with NetPIPE (NPtcp -b 100000) on a pair of = machines using Intel igb devices and found >> that it provides no improvement, but I am wondering if other people = want to try this and >> see if it improves throughput at all. I was testing this on a = Nehalem class machine, not sure if it >> might help on other architectures. >=20 > And don't forget, for such a change to be good, it needs to be good on = most > supported machines and not too bad on other supported machines. This = is > especially hard to even test for changes related to memory and caches. For what it's worth I checked the assembly for both versions as well. = The bzero version does not inline, as you said, and the original does do a move of 0 for each and every field, again on Nehalem with our default version of gcc. I think that for now I will leave this alone, the code is clear either = way, and what I cared about was finding out if the code could be sped up. Best, George From owner-freebsd-net@FreeBSD.ORG Thu Jun 3 17:21:04 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80EA71065673 for ; Thu, 3 Jun 2010 17:21:04 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by mx1.freebsd.org (Postfix) with ESMTP id 4F1B68FC18 for ; Thu, 3 Jun 2010 17:21:04 +0000 (UTC) Received: by pzk5 with SMTP id 5so187912pzk.14 for ; Thu, 03 Jun 2010 10:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=xDa0zBV4iSxXrgLywi3lxs8An3FB2d48XMydVD0oifI=; b=cOcfhVybXwwuGm+2HfCRDVoSlH/e6bpUBqeIZ4Uw4ZAF77w6ew4PVE5j3PaLWxr5/5 zR/4AFvtkagnbZftDFWZkHA/sg3D/Z1CP4++Ldk8TthZKVSTZLUHat+VOm0r8BjgNREe UkZaftMwBfQKWlKpyziiDCk19F7ab4c/0xhK4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Pk5zaJjejDUdvcf9F0imclZnU1e/OzPHDW9DPI/xoDhs9Vb/L5eW06FUS5IoVSbU5A BJwLsOS2UZA6anCyF0VoQH+6Ezb021U9btOG9mJNVQP0/DAamxTJHht4ivdvQPPNH8uS f1yk300Ji/8mY9wYSw1Ua7jpmVKljNbIQN7Ho= Received: by 10.143.20.1 with SMTP id x1mr6806627wfi.148.1275585663636; Thu, 03 Jun 2010 10:21:03 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 23sm163139pzk.6.2010.06.03.10.21.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Jun 2010 10:21:01 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 3 Jun 2010 10:20:38 -0700 From: Pyun YongHyeon Date: Thu, 3 Jun 2010 10:20:38 -0700 To: Krzysztof Dajka Message-ID: <20100603172037.GA13502@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Is enabling jumbo frames on RTL8111C possible? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 17:21:04 -0000 On Thu, Jun 03, 2010 at 02:24:38PM +0200, Krzysztof Dajka wrote: > Hi, > > I'm trying to enable jumbo frames on my re0 NIC. I tried: > # ifconfig re0 mtu 1600 > ifconfig: ioctl (set mtu): Invalid argument > > I have found in /usr/src/sys/dev/re/if_re.c > /* > * These controllers support jumbo frame but it seems > * that enabling it requires touching additional magic > * registers. Depending on MAC revisions some > * controllers need to disable checksum offload. So > * disable jumbo frame until I have better idea what > * it really requires to make it support. > * RTL8168C/CP : supports up to 6KB jumbo frame. > * RTL8111C/CP : supports up to 9KB jumbo frame. > */ > > pciconf -lv shows: > re0@pci0:2:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x02 > hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' > class = network > subclass = ethernet > > Do I need to set some quirks in boot process to enable jumbo frames, or it > cannot be done because it's not implemented in the driver. > I tried setting larger mtu than 1500 on Debian Squeeze and it worked well, > so definitely my chip supports jumbo frames RealTek no longer releases datasheet so it's hard to know required information to support jumbo frame. It seems driver released by vendor has magic code which enables jumbo frame as well as DSP fixups. The magic code is very complex and hard to understand the meaning. It seems Linux borrowed the magic code from vendor but I guess they also don't know what the magic code does and why the magic is needed. Controllers targeted to servers show very good performance number with jumbo frame(e.g. about 990Mbps for bulk TCP transfers) but I'm not sure how well consumer controller works with jumbo frame. Vendor driver disables checksum offloading when jumbo frame is used. This indicates the controller has very small FIFO(less than 1 jumbo frame size) which in turn means it may show poor performance under load. From owner-freebsd-net@FreeBSD.ORG Thu Jun 3 21:46:32 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AB6C1065670 for ; Thu, 3 Jun 2010 21:46:32 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 606368FC16 for ; Thu, 3 Jun 2010 21:46:32 +0000 (UTC) Received: by pwj1 with SMTP id 1so381141pwj.13 for ; Thu, 03 Jun 2010 14:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=ILdfD3QAAbdkLSW+bc7BDx4+L1GRU9Ecd8z/X8yFxCM=; b=xaLkiEqhS85vXr1xDgg2KWugdytzfcqxV53gyvNasMuzC9F5l9YGIXMiGgh+oP8Sij Tp6Btwr6KME9XDh8/Zamx/ciDESoWVZvVf2Wq2n+3rF4z1S4/M5EiPJm9Eo8tGXleBej mkq2ozqfdwAxmgbnIK3LQqgMf5nOpbwfhUF2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=as9fTqAqb99Qc5qrwQmyBii82gCY8IswGQOksHtLCXcJPr7pgWL1vBk2nkYby6Sr8j spC5ROUO7qDh9WKHtsUxc0vyHt9Juv6XFXJi5SbS1BGC1dvV5F21v9OWFgWExren+6fN V+jegxVSMrXxFRLsoaqqQlHpeVAU2drqNZQVU= Received: by 10.114.2.25 with SMTP id 25mr7610786wab.100.1275601591651; Thu, 03 Jun 2010 14:46:31 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id c14sm2479953waa.1.2010.06.03.14.46.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Jun 2010 14:46:30 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 3 Jun 2010 14:46:06 -0700 From: Pyun YongHyeon Date: Thu, 3 Jun 2010 14:46:06 -0700 To: Perevalov Sergey Message-ID: <20100603214606.GE13502@michelle.cdnetworks.com> References: <4BE44E2D.6060907@gmail.com> <20100507210516.GI14801@michelle.cdnetworks.com> <4C01760E.2080403@gmail.com> <20100531223204.GE1577@michelle.cdnetworks.com> <4C0551F1.2010609@gmail.com> <20100601222444.GH1577@michelle.cdnetworks.com> <4C07B344.4060805@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C07B344.4060805@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Hans Petter Selasky Subject: Re: [axe][ue0] Device send packets but any host in network can not receive any packet from it. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 21:46:32 -0000 On Thu, Jun 03, 2010 at 06:51:00PM +0500, Perevalov Sergey wrote: > On 02.06.2010 03:24, Pyun YongHyeon wrote: > >On Tue, Jun 01, 2010 at 11:31:13PM +0500, Perevalov Sergey wrote: > > > >>Hi! > >>I tried it with crossover cable but results was the same bad. Then set > >>debug flag hw.usb.axe.debug: to 15, and started ping -f from ue0. > >>And in /var/log/messages I found these strings: > >> > >>Jun 1 22:28:34 laptop kernel: axe_bulk_read_callback:842: bulk read > >>error, USB_ERR_CANCELLED > >>Jun 1 22:28:35 laptop kernel: axe_bulk_write_callback:870: transfer > >>complete > >>Jun 1 22:29:12 laptop kernel: axe_bulk_write_callback:941: transfer > >>error, USB_ERR_TIMEOUT > >>Jun 1 22:29:51 laptop last message repeated 4 times > >>Jun 1 22:31:40 laptop last message repeated 11 times > >> > >>Then i googled it and found this > >>http://www.mail-archive.com/freebsd-usb@freebsd.org/msg04388.html > >>the problem is described definitely like mine. > >>I read all thread and found the patch usb2_ethernet.patch2, but I havn't > >>found > >>sys/dev/usb2/ethernet/usb2_ethernet.c file for patch. > >> > >>how can I try to apply this patch to my system? > >>http://www.mail-archive.com/freebsd-usb@freebsd.org/msg04403.html > >> > >> > >I believe the bug in the thread was fixed long time ago. > >If you're using 8.0-RELEASE, try latest stable/8 or > >8.1-PRERELEASE and see whether axe(4) works or not. > > > > > I have just finished testing device on my updated freebsd: > FreeBSD homeserv 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #0: Thu Jun 3 > 17:22:44 UTC 2010 user@homeserv:/usr/obj/usr/src/sys/GENERIC i386 > And it still shows the same problem when I try to ping -f any host from ue0: > > Jun 3 18:29:40 homeserv kernel: ue0: link state changed to UP > Jun 3 18:29:42 homeserv kernel: axe_bulk_write_callback: transfer complete > Jun 3 18:29:42 homeserv last message repeated 21 times > Jun 3 18:29:52 homeserv kernel: axe_bulk_write_callback: transfer > error, USB_ERR_TIMEOUT I don't see abnormal things in axe(4). Maybe Hans can help(CCed). > Jun 3 18:30:21 homeserv last message repeated 3 times > > > -- > Regards, Sergey. > From owner-freebsd-net@FreeBSD.ORG Fri Jun 4 07:26:58 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84AEE106566B for ; Fri, 4 Jun 2010 07:26:58 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 151368FC0C for ; Fri, 4 Jun 2010 07:26:57 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=IcRiYJMB21UA:10 a=ygRHs6EKU7oA:10 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=8BfId_Ii0bhd7dnPKrcA:9 a=EBSJqdOPlnKW7upH--G1ZThV-AoA:4 a=wPNLvfGTeEIA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 1370344695; Fri, 04 Jun 2010 09:26:56 +0200 From: Hans Petter Selasky To: pyunyh@gmail.com Date: Fri, 4 Jun 2010 09:24:11 +0200 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <4BE44E2D.6060907@gmail.com> <4C07B344.4060805@gmail.com> <20100603214606.GE13502@michelle.cdnetworks.com> In-Reply-To: <20100603214606.GE13502@michelle.cdnetworks.com> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006040924.11427.hselasky@c2i.net> Cc: freebsd-net@freebsd.org, Perevalov Sergey Subject: Re: [axe][ue0] Device send packets but any host in network can not receive any packet from it. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 07:26:58 -0000 On Thursday 03 June 2010 23:46:06 Pyun YongHyeon wrote: > > Jun 3 18:29:52 homeserv kernel: axe_bulk_write_callback: transfer > > error, USB_ERR_TIMEOUT > > I don't see abnormal things in axe(4). Maybe Hans can help(CCed). > Timeout might mean that the data format is not accepted. --HPS From owner-freebsd-net@FreeBSD.ORG Fri Jun 4 07:30:53 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15CAB106564A; Fri, 4 Jun 2010 07:30:53 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id A29C68FC16; Fri, 4 Jun 2010 07:30:52 +0000 (UTC) Received: from c122-106-160-243.carlnfd1.nsw.optusnet.com.au (c122-106-160-243.carlnfd1.nsw.optusnet.com.au [122.106.160.243]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o547UlEn011621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jun 2010 17:30:49 +1000 Date: Fri, 4 Jun 2010 17:30:47 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: George Neville-Neil In-Reply-To: <54198502-A432-4FA7-9176-0AB85D809597@freebsd.org> Message-ID: <20100604165857.D28688@delplex.bde.org> References: <0BC7AD09-B627-4F6A-AD93-B7E794A78CA2@freebsd.org> <20100603181439.Q27699@delplex.bde.org> <54198502-A432-4FA7-9176-0AB85D809597@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@freebsd.org Subject: Re: A slight change to tcpip_fillheaders... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 07:30:53 -0000 On Thu, 3 Jun 2010, George Neville-Neil wrote: > For what it's worth I checked the assembly for both versions as well. The bzero > version does not inline, as you said, and the original does do a move of > 0 for each and every field, again on Nehalem with our default version of > gcc. > > I think that for now I will leave this alone, the code is clear either way, > and what I cared about was finding out if the code could be sped up. I couldn't find any options to make gcc-4.2.1 coalesce the assignments in the following simple example: %%% struct foo { char x; char y; }; xx(struct foo *fp) { fp->x = 0; fp->y = 0; } %%% The non-coalesced version may be a bottleneck in the instruction stream in some relatively rare cases. The worst case seems to be non-coalescing 8 8-bit variables on a 64-bit arch. (gcc does do the coalescing for bit-fields, else the worst cast would be 64 assignments of 1-bit bit-fields generating 3*64 micro-instructions (3 for each assignment to preserve nearby bits).) But since there are no dependencies between these assignments they are easy to schedule, and 8 instructions isn't many (they probably take 4 cycles). struct ip has 11 separate fields (after combining the bit-fields). 11 instructions for these is a few, the extern bzero() takes almost that many just to call; then on i386 it takes 12 instructions internally for administrivia and 5 instructions internally to do the work; on amd64 it takes 7 instructions interally for administivia and 6 instructions internally to do the work (amd64 bzero actually does more assignments internally -- ones of size 8,8,1,1,1,1 instead of ones of size 4,4,4,4,4; it could do fewer, but only at a cost of more for administrivia). The function call instructions and other adminstrivia instructions are almost all heavyweight ones with strong dependencies, so you would be lucky if they ran in 25 cycles where the 11 asignments may run in 5.5 cycles. But 25 cycles isn't many, so the difference is usually insignificant. Since this is initialization code, it may involve a cache miss or two, taking several hundred cycles each... Bruce From owner-freebsd-net@FreeBSD.ORG Fri Jun 4 08:34:50 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A8921065677 for ; Fri, 4 Jun 2010 08:34:50 +0000 (UTC) (envelope-from alteriks@gmail.com) Received: from mail.agora.pl (mail.agora.pl [193.42.230.53]) by mx1.freebsd.org (Postfix) with ESMTP id B371A8FC16 for ; Fri, 4 Jun 2010 08:34:49 +0000 (UTC) Received: from agstamp1.agora.pl (agstamp1.agora.pl [10.205.39.114]) by mail.agora.pl (8.13.8/8.11.1) with ESMTP id o547bD1n018815; Fri, 4 Jun 2010 09:37:13 +0200 Received: from agora.pl (agstamp1.agora.pl [10.205.39.114]) by agstamp1.agora.pl (Postfix) with SMTP id 4971B244C7; Fri, 4 Jun 2010 09:37:13 +0200 (CEST) Received: from zcs01.agora.pl (vzcs03.agora.pl [10.205.98.92]) by agstamp1.agora.pl (Postfix) with ESMTP id 453BE244B4; Fri, 4 Jun 2010 09:37:13 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zcs01.agora.pl (Postfix) with ESMTP id 4290121AFB; Fri, 4 Jun 2010 09:37:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at zcs01.agora.pl Received: from zcs01.agora.pl ([127.0.0.1]) by localhost (zcs01.agora.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USpxMzD7l6Wb; Fri, 4 Jun 2010 09:37:13 +0200 (CEST) Received: from t42.localnet (unknown [10.201.55.171]) by zcs01.agora.pl (Postfix) with ESMTPSA id 1E6D720533; Fri, 4 Jun 2010 09:37:13 +0200 (CEST) From: "alteriks@gmail.com" To: pyunyh@gmail.com Date: Fri, 4 Jun 2010 09:37:11 +0200 User-Agent: KMail/1.13.3 (Linux/2.6.30-1-686; KDE/4.4.3; i686; ; ) References: <20100603172037.GA13502@michelle.cdnetworks.com> In-Reply-To: <20100603172037.GA13502@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006040937.11859.alteriks@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: Is enabling jumbo frames on RTL8111C possible? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 08:34:50 -0000 On Thursday, 3 of June 2010 19:20:38 Pyun YongHyeon wrote: > RealTek no longer releases datasheet so it's hard to know required > information to support jumbo frame. It seems driver released by > vendor has magic code which enables jumbo frame as well as DSP > fixups. The magic code is very complex and hard to understand the > meaning. It seems Linux borrowed the magic code from vendor but I > guess they also don't know what the magic code does and why the > magic is needed. > > Controllers targeted to servers show very good performance number > with jumbo frame(e.g. about 990Mbps for bulk TCP transfers) but I'm > not sure how well consumer controller works with jumbo frame. > Vendor driver disables checksum offloading when jumbo frame is > used. This indicates the controller has very small FIFO(less than 1 > jumbo frame size) which in turn means it may show poor performance > under load. Thanks for explanation. From owner-freebsd-net@FreeBSD.ORG Fri Jun 4 06:36:24 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A909106566C for ; Fri, 4 Jun 2010 06:36:24 +0000 (UTC) (envelope-from shelma@hostelnet.ru) Received: from emma.bazalt43.ru (emma.bazalt43.ru [91.193.143.8]) by mx1.freebsd.org (Postfix) with ESMTP id 4E9828FC22 for ; Fri, 4 Jun 2010 06:36:23 +0000 (UTC) Received: from tt (unknown [91.193.141.8]) by emma.bazalt43.ru (Postfix) with ESMTPA id 485685CF8 for ; Fri, 4 Jun 2010 12:36:21 +0600 (YEKST) X-AntiVirus: Checked by Dr.Web [version: 5.0, engine: 5.00.2.03300, virus records: 1401363, updated: 4.06.2010] Date: Fri, 4 Jun 2010 12:36:11 +0600 From: =?windows-1251?B?we7j7vHr7uLx6ujpIMTs6PLw6Ok=?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?windows-1251?B?zs7OICLV7vHy5esi?= X-Priority: 3 (Normal) Message-ID: <517660741.20100604123611@hostelnet.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 04 Jun 2010 10:59:41 +0000 Subject: how cook ng_pipe? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?we7j7vHr7uLx6ujpIMTs6PLw6Ok=?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 06:36:24 -0000 Hi. What is it ng_pipe? How it work? How use it? I dont find any manuals or docs about it. Only links to sources. But it exist in STABLE7... Thanks. --=20 Thanks,, Bogoslovskiy Dmitriy = mailto:shelma@hostelnet.ru From owner-freebsd-net@FreeBSD.ORG Fri Jun 4 09:43:26 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 562731065673 for ; Fri, 4 Jun 2010 09:43:26 +0000 (UTC) (envelope-from cosmic17@yandex.ru) Received: from forward2.mail.yandex.net (forward2.mail.yandex.net [77.88.46.7]) by mx1.freebsd.org (Postfix) with ESMTP id 6D0D38FC08 for ; Fri, 4 Jun 2010 09:43:25 +0000 (UTC) Received: from web11.yandex.ru (web11.yandex.ru [213.180.223.225]) by forward2.mail.yandex.net (Yandex) with ESMTP id 9B42738A9567 for ; Fri, 4 Jun 2010 13:28:09 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1275643689; bh=jKrO0JuJ2fGQc/RDFgdyqs8jLpcprKncK4fpGo9W+Dg=; h=From:To:Subject:MIME-Version:Message-Id:Date: Content-Transfer-Encoding:Content-Type; b=wILIfjIrBopYKuRyzNeGWF9GoOpRS5fyFkL/3wj6+gfniJByphSapjkPq4VAv9+81 eJljk4tBC6KIykPDISpfUo9ctxzGm4MY8SI8R0e1aX5oqRqHqBzK3hzXWwZFuvOJOI AaGOQfx1EUfwX4qdAH1E9tWZqGXG64gC8FsjTAZU= Received: from localhost (localhost.localdomain [127.0.0.1]) by web11.yandex.ru (Yandex) with ESMTP id 98B3D488006F for ; Fri, 4 Jun 2010 13:28:09 +0400 (MSD) X-Yandex-Spam: 1 X-Yandex-Front: web11.yandex.ru X-Yandex-TimeMark: 1275643689 Received: from 32.100.vltele.com (32.100.vltele.com [79.174.32.100]) by mail.yandex.ru with HTTP; Fri, 04 Jun 2010 13:28:08 +0400 From: =?koi8-r?B?5M3VyMEg7snLz8zByg==?= To: freebsd-net@freebsd.org Message-Id: <358371275643688@web11.yandex.ru> Date: Fri, 04 Jun 2010 13:28:08 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: base64 X-Mailman-Approved-At: Fri, 04 Jun 2010 11:39:32 +0000 MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: pf nat & ipfw kernel nat & ng_nat - what uses less computer resources? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 09:43:26 -0000 SGVsbG8uPGJyIC8+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxkaXYgY2xhc3M9ImdtYW lsX3F1 b3RlIj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdj48ZGl2IGNsYXNzPSJoNSI+PG Rpdj48 ZGl2PjxkaXY+PGJyIC8+V2UgaGF2ZSBhIG5ldHdvcmsuIE5vdyB3ZSBhcmUgdXNpbmcgcG YgTkFU LiBCdXQgd2UgYXJlIGludGVyZXN0ZWQgaW4gc29tZSBxdWVzdGlvbjo8YnIgLz48YnIgLz 4xLiBX aGF0IHR5cGUgb2YgTkFUIHVzZXMgbGVzcyBjb21wdXRlciByZXNvdXJjZXM/PGJyIC8+YS kgcGYg TkFUPGJyIC8+YikgaXBmdyBrZXJuZWwgTkFUPGJyIC8+YykgTkdfTkFUID88YnIgLz48Yn IgLz48 L2Rpdj4yLiBCSU5BVCBvciBOQVQgLSB3aGF0IGlzIGJldHRlcj8gV2hpY2ggb25lIG9mIH RoZW0g aXMgbW9yZSBmYXN0ZXIgYW5kIHVzZXMgbGVzcyBjb21wdXRlciByZXNvdXJjZXMgd2l0aC BvbmUg b2YgZmlyZXdhbGw/IEluIHRoZW9yeSBJIHRoaW5rIHRoYXQgQklOQVQgZmFzdGVyIHRoYW 4gTkFU LCBiZWNhdXNlIHRoZXJlIGlzIG5vIG5lY2Vzc2FyeSB0byB0cmFjayBjb25uZWN0aW9ucy 48YnIg Lz48YnIgLz4zLiBJIGtub3cgdGhhdCB0aGUgZmlyZXdhbGwgUEYgZG9lcyBub3Qgc3VwcG 9ydCB0 aHJlYWRzLiBJIHJlYWQgdGhhdCBJUEZXIGlzIChpbiBGcmVlQlNEIDguMCwgZm9yIGV4YW 1wbGUp LiBCdXQgaW4gbXkgdGVzdCBJIGhhdmVuYHQgc2VlbiB0aHJlYWRzIHdoZW4gdXNlZCBJUE ZXLiBN YXliZSB0aGVyZSBhcmUgc29tZSBzcGVjaWFsIG9wdGlvbnMgdG8gY29tcGlsZSBrZXJuZW wgb3Ig Y29uZmlndXJlIElQRlc/IEZvciB0ZXN0cyBJIGNvbXBpbGVkIGtlcm5lbCB3aXRoOjxkaX Y+PGRp dj48YnIgLz5vcHRpb25zIFNNUDxiciAvPiMgSVBGVzxiciAvPm9wdGlvbnMgSVBGSVJFV0 FMTDxi ciAvPm9wdGlvbnMgSVBGSVJFV0FMTF9WRVJCT1NFPGJyIC8+b3B0aW9ucyBJUEZJUkVXQU xMX0RF RkFVTFRfVE9fQUNDRVBUPGJyIC8+b3B0aW9ucyBEVU1NWU5FVDxiciAvPm9wdGlvbnMgSV BGSVJF V0FMTF9OQVQ8YnIgLz5vcHRpb25zIExJQkFMSUFTPGJyIC8+b3B0aW9ucyBIWj0iMjAwMC I8YnIg Lz48YnIgLz40LiBJIGNhbmB0IGZpbmQgYW55IGluZm9ybWF0aW9uIGFib3V0IEJJTkFUIG luIGlw ZncrbmdfbmF0PyBEb2VzIGFueW9uZSB1c2UgdGhpcyB0ZWNobm9sb2d5PyBPciBtYXliZS B5b3Ug a25vdyBpbnRlcmVzdGluZyBpbmZvcm1hdGlvbiBhYm91dCBpdD88YnIgLz48YnIgLz5JIG hhdmUg YSB0ZXN0IGNvbXB1dGVyIChib3JkZXIgbmF0KTo8YnIgLz4tIGRtZXNnIHwgbGVzczo8Yn IgLz5G cmVlQlNEIDguMC1TVEFCTEUtMjAxMDA0ICMwOiBNb24gQXByIDUgMTU6NTk6MDYgVVRDID IwMTA8 YnIgLz5DUFU6IEludGVsKFIpIFBlbnRpdW0oUikgNCBDUFUgMy4yMEdIeiAoMzIwMC4wMS 1NSHog SzgtY2xhc3MgQ1BVKTxiciAvPnJlYWwgbWVtb3J5ID0gNTM2ODcwOTEyICg1MTIgTUIpPG JyIC8+ YWdlMDogIG1lbSAweGZlYWMwMDAwLTB4ZmVhZmZmZmYgaXJxIDE3IGF0IGRldmljZSAwLj Agb24g cGNpMjxiciAvPnJsMDogIHBvcnQgMHhlODAwLTB4ZThmZiBtZW0gMHhmZWJmZmMwMC0weG ZlYmZm Y2ZmIGlycSAxOSBhdCBkZXZpY2UgMC4wIG9uIHBjaTQ8YnIgLz48YnIgLz5UZXN0IHNjaG VtZTo8 YnIgLz5sYXB0b3AoMTkyLjE2OC4wLjE4OCktLSZndDthZ2UwKDE5Mi4xNjguMC4xKS0tJm d0O3Js MCgxMC4xLjIuMTQyKS0tJmd0O2ludGVybmV0PGJyIC8+PGJyIC8+YWdlMCAtIGludGVybm FsIGlu dGVyZmFjZTxiciAvPnJsMCAtIGV4dGVybmFsIGludGVyZmFjZTxiciAvPklQIFBvb2wgZm 9yIG5h dCBpcyA8YSBocmVmPSJodHRwOi8vMTAuMS42LjAvMjQiIHRhcmdldD0iX2JsYW5rIj4xMC 4xLjYu MC8yNDwvYT4uPGJyIC8+PGJyIC8+SSBoYXZlIGNvbXBsZXRlZCAyIHRlc3RzOjxiciAvPj xiciAv PjEuIHdpdGggdXRpbGl0eSAicGluZyI6IHBpbmcgLWMgNTAwIC1mIDE5Mi4xNjguMS4xMT I8YnIg Lz4yLiB3aXRoIHV0aWxpdHkgImlwZXJmIjogaXBlcmYgLWMgMTkyLjE2OC4xLjExMiAtbi AxTSAt aSAxIC10IDE4MDxiciAvPjxiciAvPllvdSBjYW4gc2VlIHRoZSByZXN1bHRzIG9mIHRoZX NlIHRl c3RzIGJlbG93OjxiciAvPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pj xkaXY+ PGRpdj48ZGl2PjxkaXYgY2xhc3M9Img1Ij4mbmJzcDsxLiZuYnNwOyBwZiBOQVQ6PGRpdj 48YnIg Lz5UaGVyZSBpcyBvbmUgcnVsZSBmb3IgTkFUIGluIC9ldGMvcGYuY29uZi5wb3J0czo8Yn IgLz48 YnIgLz5uYXQgcGFzcyBvbiAkZXh0X2lmIGZyb20gIHRvIGFueSAtJmd0OyA8YSBocmVmPS JodHRw Oi8vMTAuMS42LjAvMjQiIHRhcmdldD0iX2JsYW5rIj4xMC4xLjYuMC8yNDwvYT4gc291cm NlLWhh c2ggdGVzdCBzdGF0aWMtcG9ydDxiciAvPjxiciAvPjwvZGl2PjxkaXY+PGRpdj5hKS4gcG luZyAt YyA1MDAgLWYgPGEgaHJlZj0iaHR0cDovLzE5Mi4xNjguMS4xMTIiIHRhcmdldD0iX2JsYW 5rIj4x OTIuMTY4LjEuMTEyPC9hPjo8YnIgLz5QSU5HIDE5Mi4xNjguMS4xMTIgKDE5Mi4xNjguMS 4xMTIp IDU2KDg0KSBieXRlcyBvZiBkYXRhLjxiciAvPi0tLSAxOTIuMTY4LjEuMTEyIHBpbmcgc3 RhdGlz dGljcyAtLS08YnIgLz41MDAgcGFja2V0cyB0cmFuc21pdHRlZCwgMzk4IHJlY2VpdmVkLC AyMCUg cGFja2V0IGxvc3MsIHRpbWUgMTY1OG1zPGJyIC8+cnR0IG1pbi9hdmcvbWF4L21kZXYgPS AwLjIz OS8wLjMzOS81LjQyNS8wLjI2MiBtcywgaXBnL2V3bWEgMy4zMjMvMC4zMjggbXM8YnIgLz 48YnIg Lz5iKSBPbiB0aGUgc2VydmVyIDxhIGhyZWY9Imh0dHA6Ly8xOTIuMTY4LjEuMTEyIiB0YX JnZXQ9 Il9ibGFuayI+MTkyLjE2OC4xLjExMjwvYT46PGJyIC8+aXBlcmYgLXMgODA8YnIgLz48Yn IgLz5P biB0aGUgbGFwdG9wOjxiciAvPmlwZXJmIC1jIDE5Mi4xNjguMS4xMTIgLXAgODAgLW4gMU 0gLWkg MSAtdCAxODA8YnIgLz48YnIgLz5UaGVyZSBhcmUgcmVzdWx0cyBvZiAmbGRxdW87bmV0c3 RhdCZy ZHF1bzs6PGJyIC8+PGJyIC8+bmV0c3RhdCAtdzFkIC1JIGFnZTA6PGJyIC8+Jm5ic3A7Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgaW5wdXQgKGFnZTApIG91dH B1dDxi ciAvPnBhY2tldHMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZXJycyZuYnNwOyZuYnNwOy ZuYnNw OyZuYnNwOyBpZHJvcHMmbmJzcDsmbmJzcDsmbmJzcDsgYnl0ZXMmbmJzcDsmbmJzcDsmbm JzcDsg cGFja2V0cyZuYnNwOyZuYnNwOyZuYnNwOyBlcnJzJm5ic3A7Jm5ic3A7Jm5ic3A7IGJ5dG VzJm5i c3A7Jm5ic3A7Jm5ic3A7IGNvbGxzPGJyIC8+NTI0NyAmbmJzcDsgJm5ic3A7ICZuYnNwOy AmbmJz cDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDczMzIyNzYmbmJzcD smbmJz cDsgMTYwMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDgzNzAwJm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7IDA8YnIgLz41Mjg2Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA3Mz MxMzMw Jm5ic3A7Jm5ic3A7IDE1NzgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA4MjI5NiZuYnNwOy ZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAwPGJyIC8+NTI3OCAmbmJzcDsgJm5ic3A7ICZuYnNwOy AmbmJz cDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDczMzkyNzgmbmJzcD smbmJz cDsgMTU4OSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDgzNzU0Jm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7IDA8YnIgLz41MzEyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA3Mz gwMzQ0 Jm5ic3A7Jm5ic3A7IDE1NzAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA4MjcyOCZuYnNwOy ZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAwPGJyIC8+NTMyOCZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsgMCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsgMCAmbmJzcDsgJm5ic3A7ICZuYnNwOyA3MzM3NzY0Jm5ic3A7Jm5ic3 A7IDE1 NjcgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7IDAgJm5ic3A7ICZuYnNwOy A4MzE2 MCAmbmJzcDsgJm5ic3A7Jm5ic3A7IDA8YnIgLz48YnIgLz5uZXRzdGF0IC13MWQgLUkgcm wwOjxi ciAvPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbnB1dCAocm wwKSBv dXRwdXQ8YnIgLz5wYWNrZXRzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVycnMmbmJzcD smbmJz cDsmbmJzcDsgaWRyb3BzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJ5dGVzJm5ic3A7Jm 5ic3A7 Jm5ic3A7IHBhY2tldHMgJm5ic3A7Jm5ic3A7IGVycnMmbmJzcDsmbmJzcDsmbmJzcDsgYn l0ZXMm bmJzcDsmbmJzcDsgJm5ic3A7IGNvbGxzPGJyIC8+MTU1NiZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDkzNTA4Jm5ic3A7Jm5ic3A7Jm5ic3A7IDUxMzMmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCAmbmJzcDsgJm5ic3A7ICZuYn NwOyA3 Mjc1Nzg4Jm5ic3A7Jm5ic3A7IDA8YnIgLz4xNTQ3Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD smbmJz cDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA5MjgzMiZuYnNwOyZuYnNwOyZuYnNwOyA1MTY5Jm5ic3 A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsgNzMzNzE3NCZuYnNwOyZuYnNwOyAwPGJyIC8+MTU1MSZuYnNwOy ZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOTMwNzImbmJzcDsmbmJzcD smbmJz cDsgNTE2MSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDczMjEwODgmbmJzcDsmbmJzcDsgMD xiciAv PjE1MzkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD smbmJz cDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID kyMzUy Jm5ic3A7Jm5ic3A7Jm5ic3A7IDUxOTkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD smbmJz cDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA3MzgxMj Y4Jm5i c3A7Jm5ic3A7IDA8YnIgLz4xNTIwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsg MCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyZuYnNwOyA5MTIxMiZuYnNwOyZuYnNwOyZuYnNwOyA1MTk1Jm5ic3A7Jm5ic3A7Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsgNzM2NzY0MiZuYnNwOyZuYnNwOyAwPGJyIC8+PGJyIC8+dG9wICZuZGFzaDtTOj xiciAv Pmxhc3QgcGlkOiA2MzIwOyBsb2FkIGF2ZXJhZ2VzOiAwLjA3LCAwLjAyLCAwLjAwIHVwID ErMTg6 MTk6MjAgMTA6MDg6MjY8YnIgLz43MCBwcm9jZXNzZXM6IDMgcnVubmluZywgNTUgc2xlZX Bpbmcs IDEyIHdhaXRpbmc8YnIgLz5DUFU6IDAuMCUgdXNlciwgMC4wJSBuaWNlLCAxLjIlIHN5c3 RlbSwg NC43JSBpbnRlcnJ1cHQsIDk0LjIlIGlkbGU8YnIgLz5NZW06IDIxTSBBY3RpdmUsIDEzNk 0gSW5h Y3QsIDg5TSBXaXJlZCwgNDRLIENhY2hlLCA1OU0gQnVmLCAyMzdNIEZyZWU8YnIgLz5Td2 FwOiAy MDQ4TSBUb3RhbCwgMjA0OE0gRnJlZTxiciAvPjxiciAvPjIuIHBmIEJJTkFUOjxiciAvPj xiciAv PlRoZXJlIGFyZSBhYm91dCAxMDAwIHJ1bGVzIGZvciBCSU5BVCBpbiAvZXRjL3BmLmNvbm YucG9y dHM6PGJyIC8+Li4uPGJyIC8+YmluYXQgb24gJGV4dF9pZiBmcm9tIDEwLjEwLjEwLjIgdG 8gYW55 IC0mZ3Q7IDEwLjEuNi4xMzxiciAvPmJpbmF0IG9uICRleHRfaWYgZnJvbSAxMC4xMC4xMC 4zIHRv IGFueSAtJmd0OyAxMC4xLjYuMTQ8YnIgLz4uLi48YnIgLz5BbmQgdGhlIGxhc3Qgb25lIG lzIGZv ciBvdXIgbGFwdG9wOjxiciAvPmJpbmF0IG9uICRleHRfaWYgZnJvbSAxOTIuMTY4LjAuMT g4IHRv IGFueSAtJmd0OyAxMC4xLjYuMTg4PGJyIC8+PGJyIC8+YSkgcGluZyAtYyA1MDAgLWYgPG EgaHJl Zj0iaHR0cDovLzE5Mi4xNjguMS4xMTIiIHRhcmdldD0iX2JsYW5rIj4xOTIuMTY4LjEuMT EyPC9h Pjo8YnIgLz5QSU5HIDE5Mi4xNjguMS4xMTIgKDE5Mi4xNjguMS4xMTIpIDU2KDg0KSBieX RlcyBv ZiBkYXRhLjxiciAvPi0tLSAxOTIuMTY4LjEuMTEyIHBpbmcgc3RhdGlzdGljcyAtLS08Yn IgLz41 MDAgcGFja2V0cyB0cmFuc21pdHRlZCwgMzk4IHJlY2VpdmVkLCAyMCUgcGFja2V0IGxvc3 MsIHRp bWUgMTY4OG1zPGJyIC8+cnR0IG1pbi9hdmcvbWF4L21kZXYgPSAwLjIzOC8wLjM1Ny8xLj AwNi8w LjA3OCBtcywgaXBnL2V3bWEgMy4zODMvMC4zMzAgbXM8YnIgLz48YnIgLz5iKSBPbiB0aG Ugc2Vy dmVyIDxhIGhyZWY9Imh0dHA6Ly8xOTIuMTY4LjEuMTEyIiB0YXJnZXQ9Il9ibGFuayI+MT kyLjE2 OC4xLjExMjwvYT46PGJyIC8+aXBlcmYgLXMgODA8YnIgLz48YnIgLz5PbiB0aGUgbGFwdG 9wOjxi ciAvPmlwZXJmIC1jIDE5Mi4xNjguMS4xMTIgLXAgODAgLW4gMU0gLWkgMSAtdCAxODA8Yn IgLz48 YnIgLz5UaGVyZSBhcmUgcmVzdWx0cyBvZiAmbGRxdW87bmV0c3RhdCZyZHF1bzs6PGJyIC 8+PGJy IC8+bmV0c3RhdCAtdzFkIC1JIGFnZTA6PGJyIC8+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlucHV0IChhZ2UwKSBvdXRwdXQ8YnIgLz 5wYWNr ZXRzJm5ic3A7Jm5ic3A7IGVycnMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWRyb3BzJm 5ic3A7 Jm5ic3A7ICZuYnNwOyZuYnNwOyBieXRlcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbm JzcDsg cGFja2V0cyAmbmJzcDsmbmJzcDsgZXJycyZuYnNwOyAmbmJzcDsgYnl0ZXMmbmJzcDsmbm JzcDsg Y29sbHM8YnIgLz41Mjk0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5ic3A7 Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyA3 MzE4MjcyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE1ODUmbmJzcDsmbmJzcD smbmJz cDsgJm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgODQ5OT YmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMDxiciAvPjAmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA3MzU3ODI0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA4Mzg2Mi ZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAwPGJyIC8+NTMxNCZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sgJm5i c3A7Jm5ic3A7IDczNjc4NTQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTU5MS ZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyA4MzI2OCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwPGJyIC8+NTMwMiZuYnNwOyZuYn NwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3 A7ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDcyOTA2NDImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD smbmJz cDsgMTU5MSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDgzNjQ2Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDA8Yn IgLz41 MjcwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID AmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMC ZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA3MzMyMjc2Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE1NzcmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD smbmJz cDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA4NTkxNCZuYnNwOy ZuYnNw OyZuYnNwOyZuYnNwOyAwPGJyIC8+PGJyIC8+bmV0c3RhdCAtdzFkIC1JIHJsMDo8YnIgLz 4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsgaW5wdXQgKHJsMCkgb3V0cHV0PGJyIC8+cGFja2V0cyZuYnNwOyZuYnNwOyZuYn NwOyBl cnJzJm5ic3A7Jm5ic3A7Jm5ic3A7IGlkcm9wcyZuYnNwOyZuYnNwOyZuYnNwOyBieXRlcy ZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBwYWNrZXRzJm5ic3A7Jm5ic3A7Jm5ic3A7IGVycnMmbm JzcDsm bmJzcDsmbmJzcDsgYnl0ZXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29sbHM8YnIgLz 4xNTg2 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsgMCZuYnNwOyZuYnNwOy ZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDk1MTcyICZuYnNwOyAmbmJzcDsgJm5ic3A7IDUxNzImbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyZuYnNwOyA3MzQxMTQ4Jm5ic3A7Jm5ic3A7Jm5ic3A7IDA8YnIgLz4xNTY3Jm5ic3 A7Jm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7IDk0MDM4ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDUxNzcmbmJzcDsmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyA3MzQ0NTE0Jm5ic3A7Jm5ic3A7Jm5ic3A7IDA8YnIgLz4xNTM3Jm5ic3A7Jm5ic3A7IC ZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5ic3A7 IDkyMjMyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDUxOTgmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyZuYnNwOyA3MzczNjk4Jm5ic3A7Jm5ic3A7Jm5ic3A7IDA8YnIgLz4xNTY1Jm5ic3A7Jm 5ic3A7 Jm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5ic3A7 Jm5ic3A7IDkzOTEyICZuYnNwOyAmbmJzcDsgJm5ic3A7IDUxNjYmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyA3 MzI4MDkwJm5ic3A7Jm5ic3A7Jm5ic3A7IDA8YnIgLz4xNTYxJm5ic3A7Jm5ic3A7Jm5ic3 A7ICZu YnNwOyZuYnNwOyAmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7IDkz NjcyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDUxMzkmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyZuYnNwOyA3MzAxNTk2Jm5ic3A7Jm5ic3A7IDA8YnIgLz48YnIgLz50b3AgJm5kYX NoO1M6 PGJyIC8+bGFzdCBwaWQ6IDg2MjI7IGxvYWQgYXZlcmFnZXM6IDAuMTYsIDAuMDcsIDAuMD EgdXAg MisxMzoyMjo0MyAwNToxMTo0OTxiciAvPjYxIHByb2Nlc3NlczogMyBydW5uaW5nLCA0Ni BzbGVl cGluZywgMTIgd2FpdGluZzxiciAvPkNQVTogMC4wJSB1c2VyLCAwLjAlIG5pY2UsIDQuNC Ugc3lz dGVtLCA1LjElIGludGVycnVwdCwgOTAuNSUgaWRsZTxiciAvPk1lbTogMTRNIEFjdGl2ZS wgMTI3 TSBJbmFjdCwgODlNIFdpcmVkLCA1OU0gQnVmLCAyNTFNIEZyZWU8YnIgLz5Td2FwOiAyMD Q4TSBU b3RhbCwgMjA0OE0gRnJlZTxiciAvPjxiciAvPjMuSVBGVyBLRVJORUwgTkFUOjxiciAvPj xiciAv PjwvZGl2PjwvZGl2PmEpLiBwaW5nIC1jIDUwMCAtZiA8YSBocmVmPSJodHRwOi8vMTkyLj E2OC4x LjUiIHRhcmdldD0iX2JsYW5rIj4xOTIuMTY4LjEuNTwvYT46PC9kaXY+PC9kaXY+PGRpdj 48ZGl2 PjxkaXY+PGRpdiBjbGFzcz0iaDUiPlBJTkcgMTkyLjE2OC4xLjExMiAoMTkyLjE2OC4xLj ExMikg NTYoODQpIGJ5dGVzIG9mIGRhdGEuPGJyIC8+LS0tIDE5Mi4xNjguMS4xMTIgcGluZyBzdG F0aXN0 aWNzIC0tLTxiciAvPjUwMCBwYWNrZXRzIHRyYW5zbWl0dGVkLCA0MjUgcmVjZWl2ZWQsID E1JSBw YWNrZXQgbG9zcywgdGltZSAxNTk4bXM8YnIgLz5ydHQgbWluL2F2Zy9tYXgvbWRldiA9ID AuMjUz LzEuMDgxLzEuNTc2LzAuNDE0IG1zLCBpcGcvZXdtYSAzLjIwMy8wLjg5NSBtczxiciAvPj xiciAv PmIpIE9uIHRoZSBzZXJ2ZXIgPGEgaHJlZj0iaHR0cDovLzE5Mi4xNjguMS4xMTIiIHRhcm dldD0i X2JsYW5rIj4xOTIuMTY4LjEuMTEyPC9hPjo8YnIgLz5pcGVyZiAtcyA4MDxiciAvPjxici AvPk9u IHRoZSBsYXB0b3A6PGJyIC8+aXBlcmYgLWMgMTkyLjE2OC4xLjExMiAtcCA4MCAtbiAxTS AtaSAx IC10IDE4MDxiciAvPjxiciAvPlRoZXJlIGFyZSByZXN1bHRzIG9mICZsZHF1bztuZXRzdG F0JnJk cXVvOzo8YnIgLz48YnIgLz5uZXRzdGF0IC13MWQgLUkgYWdlMDo8YnIgLz4mbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5wdX QgKGFn ZTApIG91dHB1dDxiciAvPnBhY2tldHMmbmJzcDsmbmJzcDsmbmJzcDsgZXJycyZuYnNwOy ZuYnNw OyZuYnNwOyZuYnNwOyBpZHJvcHMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYnl0ZXMmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGFja2V0cyZuYnNwOyZuYnNwOyZuYnNwOyBlcn JzJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJ5dGVzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG NvbGxz PGJyIC8+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IGNsYXNzPSJoNSI+Mzk2NiZuYnNwOyZuYn NwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3 A7Jm5i c3A7ICZuYnNwOyA1NTAxMzM2Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEwOD YmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyZuYnNwOyA1NjY0NiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyAw PGJyIC8+NDM4MCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy AwJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IDYxNDAwMzYmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMTEwMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDU4MjY2Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDA8YnIgLz40MzE1Jm5ic3A7Jm5ic3A7Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgJm 5ic3A7 Jm5ic3A7IDU2NTQ2OTgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTA4OSZuYn NwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7IDU1NDI0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID A8YnIg Lz4zNzAzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYn NwOyZu YnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IDUyOTE1MzgmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsgOTkwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5ic3A7 IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNTQxODImbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMDxiciAvPjM1NDgmbmJzcDsmbmJzcDsmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOy AmbmJz cDsgNDkxMDc3OCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA5OTImbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyZuYnNwOyA1MjI5MiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy AwPGJy IC8+Mzg5NCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyA1Mzk5MjE4Jm5ic3A7Jm5ic3A7Jm 5ic3A7 Jm5ic3A7Jm5ic3A7IDExNDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sgMCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA2MDc3MCZuYnNwOyZuYnNwOy ZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAwPGJyIC8+PGJyIC8+bmV0c3RhdCAtdzFkIC1JIHJsMD o8YnIg Lz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5wdXQgKHJsMCkgb3V0cHV0PGJyIC 8+cGFj a2V0cyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlcnJzJm5ic3A7Jm5ic3A7IGlkcm9wcy ZuYnNw OyZuYnNwOyZuYnNwOyBieXRlcyZuYnNwOyZuYnNwOyZuYnNwOyBwYWNrZXRzJm5ic3A7Jm 5ic3A7 Jm5ic3A7ICZuYnNwOyZuYnNwOyBlcnJzJm5ic3A7Jm5ic3A7IGJ5dGVzJm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7IGNvbGxzPGJyIC8+MTA4NSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sgNjUx MTImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNDAwNCZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7IDU2ODA1Nz YmbmJz cDsmbmJzcDsmbmJzcDsgMDxiciAvPjEwNTMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7IDYz Mjk2Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQ0MzImbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7ID YyODk1 ODYmbmJzcDsmbmJzcDsmbmJzcDsgMDxiciAvPjk3MiZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyA1ODUwOCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzNjY4Jm5ic3A7Jm5ic3A7Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOy ZuYnNw OyA1MTk1MTkwJm5ic3A7Jm5ic3A7Jm5ic3A7IDA8YnIgLz45NDQmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsgNTY2NzImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMzU1MCZuYnNwOy ZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7IDAmbmJzcD smbmJz cDsmbmJzcDsgNTAzMzkxNiZuYnNwOyZuYnNwOyZuYnNwOyAwPGJyIC8+MTEwOSZuYnNwOy ZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsgNjY5ODEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMzgxMy ZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ID AmbmJz cDsmbmJzcDsmbmJzcDsgNTQwODA5MCZuYnNwOyZuYnNwOyZuYnNwOyAwPGJyIC8+MTA5OS ZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNjU5NzImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sgMzk1 MiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7IDU2MDQ3NjAmbmJzcDsmbmJzcDsmbm JzcDsg MDxiciAvPjxiciAvPnRvcCAmbmRhc2g7Uzo8YnIgLz5sYXN0IHBpZDogMjM5NzsgbG9hZC BhdmVy YWdlczogMC4wNiwgMC4wNSwgMC4wNCB1cCAwKzAwOjA5OjEzIDE0OjI1OjUwPGJyIC8+Nj YgcHJv Y2Vzc2VzOiAzIHJ1bm5pbmcsIDUxIHNsZWVwaW5nLCAxMiB3YWl0aW5nPGJyIC8+Q1BVOi AwLjAl IHVzZXIsIDAuMCUgbmljZSwgMC41JSBzeXN0ZW0sIDMuNSUgaW50ZXJydXB0LCA5Ni4xJS BpZGxl PGJyIC8+TWVtOiAxNE0gQWN0aXZlLCA5MjQ4SyBJbmFjdCwgNTVNIFdpcmVkLCA5MksgQ2 FjaGUs IDExTSBCdWYsIDQwM00gRnJlZTxiciAvPlN3YXA6IDIwNDhNIFRvdGFsLCAyMDQ4TSBGcm VlPGJy IC8+PGJyIC8+NC5JUEZXIEtFUk5FTCBCSU5BVDxiciAvPjxiciAvPjwvZGl2PjwvZGl2Pj wvZGl2 PjwvZGl2PjxkaXY+PGRpdiBjbGFzcz0iaDUiPjxkaXY+YSkgcGluZyAtYyA1MDAgLWYgPG EgaHJl Zj0iaHR0cDovLzE5Mi4xNjguMS4xMTIiIHRhcmdldD0iX2JsYW5rIj4xOTIuMTY4LjEuMT EyPC9h Pjo8YnIgLz48L2Rpdj48ZGl2PlBJTkcgMTkyLjE2OC4xLjExMiAoMTkyLjE2OC4xLjExMi kgNTYo ODQpIGJ5dGVzIG9mIGRhdGEuPGJyIC8+LS0tIDE5Mi4xNjguMS4xMTIgcGluZyBzdGF0aX N0aWNz IC0tLTxiciAvPjwvZGl2PjxkaXY+PGRpdj41MDAgcGFja2V0cyB0cmFuc21pdHRlZCwgMz k4IHJl Y2VpdmVkLCAyMCUgcGFja2V0IGxvc3MsIHRpbWUgMTk2OG1zPGJyIC8+cnR0IG1pbi9hdm cvbWF4 L21kZXYgPSAwLjI4NC8xLjE0Ny8xLjU2OC8wLjQwNiBtcywgaXBnL2V3bWEgMy45NDQvMS 4wNTUg bXM8L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PGJyIC8+PGJyIC8+YikgT24gdGhlIHNlcnZlci A8YSBo cmVmPSJodHRwOi8vMTkyLjE2OC4xLjExMiIgdGFyZ2V0PSJfYmxhbmsiPjE5Mi4xNjguMS 4xMTI8 L2E+OjxiciAvPmlwZXJmIC1zIDgwPGJyIC8+PGJyIC8+T24gdGhlIGxhcHRvcDo8YnIgLz 5pcGVy ZiAtYyAxOTIuMTY4LjEuMTEyIC1wIDgwIC1uIDFNIC1pIDEgLXQgMTgwPGJyIC8+PGJyIC 8+VGhl cmUgYXJlIHJlc3VsdHMgb2YgJmxkcXVvO25ldHN0YXQmcmRxdW87OjxiciAvPjxiciAvPm 5ldHN0 YXQgLXcxZCAtSSBhZ2UwOjxiciAvPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsgJm 5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbnB1dCAoYWdlMCkgb3V0cHV0PGJyIC 8+cGFj a2V0cyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlcnJzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5ic3A7 IGlkcm9wcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBieXRlcyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyBwYWNrZXRzJm5ic3A7Jm5ic3A7IGVycnMmbmJzcDsmbmJzcDsmbmJzcDsgYnl0ZX MmbmJz cDsmbmJzcDsgY29sbHM8YnIgLz40MTM4Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD smbmJz cDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy A0NzE2 MzUwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDExMzgmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0Nz Y4MiZu YnNwOyZuYnNwOyZuYnNwOyAwPGJyIC8+MzQ1OCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5ic3A7 Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsg NTgxMjQ1NCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA4NjImbmJzcDsmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyZuYnNwOyA1ODM3NCZuYnNwOyZuYnNwOyZuYnNwOyAwPGJyIC8+NDE0NCZuYnNwOyZuYn NwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsgNTc2ODM2MCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy AxMTQz Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsgNTk2NzAmbmJzcDsmbmJzcDsmbmJzcDsgMDxiciAvPjQxNjQmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOy ZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDU1NDA4ODgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsg MTEzMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDYyNjQwJm5ic3A7Jm5ic3A7Jm5ic3A7IDA8YnIgLz4zOTU0Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0ODAzMDI0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7IDExOTUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOy ZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA1MDU5OCZuYnNwOyZuYnNwOyAwPGJyIC8+PG JyIC8+ bmV0c3RhdCAtdzFkIC1JIHJsMDo8YnIgLz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcD smbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7IGlu cHV0IChybDApIG91dHB1dDxiciAvPnBhY2tldHMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sgZXJy cyZuYnNwOyZuYnNwOyZuYnNwOyBpZHJvcHMmbmJzcDsmbmJzcDsmbmJzcDsgYnl0ZXMmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsgcGFja2V0cyZuYnNwOyZuYnNwOyZuYnNwOyBlcnJzJm5ic3 A7Jm5i c3A7Jm5ic3A7IGJ5dGVzJm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbGxzPGJyIC8+MTAwNyZuYn NwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3 A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsgNjA0OTImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsg MzYwOSZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7IDAmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsgNTExODY4MiZuYnNwOyZuYnNwOyAwPGJyIC8+OTUwJm5ic3 A7Jm5i c3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7IDAmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyZuYnNwOyA1NzAxMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy AzNjE0 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDUxMjY5ODgmbmJzcDsmbmJzcDsgMDxiciAvPjExNDYmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7IDAmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyZuYnNwOyA2ODc3MiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy A0MDM0 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNTcyMzEwOCZuYnNwOyZuYnNwOyAwPGJyIC8+MT EyMSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsgMCZuYn NwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDY3MjcyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5ic3A7 IDQwODgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IDAmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNTgwMTI2NiZuYnNwOyZuYnNwOyAwPGJyIC8+MT A0OCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsgMCZuYn NwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDYyODkyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5ic3A7 IDM0ODgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYn NwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0OTQ2NjM4Jm5ic3A7Jm5ic3A7IDA8Yn IgLz48 YnIgLz50b3AgJm5kYXNoO1M6PGJyIC8+bGFzdCBwaWQ6IDQ4NTI7IGxvYWQgYXZlcmFnZX M6IDAu MDcsIDAuMDMsIDAuMDAgdXAgMCsxNjowNjoxNSAwNTo1MzowNDxiciAvPjYzIHByb2Nlc3 Nlczog NCBydW5uaW5nLCA0NyBzbGVlcGluZywgMTIgd2FpdGluZzxiciAvPkNQVTogMC4wJSB1c2 VyLCAw LjAlIG5pY2UsIDcuMyUgc3lzdGVtLCA2LjclIGludGVycnVwdCwgODYuMCUgaWRsZTxici AvPk1l bTogMTVNIEFjdGl2ZSwgMTQyTSBJbmFjdCwgMTEwTSBXaXJlZCwgMTAwSyBDYWNoZSwgNT lNIEJ1 ZiwgMjE0TSBGcmVlPGJyIC8+U3dhcDogMjA0OE0gVG90YWwsIDIwNDhNIEZyZWU8YnIgLz 48YnIg Lz41Lk5HX05BVDo8YnIgLz48YnIgLz48L2Rpdj48L2Rpdj5hKSBwaW5nIC1jIDUwMCAtZi A8YSBo cmVmPSJodHRwOi8vMTkyLjE2OC4xLjExMiIgdGFyZ2V0PSJfYmxhbmsiPjE5Mi4xNjguMS 4xMTI8 L2E+OjxkaXY+PGRpdj5QSU5HIDE5Mi4xNjguMS4xMTIgKDE5Mi4xNjguMS4xMTIpIDU2KD g0KSBi eXRlcyBvZiBkYXRhLjxiciAvPi0tLSAxOTIuMTY4LjEuMTEyIHBpbmcgc3RhdGlzdGljcy AtLS08 YnIgLz41MDAgcGFja2V0cyB0cmFuc21pdHRlZCwgNDIyIHJlY2VpdmVkLCAxNSUgcGFja2 V0IGxv c3MsIHRpbWUgMTYyNG1zPGJyIC8+cnR0IG1pbi9hdmcvbWF4L21kZXYgPSAwLjI1NC8xLj AzOC84 Ljg2Mi8wLjU1MSBtcywgaXBnL2V3bWEgMy4yNTUvMC45NjEgbXM8YnIgLz48YnIgLz5iKS BPbiB0 aGUgc2VydmVyIDxhIGhyZWY9Imh0dHA6Ly8xOTIuMTY4LjEuMTEyIiB0YXJnZXQ9Il9ibG FuayI+ MTkyLjE2OC4xLjExMjwvYT46PGJyIC8+aXBlcmYgLXMgODA8YnIgLz48YnIgLz5PbiB0aG UgbGFw dG9wOjxiciAvPmlwZXJmIC1jIDE5Mi4xNjguMS4xMTIgLXAgODAgLW4gMU0gLWkgMSAtdC AxODA8 YnIgLz48YnIgLz5UaGVyZSBhcmUgcmVzdWx0cyBvZiAmbGRxdW87bmV0c3RhdCZyZHF1bz s6PGJy IC8+PGJyIC8+bmV0c3RhdCAtdzFkIC1JIGFnZTA6PGJyIC8+Jm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlucHV0IChhZ2UwKSBvdXRwdXQ8YnIgLz5wYWNrZXRzJm 5ic3A7 Jm5ic3A7Jm5ic3A7IGVycnMmbmJzcDsmbmJzcDsmbmJzcDsgaWRyb3BzJm5ic3A7Jm5ic3 A7Jm5i c3A7IGJ5dGVzJm5ic3A7Jm5ic3A7Jm5ic3A7IHBhY2tldHMmbmJzcDsmbmJzcDsgZXJycy ZuYnNw OyZuYnNwOyBieXRlcyZuYnNwOyZuYnNwOyBjb2xsczxiciAvPjQ4MTImbmJzcDsmbmJzcD sgJm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7Jm5i c3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sgNjYz NDAzOCZuYnNwOyZuYnNwOyAxMjY4Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID AmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNjY0NzQmbmJzcDsmbmJzcDsmbmJzcDsgMD xiciAv PjQ3NjUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3 A7IDAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA2NzAyMDkyJm5ic3A7Jm5ic3A7IDEyMzQmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy A2NjE1 MCZuYnNwOyZuYnNwOyZuYnNwOyAwPGJyIC8+NDg0OCZuYnNwOyZuYnNwOyZuYnNwOyZuYn NwOyZu YnNwOyAmbmJzcDsgJm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsg MCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA2NjE2OTMyJm 5ic3A7 Jm5ic3A7IDEyNjMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYn NwOyZu YnNwOyZuYnNwOyZuYnNwOyA2NjYzNiZuYnNwOyZuYnNwOyZuYnNwOyAwPGJyIC8+NDc2NC ZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7IDAmbmJzcDsmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyZuYnNwOyA2NTgyODY4Jm5ic3A7Jm5ic3A7IDEyMzcmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA3MDY4NiZuYnNwOyZuYn NwOyZu YnNwOyAwPGJyIC8+NDc0NiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcD sgJm5i c3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYn NwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA2NDk0NjgwJm5ic3A7Jm5ic3A7IDE0MD MmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyA3NjAzMiZuYnNwOyZuYnNwOyZuYnNwOyAwPGJyIC8+PGJyIC8+bmV0c3RhdCAtdzFkIC 1JIHJs MDo8YnIgLz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5wdXQgKHJsMCkgb3V0cHV0PGJyIC8+cG Fja2V0 cyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlcnJzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7IGlk cm9wcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBieXRlcyZuYnNwOyZuYnNwOyZuYnNwOy BwYWNr ZXRzJm5ic3A7Jm5ic3A7Jm5ic3A7IGVycnMmbmJzcDsmbmJzcDsgYnl0ZXMmbmJzcDsmbm JzcDsg Y29sbHM8YnIgLz4xMjE5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC ZuYnNw OyAmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID czMTcw Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQ2ODAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD smbmJz cDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyA2NjM0ODg2Jm5ic3A7Jm5ic3A7Jm5ic3 A7IDA8 YnIgLz4xMjI1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5ic3A7 ICZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5ic3A7 IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNz M1MTIm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNDcyMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7IDY2OTY5NjAmbmJzcDsmbmJzcDsmbmJzcD sgMDxi ciAvPjEyMTkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOy ZuYnNw OyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID AmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNzMxNzAmbm JzcDsm bmJzcDsmbmJzcDsmbmJzcDsgNDY1NSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy ZuYnNw OyAwJm5ic3A7Jm5ic3A7Jm5ic3A7IDY2MDM0NDAmbmJzcDsmbmJzcDsmbmJzcDsgMDxici AvPjEz ODAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOy AwJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgODI4MTImbmJzcDsmbm JzcDsm bmJzcDsmbmJzcDsgNDYzMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy AwJm5i c3A7Jm5ic3A7Jm5ic3A7IDY1NzAxNjYmbmJzcDsmbmJzcDsmbmJzcDsgMDxiciAvPjE0MT QmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAwJm5ic3 A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcD smbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgODQ4NjQmbmJzcDsmbmJzcDsmbm JzcDsm bmJzcDsgNDU4NSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3 A7Jm5i c3A7Jm5ic3A7IDY1MDQxNzgmbmJzcDsmbmJzcDsmbmJzcDsgMDxiciAvPjxiciAvPjwvZG l2Pjwv ZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PkNyb3NzcG9zdGVkIHRvIGZyZW Vic2Qt cGVyZm9tYW5jZS48YnIgLz48L2Rpdj48L2Rpdj4= From owner-freebsd-net@FreeBSD.ORG Fri Jun 4 15:11:13 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7F44106567D for ; Fri, 4 Jun 2010 15:11:13 +0000 (UTC) (envelope-from josemi@freebsd.jazztel.es) Received: from smtp01.jazztel.es (smtp01.jazztel.es [62.14.3.170]) by mx1.freebsd.org (Postfix) with ESMTP id 4F39B8FC1F for ; Fri, 4 Jun 2010 15:11:12 +0000 (UTC) Received: from [87.217.187.210] (helo=[192.168.254.16]) by smtp01.jazztel.es with esmtpa (Exim 4.69) (envelope-from ) id 1OKYEh-0001dt-Hh; Fri, 04 Jun 2010 16:51:04 +0200 Message-ID: <4C0912CC.8030807@freebsd.jazztel.es> Date: Fri, 04 Jun 2010 16:50:52 +0200 From: Jose M Rodriguez User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; es-ES; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ian Smith References: <201006020240.o522e3sU024508@freefall.freebsd.org> <20100603154510.T27982@sola.nimnet.asn.au> In-Reply-To: <20100603154510.T27982@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiSpam-Checked: Passed : Threshold - 0.0 : SA jazztel.es X-Virus-Checked: Passed : Kaspersky at jazztel.es Cc: freebsd-net@freebsd.org Subject: Re: kern/147191: [ppp] Problems with ppp -nat [pppoe], ipfw, dummynet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 15:11:14 -0000 El 03/06/2010 9:15, Ian Smith escribió: > On Wed, 2 Jun 2010, Jose M Rodriguez wrote: > > The following reply was made to PR kern/147191; it has been noted by GNATS. > > > > From: Jose M Rodriguez > > To: bug-followup@FreeBSD.org > > Cc: > > Subject: Re: kern/147191: [ppp] Problems with ppp -nat [pppoe], ipfw, dummynet > > Date: Wed, 02 Jun 2010 04:31:49 +0200 > [..] > > El 02/06/2010 2:37, Jose M Rodriguez escribió: > > > Seems that this must be reopen. > > > ... > > Seems this one worked, but I don't remember this last time I use ipfw on > > FreeBSD-7 > > > [..] > > Content-Disposition: attachment; > > filename="rc.firewall.router.4" > > > > #!/bin/sh - > > # Copyright (c) 1996 Poul-Henning Kamp > > # All rights reserved. > [..] > > # $FreeBSD: src/etc/rc.firewall,v 1.60.2.3 2010/04/14 15:03:58 ume Exp $ > > I had to do a 'diff -uw rc.firewall.1.60.2.3 rc.firewall.router.4' (and > before that, vs your previous rc.firewall.router.1) to follow what was > going on here; you've added some 'interesting' stuff (esp dummynet), but > I think your main problem is the placement of the NAT rule, where you've > merged it into what is otherwise based on the 'workstation' ruleset. > > ... I don't have much experience doing ipfw setups, but I've setup docens of boxes with ipfilter. I don't think this maybe a 'rule' problem. I expect two hits, one IN and other OUT, per IP packet. But maybe this is NOT the case. I do things as I learned to do: - lo0 - local lans (big traffic, more simple) - outside (less traffic, complex) My initial setup (rc.firewall.router.4) uses ppp -nat, without natd. and one_pass=1 (without I Know). It mostly works, and I learn that I must setup one_pass=0 to get the packet again on ipfw after dummynet. As I can read, this must also matters to ppp -nat. So I expect that a packed passed IN from local lan, after translated, hit the firewall as XMIT on tun0. I near sure this is not the case. Can anyone probe this? So I must put the dummynet catching incoming traffic from lan to be translated later by ppp. This setup is NOW WORKING, with the sharper being effective and without problems with ppp -nat rc.firewall.router.1 it's another history, after the problems with ppp, using mpd5 and natd. I can't test this well, and the way things go are really odd, but this is how I get things mostly working. What I noted on this setup is that I must pass the traffic incoming from local lan LAST, or NATP is not fuction at all (I use to do LAN traffic very first by performance reasons). I begin to think in a libalias problem (inside natd this time), but I'm also in doubt about the two IN/OUT hits. Maybe there's only one hit as IN/OUT, as from a bridge hook? In any case, the gotos (skipto) are placed not only as logic, but also to get counts of packets and try to see what's going on. I know that the natd rule in not at the very first (/etc/rc.firewall use to put it as rule 25, even before 100 lo0.) but also near sure that no traffic that can matters natd (via oif, ng0) is passed or denied before that. This matters about being able to catch incoming lan Traffic before translated. This maybe my first test when I got time again. Replace natd at rule 25 and do again LAN traffic at FIRST. Also thinking in doing an altq/pf test. And I added SOME line to my ipfw Notes: - put dummynet VERY FIRST, if possible on INCOMING, and be sure that sysctl net.inet.ip.fw.one_pass=0. - FreeBSD don't expect by default any firewall processing after libalias. But now, I'm very busy, really -- josemi From owner-freebsd-net@FreeBSD.ORG Fri Jun 4 19:43:06 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F2851065678; Fri, 4 Jun 2010 19:43:06 +0000 (UTC) (envelope-from bseklecki@collaborativefusion.com) Received: from collaborativefusion.com (pr40.pitbpa0.pub.collaborativefusion.com [206.210.89.202]) by mx1.freebsd.org (Postfix) with ESMTP id F11EC8FC1B; Fri, 4 Jun 2010 19:43:05 +0000 (UTC) Received: from [192.168.2.161] (soundwave.ws.pitbpa0.priv.collaborativefusion.com [192.168.2.161]) by relay.admin.pitbpa0.priv.collaborativefusion.com with esmtp; Fri, 04 Jun 2010 15:33:03 -0400 id 00000013.000000004C0954EF.0000C4ED From: "Brian A. Seklecki" To: freebsd-net Organization: Collaborative Fusion, Inc. Date: Fri, 04 Jun 2010 15:33:03 -0400 Message-ID: <1275679983.3910.134.camel@soundwave> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=_skyhopper-50413-1275679983-0001-2" X-Mailer: Evolution 2.30.1.2 (2.30.1.2-8.fc13) Cc: brooks@freebsd.org, Steve Polyack , Sean McAfee , jon.otterholm@ide.resurscentrum.se, jfvogel@gmail.com, samflanker@gmail.com, Zaphod Beeblebrox Subject: re: [trouble] restart network & vlan`s interface (if_vlan / conf/63700 redux) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bseklecki@collaborativefusion.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 19:43:06 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_skyhopper-50413-1275679983-0001-2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [Originally from freebsd-hackers@ / Feb 2008] All: =20 pf conf/63700 got the ball rolling on fixing cloned/VLAN=20 interface management with rc.d/netif, but problems still remain. =20 For example, adding an alias to a VLAN and running: /etc/rc.d/netif restart && /etc/rc.d/routing restart=20 is a failure. Take the following rc.conf(4) config: hostname=3D"sexdrugsandunix" cloned_interfaces=3D"vlan14" ifconfig_em0=3D"up media 100baseTX mediaopt full-duplex -tso" ifconfig_vlan14=3D"inet 1.2.3.4 netmask 255.255.255.128 vlan 14 vlandev em0 up" ifconfig_vlan14_alias0=3D"inet 1.2.3.5 netmask 255.255.255.255" Change it to include a second alias without a reboot, instead run 'rc.d/netif restart', as works on a physical interface: hostname=3D"sexdrugsandunix" cloned_interfaces=3D"vlan14" ifconfig_em0=3D"up media 100baseTX mediaopt full-duplex -tso" ifconfig_vlan14=3D"inet 1.2.3.4 netmask 255.255.255.128 vlan 14 vlandev em0 up" ifconfig_vlan14_alias0=3D"inet 1.2.3.5 netmask 255.255.255.255" ifconfig_vlan14_alias1=3D"inet 1.2.3.6 netmask 255.255.255.255" The result will be: % ifconfig vlan14 [bseklecki@sureshot ~]$ ifconfig vlan14 vlan14: flags=3D8843 metric 0 mtu= =20 inet 1.2.3.6 netmask 0xffffffff broadcast 192.168.158.152 inet 1.2.3.5 netmask 0xffffffff broadcast 192.168.158.255 1) I'm not sure where the .152 broadcast comes from. ?! 2) The new _alias1=3D data is now in the primary IP slot 3) The primary IP is lost, there is no routable IP 4) The original _alias0=3D data is now in the 1st alias slot 5) rc.d/routing fails because the interface lacks a routable IP with a valid netmask/broadcast combination. --------------------------- Problem #1: rc.d/netif::network_stop() The core problem is that rc.d/netif::network_stop() never calls network.subr::clone_down() in the same way that rc.d/netif::network_start() calls network.subr::cloned_up() I'd speculate that this is a design decision not to destroy=20 network interfaces that certain userland daemons (DHCP, RTADVD,=20 BPF) may be strictly bound to; I disagree. Even if you explicitly pass your VLAN interface to rc.d/netif, a stop doesn't call 'ifconfig VL destory', and, when 'rc.d/netif start' is called later, SIOCSETVLAN results. jail-host-80:/home/bseklecki% sudo ifconfig vlan666 destroy jail-host-80:/home/bseklecki% sudo ifconfig vlan666=20 create inet 1.2.3.4 netmask 255.255.255.0 vlan 666 vlandev em0 jail-host-80:/home/bseklecki% sudo ifconfig vlan666=20 create inet 1.2.3.4 netmask 255.255.255.0 vlan 666 vlandev em0 ifconfig: create: bad value A simple rc.d/network_stop() patch could fix this problem if=20 we can avoid bikeshedding. ------------------------------------------ Problem #2: VLAN interface data structures maintain configuration=20 data after being destroyed, *SOMETIMES* %ifconfig vlan666 vlan666: flags=3D8843 metric 0 mtu 1500 options=3D3 ether 00:0c:29:a1:4b:9d inet 192.168.15.54 netmask 0xffffff00 broadcast 192.168.15.255 media: Ethernet 1000baseT status: active vlan: 666 parent interface: em0 %sudo ifconfig vlan666 destroy %sudo ifconfig vlan666 create %ifconfig vlan666 vlan666: flags=3D8843 metric 0 mtu 1500 options=3D3 ether 00:0c:29:a1:4b:9d !!**?>> inet 192.168.15.54 netmask 0xffffff00 broadcast 192.168.15.255 media: Ethernet 1000baseT status: active vlan: 666 parent interface: em0 Now, that's something you don't see very day!! ---------------------------------------------------- NOTE: I can't get that persistent IP data problem to happen consistently, but its highly reproducible. I also have no idea on the fixes, I'll check this weekend, but I have a work-around. To avoid destroying your routing table after adding an alias to a VLAN interface in rc.conf(5), simply run: $ sudo /etc/rc.d/netif [VLAN####] start DO NOT RESTART, and you should be okay. ~BAS References: http://lists.freebsd.org/pipermail/freebsd-hackers/2008-February/023440.htm= l http://www.freebsd.org/cgi/query-pr.cgi?pr=3D63700&cat=3D (Circa 2004) http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015447.html --=20 Brian A. Seklecki Collaborative Fusion, Inc. --=_skyhopper-50413-1275679983-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkwJVO8ACgkQCne6BNDQ+R8HwgCfT4bArdbmohpzNxPW2bqj0EJ7 YKoAn3uFMA0eEtgogxn1Ig+BjppHh9dD =oBT8 -----END PGP SIGNATURE----- --=_skyhopper-50413-1275679983-0001-2-- From owner-freebsd-net@FreeBSD.ORG Sat Jun 5 08:08:38 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB9051065672; Sat, 5 Jun 2010 08:08:38 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 643B98FC1D; Sat, 5 Jun 2010 08:08:38 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 67EB9A5667D; Sat, 5 Jun 2010 16:08:37 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id J6SD2Q-FrbrS; Sat, 5 Jun 2010 16:08:32 +0800 (CST) Received: from quakelee-work (unknown [222.131.125.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 47F53A5664E; Sat, 5 Jun 2010 16:08:29 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=geekcn.org; c=nofws; q=dns; h=content-type:to:subject:date:cc:mime-version: content-transfer-encoding:from:organization:message-id:user-agent; b=ti/+cWU11SxkFWREt2/3O9OZB4FCuG8RuF/4e31UhJiyjhvF9MTwfVx3rR7k/fEah D0igCh8YbpZS0VDTrYhHw== Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Date: Sat, 05 Jun 2010 16:08:18 +0800 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Chao Shin" Organization: GeekCN Message-ID: User-Agent: Opera Mail/10.51 (Win32) Cc: "freebsd-net@freebsd.org" , sam@freebsd.org, bz@freebsd.org, qingli@freebsd.org Subject: panic: rtqkill route really not free on freebsd 8.0-release update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2010 08:08:38 -0000 Hi, all We add kdb/ddb and extra panic info printing into kernel and catch this panic again. We have instrumented the kernel and found that this panic happens when draining == 1, but seems to be confused with the fact that all access to radix trees are protected by locks. Can anyone familiar with these code shed us some light on this? below is url to screenshot in ddb: http://www.delphij.net/zhao/1.png http://www.delphij.net/zhao/2.png -- The Power to Serve From owner-freebsd-net@FreeBSD.ORG Sat Jun 5 16:47:52 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9C411065676 for ; Sat, 5 Jun 2010 16:47:52 +0000 (UTC) (envelope-from perevalov84@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 77E4E8FC20 for ; Sat, 5 Jun 2010 16:47:52 +0000 (UTC) Received: by pxi7 with SMTP id 7so825579pxi.13 for ; Sat, 05 Jun 2010 09:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=rdb865+qS+qSojygLp98xe+H9x9FWOAfRjG7wS8q4Wk=; b=Z+45OHdwea7CBo8LO2o7pGw52UecjsLSGSO738pIgj588BwCGDNdiqXnv8APfvjwh/ zQmeUszynF/tqCIu/fKBb1kgMsOZC+nIWUPao9TUifnHdRAlbTYAG9PMzLYs2PWD4N5W Gvl0jyOF4LSSP5mJZNfteHvR6Yrr9IAUyEDB4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=XMvXQLRzAkochMQ46ixZtoTTBFUoYEQ5RpoqL8r/ptGomkp8mb7GbzVGBlWs5nH0mH lFbsqi8lRwdF0akXfIRwnB524BHvGNSu6bIYqbSTU5onVf07xMqwatAelfxcVv9UmRAS sUxTM+bpuEZFUxEIVd9+iUUD6VYLs8JqqMphA= Received: by 10.115.134.10 with SMTP id l10mr9912376wan.138.1275756470792; Sat, 05 Jun 2010 09:47:50 -0700 (PDT) Received: from [192.168.2.2] ([95.58.35.15]) by mx.google.com with ESMTPS id c14sm20069963waa.13.2010.06.05.09.47.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 05 Jun 2010 09:47:48 -0700 (PDT) Message-ID: <4C0A7F66.2040701@gmail.com> Date: Sat, 05 Jun 2010 21:46:30 +0500 From: Perevalov Sergey User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100506 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4BE44E2D.6060907@gmail.com> <4C07B344.4060805@gmail.com> <20100603214606.GE13502@michelle.cdnetworks.com> <201006040924.11427.hselasky@c2i.net> In-Reply-To: <201006040924.11427.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, Hans Petter Selasky Subject: Re: [axe][ue0] Device send packets but any host in network can not receive any packet from it. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2010 16:47:52 -0000 On 04.06.2010 12:24, Hans Petter Selasky wrote: > On Thursday 03 June 2010 23:46:06 Pyun YongHyeon wrote: > >>> Jun 3 18:29:52 homeserv kernel: axe_bulk_write_callback: transfer >>> error, USB_ERR_TIMEOUT >>> >> I don't see abnormal things in axe(4). Maybe Hans can help(CCed). >> >> > Timeout might mean that the data format is not accepted. > > --HPS > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > Guys, would you suggest ways to test this device for determine exact cause of my problem. Thank you! -- Regards, Sergey.