From owner-freebsd-net Sun Sep 2 5:59:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from elm.phenome.org (elm.phenome.org [194.153.169.3]) by hub.freebsd.org (Postfix) with ESMTP id CBF3937B406 for ; Sun, 2 Sep 2001 05:59:03 -0700 (PDT) Received: from localhost (joshua@localhost [127.0.0.1]) by localhost (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) with ESMTP id f82Cx22r018883; Sun, 2 Sep 2001 13:59:02 +0100 Date: Sun, 2 Sep 2001 13:59:02 +0100 (BST) From: Joshua Goodall X-X-Sender: To: Paul Chvostek Cc: Subject: arpwh (was: Gratuitous ARP (summary)) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1715338327-2083909239-999435542=:20276" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1715338327-2083909239-999435542=:20276 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 2 Sep 2001, I wrote: > I think, ultimately, the only guaranteed way is to construct your own ARP > packet and write it at the link layer. arping uses libnet for this. ... and just for a lark, I rolled a tool using libnet to fulfill my own requirements. sharball attached. Requires the libnet port/package. Possibly this is a useful template for people needing similiar code. If anyone cares enough I might make it a port, but it does duplicate functionality available in several existing ports (dsniff, arping, others?). J ---1715338327-2083909239-999435542=:20276 Content-Type: APPLICATION/x-shar; name="arpwh.shar" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="arpwh.shar" IyBUaGlzIGlzIGEgc2hlbGwgYXJjaGl2ZS4gIFNhdmUgaXQgaW4gYSBmaWxl LCByZW1vdmUgYW55dGhpbmcgYmVmb3JlCiMgdGhpcyBsaW5lLCBhbmQgdGhl biB1bnBhY2sgaXQgYnkgZW50ZXJpbmcgInNoIGZpbGUiLiAgTm90ZSwgaXQg bWF5CiMgY3JlYXRlIGRpcmVjdG9yaWVzOyBmaWxlcyBhbmQgZGlyZWN0b3Jp ZXMgd2lsbCBiZSBvd25lZCBieSB5b3UgYW5kCiMgaGF2ZSBkZWZhdWx0IHBl cm1pc3Npb25zLgojCiMgVGhpcyBhcmNoaXZlIGNvbnRhaW5zOgojCiMJYXJw d2gKIwlhcnB3aC9NYWtlZmlsZQojCWFycHdoL2FycHdoLmMKIwlhcnB3aC9h cnB3aC44CiMKZWNobyBjIC0gYXJwd2gKbWtkaXIgLXAgYXJwd2ggPiAvZGV2 L251bGwgMj4mMQplY2hvIHggLSBhcnB3aC9NYWtlZmlsZQpzZWQgJ3MvXlgv LycgPmFycHdoL01ha2VmaWxlIDw8ICdFTkQtb2YtYXJwd2gvTWFrZWZpbGUn ClgjICRJZDogTWFrZWZpbGUsdiAxLjkgMjAwMS8wOS8wMiAxMjo0NDozMCBq b3NodWEgRXhwIGpvc2h1YSAkClgKWFBST0c9CWFycHdoClhNQU49CWFycHdo LjgKWEJJTkRJUj0JL3Vzci9sb2NhbC9zYmluClhNQU5ESVI9CS91c3IvbG9j YWwvbWFuL21hbgpYTk9PQko9CTEKWApYTElCTkVUREVGUyE9CWxpYm5ldC1j b25maWcgLS1kZWZpbmVzClhDRkxBR1MrPS1JL3Vzci9sb2NhbC9pbmNsdWRl ICR7TElCTkVUREVGU30KWExEQUREKz0JLWxuZXQKWExERkxBR1MrPQktTC91 c3IvbG9jYWwvbGliClgKWC5pbmNsdWRlIDxic2QucHJvZy5taz4KRU5ELW9m LWFycHdoL01ha2VmaWxlCmVjaG8geCAtIGFycHdoL2FycHdoLmMKc2VkICdz L15YLy8nID5hcnB3aC9hcnB3aC5jIDw8ICdFTkQtb2YtYXJwd2gvYXJwd2gu YycKWC8qClggKiBDb3B5cmlnaHQgKEMpIDIwMDEgSm9zaHVhIEdvb2RhbGwg PGpvc2h1YUByb3VnaHRyYWRlLm5ldD4KWCAqIEFsbCByaWdodHMgcmVzZXJ2 ZWQuClggKgpYICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2Ug YW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0ClggKiBtb2RpZmlj YXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93 aW5nIGNvbmRpdGlvbnMKWCAqIGFyZSBtZXQ6ClggKiAxLiBSZWRpc3RyaWJ1 dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNv cHlyaWdodApYICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9u cyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgpYICogMi4gUmVkaXN0 cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBh Ym92ZSBjb3B5cmlnaHQKWCAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNv bmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUK WCAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBw cm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uClggKgpYICogVEhJUyBT T0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBBVVRIT1IgQU5EIENPTlRSSUJVVE9S UyBgYEFTIElTJycgQU5EClggKiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdB UlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUK WCAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5E IEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFClggKiBBUkUgRElT Q0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIEFVVEhPUiBPUiBDT05UUklC VVRPUlMgQkUgTElBQkxFClggKiBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1Qs IElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVO VElBTApYICogREFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQg VE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMKWCAqIE9SIFNF UlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVT SU5FU1MgSU5URVJSVVBUSU9OKQpYICogSE9XRVZFUiBDQVVTRUQgQU5EIE9O IEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNU LCBTVFJJQ1QKWCAqIExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5F R0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkKWCAq IE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURW SVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKWCAqIFNVQ0ggREFNQUdFLgpY ICoKWCAqICRJZDogYXJwd2guYyx2IDEuNiAyMDAxLzA5LzAyIDExOjUwOjMx IGpvc2h1YSBFeHAgam9zaHVhICQKWCAqLwpYClgjaW5jbHVkZSA8c3RkaW8u aD4KWCNpbmNsdWRlIDxsaWJuZXQuaD4KWApYdV9jaGFyIGV0aF9icm9hZGNh c3RbRVRIRVJfQUREUl9MRU5dID0gezB4ZmYsIDB4ZmYsIDB4ZmYsIDB4ZmYs IDB4ZmYsIDB4ZmZ9OwpYdV9jaGFyIGV0aF9ub3NyY1tFVEhFUl9BRERSX0xF Tl0gPSB7MHgwMCwgMHgwMCwgMHgwMCwgMHgwMCwgMHgwMCwgMHgwMH07ClgK WGludCBtYWluIF9fUCgoaW50LCBjaGFyICpbXSkpOwpYdm9pZCB1c2FnZSBf X1AoKHZvaWQpKTsKWApYaW50ClhtYWluKGFyZ2MsIGFyZ3YpClgJaW50IGFy Z2M7ClgJY2hhciAqYXJndltdOwpYewpYCWNoYXIgZXJyX2J1ZltMSUJORVRf RVJSQlVGX1NJWkVdOwpYCXN0cnVjdCBldGhlcl9hZGRyICpzaGE7ClgJc3Ry dWN0IGxpYm5ldF9saW5rX2ludCAqbGluazsKWAljaGFyICAgKmludGVyZmFj ZTsKWAljaGFyICAgKmFkZHJlc3N6OwpYCXVfY2hhciAqcGFja2V0OwpYCXVf Y2hhciBldGhfZHN0W0VUSEVSX0FERFJfTEVOXTsKWAl1X2NoYXIgZXRoX3Ny Y1tFVEhFUl9BRERSX0xFTl07ClgJdV9sb25nIGlwYWRkcjsKWApYCWlmIChh cmdjICE9IDMpClgJCXVzYWdlKCk7ClgKWAlpbnRlcmZhY2UgPSAqKythcmd2 OwpYCWFkZHJlc3N6ICA9ICorK2FyZ3Y7ClgKWAkvKiBCdWlsZCBkYXRhIHN0 cnVjdHVyZXMuICovClgKWAlsaW5rID0gbGlibmV0X29wZW5fbGlua19pbnRl cmZhY2UoaW50ZXJmYWNlLCBlcnJfYnVmKTsKWAlpZiAobGluayA9PSBOVUxM KQpYCQlsaWJuZXRfZXJyb3IoTElCTkVUX0VSUl9GQVRBTCwgIiVzXG4iLCBl cnJfYnVmKTsKWApYCXNoYSA9IGxpYm5ldF9nZXRfaHdhZGRyKGxpbmssIGlu dGVyZmFjZSwgZXJyX2J1Zik7ClgJaWYgKHNoYSA9PSBOVUxMKQpYCQlsaWJu ZXRfZXJyb3IoTElCTkVUX0VSUl9GQVRBTCwgIiVzXG4iLCBlcnJfYnVmKTsK WApYCWlmICgoaXBhZGRyID0gbGlibmV0X25hbWVfcmVzb2x2ZShhZGRyZXNz eiwgMSkpID09IC0xKQpYCQlsaWJuZXRfZXJyb3IoTElCTkVUX0VSUl9GQVRB TCwgImxpYm5ldF9uYW1lX3Jlc29sdmUoKVxuIik7ClgJClgJbWVtY3B5KGV0 aF9kc3QsIGV0aF9icm9hZGNhc3QsIEVUSEVSX0FERFJfTEVOKTsKWAltZW1j cHkoZXRoX3NyYywgc2hhLT5ldGhlcl9hZGRyX29jdGV0LCBFVEhFUl9BRERS X0xFTik7ClgKWAkvKiBCdWlsZCBwYWNrZXQuICovClgKWAlpZiAobGlibmV0 X2luaXRfcGFja2V0KExJQk5FVF9FVEhfSCArIExJQk5FVF9BUlBfSCwgJnBh Y2tldCkgPT0gLTEpClgJCWxpYm5ldF9lcnJvcihMSUJORVRfRVJSX0ZBVEFM LCAibGlibmV0X2luaXRfcGFja2V0KCkiKTsKWApYCWlmIChsaWJuZXRfYnVp bGRfZXRoZXJuZXQoZXRoX2RzdCwgZXRoX3NyYywgRVRIRVJUWVBFX0FSUCwg TlVMTCwgMCwKWAkgICAgcGFja2V0KSA9PSAtMSkKWAkJbGlibmV0X2Vycm9y KExJQk5FVF9FUlJfRkFUQUwsICJsaWJuZXRfYnVpbGRfZXRoZXJuZXQoKVxu Iik7ClgKWAlpZiAobGlibmV0X2J1aWxkX2FycChBUlBIUkRfRVRIRVIsIEVU SEVSVFlQRV9JUCwgRVRIRVJfQUREUl9MRU4sClgJICAgIDQsIEFSUE9QX1JF UVVFU1QsIHNoYS0+ZXRoZXJfYWRkcl9vY3RldCwgKHVfY2hhciAqKSZpcGFk ZHIsClgJICAgIC8qIHNoYS0+ZXRoZXJfYWRkcl9vY3RldCwgKHVfY2hhciAq KSZpcGFkZHIsIE5VTEwsIDAsICovClgJICAgIGV0aF9ub3NyYywgKHVfY2hh ciAqKSZpcGFkZHIsIE5VTEwsIDAsClgJICAgIHBhY2tldCArIExJQk5FVF9F VEhfSCkgPT0gLTEpClgJCWxpYm5ldF9lcnJvcihMSUJORVRfRVJSX0ZBVEFM LCAibGlibmV0X2J1aWxkX2FycCgpXG4iKTsKWApYCS8qIFdyaXRlIHBhY2tl dC4gKi8KWApYCWlmIChsaWJuZXRfd3JpdGVfbGlua19sYXllcihsaW5rLCBp bnRlcmZhY2UsIHBhY2tldCwKWAkgICAgTElCTkVUX0VUSF9IICsgTElCTkVU X0FSUF9IKSA9PSAtMSkKWAkJbGlibmV0X2Vycm9yKExJQk5FVF9FUlJfRkFU QUwsICJsaWJuZXRfd3JpdGVfbGlua19sYXllcigpXG4iKTsKWApYCWV4aXQo MCk7Clh9ClgKWHZvaWQKWHVzYWdlKCkKWHsKWAkodm9pZClmcHJpbnRmKHN0 ZGVyciwgInVzYWdlOiBhcnB3aCBpbnRlcmZhY2UgYWRkcmVzc1xuIik7ClgJ ZXhpdCgxKTsKWH0KRU5ELW9mLWFycHdoL2FycHdoLmMKZWNobyB4IC0gYXJw d2gvYXJwd2guOApzZWQgJ3MvXlgvLycgPmFycHdoL2FycHdoLjggPDwgJ0VO RC1vZi1hcnB3aC9hcnB3aC44JwpYLlwiIENvcHlyaWdodCAoQykgMjAwMSBK b3NodWEgR29vZGFsbCA8am9zaHVhQHJvdWdodHJhZGUubmV0PgpYLlwiIEFs bCByaWdodHMgcmVzZXJ2ZWQuClguXCIgClguXCIgUmVkaXN0cmlidXRpb24g YW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3 aXRob3V0ClguXCIgbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3Zp ZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zClguXCIgYXJlIG1l dDoKWC5cIiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVz dCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodApYLlwiICAgIG5vdGljZSwg dGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlz Y2xhaW1lci4KWC5cIiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZv cm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodApYLlwiICAg IG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xs b3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKWC5cIiAgICBkb2N1bWVudGF0aW9u IGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlz dHJpYnV0aW9uLgpYLlwiIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkg QVVUSE9SIEFORCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORApYLlwiIEFO WSBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBC VVQgTk9UIExJTUlURUQgVE8sIFRIRQpYLlwiIElNUExJRUQgV0FSUkFOVElF UyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElD VUxBUiBQVVJQT1NFClguXCIgQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVO VCBTSEFMTCBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQpYLlwi IEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lB TCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMClguXCIgREFNQUdFUyAo SU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9G IFNVQlNUSVRVVEUgR09PRFMKWC5cIiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBV U0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElP TikKWC5cIiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBM SUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVApYLlwiIExJ QUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RI RVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkKWC5cIiBPVVQgT0YgVEhFIFVT RSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBP U1NJQklMSVRZIE9GClguXCIgU1VDSCBEQU1BR0UuClguXCIKWC5cIiAkSWQ6 IGFycHdoLjgsdiAxLjQgMjAwMS8wOS8wMiAxMjo0NDozMCBqb3NodWEgRXhw IGpvc2h1YSAkClguXCIKWC5EZCBTZXB0ZW1iZXIgMiwgMjAwMQpYLkR0IEFS UFdIIDgKWC5PcyBhcnB3aCAxLjIKWC5TaCBOQU1FClguTm0gYXJwd2gKWC5O ZCBzZW5kIGFycCB3aG8taGFzClguU2ggU1lOT1BTSVMKWC5ObQpYLkFyIGlu dGVyZmFjZSBob3N0ClguU2ggREVTQ1JJUFRJT04KWFRoZQpYLk5tClh1dGls aXR5IHdyaXRlcyBhIEdyYXR1aXRvdXMgQVJQIHdoby1oYXMgcGFja2V0IG91 dCBvZiB0aGUKWC5BciBpbnRlcmZhY2UKWHdpdGggYm90aCB0aGUgcmVxdWVz dCBhbmQgdGVsbCBJUCBhZGRyZXNzZXMgc2V0IHRvIHRoZSBnaXZlbgpYLkFy IGhvc3QgLgpYLlNoIERJQUdOT1NUSUNTClhUaGUKWC5ObQpYdXRpbGl0eSBl eGl0cyAwIG9uIHN1Y2Nlc3MsIGFuZCA+MCBpZiBhbiBlcnJvciBvY2N1cnMu ClguU2ggU0VFIEFMU08KWC5YciBhcnAgOCAsClguWHIgaWZjb25maWcgOApY LlNoIEFVVEhPUiAKWC5BbiBKb3NodWEgR29vZGFsbCBBcSBqb3NodWFAcm91 Z2h0cmFkZS5uZXQKRU5ELW9mLWFycHdoL2FycHdoLjgKZXhpdAoK ---1715338327-2083909239-999435542=:20276-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 2 8:50:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id EB23E37B403 for ; Sun, 2 Sep 2001 08:50:32 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id AAA08099; Mon, 3 Sep 2001 00:50:36 +0900 (JST) Date: Mon, 03 Sep 2001 00:35:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: raviprasad20@netscape.net Cc: freebsd-net@FreeBSD.ORG Subject: Re: all router address "ff02::02" In-Reply-To: <279FE9BB.0AB663C0.9513E96F@netscape.net> References: <279FE9BB.0AB663C0.9513E96F@netscape.net> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 20 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Thu, 23 Aug 2001 07:51:03 -0400, >>>>> raviprasad20@netscape.net said: > I found that in the rtadvd daemon code there is a function which is called to join to the all router multicast address( ff02::02). > My doubt is if rtadvd is disabled for a router then whether it will join the all routers multicast list? > one reason i find for such a implementation is that joining the all router multicast address (ff02::02) is useless for a router if it is not running rtadvd. > Is my understanding correct? or is the router joins the all router multicast address at some other place other than rtadvd? In the KAME's implementation, (which is base code of FreeBSD), applications that have to join the all-routers multicast group join on their own. rtadvd, pim6dd and pim6sd are examples of such applications. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 2 10: 3: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailout05.sul.t-online.de (mailout05.sul.t-online.com [194.25.134.82]) by hub.freebsd.org (Postfix) with ESMTP id F31A137B406; Sun, 2 Sep 2001 10:02:50 -0700 (PDT) Received: from fwd01.sul.t-online.de by mailout05.sul.t-online.de with smtp id 15dae1-0006Cv-0B; Sun, 02 Sep 2001 19:02:49 +0200 Received: from dan-dyn.dan-up.de (520025278484-0001@[217.88.166.105]) by fmrl01.sul.t-online.com with esmtp id 15dadx-0D1tgmC; Sun, 2 Sep 2001 19:02:45 +0200 Received: from dan-gate.dan-up.de (dan-gate [10.8.9.40]) by dan-dyn.dan-up.de (8.11.3/8.11.3) with ESMTP id f82Grai81419; Sun, 2 Sep 2001 18:53:36 +0200 (CEST) (envelope-from daniel@dan-up.de) Received: from dan-net.dan-up.de (mail.dan-up.de [193.193.176.226]) by dan-gate.dan-up.de (8.11.3/8.11.3) with ESMTP id f82HBAS39188; Sun, 2 Sep 2001 19:11:13 +0200 (CEST) (envelope-from daniel@dan-up.de) Received: from DAN-NET/SpoolDir by dan-net.dan-up.de (Mercury 1.48); 2 Sep 01 18:55:16 +0100 Received: from SpoolDir by DAN-NET (Mercury 1.48); 2 Sep 01 18:54:55 +0100 Received: from localhost (10.8.9.50) by mx0.dan-up.de (Mercury 1.48); 2 Sep 01 18:54:51 +0100 From: "Daniel Zuck" To: "bugs@freebsd.org" , "net@freebsd.org" Date: Wed, 15 Aug 2001 22:48:30 +0100 (MEZ) Reply-To: "Daniel Zuck" X-Mailer: PMMail 2.20.2300 for OS/2 Warp 4.5 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Possibly Bug Report with Kernel ep (3com 5xx ISA and others) driver Message-ID: <6945B534F79@dan-net.dan-up.de> X-Sender: 520025278484-0001@t-dialin.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi there - to whom it may concern, I'm looking for some feed back about that problem, which occured with a 4.3 box (stripped 4.3 generic kernel, kernel security set to 3): The machine has 2 interfaces (obviously ep0 and ep1), and after about 24 hours uptime, ep1 was somehow broken: If trying to ping: sendto: no bufferspace available ifconfig ep1 down, ifconfig ep1 up was a work-around, but no solution... Netstat showed nothing 'extraordinary' like high ammount of collissions, late collisions, fragmentations, carrier losses - even the net work load was almost a little above nothing. I remember to have the same problem with another box running 3.3 generic (other hardware...) - so I am wondering if the driver might be somehow broken. Any brainstorming or ideas highly apreciated :) Thanks! Later, Daniel -- Daniel Zuck * eMail: daniel@dan-up.de * Faxmail: +49-69-823 789 49 Voicemail +49-69-823 789 50 * ... and I've also got snailmail! :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 2 11: 2:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailout02.sul.t-online.de (mailout02.sul.t-online.com [194.25.134.17]) by hub.freebsd.org (Postfix) with ESMTP id 2001937B401; Sun, 2 Sep 2001 11:02:36 -0700 (PDT) Received: from fwd02.sul.t-online.de by mailout02.sul.t-online.de with smtp id 15dbZr-0005Az-01; Sun, 02 Sep 2001 20:02:35 +0200 Received: from dan-dyn.dan-up.de (520025278484-0001@[217.88.166.105]) by fmrl02.sul.t-online.com with esmtp id 15dbZZ-1xnZ5sC; Sun, 2 Sep 2001 20:02:17 +0200 Received: from dan-gate.dan-up.de (dan-gate [10.8.9.40]) by dan-dyn.dan-up.de (8.11.3/8.11.3) with ESMTP id f82Hoti81449; Sun, 2 Sep 2001 19:50:55 +0200 (CEST) (envelope-from daniel@dan-up.de) Received: from dan-net.dan-up.de (mail.dan-up.de [193.193.176.226]) by dan-gate.dan-up.de (8.11.3/8.11.3) with ESMTP id f82IAaS39239; Sun, 2 Sep 2001 20:10:40 +0200 (CEST) (envelope-from daniel@dan-up.de) Received: from DAN-NET/SpoolDir by dan-net.dan-up.de (Mercury 1.48); 2 Sep 01 19:54:42 +0100 Received: from SpoolDir by DAN-NET (Mercury 1.48); 2 Sep 01 19:54:18 +0100 Received: from localhost (10.8.9.50) by mx0.dan-up.de (Mercury 1.48); 2 Sep 01 19:54:15 +0100 From: "Daniel Zuck" To: "net@freebsd.org" , "bugs@freebsd.org" , "Matthew Emmerton" Date: Sun, 02 Sep 2001 19:54:19 +0100 (MEZ) Reply-To: "Daniel Zuck" X-Mailer: PMMail 2.20.2370 for OS/2 Warp 4.5 In-Reply-To: <011101c133d5$c6330e90$1200a8c0@gsicomp.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: Possibly Bug Report with Kernel ep (3com 5xx ISA and others) driver Message-ID: <69558AC19D6@dan-net.dan-up.de> X-Sender: 520025278484-0001@t-dialin.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 2 Sep 2001 13:36:18 -0400, Matthew Emmerton wrote: Matthew, thank you for your reply. >> The machine has 2 interfaces (obviously ep0 and ep1), and >> after about 24 hours uptime, ep1 was somehow broken: >> >> If trying to ping: sendto: no bufferspace available >> >> ifconfig ep1 down, ifconfig ep1 up was a work-around, but no >> solution... >> >> Netstat showed nothing 'extraordinary' like high ammount of >> collissions, late collisions, fragmentations, carrier losses >> even the net work load was almost a little above nothing. >All of these are typical of media problems - bad cables or >ports on your hub or switch. I can exclude this: - The statistics do not show any 'loss of carrier' (mentioned above) - On the same hub's, there are some highly available financial applications and web-servers. If there would be that sort of problem, I'd surely noticed. - For some other reason, we changed the hub and cabeling, and the problem still exists... >> I remember to have the same problem with another box running 3.3 >> generic (other hardware...) - so I am wondering if the driver >> might be somehow broken. > >But if it was a driver problem, the problem would show up on >both interfaces, right? Yes, and inbetween I can confirm: The problem occurs on both interfaces; the chance that the problem occurs is slightly higher on the interface with the higher network load. To sum up: As the very same problem occurs with pretty different hardware, I really think there's something wrong with the cooperation of the ep-driver and 3com 509 - maybe the driver, maybe some design error on the network cards... So if sb says: 'No probs with ep driver and ne2000 cards', then I think we have to ask 3com... ;) -- Daniel Zuck * eMail: daniel@dan-up.de * Faxmail: +49-69-823 789 49 Voicemail +49-69-823 789 50 * ... and I've also got snailmail! :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 2 12:55:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts8-srv.bellnexxia.net (tomts8.bellnexxia.net [209.226.175.52]) by hub.freebsd.org (Postfix) with ESMTP id BBC8F37B406; Sun, 2 Sep 2001 12:55:49 -0700 (PDT) Received: from xena.gsicomp.on.ca ([64.228.155.124]) by tomts8-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010902195548.SJL27547.tomts8-srv.bellnexxia.net@xena.gsicomp.on.ca>; Sun, 2 Sep 2001 15:55:48 -0400 Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.11.1/8.11.1) with SMTP id f82Jn2u09282; Sun, 2 Sep 2001 15:49:03 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <014501c133e8$2f83ca80$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: "Daniel Zuck" , , References: <69558AC19D6@dan-net.dan-up.de> Subject: Re: Possibly Bug Report with Kernel ep (3com 5xx ISA and others) driver Date: Sun, 2 Sep 2001 15:48:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > >> The machine has 2 interfaces (obviously ep0 and ep1), and > >> after about 24 hours uptime, ep1 was somehow broken: > >> > >> If trying to ping: sendto: no bufferspace available > >> > >> ifconfig ep1 down, ifconfig ep1 up was a work-around, but no > >> solution... > >> > >> Netstat showed nothing 'extraordinary' like high ammount of > >> collissions, late collisions, fragmentations, carrier losses > >> even the net work load was almost a little above nothing. > > >All of these are typical of media problems - bad cables or > >ports on your hub or switch. > I can exclude this: > - The statistics do not show any 'loss of carrier' (mentioned > above) > - On the same hub's, there are some highly available financial > applications and web-servers. If there would be that sort of > problem, I'd surely noticed. > - For some other reason, we changed the hub and cabeling, and > the problem still exists... Ack! My error - I didn't notice the "nothing". > >> I remember to have the same problem with another box running > 3.3 > >> generic (other hardware...) - so I am wondering if the driver > >> might be somehow broken. > > > >But if it was a driver problem, the problem would show up on > >both interfaces, right? > > Yes, and inbetween I can confirm: The problem occurs on both > interfaces; the chance that the problem occurs is slightly > higher on the interface with the higher network load. > > To sum up: As the very same problem occurs with pretty different > hardware, I really think there's something wrong with the > cooperation of the ep-driver and 3com 509 - maybe the driver, > maybe some design error on the network cards... > > So if sb says: 'No probs with ep driver and ne2000 cards', then > I think we have to ask 3com... ;) Aren't the 509s ISA-based? My thought would be just to replace them with a newer, more stable NIC. -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 2 17: 0:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by hub.freebsd.org (Postfix) with ESMTP id D1C5337B405; Sun, 2 Sep 2001 17:00:01 -0700 (PDT) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f82Nxx813034; Sun, 2 Sep 2001 19:00:00 -0500 (CDT) (envelope-from nick@rogness.net) Date: Sun, 2 Sep 2001 18:59:59 -0500 (CDT) From: Nick Rogness X-Sender: nick@cody.jharris.com Cc: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: NAT with >1 gateway interface In-Reply-To: <200109011358.JAA09511@world.std.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 1 Sep 2001, Kenneth W Cochran wrote: > Hello: > > How do I "properly" set up NAT on a system that "transmits" and > "receives" on different interfaces? > > Briefly - Machine A receives on fxp0 & transmits on ppp0. I'd like to > use a 2nd Ethernet on Machine A (fxp1) for the "NAT"ed/masqueraded > network. > [snip] > > I'm thinking something needs to be tweaked in the ipfw and/or > natd-config(s). Suggestions? Also, where would be the best place(s) > to put these "customizations" (for example, so as to not be any more > "disruptive" than necessary to the base-OS configs)? In /etc/rc.conf: firewall_enable="YES" gateway_enable="YES" natd_enable="YES" natd_interface="ppp0" Nick Rogness - Keep on Routing in a Free World... "FreeBSD: The Power to Serve!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 3 15: 2:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id EFE8837B407; Mon, 3 Sep 2001 15:01:58 -0700 (PDT) Received: by tao.org.uk (Postfix, from userid 100) id B205039; Mon, 3 Sep 2001 22:42:10 +0100 (BST) Date: Mon, 3 Sep 2001 22:42:10 +0100 From: Josef Karthauser To: Stephen Hurd Cc: net@FreeBSD.org Subject: Re: Patch to allow disabling logging of arp movements through sysctl Message-ID: <20010903224210.C28738@tao.org.uk> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="XWOWbaMNXpFDWE00" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from deuce@lordlegacy.org on Mon, Sep 03, 2001 at 03:43:41PM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --XWOWbaMNXpFDWE00 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable You should really send this to net@FreeBSD.org (Cc'd). Filing a -PR is a g= ood thing too, as you can always refer to the -PR number in any mail to the list. Joe On Mon, Sep 03, 2001 at 03:43:41PM -0600, Stephen Hurd wrote: > I've had a problem with my DSL connection for some time now, the bridging= they > use appears to forward arp responses AND respond to arp requests. This e= nds up > filling my log with: >=20 > Sep 3 15:17:57 tw2 /kernel: arp: 216.13.207.2 moved from 00:06:29:d5:04:= c7 to > 00:10:b5:4f:d1:1a on rl0 > Sep 3 15:17:57 tw2 /kernel: arp: 216.13.207.2 moved from 00:10:b5:4f:d1:= 1a to > 00:06:29:d5:04:c7 on rl0 >=20 > I've dug around on the list archives, and it looks like I'm not the first= person > to get annoyed at this, but I haven't found a solution. So, I've finally= gotten > so annoyed at my huge logs that I broke down and added the following patc= h to > add the sysctl variable net.link.ether.inet.log_arp_movements >=20 > Is this the "right place" to send the patch or should I file a PR? >=20 > --- /usr/src/sys/netinet/if_ether.c.old Mon Sep 3 14:26:38 2001 > +++ /usr/src/sys/netinet/if_ether.c Mon Sep 3 15:13:08 2001 > @@ -497,10 +497,15 @@ > * but formerly didn't normally send requests. > */ > static int log_arp_wrong_iface =3D 1; > +static int log_arp_movements =3D 1; >=20 > SYSCTL_INT(_net_link_ether_inet, OID_AUTO, log_arp_wrong_iface, CTLFLAG_= RW, > &log_arp_wrong_iface, 0, > "log arp packets arriving on the wrong interface"); > +SYSCTL_INT(_net_link_ether_inet, OID_AUTO, log_arp_movements, CTLFLAG_RW, > + &log_arp_movements, 0, > + "log arp replies from MACs different the the one in the cache"); > + >=20 > static void > in_arpinput(m) > @@ -586,12 +591,13 @@ > } > if (sdl->sdl_alen && > bcmp((caddr_t)ea->arp_sha, LLADDR(sdl), sdl->sdl_alen)) { > - if (rt->rt_expire) > - log(LOG_INFO, "arp: %s moved from %6D to %6D on %s%d\n", > - inet_ntoa(isaddr), (u_char *)LLADDR(sdl), ":", > - ea->arp_sha, ":", > - ac->ac_if.if_name, ac->ac_if.if_unit); > - else { > + if (rt->rt_expire) { > + if (log_arp_movements) > + log(LOG_INFO, "arp: %s moved from %6D to %6D on %s%d\n", > + inet_ntoa(isaddr), (u_char *)LLADDR(sdl), ":", > + ea->arp_sha, ":", > + ac->ac_if.if_name, ac->ac_if.if_unit); > + } else { > log(LOG_ERR, > "arp: %6D attempts to modify permanent entry for %s on %s%d\n", > ea->arp_sha, ":", inet_ntoa(isaddr), >=20 >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message --XWOWbaMNXpFDWE00 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuT+TIACgkQXVIcjOaxUBbOQgCfXAgDr/cKnisbgYtyLsvRIKE2 5lkAoLv44vcnXbdZaFEIJblklS2fIdXS =AW1l -----END PGP SIGNATURE----- --XWOWbaMNXpFDWE00-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 3 22:46:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by hub.freebsd.org (Postfix) with ESMTP id 81B0837B403 for ; Mon, 3 Sep 2001 22:46:25 -0700 (PDT) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id OAA05766; Tue, 4 Sep 2001 14:46:20 +0900 (JST) Received: from keiichi00.osaka.iij.ad.jp (keiichi00.osaka.iij.ad.jp [192.168.65.65]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id OAA00340; Tue, 4 Sep 2001 14:46:19 +0900 (JST) Date: Tue, 04 Sep 2001 14:47:05 +0900 Message-ID: <87sne3y0bq.wl@keiichi00.osaka.iij.ad.jp> From: Keiichi SHIMA To: Julian Elischer , itojun@iijlab.net, net@FreeBSD.ORG, users@ipv6.org, core@kame.net Subject: Re: IPV6/KAME/protosw integration cleanup In-Reply-To: <86heutd3z1.wl@keiichi01.osaka.iij.ad.jp> References: <28752.998915728@itojun.org> <86heutd3z1.wl@keiichi01.osaka.iij.ad.jp> User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all, We had removed all the varargs input/output functions from the IPv4/IPv6 stacks of the KAME repositry. These modifications will make it easier to import KAME code into FreeBSD4/5. Now we are testing the code with KAME/FreeBSD4 and it looks OK. I will soon make a patch for FreeBSD5 and post it to the related mailing lists for review. Thanks, --- Keiichi SHIMA Internet Initiative Japan Inc. / KAME Project Keiichi SHIMA wrote: > > We are planning to fill your (and many freebsd hackers') requirements. > These plans include introducing some #ifdef clause to match freebsd's > prototypes if there is no other way to live with freebsd in peace, > though it increases our maintanance cost. (on the contrary, not > introducing #ifdef clause increases the maintance cost of your KSE > work. the dilemma.) > > We will decide how should we do in a week. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 3 23:47:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by hub.freebsd.org (Postfix) with ESMTP id B3B0537B405; Mon, 3 Sep 2001 23:47:31 -0700 (PDT) Received: from mindspring.com (dialup-209.247.140.38.Dial1.SanJose1.Level3.net [209.247.140.38]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id XAA20459; Mon, 3 Sep 2001 23:47:18 -0700 (PDT) Message-ID: <3B947922.F8B98DBD@mindspring.com> Date: Mon, 03 Sep 2001 23:48:02 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vladimir A. Jakovenko" Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: SO_REUSEPORT on unicast UDP sockets References: <20010902054617.A47742@lucky.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "Vladimir A. Jakovenko" wrote: > > Hello! > > According to UNPv1 SO_REUSEPORT on UDP sockets can be used to bind more than > one socket to the same port (even with same source ip address). But quick > look on /sys/netinet/udp_usrreq.c function udp_input() shows that this will > work as expected (data stream duplicate) only on multicast/broadcast local > addresses. Please pay attention to the following code fragment comments: [ ... ] > Is there still any real need in such backward compatibility? Can such > functionality be added (fixed) with possibility to switch it off using > sysctl or kernel-build option? > > I find such possibility realy useful at least for NetFlow data > processing and believe that it would be useful for many UDP-based > protocols. Bound UDP sockets have always been problematic; there's a lot of code out there that depnds on the historical behaviour for unicast, unfortunately, including a number of commercial applications that run on FreeBSD (e.g. Real Server). If you look at that code for any length of time, you will get to see it as an armpit: it's not a good place to stick your nose, and it tends to smell to high heaven. At my current job, I'm up to my elbows in it... Similarly, there are a number of bugs in the TCP sockets as well; specifically, there's a problem with all sockets being treated as being in the same collision domain, when doing automatic port assignment. This limits you to 65535 oubound TCP connections, even though you have multiple IP aliases on an interface (theoretically, you should get 64k connections per IP address, if you bind _not_ to IN_ADDR_ANY, but instead use a specific port, but the hash is broken). There's also another problem with the cloned route, in the case you get a redirect, since the clone is not properly updated (e.g. do a ping, get a redirect, and notice that you keep getting the redirect until you stop and restart the ping, after which you get the correct route record: there was a recent thread on this in -current, where someone ICMP'ed themselves to death using multiple Gigabit interfaces as unbonded non-VLAN equivalence routes). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 4 2:23:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from samar.sasken.com (samar.sasken.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id E31A837B401 for ; Tue, 4 Sep 2001 02:23:47 -0700 (PDT) Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.3/8.11.3) with SMTP id f849NdM28451 for ; Tue, 4 Sep 2001 14:53:43 +0530 (IST) Received: (from gbnaidu@localhost) by sunk2.sasi.com (8.9.3/8.9.3) id OAA22567; Tue, 4 Sep 2001 14:53:37 +0530 (IST) From: Brahma Naidu Golla MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15252.40345.212692.832960@sunk2.sasi.com> Date: Tue, 4 Sep 2001 14:53:37 +0530 (IST) To: freebsd-net@FreeBSD.org Cc: sameerbr@sasken.com Subject: Packet capturing at Link Layer... X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Reply-To: gbnaidu@sasken.com Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I would like to capture certain packets (Based on the Protocol type of ether header) at the link layer. I dont want the copies of the packets, but I want the packets to be received by my user land application and not to be processed by the L3 and L4. Could some body give me some pointers on this? One possibility is to use Raw sockets at the link layer. But how do I specify the protocol type of ether header to filter the packets? TIA --gb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 4 10: 9:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id AE92037B40D for ; Tue, 4 Sep 2001 10:09:22 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA18475; Tue, 4 Sep 2001 10:36:09 -0700 (PDT) Date: Tue, 4 Sep 2001 10:36:08 -0700 (PDT) From: Julian Elischer To: Brahma Naidu Golla Cc: freebsd-net@FreeBSD.org, sameerbr@sasken.com Subject: Re: Packet capturing at Link Layer... In-Reply-To: <15252.40345.212692.832960@sunk2.sasi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org you can use a netgraph node to filter them feed the ones you DON'T want back into the "upper" hook of the ethernet interface. (I actually have a special node written to do this if I can get a release from Monzoon networks to release it) On Tue, 4 Sep 2001, Brahma Naidu Golla wrote: > Hi, > > I would like to capture certain packets (Based on the Protocol type of > ether header) at the link layer. I dont want the copies of the packets, but > I want the packets to be received by my user land application and not to be > processed by the L3 and L4. Could some body give me some pointers on this? > > One possibility is to use Raw sockets at the link layer. But how do I > specify the protocol type of ether header to filter the packets? > > TIA > --gb > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 4 10:57:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from mgw1.MEIway.com (mgw1.meiway.com [212.73.210.75]) by hub.freebsd.org (Postfix) with ESMTP id 0518137B407 for ; Tue, 4 Sep 2001 10:57:20 -0700 (PDT) Received: from mail.Go2France.com (ms1.meiway.com [212.73.210.73]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id 337A816B26 for ; Tue, 4 Sep 2001 19:57:18 +0200 (CEST) Received: from IBM-HIRXKN66F0W.Go2France.com [66.64.14.18] by mail.Go2France.com with ESMTP (SMTPD32-6.06) id A89779004A; Tue, 04 Sep 2001 20:08:23 +0200 Message-Id: <5.1.0.14.0.20010904123753.05df08f8@mail.Go2France.com> X-Sender: LConrad@Go2France.com@mail.Go2France.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 12:57:07 -0500 To: freebsd-net@freebsd.org From: Len Conrad Subject: PPPoE dying too long Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Prior to installing in a customer site, we´ve been running a 4.3R and PPPoE into a banal Alcatel ADSL bridge, "Home Speed" or somethting, in France as LAN router/ipfilter firewall. All seems to be running well, but after very long observation, we don´t like: 1. pinging from an LAN station to the ip of the upstream WAN port, we observe 5 to 10% ping loss. It´s ADSL from France Telecom , sh!t is to be expected. 2. pinging from internet to the FreeBSD ethernet/PPPoE interface, we see similar ping loss. cool, it´s symmetrical. 3. what´s disturbing is that from the inside, we sometimes see total disconnects of 3 minutes or more, where ping just times out 20 times or so, 5 second timeouts. We don´t see these long disconnnects when pinging from internet to FreeBSD. 4. During these long disconnects, we can sometimes shorten them by refreshing a website page from the LAN to Internet, ie, it seems that we can get PPPoE, dead to ping and POP3 mailbox checks, going again by hitting a website. But, this is not a reliable technique. We can´t fix the crappy ip over ADSL from FT, but what can we do to prevent what appears to be long timeouts in the PPPoE to Internet provoked by lost packets, which renders the FreeBSD solution unuseable. here´s our ppp.conf: set log Chat Warning Alert Error Connect set device PPPoE:ste0:meidsl set speed sync set mru 1454 set mtu 1454 set ctsrts off enable lqr add default HISADDR set timeout 0 set redial 0 0 enable lqr set lqrperiod 2 accept lqr #Network Address Translation (NAT) nat enable no #nat log yes #nat same_ports yes #nat unregistered_only yes enable dns meidsl: set authname mei-ip-n2@adsl-tp2.fsa set authkey something thanks Len http://MenAndMice.com/DNS-training http://BIND8NT.MEIway.com : ISC BIND 8.2.4 for NT4 & W2K http://IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gateways To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 4 11: 9:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id D3FB937B40D for ; Tue, 4 Sep 2001 11:09:15 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA18821; Tue, 4 Sep 2001 11:38:18 -0700 (PDT) Date: Tue, 4 Sep 2001 11:38:16 -0700 (PDT) From: Julian Elischer To: Len Conrad Cc: freebsd-net@freebsd.org, ericdahan@meiway.com Subject: Re: PPPoE dying too long In-Reply-To: <5.1.0.14.0.20010904123753.05df08f8@mail.Go2France.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org You can help us understadn this by doing the following: while doing the tests or when experiencing difficulties, run "tcpdump" on the ethernet interface attached to the DSL modem. It knows how to interpret PPPoE packets and we can see whether there are any packets coming in or out and if so, what they are. Tjos will help us work out what the problem is. thanks for using FreeBSD, and for reporting yuor problem to us! we will help as much as we can.. On Tue, 4 Sep 2001, Len Conrad wrote: > Prior to installing in a customer site, we=B4ve been running a 4.3R and P= PPoE=20 > into a banal Alcatel ADSL bridge, "Home Speed" or somethting, in France a= s=20 > LAN router/ipfilter firewall. All seems to be running well, but after ve= ry=20 > long observation, we don=B4t like: >=20 > 1. pinging from an LAN station to the ip of the upstream WAN port, we=20 > observe 5 to 10% ping loss. It=B4s ADSL from France Telecom , sh!t is to= be=20 > expected. >=20 > 2. pinging from internet to the FreeBSD ethernet/PPPoE interface, we see= =20 > similar ping loss. cool, it=B4s symmetrical. >=20 > 3. what=B4s disturbing is that from the inside, we sometimes see total=20 > disconnects of 3 minutes or more, where ping just times out 20 times or s= o,=20 > 5 second timeouts. We don=B4t see these long disconnnects when pinging = from=20 > internet to FreeBSD. >=20 > 4. During these long disconnects, we can sometimes shorten them by=20 > refreshing a website page from the LAN to Internet, ie, it seems that we= =20 > can get PPPoE, dead to ping and POP3 mailbox checks, going again by hitti= ng=20 > a website. But, this is not a reliable technique. >=20 > We can=B4t fix the crappy ip over ADSL from FT, but what can we do to pre= vent=20 > what appears to be long timeouts in the PPPoE to Internet provoked by los= t=20 > packets, which renders the FreeBSD solution unuseable. >=20 > here=B4s our ppp.conf: >=20 > set log Chat Warning Alert Error Connect >=20 > set device PPPoE:ste0:meidsl > set speed sync > set mru 1454 > set mtu 1454 > set ctsrts off > enable lqr > add default HISADDR > set timeout 0 > set redial 0 0 > enable lqr > set lqrperiod 2 > accept lqr > #Network Address Translation (NAT) > nat enable no > #nat log yes > #nat same_ports yes > #nat unregistered_only yes > enable dns >=20 > meidsl: > set authname mei-ip-n2@adsl-tp2.fsa > set authkey something >=20 > thanks > Len >=20 >=20 > http://MenAndMice.com/DNS-training > http://BIND8NT.MEIway.com : ISC BIND 8.2.4 for NT4 & W2K > http://IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gateways >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 4 13:48: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id CDB8E37B407; Tue, 4 Sep 2001 13:47:51 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.5/8.11.5) with SMTP id f84KlgP57981; Tue, 4 Sep 2001 16:47:42 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 4 Sep 2001 16:47:42 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Garrett Wollman Cc: Ruslan Ermilov , net@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: Proposed change to route(4) sockets to make them available to non-superuser In-Reply-To: <200108301820.f7UIKGZ66585@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 30 Aug 2001, Garrett Wollman wrote: > < said: > > > + if (rtm->rtm_type != RTM_GET && so->so_cred->cr_uid != 0) > > + senderr(EACCES); > > I'm certain rwatson would object to this. suser_xxx() allows checking > on the basis of credentials rather than a process, so that's what should > be used. In any case, the correct error is EPERM, not EACCES. There are a number of situations where it's desirable to authorize based on the current process, and others based on the current socket credential. So far, the only interesting case I know of for using process rather than socket credentials is wrt bind() and connect(), where you want to use the process credential when changing the port/address binding--this permits a privileged process to share a socket bound to a low port with an unprivileged process, and know that the unprivileged process can't rebind it to another low port number, but must use the one provided by the privileged process. Likewise, a concerning scenerio is one where a socket is provided by a privileged process to an unprivileged process as its stdio on execve() -- you don't want the child process to be able to manipulate that socket in undesirable ways. Generally, routing sockets aren't passed from process to process, and any process doing so should beware the consequences of poorly defined access control policies. My suspicion is that this class of socket operations should be authorized using the credential of the current process, but I'd be interested to know what (if anything) other operating systems do to address this problem. Cached credentials in open files/sockets/etc introduces a lot of complication to the UNIX-like security model. I suppose the more conservative view would be that, with the exception of "traditional" file operations (read/write/close), all operations on devices, sockets, et al, should use current process credentials rather than cached credentials. I'm not sure I'm comfortable with that, since I haven't thought through all the cases, but it seems "safe". Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 4 17:33:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by hub.freebsd.org (Postfix) with ESMTP id 34ADC37B403 for ; Tue, 4 Sep 2001 17:33:10 -0700 (PDT) Received: from xena.gsicomp.on.ca ([65.93.38.74]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010905003309.KCNI29250.tomts7-srv.bellnexxia.net@xena.gsicomp.on.ca> for ; Tue, 4 Sep 2001 20:33:09 -0400 Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.11.1/8.11.1) with SMTP id f850QNu16184 for ; Tue, 4 Sep 2001 20:26:23 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <002b01c135a1$5aa23070$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: Subject: ping gif0 Date: Tue, 4 Sep 2001 20:26:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've got a question for all of you net hackers. When I configure a gif interface, why can't I ping the local endpoint on the inside of the tunnel? I've just been through hell and back trying to get some IPSec tunnels created (they're working now, thanks to all those who helped me out), and this was one of my big stumbling blocks -- since I couldn't ping the local or remote endpoint of the gif tunnel, I spent much time chasing down problems with gif when it wasn't a problem at all. -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 4 20:28:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from tokyogw.iij.ad.jp (tokyogw.iij.ad.jp [202.232.15.22]) by hub.freebsd.org (Postfix) with ESMTP id C829937B406 for ; Tue, 4 Sep 2001 20:28:47 -0700 (PDT) Received: by tokyogw.iij.ad.jp; id MAA24781; Wed, 5 Sep 2001 12:28:45 +0900 (JST) Received: from h084n005.iij.ad.jp(192.168.5.84) by tokyogw.iij.ad.jp via smap (V4.2) id xma024302; Wed, 5 Sep 01 12:28:13 +0900 Received: from keiichi01.osaka.iij.ad.jp (localhost.osaka.iij.ad.jp [127.0.0.1]) by keiichi01.osaka.iij.ad.jp (8.11.3/8.11.3) with ESMTP id f853RqY20056; Wed, 5 Sep 2001 12:27:52 +0900 (JST) (envelope-from keiichi@iij.ad.jp) Date: Wed, 05 Sep 2001 12:27:52 +0900 Message-ID: <86ae0afhaf.wl@keiichi01.osaka.iij.ad.jp> From: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= To: Julian Elischer , itojun@iijlab.net, net@FreeBSD.ORG, users@ipv6.org, core@kame.net Subject: Re: IPV6/KAME/protosw integration cleanup In-Reply-To: <87sne3y0bq.wl@keiichi00.osaka.iij.ad.jp> References: <28752.998915728@itojun.org> <86heutd3z1.wl@keiichi01.osaka.iij.ad.jp> <87sne3y0bq.wl@keiichi00.osaka.iij.ad.jp> User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.2 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Internet Initiative Japan Inc. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: multipart/mixed; boundary="Multipart_Wed_Sep__5_12:27:52_2001-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --Multipart_Wed_Sep__5_12:27:52_2001-1 Content-Type: text/plain; charset=US-ASCII Hi all, At first, I told a lie in one point, > We had removed all the varargs input/output functions from the > IPv4/IPv6 stacks of the KAME repositry. These modifications will > make We removed all the varargs functions from the IPv4 stack (#ifdef'ed for FreeBSD), but preserved for the IPv6 stack. This is for our inter-OS source code maintainancability. We share all the IPv6 code among the *BSDs. Since we are developing the IPv6 stack actively now, it is important for us to reduce the difference among several OSes. Anyway, as we don't have any varargs input/output functions in FreeBSD code any more, some of annoying warning messages have disappeared. > it easier to import KAME code into FreeBSD4/5. Now we are testing the > code with KAME/FreeBSD4 and it looks OK. I will soon make a patch for > FreeBSD5 and post it to the related mailing lists for review. Please look into the attached patch for FreeBSD-current. --- Keiichi SHIMA IIJ Research Laboratory / KAME Project --Multipart_Wed_Sep__5_12:27:52_2001-1 Content-Type: text/plain; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="varargs.diff" Content-Transfer-Encoding: 7bit diff -ur sys.orig/net/if_stf.c sys/net/if_stf.c --- sys.orig/net/if_stf.c Tue Sep 4 15:25:24 2001 +++ sys/net/if_stf.c Wed Sep 5 10:22:33 2001 @@ -530,14 +530,11 @@ } void -#if __STDC__ -in_stf_input(struct mbuf *m, ...) -#else -in_stf_input(m, va_alist) +in_stf_input(m, off) struct mbuf *m; -#endif + int off; { - int off, proto; + int proto; struct stf_softc *sc; struct ip *ip; struct ip6_hdr *ip6; @@ -545,12 +542,8 @@ int len, isr; struct ifqueue *ifq = NULL; struct ifnet *ifp; - va_list ap; - va_start(ap, m); - off = va_arg(ap, int); proto = mtod(m, struct ip *)->ip_p; - va_end(ap); if (proto != IPPROTO_IPV6) { m_freem(m); diff -ur sys.orig/net/if_stf.h sys/net/if_stf.h --- sys.orig/net/if_stf.h Wed Jul 5 01:35:04 2000 +++ sys/net/if_stf.h Wed Sep 5 10:22:45 2001 @@ -33,6 +33,6 @@ #ifndef _NET_IF_STF_H_ #define _NET_IF_STF_H_ -void in_stf_input __P((struct mbuf *, ...)); +void in_stf_input __P((struct mbuf *, int)); #endif /* _NET_IF_STF_H_ */ diff -ur sys.orig/netinet/ip_encap.c sys/netinet/ip_encap.c --- sys.orig/netinet/ip_encap.c Tue Sep 4 15:25:28 2001 +++ sys/netinet/ip_encap.c Wed Sep 5 10:11:26 2001 @@ -127,25 +127,16 @@ #ifdef INET void -#if __STDC__ -encap4_input(struct mbuf *m, ...) -#else -encap4_input(m, va_alist) +encap4_input(m, off) struct mbuf *m; - va_dcl -#endif + int off; { - int off, proto; struct ip *ip; + int proto; struct sockaddr_in s, d; const struct protosw *psw; struct encaptab *ep, *match; - va_list ap; int prio, matchprio; - - va_start(ap, m); - off = va_arg(ap, int); - va_end(ap); ip = mtod(m, struct ip *); proto = ip->ip_p; diff -ur sys.orig/netinet/ip_encap.h sys/netinet/ip_encap.h --- sys.orig/netinet/ip_encap.h Wed Jul 5 01:35:05 2000 +++ sys/netinet/ip_encap.h Tue Sep 4 15:51:33 2001 @@ -49,7 +49,7 @@ }; void encap_init __P((void)); -void encap4_input __P((struct mbuf *, ...)); +void encap4_input __P((struct mbuf *, int)); int encap6_input __P((struct mbuf **, int *, int)); const struct encaptab *encap_attach __P((int, int, const struct sockaddr *, const struct sockaddr *, const struct sockaddr *, diff -ur sys.orig/netinet6/ah.h sys/netinet6/ah.h --- sys.orig/netinet6/ah.h Mon Jun 11 21:39:03 2001 +++ sys/netinet6/ah.h Wed Sep 5 10:08:12 2001 @@ -85,7 +85,7 @@ extern int ah_hdrlen __P((struct secasvar *)); extern size_t ah_hdrsiz __P((struct ipsecrequest *)); -extern void ah4_input __P((struct mbuf *, ...)); +extern void ah4_input __P((struct mbuf *, int)); extern int ah4_output __P((struct mbuf *, struct ipsecrequest *)); extern int ah4_calccksum __P((struct mbuf *, caddr_t, size_t, const struct ah_algorithm *, struct secasvar *)); diff -ur sys.orig/netinet6/ah_input.c sys/netinet6/ah_input.c --- sys.orig/netinet6/ah_input.c Tue Sep 4 15:25:32 2001 +++ sys/netinet6/ah_input.c Wed Sep 5 10:12:09 2001 @@ -97,13 +97,9 @@ extern struct protosw inetsw[]; void -#if __STDC__ -ah4_input(struct mbuf *m, ...) -#else -ah4_input(m, va_alist) +ah4_input(m, off) struct mbuf *m; - va_dcl -#endif + int off; { struct ip *ip; struct ah *ah; @@ -115,15 +111,9 @@ struct secasvar *sav = NULL; u_int16_t nxt; size_t hlen; - int off, proto; - va_list ap; + int proto; size_t stripsiz = 0; - va_start(ap, m); - off = va_arg(ap, int); - proto = mtod(m, struct ip *)->ip_p; - va_end(ap); - #ifndef PULLDOWN_TEST if (m->m_len < off + sizeof(struct newah)) { m = m_pullup(m, off + sizeof(struct newah)); @@ -136,9 +126,11 @@ } ip = mtod(m, struct ip *); + proto = ip->ip_p; ah = (struct ah *)(((caddr_t)ip) + off); #else ip = mtod(m, struct ip *); + proto = ip->ip_p; IP6_EXTHDR_GET(ah, struct ah *, m, off, sizeof(struct newah)); if (ah == NULL) { ipseclog((LOG_DEBUG, "IPv4 AH input: can't pullup;" diff -ur sys.orig/netinet6/esp.h sys/netinet6/esp.h --- sys.orig/netinet6/esp.h Mon Jun 11 21:39:04 2001 +++ sys/netinet6/esp.h Wed Sep 5 10:09:28 2001 @@ -98,7 +98,7 @@ /* crypt routines */ extern int esp4_output __P((struct mbuf *, struct ipsecrequest *)); -extern void esp4_input __P((struct mbuf *, ...)); +extern void esp4_input __P((struct mbuf *, int)); extern size_t esp_hdrsiz __P((struct ipsecrequest *)); extern int esp_schedule __P((const struct esp_algorithm *, struct secasvar *)); diff -ur sys.orig/netinet6/esp_input.c sys/netinet6/esp_input.c --- sys.orig/netinet6/esp_input.c Tue Sep 4 15:25:32 2001 +++ sys/netinet6/esp_input.c Wed Sep 5 10:12:24 2001 @@ -100,13 +100,9 @@ extern struct protosw inetsw[]; void -#if __STDC__ -esp4_input(struct mbuf *m, ...) -#else -esp4_input(m, va_alist) +esp4_input(m, off) struct mbuf *m; - va_dcl -#endif + int off; { struct ip *ip; struct esp *esp; @@ -119,13 +115,7 @@ int ivlen; size_t hlen; size_t esplen; - va_list ap; - int off, proto; - - va_start(ap, m); - off = va_arg(ap, int); - proto = mtod(m, struct ip *)->ip_p; - va_end(ap); + int proto; /* sanity check for alignment. */ if (off % 4 != 0 || m->m_pkthdr.len % 4 != 0) { @@ -146,6 +136,7 @@ } ip = mtod(m, struct ip *); + proto = ip->ip_p; esp = (struct esp *)(((u_int8_t *)ip) + off); #ifdef _IP_VHL hlen = IP_VHL_HL(ip->ip_vhl) << 2; diff -ur sys.orig/netinet6/ipcomp.h sys/netinet6/ipcomp.h --- sys.orig/netinet6/ipcomp.h Mon Jun 11 21:39:06 2001 +++ sys/netinet6/ipcomp.h Wed Sep 5 10:10:34 2001 @@ -64,7 +64,7 @@ struct ipsecrequest; extern const struct ipcomp_algorithm *ipcomp_algorithm_lookup __P((int)); -extern void ipcomp4_input __P((struct mbuf *, ...)); +extern void ipcomp4_input __P((struct mbuf *, int)); extern int ipcomp4_output __P((struct mbuf *, struct ipsecrequest *)); #endif /*KERNEL*/ diff -ur sys.orig/netinet6/ipcomp_input.c sys/netinet6/ipcomp_input.c --- sys.orig/netinet6/ipcomp_input.c Tue Sep 4 15:25:32 2001 +++ sys/netinet6/ipcomp_input.c Wed Sep 5 10:10:24 2001 @@ -86,13 +86,9 @@ extern struct protosw inetsw[]; void -#if __STDC__ -ipcomp4_input(struct mbuf *m, ...) -#else -ipcomp4_input(m, va_alist) +ipcomp4_input(m, off) struct mbuf *m; - va_dcl -#endif + int off; { struct mbuf *md; struct ip *ip; @@ -104,13 +100,7 @@ int error; size_t newlen, olen; struct secasvar *sav = NULL; - int off, proto; - va_list ap; - - va_start(ap, m); - off = va_arg(ap, int); - proto = mtod(m, struct ip *)->ip_p; - va_end(ap); + int proto; if (m->m_pkthdr.len < off + sizeof(struct ipcomp)) { ipseclog((LOG_DEBUG, "IPv4 IPComp input: assumption failed " @@ -129,6 +119,7 @@ } ipcomp = mtod(md, struct ipcomp *); ip = mtod(m, struct ip *); + proto = ip->ip_p; nxt = ipcomp->comp_nxt; #ifdef _IP_VHL hlen = IP_VHL_HL(ip->ip_vhl) << 2; --Multipart_Wed_Sep__5_12:27:52_2001-1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 4 21: 9: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 0315037B403 for ; Tue, 4 Sep 2001 21:08:56 -0700 (PDT) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id VAA21213; Tue, 4 Sep 2001 21:21:02 -0700 (PDT) Message-ID: <3B95A0BE.9F2BEC4D@elischer.org> Date: Tue, 04 Sep 2001 20:49:18 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: keiichi@iij.ad.jp Cc: itojun@iijlab.net, net@FreeBSD.ORG, users@ipv6.org, core@kame.net Subject: Re: IPV6/KAME/protosw integration cleanup References: <28752.998915728@itojun.org> <86heutd3z1.wl@keiichi01.osaka.iij.ad.jp> <87sne3y0bq.wl@keiichi00.osaka.iij.ad.jp> <86ae0afhaf.wl@keiichi01.osaka.iij.ad.jp> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Keiichi SHIMA wrote: > > Hi all, > > At first, I told a lie in one point, > > > We had removed all the varargs input/output functions from the > > IPv4/IPv6 stacks of the KAME repositry. These modifications will > > make > > We removed all the varargs functions from the IPv4 stack (#ifdef'ed > for FreeBSD), but preserved for the IPv6 stack. This is for our > inter-OS source code maintainancability. We share all the IPv6 code > among the *BSDs. Since we are developing the IPv6 stack actively now, > it is important for us to reduce the difference among several OSes. that suits me. IPV6 is under active development and not yet a core function. It is expected to be 1/ changing 2/ suboptimal (due to debugging etc) 3/ not completely tidied up Firstly let me apologise somewhat for the strength of my complaints recently. I was less polite than I should have been. Also I wish to thank you about these changes. > > Anyway, as we don't have any varargs input/output functions in FreeBSD > code any more, some of annoying warning messages have disappeared. thankyou > > > it easier to import KAME code into FreeBSD4/5. Now we are testing the > > code with KAME/FreeBSD4 and it looks OK. I will soon make a patch for > > FreeBSD5 and post it to the related mailing lists for review. > > Please look into the attached patch for FreeBSD-current. I am looking now they seem fine.. If you wish I could commit them.. have you tested them? Also, there was some code in the previous patch from KAME that had some confusion. at the bottom of encap4_input() can you let me know what the correct cod eshould look like.. (keeping in mind that ipip_input() just calls rip_input() and that ipip_input is not compiled by default in LINT so lint failed to compile as it was.) -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 4 21:12:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 97B7C37B401 for ; Tue, 4 Sep 2001 21:12:44 -0700 (PDT) Received: (qmail 8107 invoked by uid 1000); 5 Sep 2001 04:12:43 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Sep 2001 04:12:43 -0000 Date: Tue, 4 Sep 2001 23:12:43 -0500 (CDT) From: Mike Silbersack To: Terry Lambert Cc: "Vladimir A. Jakovenko" , , Subject: Re: SO_REUSEPORT on unicast UDP sockets In-Reply-To: <3B947922.F8B98DBD@mindspring.com> Message-ID: <20010904231049.E7815-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 3 Sep 2001, Terry Lambert wrote: > Similarly, there are a number of bugs in the TCP sockets as > well; specifically, there's a problem with all sockets being > treated as being in the same collision domain, when doing > automatic port assignment. This limits you to 65535 oubound > TCP connections, even though you have multiple IP aliases on > an interface (theoretically, you should get 64k connections > per IP address, if you bind _not_ to IN_ADDR_ANY, but instead > use a specific port, but the hash is broken). I like this problem's evil sibling: client side TIME_WAITs. If you build them up, you just sit there unable to allocate outgoing ports until they time out. Maybe net or openbsd handle these situations better, I'll have to check later. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 4 21:18:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from galilei.ebina.hitachi.co.jp (galilei.v6.hitachi.co.jp [133.145.167.4]) by hub.freebsd.org (Postfix) with ESMTP id 0A38637B409 for ; Tue, 4 Sep 2001 21:18:12 -0700 (PDT) Received: from prince.don.to ([172.16.46.18]) by galilei.ebina.hitachi.co.jp (8.11.6/3.7W) with ESMTP id f854HhN00521; Wed, 5 Sep 2001 13:17:43 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by prince.don.to (8.11.5/3.7W) with ESMTP id f854Gia02206; Wed, 5 Sep 2001 13:16:44 +0900 (JST) Date: Wed, 05 Sep 2001 13:16:43 +0900 (JST) Message-Id: <20010905.131643.15831593.sumikawa@ebina.hitachi.co.jp> To: julian@elischer.org Cc: keiichi@iij.ad.jp, itojun@iijlab.net, net@FreeBSD.ORG, users@ipv6.org, core@kame.net, sumikawa@ebina.hitachi.co.jp Subject: Re: IPV6/KAME/protosw integration cleanup From: SUMIKAWA Munechika In-Reply-To: <3B95A0BE.9F2BEC4D@elischer.org> References: <87sne3y0bq.wl@keiichi00.osaka.iij.ad.jp> <86ae0afhaf.wl@keiichi01.osaka.iij.ad.jp> <3B95A0BE.9F2BEC4D@elischer.org> X-Mailer: xcite1.39> Mew version 2.0 on XEmacs 21.4.3 (Academic Rigor) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Julian, > Also, there was some code in the previous patch from KAME that had > some confusion. at the bottom of encap4_input() > can you let me know what the correct cod eshould look like.. > (keeping in mind that ipip_input() just calls rip_input() and that > ipip_input is not compiled by default in LINT so lint failed to > compile as it was.) I've sent the following mail to you. I'll commit my patch later. --- Munechika SUMIKAWA @ KAME Project / FreeBSD.org ---------------------------------------------------------------- Subject: Re: cvs commit: src/sys/netinet ip_encap.c From: Munechika Sumikawa To: julian@elischer.org Cc: sumikawa@FreeBSD.org Date: Tue, 04 Sep 2001 15:03:14 +0900 (JST) X-Mailer: xcite1.39> Mew version 2.0 on XEmacs 21.4.3 (Academic Rigor) > It didn't compile in LINT? > > what is supposed to be called? previously the code was: > if ipv4 > call rip_input > else > call rip_input > > except that it called rip_input via ipip_input() > which is not compiled in LINT (I haven't worked out why yet) > > the only sense I could see was maybe to cut off the header and > submit the ipv4 packet to ip_input. > > I'm happy to change it if I can figure out what it's trying to do. I see. I am also wrong. ip_mroute.c:ipip_input() was removed in rev 1.64 and use ip_encap.c's encapsulation support so we don't need to provide last resort codes anymore. unregisterd tunneled packets must be discarded from security point and just toss them up to applications if they listen raw packets. I believe the below patch makes us happy. removing ipip_input() was introduced only in -cuurennt so it's not need to MFC. Thanks, --- Munechika SUMIKAWA @ KAME Project / FreeBSD.org Index: ip_encap.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_encap.c,v retrieving revision 1.8 diff -u -r1.8 ip_encap.c --- ip_encap.c 2001/09/03 21:07:31 1.8 +++ ip_encap.c 2001/09/04 05:59:26 @@ -73,7 +73,6 @@ #include #include -#include #include #include #include @@ -211,20 +210,6 @@ (*psw->pr_input)(m, off); } else m_freem(m); - return; - } - - /* for backward compatibility - messy... */ - /* XXX - * I THINK they meant to call ip_input() - * The original code called ipip_input() - * which just calls rip_input() - * which makes no sense. - * (It is also not compiled in in LINT) - */ - if (proto == IPPROTO_IPV4) { - m_adj(m, off); - ip_input(m/*, off */); return; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 4 21:36: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by hub.freebsd.org (Postfix) with ESMTP id A292737B408 for ; Tue, 4 Sep 2001 21:36:06 -0700 (PDT) Received: from chimp.simianscience.com (cage.simianscience.com [64.7.134.1]) by smtp1.sentex.ca (8.11.6/8.11.6) with SMTP id f854ZdX21699; Wed, 5 Sep 2001 00:35:39 -0400 (EDT) (envelope-from mike@sentex.net) From: Mike Tancsa To: LConrad@Go2France.com (Len Conrad) Cc: freebsd-net@freebsd.org Subject: Re: PPPoE dying too long Date: Wed, 05 Sep 2001 00:35:38 -0400 Message-ID: <2oabpt0mav5maj5k0bie8q139jamft8rb7@4ax.com> References: In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 4 Sep 2001 13:57:30 -0400, in sentex.lists.freebsd.net you wrote: If it really is a lossy layer one issue, you are best off getting them to fix that. Have a look at the speed touch and make sure its configured correctly and not trying to sync to too high a speed. > set device PPPoE:ste0:meidsl > set speed sync > set mru 1454 > set mtu 1454 Why 1454 ? 1492 is normally what you want. ---Mike Mike Tancsa (mdtancsa@sentex.net) =09 Sentex Communications Corp, =09 Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers=20 could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 4 21:54:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from mgw1.MEIway.com (mgw1.meiway.com [212.73.210.75]) by hub.freebsd.org (Postfix) with ESMTP id B7DB937B406 for ; Tue, 4 Sep 2001 21:54:38 -0700 (PDT) Received: from mail.Go2France.com (ms1.meiway.com [212.73.210.73]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id C72C416B13 for ; Wed, 5 Sep 2001 06:54:36 +0200 (CEST) Received: from IBM-HIRXKN66F0W.Go2France.com [66.64.14.18] by mail.Go2France.com with ESMTP (SMTPD32-6.06) id A293751E004A; Wed, 05 Sep 2001 07:05:23 +0200 Message-Id: <5.1.0.14.0.20010904235249.04181268@mail.Go2France.com> X-Sender: LConrad@Go2France.com@mail.Go2France.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 23:54:25 -0500 To: freebsd-net@freebsd.org From: Len Conrad Subject: Re: PPPoE dying too long In-Reply-To: <2oabpt0mav5maj5k0bie8q139jamft8rb7@4ax.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >If it really is a lossy layer one issue, you are best off getting them to >fix that. We have no hopes that FT or it´s ADSL reseller will do anyting about that. The reseller said "just turn on ip spoofing so your apps don´t die" > Have a look at the speed touch and make sure its configured >correctly and not trying to sync to too high a speed. ok > > set device PPPoE:ste0:meidsl > > set speed sync > > set mru 1454 > > set mtu 1454 > >Why 1454 ? 1492 is normally what you want. ok, we´ll look at that. thanks Len http://MenAndMice.com/DNS-training http://BIND8NT.MEIway.com : ISC BIND 8.2.4 for NT4 & W2K http://IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gateways To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 5 0:27:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from samar.sasken.com (samar.sasken.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id 4331A37B405 for ; Wed, 5 Sep 2001 00:27:14 -0700 (PDT) Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.3/8.11.3) with SMTP id f857R7M03960; Wed, 5 Sep 2001 12:57:07 +0530 (IST) Received: (from gbnaidu@localhost) by sunk2.sasi.com (8.9.3/8.9.3) id MAA16712; Wed, 5 Sep 2001 12:57:04 +0530 (IST) From: Brahma Naidu Golla MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15253.54216.381750.779254@sunk2.sasi.com> Date: Wed, 5 Sep 2001 12:57:04 +0530 (IST) To: Julian Elischer Cc: freebsd-net@FreeBSD.ORG, sameerbr@sasken.com Subject: Re: Packet capturing at Link Layer... In-Reply-To: References: <15252.40345.212692.832960@sunk2.sasi.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Reply-To: gbnaidu@sasken.com Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Julian, Thanks for your reply. I forgot about the netgraph. Thanks for reminding. regards --gb Julian Elischer writes: > > you can use a netgraph node to filter them > feed the ones you DON'T want back into the > "upper" hook of the ethernet interface. > > (I actually have a special node written to do this if I can get a release > from Monzoon networks to release it) > > On Tue, 4 Sep 2001, Brahma Naidu Golla wrote: > > > Hi, > > > > I would like to capture certain packets (Based on the Protocol type of > > ether header) at the link layer. I dont want the copies of the packets, but > > I want the packets to be received by my user land application and not to be > > processed by the L3 and L4. Could some body give me some pointers on this? > > > > One possibility is to use Raw sockets at the link layer. But how do I > > specify the protocol type of ether header to filter the packets? > > > > TIA > > --gb > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 5 1: 1:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id A733B37B408; Wed, 5 Sep 2001 01:01:12 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f8580sn07926; Wed, 5 Sep 2001 11:00:54 +0300 (EEST) (envelope-from ru) Date: Wed, 5 Sep 2001 11:00:53 +0300 From: Ruslan Ermilov To: Robert Watson Cc: Garrett Wollman , net@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: Proposed change to route(4) sockets to make them available to non-superuser Message-ID: <20010905110053.G96906@sunbay.com> References: <200108301820.f7UIKGZ66585@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.ORG on Tue, Sep 04, 2001 at 04:47:42PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Sep 04, 2001 at 04:47:42PM -0400, Robert Watson wrote: > > On Thu, 30 Aug 2001, Garrett Wollman wrote: > > > < said: > > > > > + if (rtm->rtm_type != RTM_GET && so->so_cred->cr_uid != 0) > > > + senderr(EACCES); > > > > I'm certain rwatson would object to this. suser_xxx() allows checking > > on the basis of credentials rather than a process, so that's what should > > be used. In any case, the correct error is EPERM, not EACCES. > > There are a number of situations where it's desirable to authorize based > on the current process, and others based on the current socket credential. > So far, the only interesting case I know of for using process rather than > socket credentials is wrt bind() and connect(), where you want to use the > process credential when changing the port/address binding--this permits a > privileged process to share a socket bound to a low port with an > unprivileged process, and know that the unprivileged process can't rebind > it to another low port number, but must use the one provided by the > privileged process. Likewise, a concerning scenerio is one where a socket > is provided by a privileged process to an unprivileged process as its > stdio on execve() -- you don't want the child process to be able to > manipulate that socket in undesirable ways. > Definitely, we don't want it this way! > Generally, routing sockets aren't passed from process to process, and any > process doing so should beware the consequences of poorly defined access > control policies. My suspicion is that this class of socket operations > should be authorized using the credential of the current process, but I'd > be interested to know what (if anything) other operating systems do to > address this problem. > OpenBSD and NetBSD both authorize based on the curproc's privileges. Should I commit this? Index: rtsock.c =================================================================== RCS file: /home/ncvs/src/sys/net/rtsock.c,v retrieving revision 1.56 diff -u -p -r1.56 rtsock.c --- rtsock.c 2001/08/31 12:31:09 1.56 +++ rtsock.c 2001/09/05 07:58:47 @@ -331,8 +331,8 @@ route_output(m, so) * Verify that the caller has the appropriate privilege; RTM_GET * is the only operation the non-superuser is allowed. */ - if (rtm->rtm_type != RTM_GET && suser_xxx(so->so_cred, NULL, 0) != 0) - senderr(EPERM); + if (rtm->rtm_type != RTM_GET && (error = suser(curproc)) != 0) + senderr(error); switch (rtm->rtm_type) { Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 5 1:15:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from tokyogw.iij.ad.jp (tokyogw.iij.ad.jp [202.232.15.22]) by hub.freebsd.org (Postfix) with ESMTP id F22FD37B408 for ; Wed, 5 Sep 2001 01:15:45 -0700 (PDT) Received: by tokyogw.iij.ad.jp; id RAA04067; Wed, 5 Sep 2001 17:15:45 +0900 (JST) Received: from h207n005.iij.ad.jp(192.168.5.207) by tokyogw.iij.ad.jp via smap (V4.2) id xma003570; Wed, 5 Sep 01 17:15:05 +0900 Received: from keiichi01.osaka.iij.ad.jp (localhost.osaka.iij.ad.jp [127.0.0.1]) by keiichi01.osaka.iij.ad.jp (8.11.3/8.11.3) with ESMTP id f858EgB01494; Wed, 5 Sep 2001 17:14:43 +0900 (JST) (envelope-from keiichi@iij.ad.jp) Date: Wed, 05 Sep 2001 17:14:42 +0900 Message-ID: <86zo8akqa5.wl@keiichi01.osaka.iij.ad.jp> From: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= To: Julian Elischer Cc: itojun@iijlab.net, net@FreeBSD.ORG, users@ipv6.org, core@kame.net Subject: Re: IPV6/KAME/protosw integration cleanup In-Reply-To: <3B95A0BE.9F2BEC4D@elischer.org> References: <28752.998915728@itojun.org> <86heutd3z1.wl@keiichi01.osaka.iij.ad.jp> <87sne3y0bq.wl@keiichi00.osaka.iij.ad.jp> <86ae0afhaf.wl@keiichi01.osaka.iij.ad.jp> <3B95A0BE.9F2BEC4D@elischer.org> User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.2 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Internet Initiative Japan Inc. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Julian, Julian Elischer wrote: > > > Please look into the attached patch for FreeBSD-current. > > I am looking now > > they seem fine.. > If you wish I could commit them.. Yes. As I am not a commiter, could you commit them? > have you tested them? Not all parts. I have checked 1) gif over ipv4 is working, 2) ah/esp transport mode for ipv4 is working. > Also, there was some code in the previous patch from KAME > that had some confusion. > at the bottom of encap4_input() This is my mistake. Please see the mail sent by Sumikawa that ID is <20010905.131643.15831593.sumikawa@ebina.hitachi.co.jp>. I think he will commit needed changes later. > can you let me know what the correct cod eshould look like.. > (keeping in mind that ipip_input() just calls rip_input() > and that ipip_input is not compiled by default in LINT so lint failed to compile > as it was.) --- Keiichi SHIMA IIJ Research Laboratory / KAME Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 5 2:20:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by hub.freebsd.org (Postfix) with ESMTP id 9052A37B407; Wed, 5 Sep 2001 02:19:46 -0700 (PDT) Received: from mindspring.com (dialup-209.245.138.192.Dial1.SanJose1.Level3.net [209.245.138.192]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id CAA05452; Wed, 5 Sep 2001 02:19:26 -0700 (PDT) Message-ID: <3B95EE4A.EF204095@mindspring.com> Date: Wed, 05 Sep 2001 02:20:10 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack Cc: "Vladimir A. Jakovenko" , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: SO_REUSEPORT on unicast UDP sockets References: <20010904231049.E7815-100000@achilles.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mike Silbersack wrote: > > Similarly, there are a number of bugs in the TCP sockets as > > well; specifically, there's a problem with all sockets being > > treated as being in the same collision domain, when doing > > automatic port assignment. This limits you to 65535 oubound > > TCP connections, even though you have multiple IP aliases on > > an interface (theoretically, you should get 64k connections > > per IP address, if you bind _not_ to IN_ADDR_ANY, but instead > > use a specific port, but the hash is broken). > > I like this problem's evil sibling: client side TIME_WAITs. If > you build them up, you just sit there unable to allocate outgoing > ports until they time out. If you fix or workaround the source IP address problem, and patch/tune the kernel for enough outbound sockets, you can go to 250,000 outbound connections very easily. I used a couple of 1GB memory systems in this configuration to get my 1M (actually, closer to 2M) inbound server connections... obviously, a server doesn't have the port limitation, when it comes to accepting connections. The client TIME_WAIT problem is more an issue for port reuse; for a 2MSL timer in the standard 60 second range, this will basically limit you to 65535/60, or ~1000 outbound connections a second per IP address, as a sustained rate, with a total outstanding count of 65535 * IP_address_count. Unless you set SO_REUSEPORT/SO_REUSEADDR. So for the client side, you are pretty much limited by the bug (or your fix), and whatever you set the 2MSL timer down to, as a sustained rate top end. For most real world uses, apart from test equipment, which will usually just use raw sockets directly, and fake the AYN/ACK for the SYN, and then accept the ACK without an RST, you never really get up into this number of client connections on a single box. > Maybe net or openbsd handle these situations better, I'll have > to check later. I doubt it. Until I did testing on 4.3, no one had really run over 32,766 open sockets in a production server, since at that point, the ucred reference count overflowed, which would result in some strange and very hard to identify crashes, when closing those connections. Alfred fixed this in -current, but it wasn't done consciously to address a known problem, it was done "just in case" (Alfred finds problems like that, and fixes them without necessarily being aware of it... 8-)). It hadn't been MFC'ed back to 4.3 until I identified an actual problem, and the root cause. NetBSD and OpenBSD have some hacks on the server side of the scaling problem (e.g. they have each implemented a SYN cache, which is OK as far as it goes, but is really inferior to the SYN cache and rate halving algorithm code (also against FreeBSD) out of the Pittsburgh Supercomputing Center. I've done a preliminary port of the PSC code to 4.x, actually, though I would need to strip out a number of local changes. One interesting thing about the SYN cache code is that it could use the tcptmpl allocation until it saw the ACK (or even the first data, as was suggested by some of the researchers at that startup in India, a while back, though that's very aggressive). Mostly, you aren't going to see the hashing on both source and detination IP's and ports -- what you'd see in an L2/L3 switch, if you were building one -- which would let you reuse the local pair, so long as it was associated with a different remote pair. That's probably the real long term fix, if there is one. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 5 3:33: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id EC46237B407 for ; Wed, 5 Sep 2001 03:32:55 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [fec0::1:12]) by Awfulhak.org (8.11.6/8.11.6) with ESMTP id f85AWsi09996; Wed, 5 Sep 2001 11:32:54 +0100 (BST) (envelope-from brian@freebsd-services.com) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.6/8.11.6) with ESMTP id f85AWtA02348; Wed, 5 Sep 2001 11:32:55 +0100 (BST) (envelope-from brian@freebsd-services.com) Message-Id: <200109051032.f85AWtA02348@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Len Conrad Cc: freebsd-net@FreeBSD.ORG, brian@freebsd-services.com Subject: Re: PPPoE dying too long In-Reply-To: Message from Len Conrad of "Tue, 04 Sep 2001 23:54:25 CDT." <5.1.0.14.0.20010904235249.04181268@mail.Go2France.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 05 Sep 2001 11:32:55 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > > set device PPPoE:ste0:meidsl > > > set speed sync > > > set mru 1454 > > > set mtu 1454 > > > >Why 1454 ? 1492 is normally what you want. > = > ok, we=B4ll look at that. This is now imposed by ppp, so you *should* be able to remove the = ``set mru'' and ``set mtu'' lines in 4.4-release and -current. > thanks > Len > = > = > http://MenAndMice.com/DNS-training > http://BIND8NT.MEIway.com : ISC BIND 8.2.4 for NT4 & W2K > http://IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gatewa= ys -- = Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 5 8:12: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailer.berkom.de (mailer.berkom.de [141.39.13.2]) by hub.freebsd.org (Postfix) with ESMTP id D61FB37B40C for ; Wed, 5 Sep 2001 08:12:03 -0700 (PDT) Received: from charisma (charisma.t33.berkom.de [141.39.27.102]) by mailer.berkom.de (1.1.1/0.0.0) with SMTP id f85FBwk05138 for ; Wed, 5 Sep 2001 17:11:59 +0200 (MET DST) Received: by localhost with Microsoft MAPI; Wed, 5 Sep 2001 17:14:03 +0200 Message-ID: <01C1362E.29C052B0.ruhle@berkom.de> From: Christian Ruhle To: "net@FreeBSD.ORG" Subject: CSELT Tunnelbroker Date: Wed, 5 Sep 2001 17:14:02 +0200 X-Mailer: Microsoft Internet E-Mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello I?ve installed the CSELT tunnelbroker/server on FreeBSD 4.1 (with perl, msql, apache-ssl). All works fine (http-access, configuration via http, the client-scripts, the database) But the tunnelserver dont configure his own tunnelinterface (gif). I had configured the tunnelinterface by hand (with the same commands like in the perl script) and the tunnel works. Know somebody why the configuration of the gif-interface don't work by the perl script? regards christian Christian Ruhle T-Nova Berkom EB 11 IP-Technologien Student Goslarer Ufer 35, 10589 Berlin Mail ruhle@berkom.de Phone (+49 30) 3497-2482 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 5 9:27:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 4A4BE37B406 for ; Wed, 5 Sep 2001 09:27:04 -0700 (PDT) Received: from hbo (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with SMTP id f85GR3Q29636 for ; Wed, 5 Sep 2001 09:27:03 -0700 (PDT) From: "Lars Eggert" To: Subject: RE: ping gif0 Date: Wed, 5 Sep 2001 09:27:04 -0800 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) MIME-Version: 1.0 In-Reply-To: <002b01c135a1$5aa23070$1200a8c0@gsicomp.on.ca> Importance: Normal Content-Type: multipart/signed; boundary="----=_NextPart_000_005F_01C135EC.ECB34490"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_005F_01C135EC.ECB34490 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > When I configure a gif interface, why can't I ping the local > endpoint on the inside of the tunnel? (This is from memory, can't double-check right now.) I believe I've seen this, too; and the problem was that when gifs are brought up, no route to loopback is added for the local address. (This loopback route gets added for "real" interfaces.) Try adding it manually? This may already be fixed in a more recent KAME release (FreeBSD's is kinda stale.) Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California ------=_NextPart_000_005F_01C135EC.ECB34490 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF5jCCArUw ggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEPMA0GA1UEBBMGRWdnZXJ0 MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFy c2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0AvLBsD78nxcUHeHkaMgl3b4 qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD11uZDy4CNNJUu3gKxKSb+zRV70O+lkwwf tuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcUSF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEA AaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREE ETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQ A8zI7U2K1ZIAl11j0a1DKxnp3GtTvOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2 OhB+jeKEqY7IDAJE4/fI0e+d6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4 fdcOo1S34r4wggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0 ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQw IgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDIwODI5MjM1OTU5WjCB kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y 8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtU ihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcN AQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kNaiYqYoQfuIdjdBxtt88aU5FL4c3mONnt UPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvBUFe17BzX7xe21Yibt6KIGu05Wzl9NPy2 lhglTWr0ncXDkS+plrgFPFL83eliA0gxggKqMIICpgIBATCBmjCBkjELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFp bCBSU0EgMjAwMC44LjMwAgMFgUcwCQYFKw4DAhoFAKCCAWUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwOTA1MTcyNzA0WjAjBgkqhkiG9w0BCQQxFgQUSN9+b5Ye LQfOb5xseTDbBrNczD4wWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgasGCSsGAQQB gjcQBDGBnTCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZI hvcNAQEBBQAEgYCkyXsTSzA6oW2myZzwGQ6VSUsugr9h1KpZq361i7mM/aEVhNLZ1W0h5LuYL+lJ 9M9zkJ6z7uM/TTwYerD2X2qSVaino/lFi8aVhhvbj+6M4t8EPf86v34fYlG8N9BAgkseKUdgKATP iXH+dIG0HigKZwrflFJp9ul7qZ1NszpSAgAAAAAAAA== ------=_NextPart_000_005F_01C135EC.ECB34490-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 5 9:47:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id B6A4937B405; Wed, 5 Sep 2001 09:47:17 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f85GlGY44472; Wed, 5 Sep 2001 12:47:16 -0400 (EDT) (envelope-from wollman) Date: Wed, 5 Sep 2001 12:47:16 -0400 (EDT) From: Garrett Wollman Message-Id: <200109051647.f85GlGY44472@khavrinen.lcs.mit.edu> To: Robert Watson Cc: net@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: Proposed change to route(4) sockets to make them available to non-superuser In-Reply-To: References: <200108301820.f7UIKGZ66585@khavrinen.lcs.mit.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > There are a number of situations where it's desirable to authorize based > on the current process, and others based on the current socket credential. I would argue that any file descriptor is, in and of itself, a (somewhat limited form of) credential. Presumably the 4.3BSD developers thought so as well, since they called the file-descriptor-passing mechanism in Unix-domain sockets SCM_RIGHTS and not SCM_PASSFDS or something similar. > Likewise, a concerning scenerio is one where a socket is provided by > a privileged process to an unprivileged process as its stdio on > execve() -- you don't want the child process to be able to > manipulate that socket in undesirable ways. Indeed. My general objection is not to using the caller's credentials -- although I think the whole issue with cached credentials needs to be rethought -- but to the reintroduction of references to `curproc', which I spent a good deal of time several years ago stamping out. > I suppose the more conservative view would be that, with the > exception of "traditional" file operations (read/write/close), all > operations on devices, sockets, et al, should use current process > credentials rather than cached credentials. An alternative model would be to explicitly associate privilege with file descriptors, and provide some mechanism to explicitly downgrade a descriptor's associated privilege. We actually did this: I introduced a socket option which, when set, would clear the SS_PRIV flag on the socket. Eventually this was forgone in favor of a true credential check in the places where SS_PRIV was formerly used. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 5 12:55:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by hub.freebsd.org (Postfix) with ESMTP id 7B46437B410 for ; Wed, 5 Sep 2001 12:55:17 -0700 (PDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f85JuWI11350 for ; Wed, 5 Sep 2001 14:56:32 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 5 Sep 2001 14:55:12 -0500 content-class: urn:content-classes:message Subject: RE: Reg. mbuf structure Date: Wed, 5 Sep 2001 14:50:07 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reg. mbuf structure X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEut9Cow/9oQJqkEdWJUgAIx6TWpQHi6sqA From: "Ramasubramanian Ramamoorthy (EXT-NRC/Boston)" To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I had mailed regarding extracting the same data from the skbuff structure in Linux and the mbuf structure in BSD. I am calculating the checksum in two machines, one running BSD and the other running Red Hat. I need to calculate the checksum at both the machines, for which I should be extracting the same data from these structures and send that to the algorithm, which calculates the checksum. Can you tell me how we can confirm that we are extracting the same data from both these structures. It would be of great help, if anybody could help me in this regard soon. Thanks, Best Regards, Ramamoorthy. R. -----Original Message----- From: ext Julian Elischer [mailto:julian@elischer.org] Sent: Monday, August 27, 2001 1:04 AM To: Ramasubramanian Ramamoorthy (EXT-NRC/Boston) Cc: freebsd-net@FreeBSD.org Subject: Re: Reg. mbuf structure > On Sun, Aug 26, 2001 at 05:59:22PM -0500, Ramasubramanian Ramamoorthy (EXT-NRC/Boston) wrote: > > Hi, > > I am trying to extract same data from the skbuff structure and mbuf > > structure for a checksum calculation. Can you tell me how we can can > > confirm that we are extracting the same data from both these structures? > > > > Thanks, > > Ramamoorthy. R. > > > Well, you need to tell us what information you wish to extract.... --=20 +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in=20 | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 5 13:28: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id A50CE37B403 for ; Wed, 5 Sep 2001 13:27:59 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA25092; Wed, 5 Sep 2001 13:59:59 -0700 (PDT) Date: Wed, 5 Sep 2001 13:59:58 -0700 (PDT) From: Julian Elischer To: "Ramasubramanian Ramamoorthy (EXT-NRC/Boston)" Cc: freebsd-net@freebsd.org Subject: RE: Reg. mbuf structure In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 5 Sep 2001, Ramasubramanian Ramamoorthy (EXT-NRC/Boston) wrote: > Hi, > I had mailed regarding extracting the same data from the skbuff > structure in Linux and the mbuf structure in BSD. I am calculating the > checksum in two machines, one running BSD and the other running Red Hat. > I need to calculate the checksum at both the machines, for which I > should be extracting the same data from these structures and send that > to the algorithm, which calculates the checksum. > > Can you tell me how we can confirm that we are extracting the same data > from both these structures. It would be of great help, if anybody could > help me in this regard soon. > Do you know how much data you are supposed to be extracting? Do you have an IP header or something on the front you want to ignore? I assume this is a kernel module. Here is a data extraction function from kern/uipc_mbuf.c You can modify this function to checksum intead of copying.. or since this is always in the kernel, you could just call it. /* * Copy data from an mbuf chain starting "off" bytes from the beginning, * continuing for "len" bytes, into the indicated buffer. */ void m_copydata(m, off, len, cp) register struct mbuf *m; register int off; register int len; caddr_t cp; { register unsigned count; while (off > 0) { if (off < m->m_len) break; off -= m->m_len; m = m->m_next; } while (len > 0) { count = min(m->m_len - off, len); bcopy(mtod(m, caddr_t) + off, cp, count); len -= count; cp += count; off = 0; m = m->m_next; } } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 5 13:32:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by hub.freebsd.org (Postfix) with ESMTP id DC14537B417 for ; Wed, 5 Sep 2001 13:32:42 -0700 (PDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f85KWfo11627 for ; Wed, 5 Sep 2001 15:32:41 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Sep 2001 15:32:41 -0500 content-class: urn:content-classes:message Subject: RE: Reg. mbuf structure Date: Wed, 5 Sep 2001 15:32:40 -0500 Message-ID: X-MS-Has-Attach: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MS-TNEF-Correlator: Thread-Topic: Reg. mbuf structure Thread-Index: AcE2SUJnu+Hza6I6EdWBSQBQi2X+DwAAC8iw X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 From: "Ramasubramanian Ramamoorthy (EXT-NRC/Boston)" To: "'ext Julian Elischer'" Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Yes, I used this copydata function, to extract some data to calculate my checksum. But, how do I send the same extracted data which is contained in skbuff structure in the linux machine? I need to check that the packet what I am sending from the Linux machine to the BSD machine using the checksum that I am generating.=20 I am able to extract data using m_copydata() in BSD. But, I need the same data in Linux for calculating the same checksum, as the algorithms are same at both ends. Thanks, Ram. -----Original Message----- From: ext Julian Elischer [mailto:julian@elischer.org] Sent: Wednesday, September 05, 2001 5:00 PM To: Ramasubramanian Ramamoorthy (EXT-NRC/Boston) Cc: freebsd-net@freebsd.org Subject: RE: Reg. mbuf structure On Wed, 5 Sep 2001, Ramasubramanian Ramamoorthy (EXT-NRC/Boston) wrote: > Hi, > I had mailed regarding extracting the same data from the skbuff > structure in Linux and the mbuf structure in BSD. I am calculating the > checksum in two machines, one running BSD and the other running Red Hat. > I need to calculate the checksum at both the machines, for which I > should be extracting the same data from these structures and send that > to the algorithm, which calculates the checksum. >=20 > Can you tell me how we can confirm that we are extracting the same data > from both these structures. It would be of great help, if anybody could > help me in this regard soon. >=20 Do you know how much data you are supposed to be extracting? Do you have an IP header or something on the front you want to=20 ignore? I assume this is a kernel module. Here is a data extraction function from kern/uipc_mbuf.c You can modify this function to checksum intead of copying.. or since this is always in the kernel, you could just call it. /* * Copy data from an mbuf chain starting "off" bytes from the beginning, * continuing for "len" bytes, into the indicated buffer. */ void m_copydata(m, off, len, cp) register struct mbuf *m; register int off; register int len; caddr_t cp; { register unsigned count; while (off > 0) { if (off < m->m_len) break; off -=3D m->m_len; m =3D m->m_next; } while (len > 0) { count =3D min(m->m_len - off, len); bcopy(mtod(m, caddr_t) + off, cp, count); len -=3D count; cp +=3D count; off =3D 0; m =3D m->m_next; } } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 5 13:48:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 3DEAF37B407 for ; Wed, 5 Sep 2001 13:48:07 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA25199; Wed, 5 Sep 2001 14:11:44 -0700 (PDT) Date: Wed, 5 Sep 2001 14:11:43 -0700 (PDT) From: Julian Elischer To: "Ramasubramanian Ramamoorthy (EXT-NRC/Boston)" Cc: freebsd-net@freebsd.org Subject: RE: Reg. mbuf structure In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 5 Sep 2001, Ramasubramanian Ramamoorthy (EXT-NRC/Boston) wrote: > Yes, I used this copydata function, to extract some data to calculate my > checksum. But, how do I send the same extracted data which is contained > in skbuff structure in the linux machine? > > I need to check that the packet what I am sending from the Linux machine > to the BSD machine using the checksum that I am generating. > I am able to extract data using m_copydata() in BSD. But, I need the > same data in Linux for calculating the same checksum, as the algorithms > are same at both ends. Shouldn't you ask the linux people? none of us have lookad at skbufs. I thought you just needed to extract the data to checksum it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 5 16:35:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from mine.kame.net (kame195.kame.net [203.178.141.195]) by hub.freebsd.org (Postfix) with ESMTP id 87CBF37B403 for ; Wed, 5 Sep 2001 16:35:05 -0700 (PDT) Received: from localhost ([3ffe:501:4819:cafe:260:1dff:fe1e:f7d4]) by mine.kame.net (8.11.1/3.7W) with ESMTP id f85NZCY83496; Thu, 6 Sep 2001 08:35:12 +0900 (JST) To: matt@gsicomp.on.ca Cc: freebsd-net@freebsd.org Subject: Re: Help with IPSec VPN In-Reply-To: Your message of "Fri, 31 Aug 2001 09:18:37 -0400" <003201c1321f$71de65e0$1200a8c0@gsicomp.on.ca> References: <003201c1321f$71de65e0$1200a8c0@gsicomp.on.ca> X-Mailer: Cue version 0.6 (010810-1737/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20010906083441E.sakane@kame.net> Date: Thu, 06 Sep 2001 08:34:41 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 25 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > 8 outbound packets with no SA available > Both boxes are running RELENG_4_3 (security release), and have 'options > IPSEC' and 'options IPSEC_ESP' in the kernel. > > Box A is 192.168.0.2/24, Box B is 192.168.0.3/24. > > Here's what I'm doing on box A: > > gabby# setkey -c << EOF > add 10.0.2.1 10.0.3.1 esp 1000 -E 3des-cbc "goofgoofgoofgoofgoofgoof"; > add 10.0.3.1 10.0.2.1 esp 1001 -E 3des-cbc "foolfoolfoolfoolfoolfool"; > spdadd 10.0.2.0/24 10.0.3.0/24 any -P out ipsec > esp/tunnel/192.168.0.2-192.168.0.3/require; > spdadd 10.0.3.0/24 10.0.2.0/24 any -P in ipsec > esp/tunnel/192.168.0.3-192.168.0.2/require; > EOF you want to establish the SA between 192.168.0.2 and 192.196.0.3 in ordert to protect the communication between 10.0.2.0/24 and 10.0.3.0/24, don't you ? you have to configure the SAD like following: add 192.168.0.2 192.196.0.3 esp 1000 -E 3des-cbc "goofgoofgoofgoofgoofgoof"; add 192.168.0.3 192.196.0.2 esp 1001 -E 3des-cbc "foolfoolfoolfoolfoolfool"; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 5 16:54:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id DD0EA37B407 for ; Wed, 5 Sep 2001 16:54:53 -0700 (PDT) Received: (qmail 11773 invoked by uid 1000); 5 Sep 2001 23:54:53 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Sep 2001 23:54:53 -0000 Date: Wed, 5 Sep 2001 18:54:53 -0500 (CDT) From: Mike Silbersack To: Terry Lambert Cc: "Vladimir A. Jakovenko" , Subject: Re: SO_REUSEPORT on unicast UDP sockets In-Reply-To: <3B95EE4A.EF204095@mindspring.com> Message-ID: <20010905183432.Y11391-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 5 Sep 2001, Terry Lambert wrote: > Mike Silbersack wrote: > > The client TIME_WAIT problem is more an issue for port reuse; > for a 2MSL timer in the standard 60 second range, this will > basically limit you to 65535/60, or ~1000 outbound connections > a second per IP address, as a sustained rate, with a total > outstanding count of 65535 * IP_address_count. > > Unless you set SO_REUSEPORT/SO_REUSEADDR. Hm, I wonder if client-side TIME_WAIT recycling should be made the norm even without those options specified. Of course, that's if it's a real problem; I'm not sure that many apps would be affected. Oh, I think there's one other bug with the current code; it can't seem to find free ports if they're surrounded by sockets in the TIME_WAIT state already. I think that was the case, at least... when I ran into these problems myself I decided not to pursue it and just concentrated on how server-side time_wait recycling was working. > > Maybe net or openbsd handle these situations better, I'll have > > to check later. > > I doubt it. Until I did testing on 4.3, no one had really > run over 32,766 open sockets in a production server, since at > that point, the ucred reference count overflowed, which would > result in some strange and very hard to identify crashes, when > closing those connections. True, true. > NetBSD and OpenBSD have some hacks on the server side of the > scaling problem (e.g. they have each implemented a SYN cache, > which is OK as far as it goes, but is really inferior to the > SYN cache and rate halving algorithm code (also against FreeBSD) > out of the Pittsburgh Supercomputing Center. What's the primary difference between the psc syn cache and netbsd one? > One interesting thing about the SYN cache code is that it could > use the tcptmpl allocation until it saw the ACK (or even the > first data, as was suggested by some of the researchers at that > startup in India, a while back, though that's very aggressive). Well, it still could; the pointer's there if you want to associate it with a mbuf. :) Waiting for data to arrive before setting up the socket sounds like it's not so much part of defense against a syn flood as part of reducing kernel -> userland switches. I suspect accept filters + a normal syn cache would achieve the same purpose. > Mostly, you aren't going to see the hashing on both source and > detination IP's and ports -- what you'd see in an L2/L3 switch, > if you were building one -- which would let you reuse the local > pair, so long as it was associated with a different remote pair. > > That's probably the real long term fix, if there is one. > > -- Terry Or we could just rig something up. :) But, since it's probably not a problem in many cases, I'm not going to worry about it for a while. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 5 20: 1:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 6979737B407 for ; Wed, 5 Sep 2001 20:01:21 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id MAA13916; Thu, 6 Sep 2001 12:01:29 +0900 (JST) Date: Thu, 06 Sep 2001 12:01:21 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Matthew Emmerton" Cc: Subject: Re: ping gif0 In-Reply-To: <002b01c135a1$5aa23070$1200a8c0@gsicomp.on.ca> References: <002b01c135a1$5aa23070$1200a8c0@gsicomp.on.ca> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 24 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Tue, 4 Sep 2001 20:26:04 -0400, >>>>> "Matthew Emmerton" said: > I've got a question for all of you net hackers. > When I configure a gif interface, why can't I ping the local endpoint on the > inside of the tunnel? I've just been through hell and back trying to get > some IPSec tunnels created (they're working now, thanks to all those who > helped me out), and this was one of my big stumbling blocks -- since I > couldn't ping the local or remote endpoint of the gif tunnel, I spent much > time chasing down problems with gif when it wasn't a problem at all. Please be more specific. I guess we need at least - the version of the OS - the result of 'ifconfig -a' - the result of 'gifconfig -a' - the result of 'netstat -rnal' - the exact output of ping (do not *describe* the situation, please. just copy and paste the output -by script(1) etc-) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 6 17:12:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from samuel.interplex.ca (abi.ca [216.18.127.185]) by hub.freebsd.org (Postfix) with ESMTP id 0890D37B406 for ; Thu, 6 Sep 2001 17:12:52 -0700 (PDT) Received: from there (deejay2@smart-x.ctlc.interplex.ca [209.71.202.73]) by samuel.interplex.ca (8.11.3/8.11.3) with SMTP id f8748l107831 for ; Fri, 7 Sep 2001 00:08:49 -0400 (EDT) (envelope-from db@interplex.ca) Message-Id: <200109070408.f8748l107831@samuel.interplex.ca> Content-Type: text/plain; charset="iso-8859-1" From: Dominic Blais To: freebsd-net@freebsd.org Subject: (FreeBSD 4.3 + fxp + VLAN) == Problems... ?! Date: Thu, 6 Sep 2001 20:15:49 -0400 X-Mailer: KMail [version 1.3] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I got fxp cards when I saw that it has native vlan support... But the problem is that even with this card, the mtu is set to 1496 instead of 1500... So, I tried to force it... ifconfig fpx0 mtu 1500 But there are things that starts not working... and other working... Any email sent that is longer than 3 lines doesn't pass through the freebsd router.. (doesn't get through the vlan interface) So I guess this isn't a good thing.. I saw a patch for freebsd 4.2 that sets a bit on the card to support long frames and sets the mtu to 1500 as default value.. Is it available for FreeBSD 4.3 somewhere?? Thanks a lot, Dominic Blais To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 6 21:23:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from snowflake.apdata.com.au (cerberus.apdata.com.au [202.14.95.17]) by hub.freebsd.org (Postfix) with ESMTP id F332E37B401 for ; Thu, 6 Sep 2001 21:23:32 -0700 (PDT) Received: from localhost (localhost.apdata.com.au [127.0.0.1]) by snowflake.apdata.com.au (Postfix) with ESMTP id A0F6676214 for ; Fri, 7 Sep 2001 13:53:30 +0930 (CST) Received: from apdata.com.au (alpha.apdata.com.au [192.168.255.29]) by snowflake.apdata.com.au (Postfix) with ESMTP id C718476210 for ; Fri, 7 Sep 2001 13:53:24 +0930 (CST) Message-ID: <3B984BBC.38C0FA7B@apdata.com.au> Date: Fri, 07 Sep 2001 13:53:24 +0930 From: David Hunt Organization: Applied Data Control X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: PPP not adding an interface route Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi All I am running FreeBSD 4.4-RC, compiled on the 7-september and have found that PPP is not adding a local interface route when the link comes up. I am using a legal subnet as follows: tun0: flags=8051 mtu 1500 inet6 fe80::260:97ff:fe7b:3dc2%tun0 prefixlen 64 scopeid 0xa inet 192.168.252.2 --> 192.168.252.1 netmask 0xfffffffc Opened by PID 117 but the route table shows: bash-2.04# netstat -arn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 127.0.0.1 127.0.0.1 UH 2 180 lo0 192.168.6 link#1 UC 1 0 xl0 192.168.6.255 ff:ff:ff:ff:ff:ff UHLWb 1 1 xl0 192.168.252.1 192.168.252.2 UH 2 59 tun0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::%xl0/64 link#1 UC xl0 fe80::260:97ff:fe7b:3dc2%xl0 0:60:97:7b:3d:c2 UHL lo0 fe80::%lo0/64 fe80::1%lo0 Uc lo0 fe80::1%lo0 link#4 UHL lo0 fe80::%tun0/64 fe80::260:97ff:fe7b:3dc2%tun0 Uc tun0 fe80::260:97ff:fe7b:3dc2%tun0 link#10 UHL lo0 ff01::/32 ::1 U lo0 ff02::%xl0/32 link#1 UC xl0 ff02::%lo0/32 ::1 UC lo0 ff02::%tun0/32 fe80::260:97ff:fe7b:3dc2%tun0 UC tun0 With the link up and able to ping the remote end 192.168.252.1 just fine from the server, if you try to ping the local interface, you get the following: bash-2.04# ping 192.168.252.2 PING 192.168.252.2 (192.168.252.2): 56 data bytes ping: sendto: No route to host ping: sendto: No route to host ^C --- 192.168.252.2 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss bash-2.04# route -n get 192.168.252.2 route: writing to routing socket: No such process Please indicate where the problem with this may be. Thanks David Hunt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 6 22:52:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id F055837B405 for ; Thu, 6 Sep 2001 22:52:39 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f875qq252646; Fri, 7 Sep 2001 00:52:52 -0500 (CDT) (envelope-from jlemon) Date: Fri, 7 Sep 2001 00:52:52 -0500 (CDT) From: Jonathan Lemon Message-Id: <200109070552.f875qq252646@prism.flugsvamp.com> To: db@interplex.ca, net@freebsd.org Subject: Re: (FreeBSD 4.3 + fxp + VLAN) == Problems... ?! X-Newsgroups: local.mail.freebsd-net In-Reply-To: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article you write: > >I got fxp cards when I saw that it has native vlan support... But the problem >is that even with this card, the mtu is set to 1496 instead of 1500... The native VLAN support was added to the driver after 4.3 was released. The patch for 4.2 should apply to 4.3 as well. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 7 3:44:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by hub.freebsd.org (Postfix) with ESMTP id 2315237B403; Fri, 7 Sep 2001 03:44:15 -0700 (PDT) Received: from vovik@localhost (vovik@localhost) by burka.carrier.kiev.ua id NQY70812; Fri, 7 Sep 2001 13:44:03 +0300 (EEST) (envelope-from vovik) Date: Fri, 7 Sep 2001 13:44:03 +0300 From: "Vladimir A. Jakovenko" To: Terry Lambert Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: SO_REUSEPORT on unicast UDP sockets Message-ID: <20010907134403.T2693@lucky.net> References: <20010902054617.A47742@lucky.net> <3B947922.F8B98DBD@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B947922.F8B98DBD@mindspring.com>; from tlambert2@mindspring.com on Mon, Sep 03, 2001 at 11:48:02PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Sep 03, 2001 at 11:48:02PM -0700, Terry Lambert wrote: >"Vladimir A. Jakovenko" wrote: >> >> Hello! >> >> According to UNPv1 SO_REUSEPORT on UDP sockets can be used to bind more than >> one socket to the same port (even with same source ip address). But quick >> look on /sys/netinet/udp_usrreq.c function udp_input() shows that this will >> work as expected (data stream duplicate) only on multicast/broadcast local >> addresses. Please pay attention to the following code fragment comments: > >[ ... ] > >> Is there still any real need in such backward compatibility? Can such >> functionality be added (fixed) with possibility to switch it off using >> sysctl or kernel-build option? >> >> I find such possibility realy useful at least for NetFlow data >> processing and believe that it would be useful for many UDP-based >> protocols. > >Bound UDP sockets have always been problematic; there's a lot >of code out there that depnds on the historical behaviour for >unicast, unfortunately, including a number of commercial >applications that run on FreeBSD (e.g. Real Server). > >If you look at that code for any length of time, you will get >to see it as an armpit: it's not a good place to stick your >nose, and it tends to smell to high heaven. At my current >job, I'm up to my elbows in it... Terry, I clearly understand all your explanations. Yes, we are living in real life and there is a lot of programms with bad design. But all what I want is possibility to receive UDP packets with corresponding dst IP and port by more than one process on a single host. This already works for Broadcast and Multicast addresses. If I want to get same functionality for unicast (without any kernel changes) I have to use UDP-proxy, which redirects given datagrams to loopback broadcast address, where they can be received by more that one process. According to comment in udp_input() SO_REUSEPORT hack on unicast sockets could be used in single process, right? How possibility to get duplicate traffic on two UDP sockets, which was created in _different_ processes with the same local address and port values, would break existing applications? -- Regards, Vladimir. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 7 5:40:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id D577A37B405 for ; Fri, 7 Sep 2001 05:40:09 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [fec0::1:12]) by Awfulhak.org (8.11.6/8.11.6) with ESMTP id f87Ce7i28900; Fri, 7 Sep 2001 13:40:08 +0100 (BST) (envelope-from brian@freebsd-services.com) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.6/8.11.6) with ESMTP id f87Ce5J14931; Fri, 7 Sep 2001 13:40:05 +0100 (BST) (envelope-from brian@freebsd-services.com) Message-Id: <200109071240.f87Ce5J14931@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: David Hunt Cc: freebsd-net@FreeBSD.ORG, brian@freebsd-services.com Subject: Re: PPP not adding an interface route In-Reply-To: Message from David Hunt of "Fri, 07 Sep 2001 13:53:24 +0930." <3B984BBC.38C0FA7B@apdata.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Sep 2001 13:40:05 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Hi All > > > I am running FreeBSD 4.4-RC, compiled on the 7-september and have found > that PPP is not adding a local interface route when the link comes up. I > am using a legal subnet as follows: > > > tun0: flags=8051 mtu 1500 > inet6 fe80::260:97ff:fe7b:3dc2%tun0 prefixlen 64 scopeid 0xa > inet 192.168.252.2 --> 192.168.252.1 netmask 0xfffffffc > Opened by PID 117 > > but the route table shows: > > bash-2.04# netstat -arn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > 127.0.0.1 127.0.0.1 UH 2 180 lo0 > 192.168.6 link#1 UC 1 0 xl0 > 192.168.6.255 ff:ff:ff:ff:ff:ff UHLWb 1 1 xl0 > 192.168.252.1 192.168.252.2 UH 2 59 tun0 ppp has never automatically added a lo0 route. If ppp detects an outbound packet destined for the local interface address and ``loopback'' is ``enabled'' (the default), it'll turn the packet around, but that's the extent of it's helpfulness. > Thanks > > David Hunt -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 7 11:47:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id 73A2137B405 for ; Fri, 7 Sep 2001 11:47:55 -0700 (PDT) Received: (qmail 1968 invoked by uid 0); 7 Sep 2001 18:47:53 -0000 Received: from pd901422e.dip.t-dialin.net (HELO thibaultbautze) (217.1.66.46) by mail.gmx.net (mp010-rz3) with SMTP; 7 Sep 2001 18:47:53 -0000 Message-ID: <002101c137cd$f9a5caa0$817b7b7b@my.network.net> From: "Thibault Bautze" To: Subject: nat problems Date: Fri, 7 Sep 2001 20:50:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello! I'm currently configuring a FreeBSD 4.2 firewall ( but my first target is a simple router ). I use PPP over ethernet for the Inet connection. To route packets between the Inet and my subnet I use ppp with nat enable yes, nat use_sockets yes and nat same_ports yes but without firewall rules. The connection between the subnet and the Inet works fine, but I still have one big problem: I cannot reach some websites if I'm sitting on my windows or freebsd box behind the firewall. www.gmx.de and www.icq.com for example cannot be opened, but I can easily open them with the webbrowser on the firewall. I found that you cannot ping this sites, even if I'm sitting on the firewall or connectet with my windows box directly to the internet. Here is the result for a ping: # ping www.gmx.de PING www.gmx.de (213.165.65.100): 56 data bytes 36 bytes from 62.156.128.226: Communication prohibited by filter Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 5400 00ff 0 0000 fa 01 8d4c 217.1.yy.xx 213.165.65.100 --- www.gmx.de ping statistics --- 16 packets transmitted, 0 packets received, 100% packet loss 62.156.128.226 is in this case the other side of the ppp tunel, my ISP ( t-online, Germany if it can help ) But I'm not sure if it makes a difference, if you can ping them or not. I got the same result with ping www.microsoft.com ( bad example, I know ; ) ) , but I can open this site on my freebsd or windows box. Thanks, Thibault Bautze To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 7 12: 0:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 39E4737B401; Fri, 7 Sep 2001 12:00:19 -0700 (PDT) Received: from mindspring.com (dialup-209.247.142.57.Dial1.SanJose1.Level3.net [209.247.142.57]) by falcon.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f87J06325278; Fri, 7 Sep 2001 12:00:06 -0700 (PDT) Message-ID: <3B991962.C8D0A398@mindspring.com> Date: Fri, 07 Sep 2001 12:00:50 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vladimir A. Jakovenko" Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: SO_REUSEPORT on unicast UDP sockets References: <20010902054617.A47742@lucky.net> <3B947922.F8B98DBD@mindspring.com> <20010907134403.T2693@lucky.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "Vladimir A. Jakovenko" wrote: > Terry, I clearly understand all your explanations. Yes, we are living in > real life and there is a lot of programms with bad design. > > But all what I want is possibility to receive UDP packets with > corresponding dst IP and port by more than one process on a single > host. This already works for Broadcast and Multicast addresses. If > I want to get same functionality for unicast (without any kernel > changes) I have to use UDP-proxy, which redirects given datagrams > to loopback broadcast address, where they can be received by more > that one process. Yes. > According to comment in udp_input() SO_REUSEPORT hack on unicast > sockets could be used in single process, right? Yes. > How possibility to get duplicate traffic on two UDP sockets, which > was created in _different_ processes with the same local address > and port values, would break existing applications? Consider a UDP based reliable delivery protocol that cares about key frames, but not about all frames. A good example of this would be any RTSP/RTP type protocol implemented on UDP, which was used to implement streaming video of a live broadcast, using limited buffer space. In this situation, the video is delivered by sending a key frame, and then subsequent data is sent as deltas on that key frame. Effectively, this MUXes two protocols: a reliable datagram protocol containing the key frames, and an unreliable protocol containing the deltas, over a single channel. This method of key frame use is the same method used to encode DVD data and a number of real time streaming protocols, including a number of streaming video protocols running over UDP (the original technique was pioneered by a company named CinemaWare, a Utah-based developer of Amiga software, which used a technique called "cell animation" to reduce image data size requirements). Your hypothetical two-process-no-proxy program would not correctly acknowledge key frames consisting of more than one UDP packet, unless you delivered the unicast to both. If you delivered the unicast to both, you would need to build an "acknowledgement proxy", which would only acknowledge when the entire key frame had been received by *both* processes. Taking an even simpler case, you could build a UDP packet payload classifier, which would classify UDP packets based on payload (size, etc.), and report statistics at the end of a run. Your change would result in erroneous reporting. On a philosophical note, it's questionable about whether a unicast is directed to an IP/port pair, or whether it is directed to a particular application, and the IP/port pair, or even the UDP protocol, are just a necessary vehicle for the delivery of the information. On a practical note, if you could fix the multiple delivery problem, so that only one listener got the packet, this would address many, but not all, of the objections above(*). On a purely technical note, I think you want to use something other than unicast for your implementation: multicast group seems to be the most correct fit (I am in the camp that a unicast is directed at an application, not merely a machine). (*) You would still have the problem of a meta relationship between multiple packets, and you would still have the problem of "correctly" selecting who would get the packet; right now, the behaviour is "first listener", not LRU more MRU... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 7 12:25:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id E312137B403 for ; Fri, 7 Sep 2001 12:25:44 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA35177; Fri, 7 Sep 2001 12:42:45 -0700 (PDT) Date: Fri, 7 Sep 2001 12:42:45 -0700 (PDT) From: Julian Elischer To: Thibault Bautze Cc: freebsd-net@freebsd.org Subject: Re: nat problems In-Reply-To: <002101c137cd$f9a5caa0$817b7b7b@my.network.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 7 Sep 2001, Thibault Bautze wrote: > > I found that you cannot ping this sites, even if I'm sitting on the firewall > or connectet with my > windows box directly to the internet. > Here is the result for a ping: > > # ping www.gmx.de > PING www.gmx.de (213.165.65.100): 56 data bytes > 36 bytes from 62.156.128.226: Communication prohibited by filter > Vr HL TOS Len ID Flg off TTL Pro cks Src Dst > 4 5 00 5400 00ff 0 0000 fa 01 8d4c 217.1.yy.xx 213.165.65.100 > --- www.gmx.de ping statistics --- > 16 packets transmitted, 0 packets received, 100% packet loss > > 62.156.128.226 is in this case the other side of the ppp tunel, my ISP ( > t-online, > Germany if it can help ) > > But I'm not sure if it makes a difference, if you can ping them or not. I > got > the same result with ping www.microsoft.com ( bad example, I know ; ) ) , > but I can open this site on my > freebsd or windows box. It makes a difference because the firewall is blocking ICMP which is used to allow the maximum packet size negotiation. > > > Thanks, > Thibault Bautze > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 7 12:51:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id BA82E37B408 for ; Fri, 7 Sep 2001 12:51:50 -0700 (PDT) Received: (qmail 6413 invoked by uid 0); 7 Sep 2001 19:51:49 -0000 Received: from pd901422e.dip.t-dialin.net (HELO thibaultbautze) (217.1.66.46) by mail.gmx.net (mp005-rz3) with SMTP; 7 Sep 2001 19:51:49 -0000 Message-ID: <005c01c137d6$e7ea3720$817b7b7b@my.network.net> From: "Thibault Bautze" To: Subject: Re: nat problems Date: Fri, 7 Sep 2001 21:54:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ----- Original Message ----- > > I found that you cannot ping this sites, even if I'm sitting on the firewall > > or connectet with my > > windows box directly to the internet. > > Here is the result for a ping: > > > > # ping www.gmx.de > > PING www.gmx.de (213.165.65.100): 56 data bytes > > 36 bytes from 62.156.128.226: Communication prohibited by filter > > Vr HL TOS Len ID Flg off TTL Pro cks Src Dst > > 4 5 00 5400 00ff 0 0000 fa 01 8d4c 217.1.yy.xx 213.165.65.100 > > --- www.gmx.de ping statistics --- > > 16 packets transmitted, 0 packets received, 100% packet loss > > > > 62.156.128.226 is in this case the other side of the ppp tunel, my ISP ( > > t-online, > > Germany if it can help ) > > > > But I'm not sure if it makes a difference, if you can ping them or not. I > > got > > the same result with ping www.microsoft.com ( bad example, I know ; ) ) , > > but I can open this site on my > > freebsd or windows box. > > It makes a difference because the firewall is blocking ICMP which is used > to allow the maximum packet size negotiation. > Even if I use IPFIREWALL_DEFAULT_TO_ACCEPT ? I'm just configuring the router, the firewall funtions comes later. Thanks for your advices, Thibault Bautze To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 7 19:36:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by hub.freebsd.org (Postfix) with ESMTP id EACE737B403 for ; Fri, 7 Sep 2001 19:36:22 -0700 (PDT) Received: from chimp.simianscience.com (cage.simianscience.com [64.7.134.1]) by smtp1.sentex.ca (8.11.6/8.11.6) with SMTP id f882aGf73970; Fri, 7 Sep 2001 22:36:16 -0400 (EDT) (envelope-from mike@sentex.net) From: Mike Tancsa To: db@interplex.ca (Dominic Blais) Cc: freebsd-net@freebsd.org Subject: Re: (FreeBSD 4.3 + fxp + VLAN) == Problems... ?! Date: Fri, 07 Sep 2001 22:36:15 -0400 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 6 Sep 2001 20:13:01 -0400, in sentex.lists.freebsd.net you wrote: > >So I guess this isn't a good thing.. I saw a patch for freebsd 4.2 that = sets=20 >a bit on the card to support long frames and sets the mtu to 1500 as = default=20 >value.. Is it available for FreeBSD 4.3 somewhere?? Either upgrade to a recent STABLE via cvsup, or upgrade to 4.4 when it comes out in a week, or=20 http://www.euitt.upm.es/~pjlobo/fbsdvlan.html should work with your 4.3R system. ---Mike Mike Tancsa (mdtancsa@sentex.net) =09 Sentex Communications Corp, =09 Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers=20 could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 8 7:10: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from mgw1.MEIway.com (mgw1.meiway.com [212.73.210.75]) by hub.freebsd.org (Postfix) with ESMTP id D5BA137B407 for ; Sat, 8 Sep 2001 07:10:01 -0700 (PDT) Received: from mail.Go2France.com (ms1.meiway.com [212.73.210.73]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id 7BB6E16B13 for ; Sat, 8 Sep 2001 16:09:59 +0200 (CEST) Received: from IBM-HIRXKN66F0W.Go2France.com [66.64.14.18] by mail.Go2France.com with ESMTP (SMTPD32-6.06) id A9318FC00058; Sat, 08 Sep 2001 16:20:33 +0200 Message-Id: <5.1.0.14.0.20010908090440.06337828@mail.Go2France.com> X-Sender: LConrad@Go2France.com@mail.Go2France.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 08 Sep 2001 09:09:42 -0500 To: Freebsd-net@freebsd.org From: Len Conrad Subject: tracing an attack using spoofed ip´s Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org A client has been receiving an attack on this mail gateway´s port 25 for 3 weeks. We increased the postfix SMTPD processes from 50 to 150, and the hourly msg rejects jumped from 5000 to 15000, roughly. The source addresses used by the attacker(s) are mostly in the various RBL bases, 100´s of them. The pb is that the attack is consuming so many SMTPD processes that valid incoming mail is taking several hours to arrive, as the sender MTA can´t get an answer when it connects to port 25. the definition of DoS. Is there anyway to trace the real source of the spoofed packets? Len http://MenAndMice.com/DNS-training http://BIND8NT.MEIway.com : ISC BIND 8.2.4 for NT4 & W2K http://IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gateways To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 8 7:51:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by hub.freebsd.org (Postfix) with ESMTP id CA1EC37B405; Sat, 8 Sep 2001 07:51:24 -0700 (PDT) Received: from vovik@localhost (vovik@localhost) by burka.carrier.kiev.ua id RTS88893; Sat, 8 Sep 2001 17:51:13 +0300 (EEST) (envelope-from vovik) Date: Sat, 8 Sep 2001 17:51:13 +0300 From: "Vladimir A. Jakovenko" To: Terry Lambert Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: SO_REUSEPORT on unicast UDP sockets Message-ID: <20010908175113.B84471@lucky.net> References: <20010902054617.A47742@lucky.net> <3B947922.F8B98DBD@mindspring.com> <20010907134403.T2693@lucky.net> <3B991962.C8D0A398@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B991962.C8D0A398@mindspring.com>; from tlambert2@mindspring.com on Fri, Sep 07, 2001 at 12:00:50PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Sep 07, 2001 at 12:00:50PM -0700, Terry Lambert wrote: >"Vladimir A. Jakovenko" wrote: >> Terry, I clearly understand all your explanations. Yes, we are living in >> real life and there is a lot of programms with bad design. >> >> But all what I want is possibility to receive UDP packets with >> corresponding dst IP and port by more than one process on a single >> host. This already works for Broadcast and Multicast addresses. If >> I want to get same functionality for unicast (without any kernel >> changes) I have to use UDP-proxy, which redirects given datagrams >> to loopback broadcast address, where they can be received by more >> that one process. > >Yes. Ok. >> According to comment in udp_input() SO_REUSEPORT hack on unicast >> sockets could be used in single process, right? > >Yes. Ok. >> How possibility to get duplicate traffic on two UDP sockets, which >> was created in _different_ processes with the same local address >> and port values, would break existing applications? >Consider a UDP based reliable delivery protocol that cares >about key frames, but not about all frames. A good example >of this would be any RTSP/RTP type protocol implemented on >UDP, which was used to implement streaming video of a live >broadcast, using limited buffer space. Terry, your example is right for UDP services which requires _acknowledgment_. But in my case what I need is the simple, even classic, unreliable UDP datastream delivery _without_ acknowledgment_ destinated to one or _more_ processes on single host. Yes, multicast (and even broadcast) is good, but not all time. I.e. if in one broadcast domain exists at least one non trusted host it would be difficult (and in the case of broadcast not possible) to restrict such host ability to receive traffic destinated to multicast group if other hosts should have ability to join group and receive traffic. Lets sum up all mentioned issues: 1. There is restriction in FreeBSD kernel about processing SO_REUSEPORT socket option on UDP scokets, which allows more than one binding to given ip:port on one host. This restriction blocks possibility to obtain UNICAST traffic destinated to same ip:port by two or more processes simultaneously. 2. If this restriction would be removed only for sockets crated by different processes it would not break existing applications. Am I right? -- Regards, Vladimir. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 8 9:27:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id B532837B405 for ; Sat, 8 Sep 2001 09:27:27 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 82E4781D05; Sat, 8 Sep 2001 11:27:22 -0500 (CDT) Date: Sat, 8 Sep 2001 11:27:22 -0500 From: Alfred Perlstein To: Len Conrad Cc: Freebsd-net@freebsd.org Subject: Re: =?iso-8859-1?Q?tracing_an_attack_using_spoofed_ip=B4s?= Message-ID: <20010908112722.G2965@elvis.mu.org> References: <5.1.0.14.0.20010908090440.06337828@mail.Go2France.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20010908090440.06337828@mail.Go2France.com>; from LConrad@Go2France.com on Sat, Sep 08, 2001 at 09:09:42AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Len Conrad [010908 09:10] wrote: > A client has been receiving an attack on this mail gateway´s port 25 for 3 > weeks. We increased the postfix SMTPD processes from 50 to 150, and the > hourly msg rejects jumped from 5000 to 15000, roughly. The source addresses > used by the attacker(s) are mostly in the various RBL bases, 100´s of them. > > The pb is that the attack is consuming so many SMTPD processes that valid > incoming mail is taking several hours to arrive, as the sender MTA can´t > get an answer when it connects to port 25. the definition of DoS. > > Is there anyway to trace the real source of the spoofed packets? The packets are mostly likely not spoofed, one can not have a 3way handshake and still spoof without: a) being on the same local lan (so you can sniff packets) b) being able to predict the next sequence number. Even with 'b' it's be quite difficult to get right because not only does one have to predeict the sequence number, it has to keep predicting them to actually send data. My suggestion is to start using firewall rules or perhaps hook tcpwrappers such that it looks up incomming connections and checks them against RBL. Another suggestion is to call the ISPs or law enforcement offcials to report this continued harrassment. best of luck, -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 8 10:53:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from mgw1.MEIway.com (mgw1.meiway.com [212.73.210.75]) by hub.freebsd.org (Postfix) with ESMTP id 393B637B403 for ; Sat, 8 Sep 2001 10:53:25 -0700 (PDT) Received: from mail.Go2France.com (ms1.meiway.com [212.73.210.73]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id 215C816B1C for ; Sat, 8 Sep 2001 19:53:23 +0200 (CEST) Received: from IBM-HIRXKN66F0W.Go2France.com [66.64.14.18] by mail.Go2France.com with ESMTP (SMTPD32-6.06) id ADB9A8CB0058; Sat, 08 Sep 2001 20:04:41 +0200 Message-Id: <5.1.0.14.0.20010908114909.02a00920@mail.Go2France.com> X-Sender: LConrad@Go2France.com@mail.Go2France.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 08 Sep 2001 12:53:05 -0500 To: Freebsd-net@freebsd.org From: Len Conrad Subject: Re: tracing an attack using spoofed ip´s In-Reply-To: <20010908112722.G2965@elvis.mu.org> References: <5.1.0.14.0.20010908090440.06337828@mail.Go2France.com> <5.1.0.14.0.20010908090440.06337828@mail.Go2France.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >My suggestion is to start using firewall rules or perhaps hook >tcpwrappers such that it looks up incomming connections and >checks them against RBL. good idea, but I´m not a c programmer. > Another suggestion is to call the >ISPs or law enforcement offcials to report this continued >harrassment. postfix´s RBL_domains is already doing the rejects, sample: RCPT blocked using or.orbl.org 2362 pat-app.lil.completel.fr 1665 210.220.162.100 1270 62.81.157.15 1086 216.122.113.44 1028 mirapoint2.brutele.be 715 pacific.net.sg 438 esat.net 410 ada.net.tr 405 202.47.250.4 357 203.181.53.2 310 optusnet.com.au 286 211.94.65.199 265 dialup.ptt.ru 215 210.102.127.253 193 202.122.64.129 192 hinet.net 182 deviet-f.a2000.nl 172 211.58.91.125 158 202.183.230.254 141 62.159.145.94 137 mail.nsu.ru 130 216.18.85.4 128 212.49.90.182 117 210.192.246.201 113 xidian.edu.cn 113 211.55.167.44 etc and blocked using relays.ordb.org 2547 202.71.144.104 1863 211.100.6.104 1733 62.110.249.67 1732 tne.net.au 1724 mymap.net 1615 delta.sote.poznan.pl 1594 194.206.55.241 1514 203.121.10.198 1506 kingston-internet.net 1485 ntgroup.com.pe 1450 211.116.17.240 1443 server.szfkszi.sulinet.hu 1419 203.239.165.42 1404 195.211.46.82 1369 202.54.124.25 1363 202.104.84.88 1355 202.157.191.22 1290 128.134.193.246 1285 202.94.1.201 1271 202.108.249.73 1183 202.43.71.123 1148 195.224.253.56 1138 202.186.154.1 1125 seeder.net 1120 213.219.55.156 1054 controller.com.ua 1045 203.239.1.125 etc The above section of the maillog report is about 3600 lines, so are you saying that 3600 unspoofed, different ip´s are doing the attack? That´s "distributed" if I ever saw one. I suppose one "master" PC could be relaying through all those open relays against this one MX host. thanks Len http://MenAndMice.com/DNS-training http://BIND8NT.MEIway.com : ISC BIND 8.2.4 for NT4 & W2K http://IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gateways To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 8 11:40:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 032B437B409 for ; Sat, 8 Sep 2001 11:40:23 -0700 (PDT) Received: (qmail 23307 invoked by uid 1000); 8 Sep 2001 18:40:21 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Sep 2001 18:40:21 -0000 Date: Sat, 8 Sep 2001 13:40:21 -0500 (CDT) From: Mike Silbersack To: Len Conrad Cc: Subject: =?X-UNKNOWN?Q?Re=3A_tracing_an_attack_using_spoofed_ip=B4s?= In-Reply-To: <5.1.0.14.0.20010908114909.02a00920@mail.Go2France.com> Message-ID: <20010908133516.K23209-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 8 Sep 2001, Len Conrad wrote: > The above section of the maillog report is about 3600 lines, so are you > saying that 3600 unspoofed, different ip=B4s are doing the attack? That= =B4s > "distributed" if I ever saw one. > > I suppose one "master" PC could be relaying through all those open relays > against this one MX host. If someone's vicious enough, that doesn't sound too unbelieveable. But, regarding the possibility of tcp spoofing: What version of FreeBSD is the client running? If it's < 4.2 that is a possibility. However, given that the IPs are almost all from open relays, it seems much more likely that this has nothing to do with spoofing. What is the content of these e-mails? I wonder if it's possible that someone is spamming with an e-mail address at your client's domain. Subsequently, those being spammed at using ordb/rbl to reject the message, and the open relay is then sending your client the bounce message. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 8 13:34:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.clickarray.com (dune.clickarray.com [209.10.62.213]) by hub.freebsd.org (Postfix) with ESMTP id B997B37B406 for ; Sat, 8 Sep 2001 13:34:57 -0700 (PDT) Received: by mail.clickarray.com (Postfix, from userid 2000) id C961C5EF05; Sat, 8 Sep 2001 13:44:26 -0700 (PDT) Date: Sat, 8 Sep 2001 13:44:26 -0700 From: Steve Shah To: Alfred Perlstein Cc: Len Conrad , Freebsd-net@freebsd.org Subject: Re: =?iso-8859-1?Q?tracing_an_attack_using_spoofed_ip=B4s?= Message-ID: <20010908134426.B61513@clickarray.com> References: <5.1.0.14.0.20010908090440.06337828@mail.Go2France.com> <20010908112722.G2965@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <20010908112722.G2965@elvis.mu.org>; from bright@mu.org on Sat, Sep 08, 2001 at 11:27:22AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Sep 08, 2001 at 11:27:22AM -0500, Alfred Perlstein wrote: > * Len Conrad [010908 09:10] wrote: > > A client has been receiving an attack on this mail gateway´s port 25 for 3 > > weeks. We increased the postfix SMTPD processes from 50 to 150, and the > > My suggestion is to start using firewall rules or perhaps hook Use the firewall rules. The earlier you drop the packets, the better off you'll be. Setting up the rules will hopefully buy you some additional time to contact your ISP so that they can setup packet filtering rules on their routers. (After all, their boxes are taking extra load too...) -Steve -- ______________________________________________________________________________ Steve Shah (sshah@clickarray.com) | Voice: 408.284.4226 Pager: 408.989.4247 http://www.clickarray.com | Pager E-Mail: pagesshah@clickarray.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Beating code into submission, one OS at a time... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 8 14:19: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from samuel.interplex.ca (abi.ca [216.18.127.185]) by hub.freebsd.org (Postfix) with ESMTP id AE1C037B401 for ; Sat, 8 Sep 2001 14:18:55 -0700 (PDT) Received: from there (deejay2@smart-x.ctlc.interplex.ca [209.71.202.73]) by samuel.interplex.ca (8.11.3/8.11.3) with SMTP id f891EnU07226 for ; Sat, 8 Sep 2001 21:14:50 -0400 (EDT) (envelope-from db@interplex.ca) Message-Id: <200109090114.f891EnU07226@samuel.interplex.ca> Content-Type: text/plain; charset="iso-8859-1" From: Dominic Blais To: freebsd-net@freebsd.org Subject: dhcpd problem Date: Sat, 8 Sep 2001 17:21:59 -0400 X-Mailer: KMail [version 1.3] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org If I start dhcpd with 15 vlan interfaces ....for the 1st time, it's OK (dhcpd vlan0 vlan1 vlan2.... vlan14) If I kill dhcpd to make changes tak effect, I can't restart dhcpd with more than 3 interfaces.... If I try with > 3 , I always get an error message [last interfaces in parameters] : not found example: dhcpd vlan0 vlan1 vlan2 vlan3 vlan3: not found dhcpd vlan0 vlan1 vlan2 vlan3 vlan4 vlan4: not found but vlan0 vlan1 vlan2 and vlan3 are not started in dhcpd anymore..dhcpd isn't running.... I must restart the box.. Where's the prob? thanks.. Dominic Blais To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 8 21: 4:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id 10FE837B406; Sat, 8 Sep 2001 21:04:17 -0700 (PDT) Received: from localhost (eddy@localhost) by a.mx.everquick.net (8.10.2/8.10.2) with ESMTP id f8944AY03851; Sun, 9 Sep 2001 04:04:11 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Sun, 9 Sep 2001 04:04:06 +0000 (GMT) From: "E.B. Dreger" To: hackers@freebsd.org, net@freebsd.org Subject: outbound SOCK_STREAM - force source addr? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Greetings all, Any way to force the source address for an outbound SOCK_STREAM? I know that one can do it for SOCK_DGRAM... but I've found no way to do so for, say, a TCP connection. Example: + dc0 has 192.168.0.1/24 as primary IP, 192.168.0.2/24 as alias + an outbound connection wishes to "come from" 192.168.0.2. I know that one can always use an IP socket (duh!), but it's silly to reinvent the TCP stack to force the source addr. I've not looked at jail(2) to see if there's anything similar. I don't necessarily want to _use_ jail(2), but if there's code that one could hack into a setsockopt(2) call, that would be a start. Finally, I don't care about how loose or tight allowed-address restrictions are, as long as any "local address" is acceptable. (Local address = one for which the machine answers ARP requests.) Suggestions? Have I overlooked something simple? TIA, Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to , or you are likely to be blocked. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 8 21:30:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 3351E37B407; Sat, 8 Sep 2001 21:30:20 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 04EF181D05; Sat, 8 Sep 2001 23:30:15 -0500 (CDT) Date: Sat, 8 Sep 2001 23:30:15 -0500 From: Alfred Perlstein To: "E.B. Dreger" Cc: hackers@freebsd.org, net@freebsd.org Subject: Re: outbound SOCK_STREAM - force source addr? Message-ID: <20010908233014.J2965@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from eddy+public+spam@noc.everquick.net on Sun, Sep 09, 2001 at 04:04:06AM +0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * E.B. Dreger [010908 23:04] wrote: > Greetings all, > > Any way to force the source address for an outbound SOCK_STREAM? I > know that one can do it for SOCK_DGRAM... but I've found no way to > do so for, say, a TCP connection. It's not immediatly obvious, but you can bind(2) a socket before calling connect(2) in order to do this. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 8 23:53:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from hermes.pressenter.com (hermes.pressenter.com [209.224.20.19]) by hub.freebsd.org (Postfix) with ESMTP id 008B037B407 for ; Sat, 8 Sep 2001 23:53:47 -0700 (PDT) Received: from [209.224.20.91] (helo=daggar) by hermes.pressenter.com with smtp (Exim 3.16 #1) id 15fyTL-00077r-00 for freebsd-net@FreeBSD.ORG; Sun, 09 Sep 2001 01:53:40 -0500 From: "Stephen Hilton" To: "FreeBSD Net" Subject: Re: Possibly Bug Report with Kernel ep (3com 5xx ISA and others) driver Date: Sun, 9 Sep 2001 01:55:09 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have just finished setting up 4.4_RC4 with GENERIC kernel on a legacy Packard Bell (aka PB) system with a 3C509B ISA set to non-pnp IO=300, IRQ=10, after securing the services on the PB I fired up my gateway system (modem based) to the net and started testing the PB. The first test I tried was a ping to a valid internet host "ping 209.xxx.xxx.xxx", no response from the ping, tried the ping several times with no response but I would ctrl-c the ping command after 10-15 seconds thinking my network setup was incorrect. Checked my internet connection by pinging the same internet host from the FreeBSD gateway and the windows box, both pinged fine. Re-checked my setup, after several minuets of examining config files etc... everything looked fine. I then used ftp from the PB, and got a quick connection with no problems, tried the ping from the PB again, worked fine, installed Lynx from ports, http connects fines. Rebooted the PB and logged in via SSH, pings to the intranet and internet work fine. Just thought I would share this with the list, and if the problem shows itself again I will post again. Regards, Stephen Hilton > Yes, and inbetween I can confirm: The problem occurs on both > interfaces; the chance that the problem occurs is slightly > higher on the interface with the higher network load. > > To sum up: As the very same problem occurs with pretty different > hardware, I really think there's something wrong with the > cooperation of the ep-driver and 3com 509 - maybe the driver, > maybe some design error on the network cards... > --------------snip--------------- from subject line: "laptop arp weirdness" posted 9-2-2001 > The lines from 153 to 174 appeared ALL AT ONCE (note the decending > times). If I leave it for a long time, the pattern repeats, with a slew > of ping responses showing up at irregular intervals. I also ran > tcpdumps elsewhere on the network, and found that ... > - pings *to* the laptop merely generate gobs of "arp who-has" on the > network, none of which is seen by the laptop, > - pings from the laptop are being seen by other hosts but ARP isn't > being answered in a timely fashion, so other machines on the network > can't respond to the pings. --------------snip--------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message