From owner-freebsd-net@FreeBSD.ORG Sun Jul 30 14:04:49 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A19616A4E2; Sun, 30 Jul 2006 14:04:49 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id B771B43D5C; Sun, 30 Jul 2006 14:04:48 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 45F3A46BBD; Sun, 30 Jul 2006 10:04:48 -0400 (EDT) Date: Sun, 30 Jul 2006 15:04:48 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: net@FreeBSD.org, arch@FreeBSD.org Message-ID: <20060730141642.D16341@fledge.watson.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1695162780-1154268288=:16341" Cc: Subject: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 14:04:49 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1695162780-1154268288=:16341 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 5BOne of the ideas that I, Scott Long, and a few others have been bouncing around for some time is a restructuring of the network interface packet transmission API to reduce the number of locking operations and allow network device drivers increased control of the queueing behavior. Right now, it works something like that following: - When a network protocol wants to transmit, it calls the ifnet's link layer output routine via ifp->if_output() with the ifnet pointer, packet, destination address information, and route information. - The link layer (e.g., ether_output() + ether_output_frame()) encapsulates the packet as necessary, performs a link layer address translation (such as ARP), and hands off to the ifnet driver via a call to IFQ_HANDOFF(), which accepts the ifnet pointer and packet. - The ifnet layer enqueues the packet in the ifnet send queue (ifp->if_snd), and then looks at the driver's IFF_DRV_OACTIVE flag to determine if it needs to "start" output by the driver. If the driver is already active, it doesn't, and otherwise, it does. - The driver dequeues the packet from ifp->if_snd, performs any driver encapsulation and wrapping, and notifies the hardware. In modern hardware, this consists of hooking the data of the packet up to the descriptor ring and notifying the hardware to pick it up via DMA. In order hardware, the driver would perform a series of I/O operations to send the entire packet directly to the card via a system bus. Why change this? A few reasons: - The ifnet layer send queue is becoming decreasingly useful over time. Most modern hardware has a significant number of slots in its transmit descriptor ring, tuned for the performance of the hardware, etc, which is the effective transmit queue in practice. The additional queue depth doesn't increase throughput substantially (if at all) but does consume memory. - On extremely fast hardware (with respect to CPU speed), the queue remains essentially empty, so we pay the cost of enqueueing and dequeuing a packet from an empty queue. - The ifnet send queue is a separately locked object from the device driver, meaning that for a single enqueue/dequeue pair, we pay an extra four lock operations (two for insert, two for remove) per packet. - For synthetic link layer drivers, such as if_vlan, which have no need for queueing at all, the cost of queueing is eliminated. - IFF_DRV_OACTIVE is no longer inspected by the link layer, only by the driver, which helps eliminate a latent race condition involving use of the flag. The proposed change is simple: right now one or more enqueue operations occurs, when a call to ifp->if_start() is made to notify the driver that it may need to do something (if the ACTIVE flag isn't set). In the new world order, the driver is directly passed the mbuf, and may then choose to queue it or otherwise handle it as it sees fit. The immediate practical benefit is clear: if the queueing at the ifnet layer is unnecessary, it is entirely avoided, skipping enqueue, dequeue, and four mutex operations. This applies immediately for VLAN processing, but also means that for modern gigabit cards, the hardware queue (which will be used anyway) is the only queue necessary. There are a few downsides, of course: - For older hardware without its own queueing, the queue is still required -- not only that, but we've now introduced an unconditional function pointer invocation, which on older hardware, is has more significant relative cost than it has on more recent CPUs. - If drivers still require or use a queue, they must now synchronize access to the queue. The obvious choices are to use the ifq lock (and restore the above four lock operations), or to use the driver mutex (and risk higher contention). Right now, if the driver is busy (driver mutex held) then an enqueue is still possible, but with this change and a single mutex protecting the send queue and driver, that is no longer possible. Attached is a patch that maintains the current if_start, but adds if_startmbuf. If a device driver implements if_startmbuf and the global sysctl net.startmbuf_enabled is set to 1, then the if_startmbuf path in the driver will be used. Otherwise, if_start is used. I have modified the if_em driver to implement if_startmbuf also. If there is no packet backlog in the if_snd queue, it directly places the packet in the transmit descriptor ring. If there is a backlog, it uses the if_snd queue protected by driver mutex, rather than a separate ifq mutex. In some basic local micro-benchmarks, I saw a 5% improvement in UDP 0-byte paylod PPS on UP, and a 10% improvement on SMP. I saw a 1.7% performance improvement in the bulk serving of 1k files over HTTP. These are only micro-benchmarks, and reflect a configuration in which the CPU is unable to keep up with the output rate of the 1gbps ethernet card in the device, so reductions in host CPU usage are immediately visible in increased output as the CPU is able to better keep up with the network hardware. Other configurations are also of interest of interesting, especially ones in which the network device is unable to keep up with the CPU, resulting in more queueing. Conceptual review as well as banchmarking, etc, would be most welcome. Robert N M Watson Computer Laboratory University of Cambridge --0-1695162780-1154268288=:16341 Content-Type: TEXT/plain; charset=US-ASCII; name=20060730-if_startmbuf.diff Content-Transfer-Encoding: BASE64 Content-ID: <20060730150448.G16341@fledge.watson.org> Content-Description: Content-Disposition: attachment; filename=20060730-if_startmbuf.diff LS0tIC8vZGVwb3QvdmVuZG9yL2ZyZWVic2Qvc3JjL3N5cy9kZXYvZW0vaWZf ZW0uYwkyMDA2LzA3LzI3IDAwOjQ2OjI0DQorKysgLy9kZXBvdC91c2VyL3J3 YXRzb24vaWZuZXQvc3JjL3N5cy9kZXYvZW0vaWZfZW0uYwkyMDA2LzA3LzI5 IDE4OjQzOjE0DQpAQCAtNzM1LDYgKzczNSw5NSBAQA0KIAlFTV9VTkxPQ0so c2MpOw0KIH0NCiANCitzdGF0aWMgaW50DQorZW1fc3RhcnRtYnVmKHN0cnVj dCBpZm5ldCAqaWZwLCBzdHJ1Y3QgbWJ1ZiAqbSkNCit7DQorICAgICAgICBz dHJ1Y3QgbWJ1ZiAgICAqbV9oZWFkOw0KKyAgICAgICAgc3RydWN0IGVtX3Nv ZnRjICpzYyA9IGlmcC0+aWZfc29mdGM7DQorCXN0cnVjdCBpZnF1ZXVlICpp ZnEgPSAoc3RydWN0IGlmcXVldWUgKikmaWZwLT5pZl9zbmQ7DQorDQorCS8q DQorCSAqIFRocmVlIGNhc2VzOg0KKwkgKg0KKwkgKiAoMSkgSW50ZXJmYWNl IGlzbid0IHJ1bm5pbmcsIGxpbmsgaXMgZG93biwgb3IgaXMgYWxyZWFkeSBh Y3RpdmUsDQorCSAqICAgICBldGMsIHNpbXBseSBlbnF1ZXVlLg0KKwkgKg0K KwkgKiAoMikgVGhlIGludGVyZmFjZSBpcyBydW5uaW5nLCBub3QgdG9vIGJ1 c3ksIGFuZCB3ZSBoYXZlIG5vIG1idWZzDQorCSAqICAgICBpbiB0aGUgaWZu ZXQgc2VuZCBxdWV1ZSwgc28gdHJ5IHRvIGhhbmQgZGlyZWN0bHkgdG8gaGFy ZHdhcmUuDQorCSAqDQorCSAqICgzKSBUaGUgaW50ZXJmYWNlIGlzIHJ1bm5p bmcsIGJ1dCB3ZSBoYXZlIGEgYmFja2xvZy4gIEluc2VydCB0aGUNCisJICog ICAgIGN1cnJlbnQgbWJ1ZiBpbnRvIHRoZSBxdWV1ZSBhbmQgcHJvY2VzcyBp bi1vcmRlciwgaWYgcG9zc2libGUuDQorCSAqLw0KKwlFTV9MT0NLKHNjKTsN CisJaWYgKCgoaWZwLT5pZl9kcnZfZmxhZ3MgJiAoSUZGX0RSVl9SVU5OSU5H fElGRl9EUlZfT0FDVElWRSkpICE9DQorCSAgICBJRkZfRFJWX1JVTk5JTkcp IHx8ICFzYy0+bGlua19hY3RpdmUpIHsNCisJCWlmIChfSUZfUUZVTEwoaWZx KSkgew0KKwkJCV9JRl9EUk9QKGlmcSk7DQorCQkJRU1fVU5MT0NLKHNjKTsN CisJCQltX2ZyZWVtKG0pOw0KKwkJCXJldHVybiAoRU5PQlVGUyk7DQorCQl9 DQorCQlfSUZfRU5RVUVVRShpZnEsIG0pOw0KKwkJRU1fVU5MT0NLKHNjKTsN CisJCXJldHVybiAoMCk7DQorCX0NCisNCisJLyoNCisJICogWFhYUlc6IFZh cmlvdXMgY2FzZXMgaGVyZSBoYXZlIGhpc3RvcmljYWxseSBjb3VudGVkIGFz IHN1Y2Nlc3NlcywNCisJICogYnV0IHBlcmhhcHMgdGhleSBzaG91bGQgcmV0 dXJuIEVOT0JVRlM/DQorCSAqLw0KKwlpZiAoX0lGX1FMRU4oaWZxKSA9PSAw KSB7DQorCSAJLyoNCisJCSAqIGVtX2VuY2FwKCkgY2FuIG1vZGlmeSBvdXIg cG9pbnRlciwgYW5kIG9yIG1ha2UgaXQgTlVMTCBvbg0KKwkJICogZmFpbHVy ZS4gIEluIHRoYXQgZXZlbnQsIHdlIGNhbid0IGVucXVldWUuDQorCQkgKi8N CisJCWlmIChlbV9lbmNhcChzYywgJm0pKSB7DQorCQkJaWYgKG0gPT0gTlVM TCkgew0KKwkJCQlFTV9VTkxPQ0soc2MpOw0KKwkJCQlyZXR1cm4gKDApOw0K KwkJCX0NCisJCQlpZnAtPmlmX2ZsYWdzIHw9IElGRl9EUlZfT0FDVElWRTsN CisJCQlfSUZfUFJFUEVORChpZnEsIG0pOw0KKwkJCUVNX1VOTE9DSyhzYyk7 DQorCQkJcmV0dXJuICgwKTsNCisJCX0NCisJCUJQRl9NVEFQKGlmcCwgbSk7 DQorCQlpZnAtPmlmX3RpbWVyID0gRU1fVFhfVElNRU9VVDsNCisJCUVNX1VO TE9DSyhzYyk7DQorCQlyZXR1cm4gKDApOw0KKwl9DQorDQorCWlmIChfSUZf UUZVTEwoaWZxKSkgew0KKwkJX0lGX0RST1AoaWZxKTsNCisJCUVNX1VOTE9D SyhzYyk7DQorCQltX2ZyZWVtKG0pOw0KKwkJcmV0dXJuIChFTk9CVUZTKTsN CisJfQ0KKwlfSUZfRU5RVUVVRShpZnEsIG0pOw0KKw0KKwl3aGlsZSAoIUlG UV9EUlZfSVNfRU1QVFkoJmlmcC0+aWZfc25kKSkgew0KKwkJSUZRX0RSVl9E RVFVRVVFKCZpZnAtPmlmX3NuZCwgbV9oZWFkKTsNCisJCWlmIChtX2hlYWQg PT0gTlVMTCkNCisJCQlicmVhazsNCisJIAkvKg0KKwkJICogZW1fZW5jYXAo KSBjYW4gbW9kaWZ5IG91ciBwb2ludGVyLCBhbmQgb3IgbWFrZSBpdCBOVUxM IG9uDQorCQkgKiBmYWlsdXJlLiAgSW4gdGhhdCBldmVudCwgd2UgY2FuJ3Qg cmVxdWV1ZS4NCisJCSAqLw0KKwkJaWYgKGVtX2VuY2FwKHNjLCAmbV9oZWFk KSkgew0KKwkJCWlmIChtX2hlYWQgPT0gTlVMTCkNCisJCQkJYnJlYWs7DQor CQkJaWZwLT5pZl9kcnZfZmxhZ3MgfD0gSUZGX0RSVl9PQUNUSVZFOw0KKwkJ CUlGUV9EUlZfUFJFUEVORCgmaWZwLT5pZl9zbmQsIG1faGVhZCk7DQorCQkJ YnJlYWs7DQorCQl9DQorCQlCUEZfTVRBUChpZnAsIG1faGVhZCk7DQorCQlp ZnAtPmlmX3RpbWVyID0gRU1fVFhfVElNRU9VVDsNCisJfQ0KKw0KKwlFTV9V TkxPQ0soc2MpOw0KKwlyZXR1cm4gKDApOw0KK30NCisNCiAvKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqDQogICogIElvY3RsIGVudHJ5IHBvaW50DQogICoN CkBAIC0yMTU0LDYgKzIyNDMsNyBAQA0KIAlpZnAtPmlmX2ZsYWdzID0gSUZG X0JST0FEQ0FTVCB8IElGRl9TSU1QTEVYIHwgSUZGX01VTFRJQ0FTVDsNCiAJ aWZwLT5pZl9pb2N0bCA9IGVtX2lvY3RsOw0KIAlpZnAtPmlmX3N0YXJ0ID0g ZW1fc3RhcnQ7DQorCWlmcC0+aWZfc3RhcnRtYnVmID0gZW1fc3RhcnRtYnVm Ow0KIAlpZnAtPmlmX3dhdGNoZG9nID0gZW1fd2F0Y2hkb2c7DQogCUlGUV9T RVRfTUFYTEVOKCZpZnAtPmlmX3NuZCwgc2MtPm51bV90eF9kZXNjIC0gMSk7 DQogCWlmcC0+aWZfc25kLmlmcV9kcnZfbWF4bGVuID0gc2MtPm51bV90eF9k ZXNjIC0gMTsNCi0tLSAvL2RlcG90L3ZlbmRvci9mcmVlYnNkL3NyYy9zeXMv bmV0L2lmLmMJMjAwNi8wNy8wOSAwNjowNjoyNQ0KKysrIC8vZGVwb3QvdXNl ci9yd2F0c29uL2lmbmV0L3NyYy9zeXMvbmV0L2lmLmMJMjAwNi8wNy8yNiAx NzozMjo1MA0KQEAgLTI0ODYsMjggKzI0ODYsMTExIEBADQogCShpZnAtPmlm X3N0YXJ0KShpZnApOw0KIH0NCiANCitzdGF0aWMgaW50CXN0YXJ0bWJ1Zl9l bmFibGVkOw0KK1NZU0NUTF9JTlQoX25ldCwgT0lEX0FVVE8sIHN0YXJ0bWJ1 Zl9lbmFibGVkLCBDVExGTEFHX1JXLCAmc3RhcnRtYnVmX2VuYWJsZWQsDQor ICAgIDAsICIiKTsNCisNCisvKg0KKyAqIFhYWFJXOg0KKyAqDQorICogaWZf dmFyLmggYW5kIHRoZSBpbnRlcmZhY2UgaGFuZG9mZiBhcmUgc29tZSBvZiB0 aGUgbmFzdGllc3QgcGllY2VzIG9mIHRoZQ0KKyAqIEJTRCBuZXR3b3JrIHN0 YWNrLiAgR2VuZXJhdGlvbnMgb2YgaGFja3MsIHZhcmlhbnRzLCBpbmNvbnNp c3RlbmN5LCBhbmQNCisgKiBmb29saXNobmVzcyBoYXZlIHJlc3VsdGVkIGlu IGVzc2VudGlhbGx5IHVucmVhZGFibGUgY29kZS4gIEZvciBleGFtcGxlLA0K KyAqIHdoeSBhcmUgdGhlIGlmcV8qIGludGVyZmFjZXMgdGhlIG9uZXMgdGhh dCB1c2UgdGhlIGRlZmF1bHQgaWZuZXQgc2VuZA0KKyAqIHF1ZXVlLCBhbmQg dGhlIGlmXyogaW50ZXJmYWNlcyB0aGUgb25lcyB0aGF0IHVzZSBhbHRlcm5h dGl2ZSBxdWV1ZXMsDQorICogcG9zc2libHkgd2l0aCBubyBpZm5ldCBhdCBh bGw/ICBBbmQgd2h5IGRvIHNvbWUgaW50ZXJmYWNlcyByZXR1cm4gZXJybm8N CisgKiB2YWx1ZXMsIGJ1dCBvdGhlcnMgYm9vbGVhbnM/DQorICovDQorDQor LyoNCisgKiBIYW5kb2ZmIGZ1bmN0aW9uIGZvciBzaW1wbGUgaWZuZXQgc3Ry dWN0dXJlcy4gIFJldHVybnMgYW4gZXJybm8gdmFsdWUuDQorICovDQogaW50 DQotaWZfaGFuZG9mZihzdHJ1Y3QgaWZxdWV1ZSAqaWZxLCBzdHJ1Y3QgbWJ1 ZiAqbSwgc3RydWN0IGlmbmV0ICppZnAsIGludCBhZGp1c3QpDQoraWZxX2hh bmRvZmYoc3RydWN0IGlmbmV0ICppZnAsIHN0cnVjdCBtYnVmICptLCBpbnQg YWRqdXN0KQ0KK3sNCisJaW50IGVycm9yLCBsZW4sIHN0YXJ0bWJ1ZjsNCisJ c2hvcnQgbWZsYWdzOw0KKw0KKwlsZW4gPSBtLT5tX3BrdGhkci5sZW47DQor CW1mbGFncyA9IG0tPm1fZmxhZ3M7DQorDQorCWlmIChzdGFydG1idWZfZW5h YmxlZCAmJiBpZnAtPmlmX3N0YXJ0bWJ1ZiAhPSBOVUxMKQ0KKwkJc3RhcnRt YnVmID0gMTsNCisJZWxzZQ0KKwkJc3RhcnRtYnVmID0gMDsNCisNCisJaWYg KHN0YXJ0bWJ1ZikNCisJCWVycm9yID0gaWZwLT5pZl9zdGFydG1idWYoaWZw LCBtKTsNCisJZWxzZQ0KKwkJSUZRX0VOUVVFVUUoJmlmcC0+aWZfc25kLCBt LCBlcnJvcik7DQorCWlmIChlcnJvciA9PSAwKSB7DQorCQlpZnAtPmlmX29i eXRlcyArPSBsZW4gKyBhZGp1c3Q7DQorCQlpZiAobWZsYWdzICYgKE1fQkNB U1R8TV9NQ0FTVCkpDQorCQkJaWZwLT5pZl9vbWNhc3RzKys7DQorCX0NCisJ aWYgKCFzdGFydG1idWYgJiYgKGlmcC0+aWZfZHJ2X2ZsYWdzICYgSUZGX0RS Vl9PQUNUSVZFKSA9PSAwKQ0KKwkJaWZfc3RhcnQoaWZwKTsNCisJcmV0dXJu IChlcnJvcik7DQorfQ0KKw0KKy8qDQorICogSGFuZG9mZiBmdW5jdGlvbiBm b3IgYW4gaWZxdWV1ZSB3aXRoIGFuIG9wdGlvbmFsbHkgYWZmaWxpdGlhdGVk IGlmbmV0Lg0KKyAqIFJldHVybnMgYSBib29sZWFuLg0KKyAqLw0KK2ludA0K K2lmX2hhbmRvZmYoc3RydWN0IGlmcXVldWUgKmlmcSwgc3RydWN0IG1idWYg Km0sIHN0cnVjdCBpZm5ldCAqaWZwLA0KKyAgICBpbnQgYWRqdXN0KQ0KK3sN CisJaW50IGxlbiwgYWN0aXZlLCBzdGFydG1idWYsIHN1Y2Nlc3M7DQorCXNo b3J0IG1mbGFnczsNCisNCisJYWN0aXZlID0gMDsNCisJbGVuID0gbS0+bV9w a3RoZHIubGVuOw0KKwltZmxhZ3MgPSBtLT5tX2ZsYWdzOw0KKw0KKwlpZiAo c3RhcnRtYnVmX2VuYWJsZWQgJiYgaWZwICE9IE5VTEwgJiYgaWZwLT5pZl9z dGFydG1idWYgIT0gTlVMTCkNCisJCXN0YXJ0bWJ1ZiA9IDE7DQorCWVsc2UN CisJCXN0YXJ0bWJ1ZiA9IDA7DQorDQorCWlmIChzdGFydG1idWYpDQorCQlz dWNjZXNzID0gKGlmcC0+aWZfc3RhcnRtYnVmKGlmcCwgbSkgPT0gMCk7DQor CWVsc2Ugew0KKwkJSUZfTE9DSyhpZnEpOw0KKwkJaWYgKF9JRl9RRlVMTChp ZnEpKSB7DQorCQkJX0lGX0RST1AoaWZxKTsNCisJCQltX2ZyZWVtKG0pOw0K KwkJCXN1Y2Nlc3MgPSAwOw0KKwkJfSBlbHNlIHsNCisJCQlfSUZfRU5RVUVV RShpZnEsIG0pOw0KKwkJCXN1Y2Nlc3MgPSAxOw0KKwkJfQ0KKwkJSUZfVU5M T0NLKGlmcSk7DQorCQlpZiAoaWZwICE9IE5VTEwgJiYgIShpZnAtPmlmX2Ry dl9mbGFncyAmIElGRl9EUlZfT0FDVElWRSkpDQorCQkJaWZfc3RhcnQoaWZw KTsNCisJfQ0KKwlpZiAoc3VjY2VzcyAmJiBpZnAgIT0gTlVMTCkgew0KKwkJ aWZwLT5pZl9vYnl0ZXMgKz0gbGVuICsgYWRqdXN0Ow0KKwkJaWYgKG0tPm1f ZmxhZ3MgJiAoTV9CQ0FTVHxNX01DQVNUKSkNCisJCQlpZnAtPmlmX29tY2Fz dHMrKzsNCisJfQ0KKwlyZXR1cm4gKHN1Y2Nlc3MpOw0KK30NCisNCisvKg0K KyAqIFV0aWxpdHkgZnVuY3Rpb24gdG8gYmUgdXNlZCBieSBkZXZpY2UgZHJp dmVycyB3aGVuIHRoZXkgbmVlZCB0byBlbnF1ZXVlIGENCisgKiBwYWNrZXQg dG8gYW4gaW50ZXJmYWNlLXJlbGF0ZWQgcXVldWUgcmF0aGVyIHRoYW4gaW1t ZWRpYXRlbHkgZGVsaXZlcmluZy4NCisgKi8NCitpbnQNCitpZl9zdGFydG1i dWZfZW5xdWV1ZShzdHJ1Y3QgaWZxdWV1ZSAqaWZxLCBzdHJ1Y3QgbWJ1ZiAq bSkNCiB7DQotCWludCBhY3RpdmUgPSAwOw0KIA0KLQlJRl9MT0NLKGlmcSk7 DQogCWlmIChfSUZfUUZVTEwoaWZxKSkgew0KIAkJX0lGX0RST1AoaWZxKTsN Ci0JCUlGX1VOTE9DSyhpZnEpOw0KIAkJbV9mcmVlbShtKTsNCiAJCXJldHVy biAoMCk7DQogCX0NCi0JaWYgKGlmcCAhPSBOVUxMKSB7DQotCQlpZnAtPmlm X29ieXRlcyArPSBtLT5tX3BrdGhkci5sZW4gKyBhZGp1c3Q7DQotCQlpZiAo bS0+bV9mbGFncyAmIChNX0JDQVNUfE1fTUNBU1QpKQ0KLQkJCWlmcC0+aWZf b21jYXN0cysrOw0KLQkJYWN0aXZlID0gaWZwLT5pZl9kcnZfZmxhZ3MgJiBJ RkZfRFJWX09BQ1RJVkU7DQotCX0NCiAJX0lGX0VOUVVFVUUoaWZxLCBtKTsN Ci0JSUZfVU5MT0NLKGlmcSk7DQotCWlmIChpZnAgIT0gTlVMTCAmJiAhYWN0 aXZlKQ0KLQkJaWZfc3RhcnQoaWZwKTsNCiAJcmV0dXJuICgxKTsNCiB9DQog DQotLS0gLy9kZXBvdC92ZW5kb3IvZnJlZWJzZC9zcmMvc3lzL25ldC9pZl92 YXIuaAkyMDA2LzA2LzE5IDIyOjIxOjIyDQorKysgLy9kZXBvdC91c2VyL3J3 YXRzb24vaWZuZXQvc3JjL3N5cy9uZXQvaWZfdmFyLmgJMjAwNi8wNy8zMCAx MDoxMTo1NA0KQEAgLTE2Miw3ICsxNjIsOCBAQA0KIAkJKHN0cnVjdCBpZm5l dCAqLCBzdHJ1Y3Qgc29ja2FkZHIgKiosIHN0cnVjdCBzb2NrYWRkciAqKTsN CiAJc3RydWN0CWlmYWRkcgkqaWZfYWRkcjsJLyogcG9pbnRlciB0byBsaW5r LWxldmVsIGFkZHJlc3MgKi8NCiAJdm9pZAkqaWZfc3BhcmUyOwkJLyogc3Bh cmUgcG9pbnRlciAyICovDQotCXZvaWQJKmlmX3NwYXJlMzsJCS8qIHNwYXJl IHBvaW50ZXIgMyAqLw0KKwlpbnQJKCppZl9zdGFydG1idWYpCQkvKiBlbnF1 ZXVlIGFuZCBzdGFydCBvdXRwdXQgKi8NCisJCShzdHJ1Y3QgaWZuZXQgKiwg c3RydWN0IG1idWYgKik7DQogCWludAlpZl9kcnZfZmxhZ3M7CQkvKiBkcml2 ZXItbWFuYWdlZCBzdGF0dXMgZmxhZ3MgKi8NCiAJdV9pbnQJaWZfc3BhcmVf ZmxhZ3MyOwkvKiBzcGFyZSBmbGFncyAyICovDQogCXN0cnVjdCAgaWZhbHRx IGlmX3NuZDsJCS8qIG91dHB1dCBxdWV1ZSAoaW5jbHVkZXMgYWx0cSkgKi8N CkBAIC0zNzAsMTIgKzM3MSwxNSBAQA0KIAkJbXR4X3VubG9jaygmR2lhbnQp OwkJCQkJXA0KIH0gd2hpbGUgKDApDQogDQoraW50CWlmcV9oYW5kb2ZmKHN0 cnVjdCBpZm5ldCAqaWZwLCBzdHJ1Y3QgbWJ1ZiAqbSwgaW50IGFkanVzdCk7 DQogaW50CWlmX2hhbmRvZmYoc3RydWN0IGlmcXVldWUgKmlmcSwgc3RydWN0 IG1idWYgKm0sIHN0cnVjdCBpZm5ldCAqaWZwLA0KIAkgICAgaW50IGFkanVz dCk7DQoraW50CWlmX3N0YXJ0bWJ1Zl9lbnF1ZXVlKHN0cnVjdCBpZnF1ZXVl ICppZnEsIHN0cnVjdCBtYnVmICptKTsNCisNCisjZGVmaW5lCUlGX0hBTkRP RkZfQURKKGlmcSwgbSwgaWZwLCBhZGopCVwNCisJaWZfaGFuZG9mZigoc3Ry dWN0IGlmcXVldWUgKilpZnEsIG0sIGlmcCwgYWRqKQ0KICNkZWZpbmUJSUZf SEFORE9GRihpZnEsIG0sIGlmcCkJCQlcDQogCWlmX2hhbmRvZmYoKHN0cnVj dCBpZnF1ZXVlICopaWZxLCBtLCBpZnAsIDApDQotI2RlZmluZQlJRl9IQU5E T0ZGX0FESihpZnEsIG0sIGlmcCwgYWRqKQlcDQotCWlmX2hhbmRvZmYoKHN0 cnVjdCBpZnF1ZXVlICopaWZxLCBtLCBpZnAsIGFkaikNCiANCiB2b2lkCWlm X3N0YXJ0KHN0cnVjdCBpZm5ldCAqKTsNCiANCkBAIC00NTksMjUgKzQ2Myw4 IEBADQogI2RlZmluZQlJRlFfSU5DX0RST1BTKGlmcSkJCSgoaWZxKS0+aWZx X2Ryb3BzKyspDQogI2RlZmluZQlJRlFfU0VUX01BWExFTihpZnEsIGxlbikJ KChpZnEpLT5pZnFfbWF4bGVuID0gKGxlbikpDQogDQotLyoNCi0gKiBUaGUg SUZGX0RSVl9PQUNUSVZFIHRlc3Qgc2hvdWxkIHJlYWxseSBvY2N1ciBpbiB0 aGUgZGV2aWNlIGRyaXZlciwgbm90IGluDQotICogdGhlIGhhbmRvZmYgbG9n aWMsIGFzIHRoYXQgZmxhZyBpcyBsb2NrZWQgYnkgdGhlIGRldmljZSBkcml2 ZXIuDQotICovDQotI2RlZmluZQlJRlFfSEFORE9GRl9BREooaWZwLCBtLCBh ZGosIGVycikJCQkJXA0KLWRvIHsJCQkJCQkJCQlcDQotCWludCBsZW47CQkJ CQkJCVwNCi0Jc2hvcnQgbWZsYWdzOwkJCQkJCQlcDQotCQkJCQkJCQkJXA0K LQlsZW4gPSAobSktPm1fcGt0aGRyLmxlbjsJCQkJCVwNCi0JbWZsYWdzID0g KG0pLT5tX2ZsYWdzOwkJCQkJCVwNCi0JSUZRX0VOUVVFVUUoJihpZnApLT5p Zl9zbmQsIG0sIGVycik7CQkJCVwNCi0JaWYgKChlcnIpID09IDApIHsJCQkJ CQlcDQotCQkoaWZwKS0+aWZfb2J5dGVzICs9IGxlbiArIChhZGopOwkJCVwN Ci0JCWlmIChtZmxhZ3MgJiBNX01DQVNUKQkJCQkJXA0KLQkJCShpZnApLT5p Zl9vbWNhc3RzKys7CQkJCVwNCi0JCWlmICgoKGlmcCktPmlmX2Rydl9mbGFn cyAmIElGRl9EUlZfT0FDVElWRSkgPT0gMCkJXA0KLQkJCWlmX3N0YXJ0KGlm cCk7CQkJCQlcDQotCX0JCQkJCQkJCVwNCisjZGVmaW5lCUlGUV9IQU5ET0ZG X0FESihpZnAsIG0sIGFkaiwgZXJyKSBkbyB7CQkJCVwNCisJZXJyID0gaWZx X2hhbmRvZmYoaWZwLCBtLCBhZGopOwkJCQkJXA0KIH0gd2hpbGUgKDApDQog DQogI2RlZmluZQlJRlFfSEFORE9GRihpZnAsIG0sIGVycikJCQkJCVwNCg== --0-1695162780-1154268288=:16341-- From owner-freebsd-net@FreeBSD.ORG Sun Jul 30 18:36:18 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7902B16A4DA; Sun, 30 Jul 2006 18:36:18 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AAF143D46; Sun, 30 Jul 2006 18:36:17 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.199] ([10.0.0.199]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k6UIaH7v011192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Jul 2006 11:36:17 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44CCFC2C.20402@errno.com> Date: Sun, 30 Jul 2006 11:36:28 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Robert Watson References: <20060730141642.D16341@fledge.watson.org> In-Reply-To: <20060730141642.D16341@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, net@freebsd.org Subject: Re: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 18:36:18 -0000 Robert Watson wrote: > > 5BOne of the ideas that I, Scott Long, and a few others have been > bouncing around for some time is a restructuring of the network > interface packet transmission API to reduce the number of locking > operations and allow network device drivers increased control of the > queueing behavior. Right now, it works something like that following: > > - When a network protocol wants to transmit, it calls the ifnet's link > layer > output routine via ifp->if_output() with the ifnet pointer, packet, > destination address information, and route information. > > - The link layer (e.g., ether_output() + ether_output_frame()) encapsulates > the packet as necessary, performs a link layer address translation > (such as > ARP), and hands off to the ifnet driver via a call to IFQ_HANDOFF(), > which > accepts the ifnet pointer and packet. > > - The ifnet layer enqueues the packet in the ifnet send queue > (ifp->if_snd), > and then looks at the driver's IFF_DRV_OACTIVE flag to determine if it > needs > to "start" output by the driver. If the driver is already active, it > doesn't, and otherwise, it does. > > - The driver dequeues the packet from ifp->if_snd, performs any driver > encapsulation and wrapping, and notifies the hardware. In modern > hardware, > this consists of hooking the data of the packet up to the descriptor ring > and notifying the hardware to pick it up via DMA. In order hardware, the > driver would perform a series of I/O operations to send the entire packet > directly to the card via a system bus. > > Why change this? A few reasons: > > - The ifnet layer send queue is becoming decreasingly useful over time. > Most > modern hardware has a significant number of slots in its transmit > descriptor > ring, tuned for the performance of the hardware, etc, which is the > effective > transmit queue in practice. The additional queue depth doesn't increase > throughput substantially (if at all) but does consume memory. > > - On extremely fast hardware (with respect to CPU speed), the queue remains > essentially empty, so we pay the cost of enqueueing and dequeuing a > packet > from an empty queue. > > - The ifnet send queue is a separately locked object from the device > driver, > meaning that for a single enqueue/dequeue pair, we pay an extra four lock > operations (two for insert, two for remove) per packet. > > - For synthetic link layer drivers, such as if_vlan, which have no need for > queueing at all, the cost of queueing is eliminated. > > - IFF_DRV_OACTIVE is no longer inspected by the link layer, only by the > driver, which helps eliminate a latent race condition involving use of > the > flag. > > The proposed change is simple: right now one or more enqueue operations > occurs, when a call to ifp->if_start() is made to notify the driver that > it may need to do something (if the ACTIVE flag isn't set). In the new > world order, the driver is directly passed the mbuf, and may then choose > to queue it or otherwise handle it as it sees fit. The immediate > practical benefit is clear: if the queueing at the ifnet layer is > unnecessary, it is entirely avoided, skipping enqueue, dequeue, and four > mutex operations. This applies immediately for VLAN processing, but > also means that for modern gigabit cards, the hardware queue (which will > be used anyway) is the only queue necessary. > > There are a few downsides, of course: > > - For older hardware without its own queueing, the queue is still > required -- > not only that, but we've now introduced an unconditional function pointer > invocation, which on older hardware, is has more significant relative > cost > than it has on more recent CPUs. > > - If drivers still require or use a queue, they must now synchronize > access to > the queue. The obvious choices are to use the ifq lock (and restore the > above four lock operations), or to use the driver mutex (and risk higher > contention). Right now, if the driver is busy (driver mutex held) > then an > enqueue is still possible, but with this change and a single mutex > protecting the send queue and driver, that is no longer possible. > You're headed in the direction of linux where the handoff goes through a packet scheduling function before it hits the driver. This is equivalent to altq which, as Max pointed out, you didn't mention in this note. But it would be very good to move altq out of the compile-time macros with this. I have a fair amount of experience with the linux model and it works ok. The main complication I've seen is when a driver needs to process multiple queues of packets things get more involved. This is seen in 802.11 drivers where there are two q's, one for data frames and one for management frames. With the current scheme you have two separate queues and the start method handles prioritization by polling the mgt q before the data q. If instead the packet is passed to the start method then it needs to be tagged in some way so the it's prioritized properly. Otherwise you end up with multiple start methods; one per type of packet. I suspect this will be ok but the end result will be that we'll need to add a priority field to mbufs (unless we pass it as an arge to the start method). All this is certainly doable but I think just replacing one mechanism with the other (as you specified) is insufficient. > Attached is a patch that maintains the current if_start, but adds > if_startmbuf. If a device driver implements if_startmbuf and the global > sysctl net.startmbuf_enabled is set to 1, then the if_startmbuf path in > the driver will be used. Otherwise, if_start is used. I have modified > the if_em driver to implement if_startmbuf also. If there is no packet > backlog in the if_snd queue, it directly places the packet in the > transmit descriptor ring. If there is a backlog, it uses the if_snd > queue protected by driver mutex, rather than a separate ifq mutex. > > In some basic local micro-benchmarks, I saw a 5% improvement in UDP > 0-byte paylod PPS on UP, and a 10% improvement on SMP. I saw a 1.7% > performance improvement in the bulk serving of 1k files over HTTP. > These are only micro-benchmarks, and reflect a configuration in which > the CPU is unable to keep up with the output rate of the 1gbps ethernet > card in the device, so reductions in host CPU usage are immediately > visible in increased output as the CPU is able to better keep up with > the network hardware. Other configurations are also of interest of > interesting, especially ones in which the network device is unable to > keep up with the CPU, resulting in more queueing. > > Conceptual review as well as banchmarking, etc, would be most welcome. Why is the startmbuf knob global and not per-interface? Seems like you want to convert drivers one at a time? FWIW the original model was driven by the expectation that you could raise the spl so the tx path was entirely synchronized from above. With the SMPng work we're synchronizing transfer through each control layer. If the driver softc lock (or similar) were exposed to upper layers we could possibly return the "lock the tx path" model we had before and eliminate all the locking your changes target. But that would be a big layering violation and would add significant contention in the SMP case. I think the key observation is that most network hardware today takes packets directly from private queues so the fast path needs to push things down to those queues w/ minimal overhead. This includes devices that implement QoS in h/w w/ multiple queues. Sam From owner-freebsd-net@FreeBSD.ORG Sun Jul 30 19:23:14 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D6F516A4DA; Sun, 30 Jul 2006 19:23:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id D333043D45; Sun, 30 Jul 2006 19:23:13 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 783F646CCD; Sun, 30 Jul 2006 15:23:13 -0400 (EDT) Date: Sun, 30 Jul 2006 20:23:13 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sam Leffler In-Reply-To: <44CCFC2C.20402@errno.com> Message-ID: <20060730200929.J16341@fledge.watson.org> References: <20060730141642.D16341@fledge.watson.org> <44CCFC2C.20402@errno.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, net@freebsd.org Subject: Re: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 19:23:14 -0000 On Sun, 30 Jul 2006, Sam Leffler wrote: > I have a fair amount of experience with the linux model and it works ok. > The main complication I've seen is when a driver needs to process multiple > queues of packets things get more involved. This is seen in 802.11 drivers > where there are two q's, one for data frames and one for management frames. > With the current scheme you have two separate queues and the start method > handles prioritization by polling the mgt q before the data q. If instead > the packet is passed to the start method then it needs to be tagged in some > way so the it's prioritized properly. Otherwise you end up with multiple > start methods; one per type of packet. I suspect this will be ok but the > end result will be that we'll need to add a priority field to mbufs (unless > we pass it as an arge to the start method). > > All this is certainly doable but I think just replacing one mechanism with > the other (as you specified) is insufficient. Hmm. This is something that I had overlooked. I was loosely aware that the if_sl code made use of multiple queues, but was under the impression that the classification to queues occured purely in the SLIP code. Indeed, it does, but structurally, SLIP is split over the link layer (if_output) and driver layer (if_start), which I had forgotten. I take it from your comments that 802.11 also does this, which I was not aware of. I'm a little uncomfortable with our current m_tag model, as it requires significant numbers of additional allocations and frees for each packet, as well as walking link lists. It's fine for occasional discretionary use (i.e., MAC labels), but I worry about cases where it is used with every packet, and we start seeing moderately non-zero numbers of tags on every packet. I think I would be more comfortable with an explicit queue identifier argument to if_start, where the link layer and driver layer agree on how to identify queues. As a straw man, how would the following strike you: int if_startmbuf(struct ifnet *ifp, struct mbuf *m, int ifqid); where for most link layers, the value would be zero, but for some link layer/driver combinations, it would identify a specific queue which the link layer believes the mbuf should be assigned, if implemented? >> Attached is a patch that maintains the current if_start, but adds >> if_startmbuf. If a device driver implements if_startmbuf and the global >> sysctl net.startmbuf_enabled is set to 1, then the if_startmbuf path in the >> driver will be used. Otherwise, if_start is used. I have modified the >> if_em driver to implement if_startmbuf also. If there is no packet backlog >> in the if_snd queue, it directly places the packet in the transmit >> descriptor ring. If there is a backlog, it uses the if_snd queue protected >> by driver mutex, rather than a separate ifq mutex. >> >> In some basic local micro-benchmarks, I saw a 5% improvement in UDP 0-byte >> paylod PPS on UP, and a 10% improvement on SMP. I saw a 1.7% performance >> improvement in the bulk serving of 1k files over HTTP. These are only >> micro-benchmarks, and reflect a configuration in which the CPU is unable to >> keep up with the output rate of the 1gbps ethernet card in the device, so >> reductions in host CPU usage are immediately visible in increased output as >> the CPU is able to better keep up with the network hardware. Other >> configurations are also of interest of interesting, especially ones in >> which the network device is unable to keep up with the CPU, resulting in >> more queueing. >> >> Conceptual review as well as banchmarking, etc, would be most welcome. > > Why is the startmbuf knob global and not per-interface? Seems like you want > to convert drivers one at a time? I may have under-described what I have implemented. The decision is currently made based on two factors: a global frob, and per-interface definition of if_startmbuf being non-zero. The global frob is intended to make it easy to benchmark the difference. I should modify the patch so that the global frob doesn't override the driver back to if_start in the event that if_startmbuf is defined and if_start isn't. The global frob is intended to be removed in the long run, and I intend for us to continue to support both the old and new start methods for the forseeable future, since I don't intend to update every device driver we have to the new method, at least not personally :-). > FWIW the original model was driven by the expectation that you could raise > the spl so the tx path was entirely synchronized from above. With the SMPng > work we're synchronizing transfer through each control layer. If the driver > softc lock (or similar) were exposed to upper layers we could possibly > return the "lock the tx path" model we had before and eliminate all the > locking your changes target. But that would be a big layering violation and > would add significant contention in the SMP case. In some ways, what I propose comes to much the same thing: the change I propose basically delegates the queueing and synchronization decisions to the device driver, which might choose either to use the lock already in the ifq, to use its own lock, or to use some other synchronization strategy. In the case of if_em, I've implemented bypass of software queueing entirely in the common case, but in the event that the hardware ring backs up, then we still fall back to the if_snd queue, only we lock it using the device driver's transmit path mutex. Delegating the synchronization down the stack comes with risks, as device driver writers will inevitably take liberties: on the other hand, it appears that devices are quite diverse, and those liberties have advantages. > I think the key observation is that most network hardware today takes > packets directly from private queues so the fast path needs to push things > down to those queues w/ minimal overhead. This includes devices that > implement QoS in h/w w/ multiple queues. Yes -- however, you're right that the link layer needs to be able to pass more information down. I'd like it to be able to do so without an m_tag allocation, though, which suggests (as you point out) an explicit argument to if_startmbuf. Thanks, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Sun Jul 30 20:40:11 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9008316A4DF; Sun, 30 Jul 2006 20:40:11 +0000 (UTC) (envelope-from prvs=julian=3594eb8d2@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4A9C43D55; Sun, 30 Jul 2006 20:40:10 +0000 (GMT) (envelope-from prvs=julian=3594eb8d2@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.32]) by a50.ironport.com with ESMTP; 30 Jul 2006 13:40:09 -0700 Message-ID: <44CD1928.6000004@elischer.org> Date: Sun, 30 Jul 2006 13:40:08 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <20060730141642.D16341@fledge.watson.org> <44CCFC2C.20402@errno.com> <20060730200929.J16341@fledge.watson.org> In-Reply-To: <20060730200929.J16341@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org, arch@freebsd.org Subject: Re: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 20:40:11 -0000 Robert Watson wrote: > On Sun, 30 Jul 2006, Sam Leffler wrote: > >> I have a fair amount of experience with the linux model and it works >> ok. The main complication I've seen is when a driver needs to process >> multiple queues of packets things get more involved. This is seen in >> 802.11 drivers where there are two q's, one for data frames and one >> for management frames. With the current scheme you have two separate >> queues and the start method handles prioritization by polling the mgt >> q before the data q. If instead the packet is passed to the start >> method then it needs to be tagged in some way so the it's prioritized >> properly. Otherwise you end up with multiple start methods; one per >> type of packet. I suspect this will be ok but the end result will be >> that we'll need to add a priority field to mbufs (unless we pass it >> as an arge to the start method). >> We have a priority tag in netgraph that we use to keep management frames on time in the frame relay code it seems to work ok. >> All this is certainly doable but I think just replacing one mechanism >> with the other (as you specified) is insufficient. > Linux did a big analysis of what was needed at the time they did most of their networking and their buffer scheme (last I looked) had all sorts of fields for this and that. I wonder how it has held up over time? > > Hmm. This is something that I had overlooked. I was loosely aware > that the if_sl code made use of multiple queues, but was under the > impression that the classification to queues occured purely in the > SLIP code. Indeed, it does, but structurally, SLIP is split over the > link layer (if_output) and driver layer (if_start), which I had > forgotten. I take it from your comments that 802.11 also does this, > which I was not aware of. > > I'm a little uncomfortable with our current m_tag model, as it > requires significant numbers of additional allocations and frees for > each packet, as well as walking link lists. It's fine for occasional > discretionary use (i.e., MAC labels), but I worry about cases where it > is used with every packet, and we start seeing moderately non-zero > numbers of tags on every packet. I think I would be more comfortable > with an explicit queue identifier argument to if_start, where the link > layer and driver layer agree on how to identify queues. It would certainly be possible to (for example) have 2 tags preallocated on each mbuf or something but it is hard to know in advance what will be needed. From owner-freebsd-net@FreeBSD.ORG Mon Jul 31 00:59:59 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 470AB16A4E2; Mon, 31 Jul 2006 00:59:59 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1-b.corp.dcn.yahoo.com (mrout1-b.corp.dcn.yahoo.com [216.109.112.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id C898143D46; Mon, 31 Jul 2006 00:59:58 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k6V0xnto001240; Sun, 30 Jul 2006 17:59:50 -0700 (PDT) Date: Mon, 31 Jul 2006 09:59:47 +0900 Message-ID: From: gnn@FreeBSD.org To: Robert Watson In-Reply-To: <20060730141642.D16341@fledge.watson.org> References: <20060730141642.D16341@fledge.watson.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.6.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: arch@FreeBSD.org, net@FreeBSD.org Subject: Re: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 00:59:59 -0000 At Sun, 30 Jul 2006 15:04:48 +0100 (BST), rwatson wrote: > Conceptual review as well as banchmarking, etc, would be most welcome. > I remember talking about this at BSDCan and certainly for high end hardware it seems that it's the right way to go. Later, George From owner-freebsd-net@FreeBSD.ORG Mon Jul 31 01:02:41 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DB2316A4DA; Mon, 31 Jul 2006 01:02:41 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8115843D49; Mon, 31 Jul 2006 01:02:40 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.199] ([10.0.0.199]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k6V12dCh012518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Jul 2006 18:02:39 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44CD56BB.6080405@errno.com> Date: Sun, 30 Jul 2006 18:02:51 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Robert Watson References: <20060730141642.D16341@fledge.watson.org> <44CCFC2C.20402@errno.com> <20060730200929.J16341@fledge.watson.org> In-Reply-To: <20060730200929.J16341@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, net@FreeBSD.org Subject: Re: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 01:02:41 -0000 Robert Watson wrote: > On Sun, 30 Jul 2006, Sam Leffler wrote: > >> I have a fair amount of experience with the linux model and it works >> ok. The main complication I've seen is when a driver needs to process >> multiple queues of packets things get more involved. This is seen in >> 802.11 drivers where there are two q's, one for data frames and one >> for management frames. With the current scheme you have two separate >> queues and the start method handles prioritization by polling the mgt >> q before the data q. If instead the packet is passed to the start >> method then it needs to be tagged in some way so the it's prioritized >> properly. Otherwise you end up with multiple start methods; one per >> type of packet. I suspect this will be ok but the end result will be >> that we'll need to add a priority field to mbufs (unless we pass it as >> an arge to the start method). >> >> All this is certainly doable but I think just replacing one mechanism >> with the other (as you specified) is insufficient. > > Hmm. This is something that I had overlooked. I was loosely aware that > the if_sl code made use of multiple queues, but was under the impression > that the classification to queues occured purely in the SLIP code. > Indeed, it does, but structurally, SLIP is split over the link layer > (if_output) and driver layer (if_start), which I had forgotten. I take > it from your comments that 802.11 also does this, which I was not aware of. There are several issues here but the basic one is, I believe, that we need to provide a per-packet notion of priority or TOS handling. The distinction between mgt frame and data in 802.11 drivers is a kludge; the right thing is to just use priority to get the desired effect. But separately 802.11 is aware of priority for WME so independent of mgt frames priority we still need a way to pass down an AC (access control). For 802.11 I was able to do this by encoding the value in the mbuf flags. If there were a field in the mbuf header this kludge could be removed. For other devices we still want a way to pass around the DiffServ bits or similar so things like vlan priority can be set w/o resorting to tagging each frame. Ideally prioritization work like what's done inside slip should be pulled out. Note that just slapping a field in the mbuf is a start but we also need to think about how to handle it up+down the stack so layers can honor existing priorty and/or filling priority for packets that aren't already classified. > > I'm a little uncomfortable with our current m_tag model, as it requires > significant numbers of additional allocations and frees for each packet, > as well as walking link lists. It's fine for occasional discretionary > use (i.e., MAC labels), but I worry about cases where it is used with > every packet, and we start seeing moderately non-zero numbers of tags on > every packet. I think I would be more comfortable with an explicit > queue identifier argument to if_start, where the link layer and driver > layer agree on how to identify queues. > > As a straw man, how would the following strike you: > > int if_startmbuf(struct ifnet *ifp, struct mbuf *m, int ifqid); > > where for most link layers, the value would be zero, but for some link > layer/driver combinations, it would identify a specific queue which the > link layer believes the mbuf should be assigned, if implemented? mbuf tags are not a solution; too expensive. I think we need something in the mbuf header. > >>> Attached is a patch that maintains the current if_start, but adds >>> if_startmbuf. If a device driver implements if_startmbuf and the >>> global sysctl net.startmbuf_enabled is set to 1, then the >>> if_startmbuf path in the driver will be used. Otherwise, if_start is >>> used. I have modified the if_em driver to implement if_startmbuf >>> also. If there is no packet backlog in the if_snd queue, it directly >>> places the packet in the transmit descriptor ring. If there is a >>> backlog, it uses the if_snd queue protected by driver mutex, rather >>> than a separate ifq mutex. >>> >>> In some basic local micro-benchmarks, I saw a 5% improvement in UDP >>> 0-byte paylod PPS on UP, and a 10% improvement on SMP. I saw a 1.7% >>> performance improvement in the bulk serving of 1k files over HTTP. >>> These are only micro-benchmarks, and reflect a configuration in which >>> the CPU is unable to keep up with the output rate of the 1gbps >>> ethernet card in the device, so reductions in host CPU usage are >>> immediately visible in increased output as the CPU is able to better >>> keep up with the network hardware. Other configurations are also of >>> interest of interesting, especially ones in which the network device >>> is unable to keep up with the CPU, resulting in more queueing. >>> >>> Conceptual review as well as banchmarking, etc, would be most welcome. >> >> Why is the startmbuf knob global and not per-interface? Seems like >> you want to convert drivers one at a time? > > I may have under-described what I have implemented. The decision is > currently made based on two factors: a global frob, and per-interface > definition of if_startmbuf being non-zero. The global frob is intended > to make it easy to benchmark the difference. I should modify the patch > so that the global frob doesn't override the driver back to if_start in > the event that if_startmbuf is defined and if_start isn't. The global > frob is intended to be removed in the long run, and I intend for us to > continue to support both the old and new start methods for the > forseeable future, since I don't intend to update every device driver we > have to the new method, at least not personally :-). > >> FWIW the original model was driven by the expectation that you could >> raise the spl so the tx path was entirely synchronized from above. >> With the SMPng work we're synchronizing transfer through each control >> layer. If the driver softc lock (or similar) were exposed to upper >> layers we could possibly return the "lock the tx path" model we had >> before and eliminate all the locking your changes target. But that >> would be a big layering violation and would add significant contention >> in the SMP case. > > In some ways, what I propose comes to much the same thing: the change I > propose basically delegates the queueing and synchronization decisions > to the device driver, which might choose either to use the lock already > in the ifq, to use its own lock, or to use some other synchronization > strategy. In the case of if_em, I've implemented bypass of software > queueing entirely in the common case, but in the event that the hardware > ring backs up, then we still fall back to the if_snd queue, only we lock > it using the device driver's transmit path mutex. Delegating the > synchronization down the stack comes with risks, as device driver > writers will inevitably take liberties: on the other hand, it appears > that devices are quite diverse, and those liberties have advantages. > >> I think the key observation is that most network hardware today takes >> packets directly from private queues so the fast path needs to push >> things down to those queues w/ minimal overhead. This includes >> devices that implement QoS in h/w w/ multiple queues. > > Yes -- however, you're right that the link layer needs to be able to > pass more information down. I'd like it to be able to do so without an > m_tag allocation, though, which suggests (as you point out) an explicit > argument to if_startmbuf. Or an addition to the mbuf header. Sam From owner-freebsd-net@FreeBSD.ORG Mon Jul 31 08:24:46 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A69916A4DA; Mon, 31 Jul 2006 08:24:46 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54F5643D45; Mon, 31 Jul 2006 08:24:44 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: gvlK0tOCzrqh9CPROFOFPw== X-Cloudmark-Score: 0.000000 [] Received: from [193.217.133.87] (HELO [10.0.0.249]) by mailfe02.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 247590042; Mon, 31 Jul 2006 10:24:40 +0200 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Mon, 31 Jul 2006 10:24:48 +0200 User-Agent: KMail/1.7 References: <20060730141642.D16341@fledge.watson.org> <44CCFC2C.20402@errno.com> <20060730200929.J16341@fledge.watson.org> In-Reply-To: <20060730200929.J16341@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607311024.50537.hselasky@c2i.net> Cc: net@freebsd.org, Robert Watson , arch@freebsd.org Subject: Re: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 08:24:46 -0000 On Sunday 30 July 2006 21:23, Robert Watson wrote: > On Sun, 30 Jul 2006, Sam Leffler wrote: Just a comment while the iron is hot: Maybe you can make the network model safe against detach. Currently I see that the processor can be stuck in routines like "if_start" after that "if_free()" has been called. This can be critical for USB ethernet devices. --HPS From owner-freebsd-net@FreeBSD.ORG Mon Jul 31 09:53:51 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4AAA16A4DE; Mon, 31 Jul 2006 09:53:51 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E48B43D45; Mon, 31 Jul 2006 09:53:51 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 2B16A46B0F; Mon, 31 Jul 2006 05:53:39 -0400 (EDT) Date: Mon, 31 Jul 2006 10:53:39 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Hans Petter Selasky In-Reply-To: <200607311024.50537.hselasky@c2i.net> Message-ID: <20060731105045.X16341@fledge.watson.org> References: <20060730141642.D16341@fledge.watson.org> <44CCFC2C.20402@errno.com> <20060730200929.J16341@fledge.watson.org> <200607311024.50537.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 09:53:51 -0000 On Mon, 31 Jul 2006, Hans Petter Selasky wrote: > On Sunday 30 July 2006 21:23, Robert Watson wrote: >> On Sun, 30 Jul 2006, Sam Leffler wrote: > > Just a comment while the iron is hot: > > Maybe you can make the network model safe against detach. Currently I see > that the processor can be stuck in routines like "if_start" after that > "if_free()" has been called. This can be critical for USB ethernet devices. This is something to fix in the short or long term, but I think we should not try to fix everything at once as there is an awful lot to fix. There are really two stages to fixing the ifnet life cycle, which Brooks has been working on for some time. The first is to make it generally make sense -- he moved ifnet out of the softc, has been working to normalize things generally, (add dead ifnets), etc. The second is to add new types of reference and tear-down magic. What Solaris does here, FYI, is basically add a lock around entering the device driver via their mac layer in order to prevent it from "disappearing" while in use via the ifnet interface. I'm not sure if we want the same solution there or not, but it's worth thinking carefully about. We had (and have) similar problems in a number of other places, where races between consumers of an API and a detach of the provider cause problems. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Mon Jul 31 10:00:29 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02BBC16A4ED; Mon, 31 Jul 2006 10:00:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 921A843D5E; Mon, 31 Jul 2006 10:00:27 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 2083D46B0D; Mon, 31 Jul 2006 06:00:27 -0400 (EDT) Date: Mon, 31 Jul 2006 11:00:26 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sam Leffler In-Reply-To: <44CD56BB.6080405@errno.com> Message-ID: <20060731105438.D16341@fledge.watson.org> References: <20060730141642.D16341@fledge.watson.org> <44CCFC2C.20402@errno.com> <20060730200929.J16341@fledge.watson.org> <44CD56BB.6080405@errno.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, net@FreeBSD.org Subject: Re: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 10:00:29 -0000 On Sun, 30 Jul 2006, Sam Leffler wrote: >> I'm a little uncomfortable with our current m_tag model, as it requires >> significant numbers of additional allocations and frees for each packet, as >> well as walking link lists. It's fine for occasional discretionary use >> (i.e., MAC labels), but I worry about cases where it is used with every >> packet, and we start seeing moderately non-zero numbers of tags on every >> packet. I think I would be more comfortable with an explicit queue >> identifier argument to if_start, where the link layer and driver layer >> agree on how to identify queues. >> >> As a straw man, how would the following strike you: >> >> int if_startmbuf(struct ifnet *ifp, struct mbuf *m, int ifqid); >> >> where for most link layers, the value would be zero, but for some link >> layer/driver combinations, it would identify a specific queue which the >> link layer believes the mbuf should be assigned, if implemented? > > mbuf tags are not a solution; too expensive. I think we need something in > the mbuf header. Agreed. I'm also quite unhappy that we have to use m_tags for VLAN tagging for identical reasons: it basically guarantees at least one extra memory allocation and free, possibly two, for each frame with encapsulation. This is one of the reasons I have been interested in reworking the ethernet link layer parts to increase integration of VLANs into the normal ethernet code, in order to avoid having to unnecessarily use expensive mbuf meta-data. What size field is needed in the mbuf pkthdr to capture all the necessary priority information between driver and link layer? An int? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Mon Jul 31 11:03:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5BC716A515 for ; Mon, 31 Jul 2006 11:03:38 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BE1943DB5 for ; Mon, 31 Jul 2006 11:03:06 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k6VB365o051886 for ; Mon, 31 Jul 2006 11:03:06 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k6VB35N7051882 for freebsd-net@freebsd.org; Mon, 31 Jul 2006 11:03:05 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 31 Jul 2006 11:03:05 GMT Message-Id: <200607311103.k6VB35N7051882@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 11:03:38 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2006/01/30] kern/92552 net A serious bug in most network drivers fro f [2006/02/12] kern/93220 net [inet6] nd6_lookup: failed to add route f o [2006/07/12] kern/100172 net [arp] Transfer of large file fails with h 3 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit o [2006/04/03] kern/95267 net packet drops periodically appear 2 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jul 31 17:05:34 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B42816A4DA; Mon, 31 Jul 2006 17:05:34 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E801843D4C; Mon, 31 Jul 2006 17:05:33 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.6/8.13.6) with ESMTP id k6VH5XKG038776; Mon, 31 Jul 2006 10:05:33 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20060730141642.D16341@fledge.watson.org> Date: Mon, 31 Jul 2006 10:05:33 -0700 (PDT) From: John Polstra To: Robert Watson Cc: arch@freebsd.org, net@freebsd.org Subject: RE: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 17:05:34 -0000 > Attached is a patch that maintains the current if_start, but adds > if_startmbuf. If a device driver implements if_startmbuf and the global > sysctl net.startmbuf_enabled is set to 1, then the if_startmbuf path in the > driver will be used. Otherwise, if_start is used. I have modified the if_em > driver to implement if_startmbuf also. If there is no packet backlog in the > if_snd queue, it directly places the packet in the transmit descriptor ring. > If there is a backlog, it uses the if_snd queue protected by driver mutex, > rather than a separate ifq mutex. I question whether you need a fallback software if_snd queue at all for modern devices such as the Intel and Broadcom gigabit chips. The hardware transmit descriptor rings typically have sizes of the order of 256 descriptors. I think if the ring fills up, you could simply drop the packet with ENOBUFS. That's what happens if the if_snd queue fills up, and its maximum size is comparable to the sizes of modern descriptor rings. It would simplify things quite a bit to eliminate the if_snd queue entirely for such devices. In any case, I'm glad you're looking at making this change. I think it's the right thing to do. John From owner-freebsd-net@FreeBSD.ORG Mon Jul 31 17:08:30 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9482316A4DE; Mon, 31 Jul 2006 17:08:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4FA943D5C; Mon, 31 Jul 2006 17:08:27 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id A8C8346B9B; Mon, 31 Jul 2006 13:08:24 -0400 (EDT) Date: Mon, 31 Jul 2006 18:08:24 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Polstra In-Reply-To: Message-ID: <20060731180643.E71432@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, net@freebsd.org Subject: RE: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 17:08:30 -0000 On Mon, 31 Jul 2006, John Polstra wrote: >> Attached is a patch that maintains the current if_start, but adds >> if_startmbuf. If a device driver implements if_startmbuf and the global >> sysctl net.startmbuf_enabled is set to 1, then the if_startmbuf path in the >> driver will be used. Otherwise, if_start is used. I have modified the >> if_em driver to implement if_startmbuf also. If there is no packet backlog >> in the if_snd queue, it directly places the packet in the transmit >> descriptor ring. If there is a backlog, it uses the if_snd queue protected >> by driver mutex, rather than a separate ifq mutex. > > I question whether you need a fallback software if_snd queue at all for > modern devices such as the Intel and Broadcom gigabit chips. The hardware > transmit descriptor rings typically have sizes of the order of 256 > descriptors. I think if the ring fills up, you could simply drop the packet > with ENOBUFS. That's what happens if the if_snd queue fills up, and its > maximum size is comparable to the sizes of modern descriptor rings. It > would simplify things quite a bit to eliminate the if_snd queue entirely for > such devices. I tend to agree, but implemented full queueing support for if_em to make sure I understood to complexity implications of completely removing queueing from the ifnet side dispatch. I guess an interesting question for us is how we decide what the right threshold is to implement software queuing. Do any if_em cards need software queueing, or do they all have adequate in-hardware queues as is? Entirely cutting the queue code would significantly simplify em_startmbuf. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Mon Jul 31 17:22:03 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14FD316A4DD; Mon, 31 Jul 2006 17:22:03 +0000 (UTC) (envelope-from pete@he.iki.fi) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BB0343D68; Mon, 31 Jul 2006 17:21:57 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from localhost (localhost [127.0.0.1]) by silver.he.iki.fi (Postfix) with ESMTP id 8F85DBBFB; Mon, 31 Jul 2006 20:21:53 +0300 (EEST) Received: from silver.he.iki.fi ([127.0.0.1]) by localhost (silver.he.iki.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZGb9qUh8C8P; Mon, 31 Jul 2006 20:21:50 +0300 (EEST) Received: from [IPv6:2001:670:84:0:2410:b116:d67f:84b] (unknown [IPv6:2001:670:84:0:2410:b116:d67f:84b]) by silver.he.iki.fi (Postfix) with ESMTP; Mon, 31 Jul 2006 20:21:50 +0300 (EEST) Message-ID: <44CE3C2E.80007@he.iki.fi> Date: Mon, 31 Jul 2006 20:21:50 +0300 From: Petri Helenius User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Robert Watson References: <20060731180643.E71432@fledge.watson.org> In-Reply-To: <20060731180643.E71432@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, net@freebsd.org, John Polstra Subject: Re: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 17:22:03 -0000 Robert Watson wrote: > > I tend to agree, but implemented full queueing support for if_em to > make sure I understood to complexity implications of completely > removing queueing from the ifnet side dispatch. I guess an > interesting question for us is how we decide what the right threshold > is to implement software queuing. Do any if_em cards need software > queueing, or do they all have adequate in-hardware queues as is? > Entirely cutting the queue code would significantly simplify > em_startmbuf. Actually most em cards support 4096 descriptors each way. Pete From owner-freebsd-net@FreeBSD.ORG Mon Jul 31 17:34:55 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5914116A4DD; Mon, 31 Jul 2006 17:34:55 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70D6643D46; Mon, 31 Jul 2006 17:34:54 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.6/8.13.6) with ESMTP id k6VHYrdi039191; Mon, 31 Jul 2006 10:34:53 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <44CE3C2E.80007@he.iki.fi> Date: Mon, 31 Jul 2006 10:34:53 -0700 (PDT) From: John Polstra To: Petri Helenius Cc: arch@freebsd.org, net@freebsd.org Subject: Re: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 17:34:55 -0000 On 31-Jul-2006 Petri Helenius wrote: > Robert Watson wrote: >> >> I tend to agree, but implemented full queueing support for if_em to >> make sure I understood to complexity implications of completely >> removing queueing from the ifnet side dispatch. I guess an >> interesting question for us is how we decide what the right threshold >> is to implement software queuing. Do any if_em cards need software >> queueing, or do they all have adequate in-hardware queues as is? >> Entirely cutting the queue code would significantly simplify >> em_startmbuf. > Actually most em cards support 4096 descriptors each way. Yes, even the earliest ones supported 4096 descriptors on paper. In practice, the early chips had bugs that required the entire descriptor ring to fit in a single page of memory. That limited them to 4096/16 = 256 transmit descriptors on x86 hardware at the time. That chip bug was fixed a long time ago, though, and in any case 256 transmit descriptors is a lot for most applications. John From owner-freebsd-net@FreeBSD.ORG Mon Jul 31 19:09:25 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 344DC16A4E2; Mon, 31 Jul 2006 19:09:25 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A27443D60; Mon, 31 Jul 2006 19:09:24 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (pq0v1uefe3wdhse6@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k6VJ9OGn098109; Mon, 31 Jul 2006 12:09:24 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k6VJ9MbM098108; Mon, 31 Jul 2006 12:09:22 -0700 (PDT) (envelope-from jmg) Date: Mon, 31 Jul 2006 12:09:22 -0700 From: John-Mark Gurney To: Robert Watson Message-ID: <20060731190922.GJ96589@funkthat.com> Mail-Followup-To: Robert Watson , John Polstra , arch@freebsd.org, net@freebsd.org References: <20060731180643.E71432@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060731180643.E71432@fledge.watson.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: arch@FreeBSD.org, net@FreeBSD.org, John Polstra Subject: Re: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 19:09:25 -0000 Robert Watson wrote this message on Mon, Jul 31, 2006 at 18:08 +0100: > >I question whether you need a fallback software if_snd queue at all for > >modern devices such as the Intel and Broadcom gigabit chips. The hardware > >transmit descriptor rings typically have sizes of the order of 256 > >descriptors. I think if the ring fills up, you could simply drop the > >packet with ENOBUFS. That's what happens if the if_snd queue fills up, > >and its maximum size is comparable to the sizes of modern descriptor > >rings. It would simplify things quite a bit to eliminate the if_snd queue > >entirely for such devices. > > I tend to agree, but implemented full queueing support for if_em to make > sure I understood to complexity implications of completely removing > queueing from the ifnet side dispatch. I guess an interesting question for > us is how we decide what the right threshold is to implement software > queuing. Do any if_em cards need software queueing, or do they all have > adequate in-hardware queues as is? Entirely cutting the queue code would > significantly simplify em_startmbuf. This work tends to lead to a generic ethernet card framework that I've been thinking about.. where instead of cards doing all the handling of a ring buffer, the card registers a few functions to manipulate a ring buffer (if it has one), and does the necessary work... Though encoding all the different style of ring buffers may be interesting, per packet instead of per segment (if_re)... The other part is to digest the current monolithic lock structure that the ethernet cards have, into three (or four) different locks, tx head, tx tail, rx head & tail... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Tue Aug 1 02:42:27 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67BFA16A4DA for ; Tue, 1 Aug 2006 02:42:27 +0000 (UTC) (envelope-from alexmgarcia@az.netcabo.pt) Received: from waka.cabotva.net (waka.cabotva.net [81.20.240.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81D9A43D55 for ; Tue, 1 Aug 2006 02:42:25 +0000 (GMT) (envelope-from alexmgarcia@az.netcabo.pt) Received: (qmail 13022 invoked from network); 1 Aug 2006 06:30:50 -0000 Received: from unknown (HELO [192.168.0.123]) ([81.20.249.183]) (envelope-sender ) by waka.cabotva.net (qmail-ldap-1.03) with SMTP for ; 1 Aug 2006 06:30:50 -0000 Message-ID: <44CEBFCA.5040505@az.netcabo.pt> Date: Tue, 01 Aug 2006 02:43:22 +0000 From: Alexandre Martins Garcia User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: No DHCPOFFERS received. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 02:42:27 -0000 Hello everybody, I have a modem connected to my freebsd machine in ethernet, so to have a configuration from my ISP I did: hydrus[/home/amg]# dhclient fxp0 DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 11 DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 9 DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 9 DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 15 DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 12 No DHCPOFFERS received. No working leases in persistent database - sleeping. But it gives this error saying No DHCPOFFERS received... Anyone had this problem before? And how to fix this? :-S Regards, Alexandre Garcia From owner-freebsd-net@FreeBSD.ORG Tue Aug 1 08:42:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21F1516A4DE; Tue, 1 Aug 2006 08:42:02 +0000 (UTC) (envelope-from joe@tao.org.uk) Received: from mailhost.tao.org.uk (transwarp.tao.org.uk [87.74.4.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 901AF43D46; Tue, 1 Aug 2006 08:42:01 +0000 (GMT) (envelope-from joe@tao.org.uk) Received: from genius.tao.org.uk (genius.tao.org.uk [87.74.4.41]) by mailhost.tao.org.uk (Postfix) with ESMTP id ACBF65C1B; Tue, 1 Aug 2006 09:42:00 +0100 (BST) Received: by genius.tao.org.uk (Postfix, from userid 100) id 779064073; Tue, 1 Aug 2006 09:41:56 +0100 (BST) Date: Tue, 1 Aug 2006 09:41:56 +0100 From: Josef Karthauser To: Chris Message-ID: <20060801084156.GD3440@genius.tao.org.uk> Mail-Followup-To: Josef Karthauser , Chris , Phil Regnauld , freebsd-net@freebsd.org, freebsd-current@freebsd.org References: <20060628103238.GA815@genius.tao.org.uk> <20060628103949.GJ2005@catpipe.net> <3aaaa3a0606281940k63c77ebfga84a854b2cd4ed84@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RhUH2Ysw6aD5utA4" Content-Disposition: inline In-Reply-To: <3aaaa3a0606281940k63c77ebfga84a854b2cd4ed84@mail.gmail.com> User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Can I pursuade someone to commit this patch? (Re: Multiple IP addresses in a jail.) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 08:42:02 -0000 --RhUH2Ysw6aD5utA4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear current folk, I'm forwarding this thread from the -net list where I asked the question, is it possible to have more than one IP address in a jail? The answer is yes, with Pawel's patch. The question here is can I pursuade anyone to commit this to head and MFC it please? The motivation is simple. I need to run a second SSL web server inside of a jail, however that needs another IP address because SSL is incompatible with HTTP/1.1. Thanks :). Joe On Thu, Jun 29, 2006 at 03:40:33AM +0100, Chris wrote: > On 28/06/06, Phil Regnauld wrote: > >Josef Karthauser (joe) writes: > >> Hi, > >> > >> I've got a jail on a machine running some web stuff and I need to add a > >> second SSL web site to it. This would mean binding another IP address > >> to the jail. Has anyone got a work around for this? > > > > Yes, use Pawel's patches: > > > > http://people.freebsd.org/~pjd/patches/jail_2006012001.patch > > > > Older readme here: > > > > http://garage.freebsd.pl/mijail5.README > > > > >=20 > these patches have been around a while, any reason why its not been > ported to the base code? seems a trivial function to have, single ip > jail is very limiting. >=20 > thanks >=20 > Chris >=20 >=20 --=20 Josef Karthauser (joe@tao.org.uk) http://www.josef-k.net/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An eclectic mix of fact an= d theory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --RhUH2Ysw6aD5utA4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iEYEARECAAYFAkTPE9MACgkQXVIcjOaxUBY+rQCfQSRHymCK7prdcyGdARiodY7V MYoAoNMMIn6U/unXN2G5Sv4QTZa70Dsj =l03C -----END PGP SIGNATURE----- --RhUH2Ysw6aD5utA4-- From owner-freebsd-net@FreeBSD.ORG Tue Aug 1 08:45:26 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0ED9316A4DF; Tue, 1 Aug 2006 08:45:26 +0000 (UTC) (envelope-from regnauld@catpipe.net) Received: from moof.catpipe.net (moof.catpipe.net [195.249.214.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8553B43D46; Tue, 1 Aug 2006 08:45:25 +0000 (GMT) (envelope-from regnauld@catpipe.net) Received: from localhost (moof.catpipe.net [195.249.214.130]) by localhost.catpipe.net (Postfix) with ESMTP id AC8216343B7; Tue, 1 Aug 2006 10:45:23 +0200 (CEST) Received: from moof.catpipe.net ([195.249.214.130]) by localhost (moof.catpipe.net [195.249.214.130]) (amavisd-new, port 10024) with ESMTP id 19674-08; Tue, 1 Aug 2006 10:45:22 +0200 (CEST) Received: from vinyl.catpipe.net (vinyl.catpipe.net [195.249.214.189]) by moof.catpipe.net (Postfix) with ESMTP id B922163439E; Tue, 1 Aug 2006 10:45:22 +0200 (CEST) Received: by vinyl.catpipe.net (Postfix, from userid 1006) id 768F378C31; Tue, 1 Aug 2006 10:40:53 +0200 (CEST) Date: Tue, 1 Aug 2006 10:40:53 +0200 From: Phil Regnauld To: Josef Karthauser , Chris , freebsd-net@freebsd.org, freebsd-current@freebsd.org Message-ID: <20060801084053.GE22731@catpipe.net> References: <20060628103238.GA815@genius.tao.org.uk> <20060628103949.GJ2005@catpipe.net> <3aaaa3a0606281940k63c77ebfga84a854b2cd4ed84@mail.gmail.com> <20060801084156.GD3440@genius.tao.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060801084156.GD3440@genius.tao.org.uk> X-Operating-System: FreeBSD 6.1-PRERELEASE i386 Organization: catpipe Systems ApS User-Agent: Mutt/1.5.11 X-Virus-Scanned: amavisd-new at catpipe.net Cc: Subject: Re: Can I pursuade someone to commit this patch? (Re: Multiple IP addresses in a jail.) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 08:45:26 -0000 Josef Karthauser (joe) writes: > Dear current folk, I'm forwarding this thread from the -net list where I > asked the question, is it possible to have more than one IP address in a > jail? The answer is yes, with Pawel's patch. The question here is can > I pursuade anyone to commit this to head and MFC it please? The > motivation is simple. I need to run a second SSL web server inside of a > jail, however that needs another IP address because SSL is incompatible > with HTTP/1.1. We have been using these patches all the way back since 5-CURRENT and they work very stable for us. I seem to remember that there were some reservations about the way it was being done, but for that matter it wouldn't be the first hack in jail (like u_int32_t for the ip_number in struct jail :) From owner-freebsd-net@FreeBSD.ORG Tue Aug 1 10:37:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF3CD16A4DD for ; Tue, 1 Aug 2006 10:37:11 +0000 (UTC) (envelope-from samspeedu@mail.ru) Received: from mx5.mail.ru (mx5.mail.ru [194.67.23.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 499A243D49 for ; Tue, 1 Aug 2006 10:37:11 +0000 (GMT) (envelope-from samspeedu@mail.ru) Received: from [80.82.44.194] (port=40211 helo=127.0.0.1) by mx5.mail.ru with esmtp id 1G7rcb-0005sM-00 for freebsd-net@freebsd.org; Tue, 01 Aug 2006 14:37:09 +0400 X-AntiVirus: Checked by Dr.Web [version: 4.33, engine: 4.33.0.09273, virus records: 86054, updated: 26.08.2005] Date: Tue, 1 Aug 2006 14:31:18 +0400 From: Andrey Smagin X-Mailer: The Bat! (v1.62r) Organization: DiP X-Priority: 3 (Normal) Message-ID: <9110097806.20060801143118@mail.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: ioctl(SIOCAIFADDR, 85.195.153.121 -> 82.198.6.19): File exists X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: SAMU List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 10:37:11 -0000 Hello All. I have a strange problem with VPN connection. PPP can't set IP address for interface. I use pptpclient by commands: #route add 82.198.6.19 192.168.1.200 #pptpclient 82.198.6.19 vpn If I route to 82.198.6.19 by #route add 80.82.6.0/24 192.168.1.200 connection successfuly esteblish, but after some seconds drop. Because GRE traffic became out via tun0 interface and after recursion overfiow connection terminated(ppp.log.1). Please help, I have no more ideas now. ppp.conf: vpn: set authname myname set authkey mypassword set timeout 0 set ifaddr 0 0 set mtu 1500 add default HISADDR ppp.log: Jul 30 12:22:27 sputnik ppp[1120]: Phase: Using interface: tun0 Jul 30 12:22:27 sputnik ppp[1120]: Phase: deflink: Created in closed state Jul 30 12:22:27 sputnik ppp[1120]: Phase: PPP Started (direct mode). Jul 30 12:22:27 sputnik ppp[1120]: Phase: bundle: Establish Jul 30 12:22:27 sputnik ppp[1120]: Phase: deflink: closed -> opening Jul 30 12:22:27 sputnik ppp[1120]: Phase: deflink: Connected! Jul 30 12:22:27 sputnik ppp[1120]: Phase: deflink: opening -> carrier Jul 30 12:22:28 sputnik ppp[1120]: Phase: deflink: carrier -> lcp Jul 30 12:22:29 sputnik ppp[1120]: Phase: bundle: Authenticate Jul 30 12:22:29 sputnik ppp[1120]: Phase: deflink: his = CHAP 0x05, mine = none Jul 30 12:22:29 sputnik ppp[1120]: Phase: Chap Input: CHALLENGE (19 bytes from satgate) Jul 30 12:22:29 sputnik ppp[1120]: Phase: Chap Output: RESPONSE (myname) Jul 30 12:22:35 sputnik ppp[1120]: Phase: Chap Input: SUCCESS (^E) Jul 30 12:22:35 sputnik ppp[1120]: Phase: deflink: lcp -> open Jul 30 12:22:35 sputnik ppp[1120]: Phase: bundle: Network Jul 30 12:22:35 sputnik ppp[1120]: Phase: deflink: IPV6CP protocol reject closes IPV6CP ! Jul 30 12:22:35 sputnik ppp[1120]: Phase: deflink: IPV6CP protocol reject closes IPV6CP ! Jul 30 12:22:38 sputnik ppp[1120]: Warning: iface add: ioctl(SIOCAIFADDR, 85.195.153.121 -> 82.198.6.19): File exists Jul 30 12:22:38 sputnik ppp[1120]: Error: ipcp_InterfaceUp: unable to set ip address Jul 30 12:22:42 sputnik ppp[1120]: Phase: deflink: IPV6CP protocol reject closes IPV6CP ! Jul 30 12:22:44 sputnik ppp[1120]: Phase: deflink: IPV6CP protocol reject closes IPV6CP ! Jul 30 12:22:45 sputnik ppp[1120]: Phase: deflink: open -> lcp Jul 30 12:22:45 sputnik ppp[1120]: Phase: bundle: Terminate Jul 30 12:22:45 sputnik ppp[1120]: Phase: Signal 15, terminate. Jul 30 12:22:48 sputnik ppp[1120]: Phase: deflink: Disconnected! Jul 30 12:22:48 sputnik ppp[1120]: Phase: deflink: Connect time: 21 secs: 664 octets in, 534 octets out Jul 30 12:22:48 sputnik ppp[1120]: Phase: deflink: 22 packets in, 28 packets out Jul 30 12:22:48 sputnik ppp[1120]: Phase: total 57 bytes/sec, peak 119 bytes/sec on Sun Jul 30 12:22:30 2006 Jul 30 12:22:48 sputnik ppp[1120]: Phase: deflink: lcp -> closed Jul 30 12:22:48 sputnik ppp[1120]: Phase: bundle: Dead Jul 30 12:22:48 sputnik ppp[1120]: Phase: PPP Terminated (normal). ppp.log.1: Jul 31 17:55:05 sputnik ppp[5536]: Phase: Using interface: tun0 Jul 31 17:55:05 sputnik ppp[5536]: Phase: deflink: Created in closed state Jul 31 17:55:05 sputnik ppp[5536]: Phase: PPP Started (direct mode). Jul 31 17:55:05 sputnik ppp[5536]: Phase: bundle: Establish Jul 31 17:55:05 sputnik ppp[5536]: Phase: deflink: closed -> opening Jul 31 17:55:05 sputnik ppp[5536]: Phase: deflink: Connected! Jul 31 17:55:05 sputnik ppp[5536]: Phase: deflink: opening -> carrier Jul 31 17:55:06 sputnik ppp[5536]: Phase: deflink: carrier -> lcp Jul 31 17:55:07 sputnik ppp[5536]: Phase: bundle: Authenticate Jul 31 17:55:07 sputnik ppp[5536]: Phase: deflink: his = CHAP 0x05, mine = none Jul 31 17:55:07 sputnik ppp[5536]: Phase: Chap Input: CHALLENGE (23 bytes from satgate) Jul 31 17:55:07 sputnik ppp[5536]: Phase: Chap Output: RESPONSE (myname) Jul 31 17:55:13 sputnik ppp[5536]: Phase: Chap Input: SUCCESS (^E) Jul 31 17:55:13 sputnik ppp[5536]: Phase: deflink: lcp -> open Jul 31 17:55:13 sputnik ppp[5536]: Phase: bundle: Network Jul 31 17:55:13 sputnik ppp[5536]: Phase: deflink: IPV6CP protocol reject closes IPV6CP ! Jul 31 17:55:13 sputnik ppp[5536]: Phase: deflink: IPV6CP protocol reject closes IPV6CP ! Jul 31 17:55:14 sputnik ppp[5536]: Phase: Signal 15, terminate. Jul 31 17:55:14 sputnik ppp[5536]: Phase: Signal 15, terminate. Jul 31 17:55:14 sputnik ppp[5536]: Phase: deflink: read (0): Got zero bytes Jul 31 17:55:14 sputnik ppp[5536]: Phase: deflink: open -> lcp Jul 31 17:55:14 sputnik ppp[5536]: Phase: bundle: Terminate Jul 31 17:55:14 sputnik ppp[5536]: Phase: deflink: Disconnected! !!!!!!! Jul 31 17:55:14 sputnik ppp[5536]: Phase: deflink: Connect time: 9 secs: 490 octets in, 872018 octets out !!!!!!! Jul 31 17:55:14 sputnik ppp[5536]: Phase: deflink: 15 packets in, 1431 packets out Jul 31 17:55:14 sputnik ppp[5536]: Phase: total 96945 bytes/sec, peak 126 bytes/sec on Mon Jul 31 17:55:08 2006 Jul 31 17:55:14 sputnik ppp[5536]: Phase: deflink: lcp -> closed Jul 31 17:55:14 sputnik ppp[5536]: Phase: bundle: Dead Jul 31 17:55:14 sputnik ppp[5536]: Phase: PPP Terminated (normal). -- Best regards, Andrey mailto:samspeedu@mail.ru From owner-freebsd-net@FreeBSD.ORG Tue Aug 1 10:58:26 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BDAA16A4DA for ; Tue, 1 Aug 2006 10:58:26 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69D6543D45 for ; Tue, 1 Aug 2006 10:58:24 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k71AwOv6092367 for ; Tue, 1 Aug 2006 03:58:24 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k71AwODN092366 for net@freebsd.org; Tue, 1 Aug 2006 03:58:24 -0700 (PDT) (envelope-from rizzo) Date: Tue, 1 Aug 2006 03:58:24 -0700 From: Luigi Rizzo To: net@freebsd.org Message-ID: <20060801035824.A92294@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Cc: Subject: conference announcement: sigcomm2006 - PIsa, 11-15 sep. 2006 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 10:58:26 -0000 [hopefully not off topic, and maybe an interesting chance for FreeBSD-related people who happen to be around to get in touch] just a short reminder that from sep.11-15 the ACM SIGCOMM 2006 conference (and workshops and tutorial) will be held in pisa, with myself playing the general chair for the event. All info can be found at http://www.acm.org/sigcomm/sigcomm2006/ cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-2217.533/600 . via Diotisalvi 2, 56122 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- From owner-freebsd-net@FreeBSD.ORG Tue Aug 1 11:48:14 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5061F16A4DF; Tue, 1 Aug 2006 11:48:14 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Received: from imap.multamedio.de (imap.multamedio.de [62.52.48.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD87443D45; Tue, 1 Aug 2006 11:48:12 +0000 (GMT) (envelope-from owner-freebsd-current@freebsd.org) Received: by imap.multamedio.de (Postfix, from userid 65534) id 4039B882F7; Tue, 1 Aug 2006 15:47:49 +0200 (CEST) Received: from smtp.multamedio.de (smtp.multamedio.de [62.52.48.116]) by imap.multamedio.de (Postfix) with ESMTP id 78128BA2 for ; Tue, 1 Aug 2006 15:47:27 +0200 (CEST) Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by smtp.multamedio.de (Postfix) with ESMTP id 2642D1B48D for ; Tue, 1 Aug 2006 13:38:01 +0200 (CEST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 2101F92DCD; Tue, 1 Aug 2006 11:37:37 +0000 (GMT) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id AC13F16A54A; Tue, 1 Aug 2006 11:37:32 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0ED9316A4DF; Tue, 1 Aug 2006 08:45:26 +0000 (UTC) (envelope-from regnauld@catpipe.net) Received: from moof.catpipe.net (moof.catpipe.net [195.249.214.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8553B43D46; Tue, 1 Aug 2006 08:45:25 +0000 (GMT) (envelope-from regnauld@catpipe.net) Received: from localhost (moof.catpipe.net [195.249.214.130]) by localhost.catpipe.net (Postfix) with ESMTP id AC8216343B7; Tue, 1 Aug 2006 10:45:23 +0200 (CEST) Received: from moof.catpipe.net ([195.249.214.130]) by localhost (moof.catpipe.net [195.249.214.130]) (amavisd-new, port 10024) with ESMTP id 19674-08; Tue, 1 Aug 2006 10:45:22 +0200 (CEST) Received: from vinyl.catpipe.net (vinyl.catpipe.net [195.249.214.189]) by moof.catpipe.net (Postfix) with ESMTP id B922163439E; Tue, 1 Aug 2006 10:45:22 +0200 (CEST) Received: by vinyl.catpipe.net (Postfix, from userid 1006) id 768F378C31; Tue, 1 Aug 2006 10:40:53 +0200 (CEST) Date: Tue, 1 Aug 2006 10:40:53 +0200 From: Phil Regnauld To: Josef Karthauser , Chris , freebsd-net@freebsd.org, freebsd-current@freebsd.org Message-ID: <20060801084053.GE22731@catpipe.net> References: <20060628103238.GA815@genius.tao.org.uk> <20060628103949.GJ2005@catpipe.net> <3aaaa3a0606281940k63c77ebfga84a854b2cd4ed84@mail.gmail.com> <20060801084156.GD3440@genius.tao.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060801084156.GD3440@genius.tao.org.uk> X-Operating-System: FreeBSD 6.1-PRERELEASE i386 Organization: catpipe Systems ApS User-Agent: Mutt/1.5.11 X-Virus-Scanned: amavisd-new at catpipe.net X-Mailman-Approved-At: Tue, 01 Aug 2006 11:37:29 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on imap.multamedio.de X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 X-Bogosity: Ham, tests=bogofilter, spamicity=0.500000, version=1.0.2 Cc: Subject: Re: Can I pursuade someone to commit this patch? (Re: Multiple IP addresses in a jail.) X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 11:48:14 -0000 Josef Karthauser (joe) writes: > Dear current folk, I'm forwarding this thread from the -net list where I > asked the question, is it possible to have more than one IP address in a > jail? The answer is yes, with Pawel's patch. The question here is can > I pursuade anyone to commit this to head and MFC it please? The > motivation is simple. I need to run a second SSL web server inside of a > jail, however that needs another IP address because SSL is incompatible > with HTTP/1.1. We have been using these patches all the way back since 5-CURRENT and they work very stable for us. I seem to remember that there were some reservations about the way it was being done, but for that matter it wouldn't be the first hack in jail (like u_int32_t for the ip_number in struct jail :) _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Aug 1 12:21:55 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D4B716A4DD; Tue, 1 Aug 2006 12:21:55 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCE3C43D69; Tue, 1 Aug 2006 12:21:54 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.6/8.13.6) with ESMTP id k71CLnCd024908 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 1 Aug 2006 08:21:49 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k71CLixZ060991; Tue, 1 Aug 2006 08:21:44 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17615.18264.172863.892776@grasshopper.cs.duke.edu> Date: Tue, 1 Aug 2006 08:21:44 -0400 (EDT) To: Robert Watson In-Reply-To: <20060731105045.X16341@fledge.watson.org> References: <20060730141642.D16341@fledge.watson.org> <44CCFC2C.20402@errno.com> <20060730200929.J16341@fledge.watson.org> <200607311024.50537.hselasky@c2i.net> <20060731105045.X16341@fledge.watson.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: arch@FreeBSD.org, net@FreeBSD.org, freebsd-arch@FreeBSD.org, Hans Petter Selasky Subject: Re: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 12:21:55 -0000 Robert Watson writes: > tear-down magic. What Solaris does here, FYI, is basically add a lock around > entering the device driver via their mac layer in order to prevent it from > "disappearing" while in use via the ifnet interface. I'm not sure if we want At least for GLDv2, this is a reader-writer lock. The transmit and receive paths take a read lock on the device's macinfo (like ifnet) struct, and the detach code takes a write lock. The Solaris driver model does not serialize transmits (or receives), as one might think from reading the above. Drew From owner-freebsd-net@FreeBSD.ORG Tue Aug 1 12:25:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68E0616A4DE; Tue, 1 Aug 2006 12:25:23 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [213.238.47.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8806643D77; Tue, 1 Aug 2006 12:25:21 +0000 (GMT) (envelope-from stb@lassitu.de) Received: (from stb@koef.zs64.net) (authenticated) by koef.zs64.net (8.13.7/8.13.7) with ESMTP id k71COsLE000172 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 1 Aug 2006 14:25:05 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <20060801084156.GD3440@genius.tao.org.uk> References: <20060628103238.GA815@genius.tao.org.uk> <20060628103949.GJ2005@catpipe.net> <3aaaa3a0606281940k63c77ebfga84a854b2cd4ed84@mail.gmail.com> <20060801084156.GD3440@genius.tao.org.uk> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9DABD829-5A98-4811-B5B4-10C1D5A8755B@lassitu.de> Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Tue, 1 Aug 2006 14:25:29 +0200 To: Josef Karthauser X-Mailer: Apple Mail (2.752.2) Cc: Chris , freebsd-net@freebsd.org Subject: Name-based vhost with HTTPS (was Re: Can I pursuade someone to commit this patch?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 12:25:23 -0000 Am 01.08.2006 um 10:41 schrieb Josef Karthauser: > I need to run a second SSL web server inside of a > jail, however that needs another IP address because SSL is > incompatible > with HTTP/1.1. Depending on who you need to sign your certificate, you might be able to use multiple host names with a single IP and a single certificate: http://wiki.cacert.org/wiki/VhostTaskForce Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-net@FreeBSD.ORG Tue Aug 1 12:30:36 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C12416A4EE for ; Tue, 1 Aug 2006 12:30:36 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [213.238.47.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0261543D66 for ; Tue, 1 Aug 2006 12:30:35 +0000 (GMT) (envelope-from stb@lassitu.de) Received: (from stb@koef.zs64.net) (authenticated) by koef.zs64.net (8.13.7/8.13.7) with ESMTP id k71CUN8x000657 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 1 Aug 2006 14:30:33 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <44CEBFCA.5040505@az.netcabo.pt> References: <44CEBFCA.5040505@az.netcabo.pt> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <49A010DB-1595-4C0E-BC08-0CD7B65D7EB9@lassitu.de> Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Tue, 1 Aug 2006 14:30:57 +0200 To: Alexandre Martins Garcia X-Mailer: Apple Mail (2.752.2) Cc: freebsd-net@freebsd.org Subject: Re: No DHCPOFFERS received. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 12:30:36 -0000 Am 01.08.2006 um 04:43 schrieb Alexandre Martins Garcia: > Hello everybody, > I have a modem connected to my freebsd machine in ethernet, so to > have a configuration from my ISP I did: > > hydrus[/home/amg]# dhclient fxp0 ... > No DHCPOFFERS received. > No working leases in persistent database - sleeping. Very clearly, there appears to be no DHCP server on the other end. If you have an *ADSL* modem (instead of the phone or ISDN variety), it is quite likely that your ISP requires you to use PPP over Ethernet (PPPoE). The handbook has a section explaining how to configure your system to connect via this method. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/pppoe.html If you can show us your ISPs instructions for configuring a Windows or Mac system, I'm certain we can help convert those for FreeBSD. HTH, Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-net@FreeBSD.ORG Tue Aug 1 12:30:49 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB52F16A4E0; Tue, 1 Aug 2006 12:30:49 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AC9C43D73; Tue, 1 Aug 2006 12:30:43 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.6/8.13.6) with ESMTP id k71CUgBl026750 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 1 Aug 2006 08:30:42 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k71CUXn6061010; Tue, 1 Aug 2006 08:30:33 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17615.18793.700752.342809@grasshopper.cs.duke.edu> Date: Tue, 1 Aug 2006 08:30:33 -0400 (EDT) To: Robert Watson In-Reply-To: <20060730141642.D16341@fledge.watson.org> References: <20060730141642.D16341@fledge.watson.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: arch@FreeBSD.org, net@FreeBSD.org Subject: Re: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 12:30:49 -0000 Robert Watson writes: > > 5BOne of the ideas that I, Scott Long, and a few others have been bouncing > around for some time is a restructuring of the network interface packet > transmission API to reduce the number of locking operations and allow network > device drivers increased control of the queueing behavior. Right now, it <....> > - The ifnet send queue is a separately locked object from the device driver, > meaning that for a single enqueue/dequeue pair, we pay an extra four lock > operations (two for insert, two for remove) per packet. > Going forward, especially now that we support sun4v CoolThreads hardware, we're going to want to rethink the "single lock" per transmit routine model that most drivers have. The most expensive operation in transmit routines is bus_dmamap_load_mbuf_sg(), especially when there is an IOMMU involved (like on CoolThreads machines) and there is no reason why this needs to be called with a driver's transmit lock held. I have hard data (from Solaris) about how much fine grained locking in a 10GbE driver's transmit routine helps. Drew From owner-freebsd-net@FreeBSD.ORG Tue Aug 1 12:41:07 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A14F16A4DD; Tue, 1 Aug 2006 12:41:07 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE87943D46; Tue, 1 Aug 2006 12:41:06 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.6/8.13.6) with ESMTP id k71Cf5ll028998 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 1 Aug 2006 08:41:05 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k71Cf0NH061024; Tue, 1 Aug 2006 08:41:00 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17615.19420.172545.986872@grasshopper.cs.duke.edu> Date: Tue, 1 Aug 2006 08:41:00 -0400 (EDT) To: Robert Watson In-Reply-To: <20060730141642.D16341@fledge.watson.org> References: <20060730141642.D16341@fledge.watson.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: arch@FreeBSD.org, net@FreeBSD.org Subject: Re: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 12:41:07 -0000 Robert Watson writes: > The immediate practical benefit is > clear: if the queueing at the ifnet layer is unnecessary, it is entirely > avoided, skipping enqueue, dequeue, and four mutex operations. This is indeed nice, but for TCP I think the benefit would be far greater if somebody would PLEASE, PLEASE, PLEASE implement TSO (aka LSO). Consider a 1460 byte mss and 64KB of data that is ready to be sent. With the current model, that is 45 separate calls to if_output(), and 45*4 (queuing) + 45 (tx routine) == 225 mutex operations. Using your model, we're down to 45 mutex operations. Using TSO, we have 4 + 1 == 5 mutex operations with the old model, and 1 with the your model. This is not even considering all the other overhead involved in 45 transmits vs TSO... Just something to think about.. Drew From owner-freebsd-net@FreeBSD.ORG Tue Aug 1 12:48:26 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B51D16A4DD for ; Tue, 1 Aug 2006 12:48:26 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from rune.pobox.com (rune.pobox.com [208.210.124.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0302B43D49 for ; Tue, 1 Aug 2006 12:48:25 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 161D3224C; Tue, 1 Aug 2006 08:48:47 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id BD9AB21A2; Tue, 1 Aug 2006 08:48:45 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1G7tfa-000Mqq-G5; Tue, 01 Aug 2006 13:48:22 +0100 Date: Tue, 1 Aug 2006 13:48:22 +0100 From: Brian Candler To: Alexandre Martins Garcia Message-ID: <20060801124822.GB87804@uk.tiscali.com> References: <44CEBFCA.5040505@az.netcabo.pt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44CEBFCA.5040505@az.netcabo.pt> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: No DHCPOFFERS received. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 12:48:26 -0000 On Tue, Aug 01, 2006 at 02:43:22AM +0000, Alexandre Martins Garcia wrote: > Hello everybody, > I have a modem connected to my freebsd machine in ethernet, so to have a > configuration from my ISP I did: > > hydrus[/home/amg]# dhclient fxp0 > DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 5 > DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 11 > DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 9 > DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 9 > DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 15 > DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 12 > No DHCPOFFERS received. > No working leases in persistent database - sleeping. > > But it gives this error saying No DHCPOFFERS received... > > Anyone had this problem before? And how to fix this? :-S Erm, does your ISP "modem" definitely offer a DHCP service? In that case it would be a "router". Maybe you need to talk PPPoE instead. Have a look at their instructions for configuring a Windows client. If it talks about setting up a dialler, where you enter a username and password, then it's PPPoE. For a FreeBSD PPPoE client, look at /usr/ports/net/mpd HTH, Brian. From owner-freebsd-net@FreeBSD.ORG Tue Aug 1 13:25:30 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E16EA16A4E2; Tue, 1 Aug 2006 13:25:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B85A43D64; Tue, 1 Aug 2006 13:25:30 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E087846C7B; Tue, 1 Aug 2006 09:25:30 -0400 (EDT) Date: Tue, 1 Aug 2006 14:25:30 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrew Gallatin In-Reply-To: <17615.19420.172545.986872@grasshopper.cs.duke.edu> Message-ID: <20060801142056.C64452@fledge.watson.org> References: <20060730141642.D16341@fledge.watson.org> <17615.19420.172545.986872@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, net@FreeBSD.org Subject: Re: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 13:25:31 -0000 On Tue, 1 Aug 2006, Andrew Gallatin wrote: > Robert Watson writes: > > > The immediate practical benefit is clear: if the queueing at the ifnet > > layer is unnecessary, it is entirely avoided, skipping enqueue, dequeue, > > and four mutex operations. > > This is indeed nice, but for TCP I think the benefit would be far greater if > somebody would PLEASE, PLEASE, PLEASE implement TSO (aka LSO). > > Consider a 1460 byte mss and 64KB of data that is ready to be sent. With the > current model, that is 45 separate calls to if_output(), and 45*4 (queuing) > + 45 (tx routine) == 225 mutex operations. > > Using your model, we're down to 45 mutex operations. > > Using TSO, we have 4 + 1 == 5 mutex operations with the old model, and 1 > with the your model. > > This is not even considering all the other overhead involved in 45 transmits > vs TSO... Jack Vogel at Intel has previously talked about having TSO patches for FreeBSD to use with if_em, but was running into stability/correctness problems on 7.x. I e-mailed him a few minutes ago to ask to take a look at the patches. Since I've not yet seen them, I don't know the details of how they work -- I assume that some amount of tweaking is required not just to TCP so that it passes down larger segments, but so that larger segments are used in the right ways, and in keeping with the facilities offered by the underlying interface, especially before a routing decision has been made. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Tue Aug 1 13:27:56 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A138716A4DD; Tue, 1 Aug 2006 13:27:56 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4522243D8C; Tue, 1 Aug 2006 13:27:49 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id CE2D246BB0; Tue, 1 Aug 2006 09:27:49 -0400 (EDT) Date: Tue, 1 Aug 2006 14:27:49 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrew Gallatin In-Reply-To: <17615.18793.700752.342809@grasshopper.cs.duke.edu> Message-ID: <20060801142558.M64452@fledge.watson.org> References: <20060730141642.D16341@fledge.watson.org> <17615.18793.700752.342809@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, net@FreeBSD.org Subject: Re: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 13:27:56 -0000 On Tue, 1 Aug 2006, Andrew Gallatin wrote: > > - The ifnet send queue is a separately locked object from the device driver, > > meaning that for a single enqueue/dequeue pair, we pay an extra four lock > > operations (two for insert, two for remove) per packet. > > Going forward, especially now that we support sun4v CoolThreads hardware, > we're going to want to rethink the "single lock" per transmit routine model > that most drivers have. The most expensive operation in transmit routines > is bus_dmamap_load_mbuf_sg(), especially when there is an IOMMU involved > (like on CoolThreads machines) and there is no reason why this needs to be > called with a driver's transmit lock held. I have hard data (from Solaris) > about how much fine grained locking in a 10GbE driver's transmit routine > helps. Right now, with the exception of locking for the ifnet dispatch queue, I believe our ifnet API pretty much leaves decisions about the nature and granularity of synchronization to the device driver author. The ifnet queue is high on my list to address (hence this thread) -- are there any other parts of our device driver framework that stand in the way from a device driver being modified to support greater parallelism in sending? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Tue Aug 1 13:37:24 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 526AE16A504; Tue, 1 Aug 2006 13:37:24 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D976243D4C; Tue, 1 Aug 2006 13:37:23 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.6/8.13.6) with ESMTP id k71DbNX7011165 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 1 Aug 2006 09:37:23 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k71DbI1c061075; Tue, 1 Aug 2006 09:37:18 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17615.22798.24602.160771@grasshopper.cs.duke.edu> Date: Tue, 1 Aug 2006 09:37:18 -0400 (EDT) To: Robert Watson In-Reply-To: <20060801142056.C64452@fledge.watson.org> References: <20060730141642.D16341@fledge.watson.org> <17615.19420.172545.986872@grasshopper.cs.duke.edu> <20060801142056.C64452@fledge.watson.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: arch@FreeBSD.org, net@FreeBSD.org Subject: Re: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 13:37:24 -0000 Robert Watson writes: > > Jack Vogel at Intel has previously talked about having TSO patches for FreeBSD > to use with if_em, but was running into stability/correctness problems on 7.x. > I e-mailed him a few minutes ago to ask to take a look at the patches. Since > I've not yet seen them, I don't know the details of how they work -- I assume > that some amount of tweaking is required not just to TCP so that it passes > down larger segments, but so that larger segments are used in the right ways, > and in keeping with the facilities offered by the underlying interface, > especially before a routing decision has been made. I'm not sure about what stack changes are required for TSO. I do know that NetBSD has had TSO for roughly 2 years, so they might be a good place to look.. Drew From owner-freebsd-net@FreeBSD.ORG Tue Aug 1 13:48:18 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A811016A4E2; Tue, 1 Aug 2006 13:48:18 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D11143DA2; Tue, 1 Aug 2006 13:47:59 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.6/8.13.6) with ESMTP id k71Dlxbp012757 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 1 Aug 2006 09:47:59 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k71Dlr6g061084; Tue, 1 Aug 2006 09:47:53 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17615.23433.918293.466584@grasshopper.cs.duke.edu> Date: Tue, 1 Aug 2006 09:47:53 -0400 (EDT) To: Robert Watson In-Reply-To: <20060801142558.M64452@fledge.watson.org> References: <20060730141642.D16341@fledge.watson.org> <17615.18793.700752.342809@grasshopper.cs.duke.edu> <20060801142558.M64452@fledge.watson.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: arch@FreeBSD.org, net@FreeBSD.org Subject: Re: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 13:48:18 -0000 Robert Watson writes: > > On Tue, 1 Aug 2006, Andrew Gallatin wrote: > > > > - The ifnet send queue is a separately locked object from the device driver, > > > meaning that for a single enqueue/dequeue pair, we pay an extra four lock > > > operations (two for insert, two for remove) per packet. > > > > Going forward, especially now that we support sun4v CoolThreads hardware, > > we're going to want to rethink the "single lock" per transmit routine model > > that most drivers have. The most expensive operation in transmit routines > > is bus_dmamap_load_mbuf_sg(), especially when there is an IOMMU involved > > (like on CoolThreads machines) and there is no reason why this needs to be > > called with a driver's transmit lock held. I have hard data (from Solaris) > > about how much fine grained locking in a 10GbE driver's transmit routine > > helps. > > Right now, with the exception of locking for the ifnet dispatch queue, I > believe our ifnet API pretty much leaves decisions about the nature and > granularity of synchronization to the device driver author. The ifnet queue > is high on my list to address (hence this thread) -- are there any other parts > of our device driver framework that stand in the way from a device driver > being modified to support greater parallelism in sending? No, not that is directly related to ethernet drivers. However, busdma is a pain. Specifically, I hate that bus_dmamap_load_mbuf_sg() requires a bus_dmamap_t. That means that any fine-grained driver will need to "allocate" a bus_dmamap_t either via bus_dmamap_create(), or by pulling a pre-allocated bus_dmamap_t from a pre-allocated pool. Either will require a lock. Solaris has a similar problem, and I use the pool approach in my Solaris driver. Linux's pci_map_single()/pci_unmap_addr_set()/pci_unmap_len_set() is just so much nicer to use... Drew From owner-freebsd-net@FreeBSD.ORG Tue Aug 1 16:01:49 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8DB616A4DD for ; Tue, 1 Aug 2006 16:01:49 +0000 (UTC) (envelope-from nayak_purushotham@yahoo.com) Received: from web56101.mail.re3.yahoo.com (web56101.mail.re3.yahoo.com [216.252.110.195]) by mx1.FreeBSD.org (Postfix) with SMTP id 358FC43D77 for ; Tue, 1 Aug 2006 16:01:42 +0000 (GMT) (envelope-from nayak_purushotham@yahoo.com) Received: (qmail 73383 invoked by uid 60001); 1 Aug 2006 16:01:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2LKuthmu2HuJ7DbF9Ri/vhELntQ2DItO+dHT6AuC1CZjlNAz8fpS8kRnOEiRRSD7ZD5Wpr5hmHbduaGhlQp4XZL9pChCQsL3KG3PQ9EM7isTmmbnbxEdH50K+THj1gjJKDOstE4rCeornngRROY8cyYZDaYGz3nPT363PEPCuxc= ; Message-ID: <20060801160141.73380.qmail@web56101.mail.re3.yahoo.com> Received: from [209.136.0.128] by web56101.mail.re3.yahoo.com via HTTP; Tue, 01 Aug 2006 09:01:41 PDT Date: Tue, 1 Aug 2006 09:01:41 -0700 (PDT) From: Purushotham Nayak To: freebsd-net@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 01 Aug 2006 17:28:48 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ethernet bridge and dhcpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 16:01:50 -0000 Hi All, I have a routerboard with two ethernet ports (sis0 and sis1). I've been trying top setup a bridge and also run the dhcpd server on it. I've setup sis0 with an IP address and sis1 is just marked up in rc.conf. The bridge seems to work because if I statically assign an IP address to a laptop and connect it to sis1 I can ping the routers IP which is what is assigned to sis0. But the laptop cannot get an IP using DHCP. tcpdumping on sis0 doesn't show me the DHCPREQUEST from the laptop that's coming in through sis1 (but it doesn't show me any traffic during ping request either but that's not broadcast so I guess that's expected). Here's my rc.conf ------------------------------------------------------------------------------------- inetd_enable="YES" ifconfig_sis0="inet 10.1.1.1 netmask 255.255.255.0" ifconfig_sis1="up" ifconfig_ath0="down" gateway_enable="YES" dhcpd_enable="YES" dhcpd_flags="-q" dhcpd_conf=/usr/local/etc/dhcpd.conf" ----------------------------------------------------------------------- And here is my dhcpd.conf ------------------------------------------------------------------------- ddns-update-style ad-hoc; default-lease-time 600; max-lease-time 7200; subnet 10.1.1.0 netmask 255.255.255.0 { range 10.1.1.64 10.1.1.250; option routers 10.1.1.1; } ------------------------------------------------------------------- Can anyone please let me know if there is something I'm doing wrong. nayak --------------------------------- Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail Beta. From owner-freebsd-net@FreeBSD.ORG Wed Aug 2 03:17:05 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2A4816A4E0 for ; Wed, 2 Aug 2006 03:17:05 +0000 (UTC) (envelope-from cybercorecentre@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A1EE43D46 for ; Wed, 2 Aug 2006 03:17:04 +0000 (GMT) (envelope-from cybercorecentre@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so1724206uge for ; Tue, 01 Aug 2006 20:17:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=r5H4Hxa7utmeehihO8/hyj+u4yy5o07dnoj8KDGhlAvED4+u//BlWCTfV/XYhEDyeanvS7Wr06qFrZhjrxMHzmfJZZw1cNs3r0+chm+seZWN/fmbPdAdEg9VkTH3/W7KRolJCEGg97TLmoGPbxIYO58oUzMZKPQCnWMfxX59eTA= Received: by 10.66.216.6 with SMTP id o6mr487807ugg; Tue, 01 Aug 2006 20:17:03 -0700 (PDT) Received: from ?192.0.0.52? ( [62.77.228.138]) by mx.gmail.com with ESMTP id c1sm6221991ugf.2006.08.01.20.17.02; Tue, 01 Aug 2006 20:17:03 -0700 (PDT) Message-ID: <44D01922.2020800@gmail.com> Date: Wed, 02 Aug 2006 05:16:50 +0200 From: Jax User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20060801160141.73380.qmail@web56101.mail.re3.yahoo.com> In-Reply-To: <20060801160141.73380.qmail@web56101.mail.re3.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ethernet bridge and dhcpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 03:17:05 -0000 Purushotham Nayak wrote: > Hi All, > > Hey! Here is a thought, don't setup dhcp server on a bridge. I tried to use firewalling on this but it works differently than in linux where you can control the traffic with --physdev-in -out, you can't determine that which card where the traffic come from and which where it goes, i read something in a handbook but dont remember atm so try to accept all packet on the firewall. You can try to tell dhcpd which interface you want to use but it's possible it won't work. > I have a routerboard with two ethernet ports (sis0 and sis1). I've been trying top setup a bridge and also run the dhcpd server on it. I've setup sis0 with an IP address and sis1 is just marked up in rc.conf. The bridge seems to work because if I statically assign an IP address to a laptop and connect it to sis1 I can ping the routers IP which is what is assigned to sis0. But the laptop cannot get an IP using DHCP. tcpdumping on sis0 doesn't show me the DHCPREQUEST from the laptop that's coming in through sis1 (but it doesn't show me any traffic during ping request either but that's not broadcast so I guess that's expected). > > Here's my rc.conf > > ------------------------------------------------------------------------------------- > inetd_enable="YES" > ifconfig_sis0="inet 10.1.1.1 netmask 255.255.255.0" > broadcast parameter? > ifconfig_sis1="up" > ifconfig_ath0="down" > > gateway_enable="YES" > > this not requied for a bridge > dhcpd_enable="YES" > dhcpd_flags="-q" > try to setup the interface as i told > dhcpd_conf=/usr/local/etc/dhcpd.conf" > ----------------------------------------------------------------------- > > And here is my dhcpd.conf > > ------------------------------------------------------------------------- > ddns-update-style ad-hoc; > default-lease-time 600; > max-lease-time 7200; > > subnet 10.1.1.0 netmask 255.255.255.0 { > range 10.1.1.64 10.1.1.250; > option routers 10.1.1.1; > } > ------------------------------------------------------------------- > > Can anyone please let me know if there is something I'm doing wrong. > > nayak > > I hope it will help. Regards, JaX From owner-freebsd-net@FreeBSD.ORG Wed Aug 2 10:01:26 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8421E16A4E2; Wed, 2 Aug 2006 10:01:26 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F66243D5A; Wed, 2 Aug 2006 10:01:20 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 31436328233; Wed, 2 Aug 2006 20:01:19 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k72A1GmC004061; Wed, 2 Aug 2006 20:01:17 +1000 Date: Wed, 2 Aug 2006 20:01:16 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: John Polstra In-Reply-To: Message-ID: <20060802184349.K90387@delplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, Robert Watson , net@FreeBSD.org Subject: RE: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 10:01:26 -0000 On Mon, 31 Jul 2006, John Polstra wrote: > I question whether you need a fallback software if_snd queue at all > for modern devices such as the Intel and Broadcom gigabit chips. The > hardware transmit descriptor rings typically have sizes of the order > of 256 descriptors. I think if the ring fills up, you could simply > drop the packet with ENOBUFS. That's what happens if the if_snd queue > fills up, and its maximum size is comparable to the sizes of modern > descriptor rings. It would simplify things quite a bit to eliminate > the if_snd queue entirely for such devices. I use an if_snd queue length of about 5000 in my version of the sk driver to work around suckage in ENOBUFS handling. The hardware (*) tx ring size is 512, and tiny packets can be sent in 4 usec, so the hardware queue provides only 2 msec worth of buffering. select(2) for output on sockets doesn't work right, so there is no good way (**) for applications to proceed when a syscall returns ENOBUFS. An extra queue length of 500 provides an extra 20 msec worth of buffering which is usually enough when HZ = 100. (*) I think the sk tx ring is not really in hardware, so it can be much larger than 512, but a length of > 5000 for it seems excessive and caused panics when I tried it. (**) Various bad ways can be found in various versions of ttcp and tools/netrate. They involve either backing off by sleeping (which doesn't keep the tx active unless the sleep granularity is small (which only happens under FreeBSD if HZ is too large)), or by never backing off (which gives busy-waiting). Instead, select() on the output socket should actually work -- it should succeed if the tx queue length is below a low watermark. Apparently, select() on output sockets normally doesn't work, since no version of ttcp that I've looked at (not many) even tries this. Bruce From owner-freebsd-net@FreeBSD.ORG Wed Aug 2 10:13:56 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AE4216A4DA for ; Wed, 2 Aug 2006 10:13:56 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D4FB43D46 for ; Wed, 2 Aug 2006 10:13:55 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail17.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k72ADr3D027012 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 2 Aug 2006 20:13:54 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k72ADqkw001513 for ; Wed, 2 Aug 2006 20:13:52 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k72ADqfT001512 for freebsd-net@freebsd.org; Wed, 2 Aug 2006 20:13:52 +1000 (EST) (envelope-from peter) Date: Wed, 2 Aug 2006 20:13:52 +1000 From: Peter Jeremy To: freebsd-net@freebsd.org Message-ID: <20060802101352.GD713@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u65IjBhB3TIa72Vp" Content-Disposition: inline X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Subject: TCP Retransmit counts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 10:13:56 -0000 --u65IjBhB3TIa72Vp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I often need to move my laptop around the house and have temporary network outages (no wireless). I've noticed that any active TCP connections drop out fairly quickly - some checking with tcpdump shows that there is only 60 seconds between the first transmit attempt and the last re-transmit. This strikes me as excessively short - it's likely to take more time than this for a managed switch or router to reboot. I've previously (5-6 years ago) done some testing on other commercial Unices and got figures of 8-10 minutes - which seems more reasonable. Having had a look at the code, there are TCP_MAXRXTSHIFT (12) re-transmit attempts with exponential back-off based on the calculated RTT. Whilst this is probably reasonable for a WAN link, I would like to extend the timeout on LAN links. Can anyone see any downsides to either increasing TCP_MAXRXTSHIFT (and associated timer arrays) or changing retransmit timeout to having a minimum value (similar but opposite to the tcp_maxpersistidle test in tcp_timer_persist)? --=20 Peter Jeremy --u65IjBhB3TIa72Vp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFE0Hrg/opHv/APuIcRAh9GAJ9tQSEumj1xUE4G8UNe87YAV0eIpwCgms5/ ml7gnGSEEiiuDPKdcdQX26I= =LYyQ -----END PGP SIGNATURE----- --u65IjBhB3TIa72Vp-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 2 13:02:18 2006 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0082A16A55B; Wed, 2 Aug 2006 13:02:17 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5986843D76; Wed, 2 Aug 2006 13:02:09 +0000 (GMT) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k72D29QA051203; Wed, 2 Aug 2006 13:02:09 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k72D28kC051199; Wed, 2 Aug 2006 13:02:08 GMT (envelope-from bms) Date: Wed, 2 Aug 2006 13:02:08 GMT From: Bruce M Simpson Message-Id: <200608021302.k72D28kC051199@freefall.freebsd.org> To: brj@vzletka.net, bms@FreeBSD.org, bms@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: kern/60293: FreeBSD arp poison patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 13:02:18 -0000 Synopsis: FreeBSD arp poison patch State-Changed-From-To: analyzed->suspended State-Changed-By: bms State-Changed-When: Wed Aug 2 13:01:22 UTC 2006 State-Changed-Why: Not ready for prime time, IMHO. Responsible-Changed-From-To: bms->freebsd-net Responsible-Changed-By: bms Responsible-Changed-When: Wed Aug 2 13:01:22 UTC 2006 Responsible-Changed-Why: Disowning it due to lack of cycles/focus. http://www.freebsd.org/cgi/query-pr.cgi?pr=60293 From owner-freebsd-net@FreeBSD.ORG Wed Aug 2 13:07:16 2006 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 729CD16A4DE; Wed, 2 Aug 2006 13:07:16 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D50C43D5C; Wed, 2 Aug 2006 13:07:15 +0000 (GMT) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k72D7FMn051428; Wed, 2 Aug 2006 13:07:15 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k72D7FHl051424; Wed, 2 Aug 2006 13:07:15 GMT (envelope-from bms) Date: Wed, 2 Aug 2006 13:07:15 GMT From: Bruce M Simpson Message-Id: <200608021307.k72D7FHl051424@freefall.freebsd.org> To: bms@FreeBSD.org, bms@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: i386/63721: [if_vr] VT6103 NIC broken since 5.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 13:07:16 -0000 Synopsis: [if_vr] VT6103 NIC broken since 5.2 Responsible-Changed-From-To: bms->freebsd-net Responsible-Changed-By: bms Responsible-Changed-When: Wed Aug 2 13:06:56 UTC 2006 Responsible-Changed-Why: Disowned... reorganising http://www.freebsd.org/cgi/query-pr.cgi?pr=63721 From owner-freebsd-net@FreeBSD.ORG Wed Aug 2 13:24:00 2006 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FF2816A4EF; Wed, 2 Aug 2006 13:24:00 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7474B43D5E; Wed, 2 Aug 2006 13:23:59 +0000 (GMT) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k72DNxpM052704; Wed, 2 Aug 2006 13:23:59 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k72DNxKL052700; Wed, 2 Aug 2006 13:23:59 GMT (envelope-from bms) Date: Wed, 2 Aug 2006 13:23:59 GMT From: Bruce M Simpson Message-Id: <200608021323.k72DNxKL052700@freefall.freebsd.org> To: bms@FreeBSD.org, bms@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: kern/19875: A new protocol family, PF_IPOPTION, to handle IP options at socket interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 13:24:00 -0000 Synopsis: A new protocol family, PF_IPOPTION, to handle IP options at socket interface Responsible-Changed-From-To: bms->freebsd-net Responsible-Changed-By: bms Responsible-Changed-When: Wed Aug 2 13:23:39 UTC 2006 Responsible-Changed-Why: ENOTIME http://www.freebsd.org/cgi/query-pr.cgi?pr=19875 From owner-freebsd-net@FreeBSD.ORG Wed Aug 2 13:29:01 2006 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DC8D16A4DE; Wed, 2 Aug 2006 13:29:01 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C989E43D46; Wed, 2 Aug 2006 13:29:00 +0000 (GMT) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k72DT0R3052845; Wed, 2 Aug 2006 13:29:00 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k72DT0B2052841; Wed, 2 Aug 2006 13:29:00 GMT (envelope-from bms) Date: Wed, 2 Aug 2006 13:29:00 GMT From: Bruce M Simpson Message-Id: <200608021329.k72DT0B2052841@freefall.freebsd.org> To: bms@FreeBSD.org, bms@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: kern/31686: Problem with the timestamp option when flag equals zero X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 13:29:01 -0000 Synopsis: Problem with the timestamp option when flag equals zero Responsible-Changed-From-To: bms->freebsd-net Responsible-Changed-By: bms Responsible-Changed-When: Wed Aug 2 13:28:14 UTC 2006 Responsible-Changed-Why: Back to the free pool. http://www.freebsd.org/cgi/query-pr.cgi?pr=31686 From owner-freebsd-net@FreeBSD.ORG Wed Aug 2 13:31:18 2006 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E866C16A4DA; Wed, 2 Aug 2006 13:31:18 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A03D543D46; Wed, 2 Aug 2006 13:31:18 +0000 (GMT) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k72DVIsR054516; Wed, 2 Aug 2006 13:31:18 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k72DVI4E054512; Wed, 2 Aug 2006 13:31:18 GMT (envelope-from bms) Date: Wed, 2 Aug 2006 13:31:18 GMT From: Bruce M Simpson Message-Id: <200608021331.k72DVI4E054512@freefall.freebsd.org> To: bms@FreeBSD.org, bms@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: conf/23063: [PATCH] for static ARP tables in rc.network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 13:31:19 -0000 Synopsis: [PATCH] for static ARP tables in rc.network Responsible-Changed-From-To: bms->freebsd-net Responsible-Changed-By: bms Responsible-Changed-When: Wed Aug 2 13:30:40 UTC 2006 Responsible-Changed-Why: ENOTIME. If big ARP changes happen, then this should probably be taken on again and looked at after those changes happen. Also the rcNG system has been taken since these changes were submitted. http://www.freebsd.org/cgi/query-pr.cgi?pr=23063 From owner-freebsd-net@FreeBSD.ORG Wed Aug 2 21:22:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EBC616A4DF for ; Wed, 2 Aug 2006 21:22:12 +0000 (UTC) (envelope-from mark@immermail.com) Received: from proof.pobox.com (proof.pobox.com [207.106.133.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id A77CB43D55 for ; Wed, 2 Aug 2006 21:22:11 +0000 (GMT) (envelope-from mark@immermail.com) Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 95EDD29D55 for ; Wed, 2 Aug 2006 17:22:32 -0400 (EDT) Received: from [172.16.1.33] (unknown [71.141.151.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id F30326749A for ; Wed, 2 Aug 2006 17:22:31 -0400 (EDT) Message-ID: <44D11785.1080107@immermail.com> Date: Wed, 02 Aug 2006 14:22:13 -0700 From: mark User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: netgraph with 10Gig interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 21:22:12 -0000 I cannot get netgraph to work with 10Gig interfaces on FreeBSD 6.1. No errors, but no traffic seen. Config works with 1 Gig interfaces. Anyone know why? ngctl mkpeer . eiface hook ether ngctl mkpeer ngeth0: one2many lower one ngctl connect $if1: ngeth0:lower lower many0 ngctl connect $if2: ngeth0:lower lower many1 ifconfig ngeth0 -arp up Thanks. From owner-freebsd-net@FreeBSD.ORG Wed Aug 2 23:07:34 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D82316A4DF for ; Wed, 2 Aug 2006 23:07:34 +0000 (UTC) (envelope-from fbsd@synoptic.org) Received: from gort.synoptic.org (gort.synoptic.org [216.254.17.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CDF343D45 for ; Wed, 2 Aug 2006 23:07:34 +0000 (GMT) (envelope-from fbsd@synoptic.org) Received: by gort.synoptic.org (Postfix, from userid 1000) id 1A20F6352811; Wed, 2 Aug 2006 16:07:34 -0700 (PDT) Date: Wed, 2 Aug 2006 16:07:34 -0700 From: Matthew Hudson To: freebsd-net@freebsd.org Message-ID: <20060802230734.GA75240@gort.synoptic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Can't create proxy-arp entries for subnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 23:07:34 -0000 Hello everybody, I believe I may have stumbled across a bug in the arp program and the reproduction is simple (and should be easy to verify) so I'll just jump to the point. This is on 6.1-RELEASE-p3 i386 I discovered this while trying to create proxy-arp entries for a subnet of a network I was directly connected to. The smaller subnet is forwarded over a tun interface. Basically, the network plugged into fxp0 is 2.2.2.0/24 however there's a small subnet (2.2.2.8/30) that lives on the other side of the tun2 interface and I want to proxy arp for it so other hosts on the wire can reach it without static routes. Basic repro instructions: # dd if=/dev/zero of=/dev/tun count=0 ## create new tun interface # ifconfig tun2 1.1.1.1 1.1.1.2 # ifconfig fxp0 2.2.2.1/24 # route add 2.2.2.8/30 1.1.1.2 add net 2.2.2.8: gateway 1.1.1.2 # arp -s 2.2.2.9 auto pub using interface fxp0 for proxy with address 00:90:27:a5:cd:33 cannot intuit interface index and type for 2.2.2.9 The "cannot intuit interace index and type" is the failure. The workaround is to add the static arp entries before you add the subnet route, however it seems like this is still a bug. Can anyone else verify that this shouldn't be? Here's a more detailed log of the reproduction along with comments. Comments are preceded by ']]' ---- script(1) start ---- # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.48.254 UGS 0 3066 em0 127.0.0.1 127.0.0.1 UH 0 0 lo0 192.168.48 link#2 UC 0 0 em0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 ff01:4::/32 ::1 UC lo0 ff02::%lo0/32 ::1 UC lo0 ]] simple enough. Note that fxp0 is completely unconfigured. ]] The network on em0 should be entirely unrelated here but is shown ]] to illustrate 'nothing up my sleeve' # ifconfig -a fxp0: flags=8843 mtu 1500 options=8 ether 00:90:27:a5:cd:33 media: Ethernet autoselect (100baseTX ) status: active em0: flags=8843 mtu 1500 options=b inet 192.168.48.154 netmask 0xffffff00 broadcast 192.168.48.255 ether 00:08:74:38:3f:ef media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 tun2: flags=8051 mtu 1500 ]] Again, we see fxp0 is unconfigured. tun2 is unconfigured as well. # ifconfig tun2 1.1.1.1 1.1.1.2 # ifconfig fxp0 2.2.2.1/24 # route add 2.2.2.8/30 1.1.1.2 add net 2.2.2.8: gateway 1.1.1.2 ]] We configure an address on tun2, fxp0, and set up the /30 subnet to ]] route over tun2. # arp -s 2.2.2.9 auto pub using interface fxp0 for proxy with address 00:90:27:a5:cd:33 cannot intuit interface index and type for 2.2.2.9 ]] Here's the problem. ]] "cannot intuit interface index and type for 2.2.2.9" # route delete 2.2.2.8/30 delete net 2.2.2.8 # arp -s 2.2.2.9 auto pub using interface fxp0 for proxy with address 00:90:27:a5:cd:33 ]] However if we delete the route, we can add the proxy arp no problem. # route add 2.2.2.8/30 1.1.1.2 add net 2.2.2.8: gateway 1.1.1.2 ]] We can even add the route *back* once the proxy arp is created. # arp -d 2.2.2.9 2.2.2.9 (2.2.2.9) deleted # arp -s 2.2.2.9 auto pub using interface fxp0 for proxy with address 00:90:27:a5:cd:33 cannot intuit interface index and type for 2.2.2.9 ]] However if we try to delete the proxy arp and then re-create it, no dice. ]] note the broken-symmetry. ---- script(1) end ---- Cheers, Matthew From owner-freebsd-net@FreeBSD.ORG Thu Aug 3 01:02:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF85F16A4DD for ; Thu, 3 Aug 2006 01:02:22 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36CBB43D45 for ; Thu, 3 Aug 2006 01:02:22 +0000 (GMT) (envelope-from nikolas.britton@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so842240nfc for ; Wed, 02 Aug 2006 18:02:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=AHH/4z4c7FgdFi6Wqv9ZbUEkMxbk+VlW+qtCkdYEsEWSfhEpaile20MScrCrOoHhDtgKRGM1b4bF+B2PL8zGcKXRknn8sGiEk+6DlpwfAaO+OdluOWtda2jy3UPLg0ugagSNMO6Unn/3FIflNWrxUMDFr6jzVLmjrTbkbsqs0ig= Received: by 10.78.156.6 with SMTP id d6mr566103hue; Wed, 02 Aug 2006 18:02:20 -0700 (PDT) Received: by 10.78.143.11 with HTTP; Wed, 2 Aug 2006 18:02:20 -0700 (PDT) Message-ID: Date: Wed, 2 Aug 2006 18:02:20 -0700 From: "Nikolas Britton" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Intel PRO/1000 EB, 82563EB and 82564EB. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 01:02:22 -0000 When is FreeBSD going to support the 82563EB/82564EB? Do we have anything yet? http://www.intel.com/design/network/products/lan/docs/82563_64_docs.htm -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ From owner-freebsd-net@FreeBSD.ORG Thu Aug 3 04:17:05 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34A7B16A4DA for ; Thu, 3 Aug 2006 04:17:05 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95CE843D46 for ; Thu, 3 Aug 2006 04:17:04 +0000 (GMT) (envelope-from nikolas.britton@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so889126nfc for ; Wed, 02 Aug 2006 21:17:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CNZiTNUtqGbXqcNxpJJ16eAiMpFG5HsRBlkA/BtPDKsV7aqHTpOzyhdgc2WVQjdr5j14LfaCWQHRpKRZHAPY5Y/1/6+uWPuw8th2MxJ2XaND+5abqo0pLOhZm7O2CkDwOTtuuwVwISIpxVBZLGWASYTaoCrzlQSCa4rmAqpkcv0= Received: by 10.78.193.19 with SMTP id q19mr612311huf; Wed, 02 Aug 2006 21:17:03 -0700 (PDT) Received: by 10.78.143.11 with HTTP; Wed, 2 Aug 2006 21:17:03 -0700 (PDT) Message-ID: Date: Wed, 2 Aug 2006 23:17:03 -0500 From: "Nikolas Britton" To: "Deuskar, Prafulla" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-net@freebsd.org Subject: Re: Intel PRO/1000 EB, 82563EB and 82564EB. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 04:17:05 -0000 On 8/2/06, Deuskar, Prafulla wrote: > > > >When is FreeBSD going to support the 82563EB/82564EB? Do we have > anything > >yet? > > > >http://www.intel.com/design/network/products/lan/docs/82563_64_docs.htm > > > > Have you tried the 6.0.5 driver from Intel's website? > > http://downloadfinder.intel.com/scripts-df-external/Detail_Desc.aspx?str > State=LIVE&ProductID=1070&DwnldID=10957&lang=eng > > In general you will find latest drivers on Intel's website. > No I have not tired this, I didn't even know Intel made FreeBSD drivers... I went looking on the site early but couldn't find anything. Do you know if they are any good?... I'll check it out, thanks. -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ From owner-freebsd-net@FreeBSD.ORG Thu Aug 3 04:26:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84BED16A4DA for ; Thu, 3 Aug 2006 04:26:20 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from H43.C18.B96.tor.eicat.ca (H43.C18.B96.tor.eicat.ca [66.96.18.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8804643D70 for ; Thu, 3 Aug 2006 04:26:11 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from [127.0.0.1] (desktop.home.local [172.16.0.200]) by H43.C18.B96.tor.eicat.ca (Postfix) with ESMTP id 2F3DD1146C; Thu, 3 Aug 2006 00:25:40 -0400 (EDT) Message-ID: <44D17AF5.5050909@rogers.com> Date: Thu, 03 Aug 2006 00:26:29 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Nikolas Britton References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SpamToaster-Information: This messages has been scanned by SpamToaster http://www.digitalprogression.ca X-SpamToaster: Found to be clean X-SpamToaster-SpamCheck: not spam, SpamAssassin (not cached, score=-2.435, required 3.5, ALL_TRUSTED -1.80, AWL 0.06, BAYES_00 -2.60, DK_POLICY_SIGNSOME 0.00, DNS_FROM_RFC_ABUSE 0.20, DNS_FROM_RFC_POST 1.71) X-SpamToaster-From: mikej@rogers.com X-Spam-Status: No Cc: freebsd-net@freebsd.org, "Deuskar, Prafulla" Subject: Re: Intel PRO/1000 EB, 82563EB and 82564EB. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 04:26:20 -0000 Nikolas Britton wrote: > No I have not tired this, I didn't even know Intel made FreeBSD > drivers... I went looking on the site early but couldn't find > anything. Do you know if they are any good?... I'll check it out, > thanks. It is essentially the same driver that FreeBSD uses, but the one provided by Intel may be newer. From owner-freebsd-net@FreeBSD.ORG Thu Aug 3 05:50:53 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36AA516A4DA for ; Thu, 3 Aug 2006 05:50:53 +0000 (UTC) (envelope-from fbsd-net@mawer.org) Received: from mail-ihug.icp-qv1-irony6.iinet.net.au (ihug-mail.icp-qv1-irony6.iinet.net.au [203.59.1.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F60343D46 for ; Thu, 3 Aug 2006 05:50:49 +0000 (GMT) (envelope-from fbsd-net@mawer.org) Received: from 203-206-173-235.perm.iinet.net.au (HELO [127.0.0.1]) ([203.206.173.235]) by mail-ihug.icp-qv1-irony6.iinet.net.au with ESMTP; 03 Aug 2006 13:50:49 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,206,1151856000"; d="scan'208"; a="401261820:sNHT34678952" Message-ID: <44D18EAF.1010907@mawer.org> Date: Thu, 03 Aug 2006 15:50:39 +1000 From: Antony Mawer User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Plans to port OpenBSD trunk(4)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 05:50:53 -0000 Hi list, Is there any interest or plans underway to port the trunk(4) feature from OpenBSD? OpenBSD's trunk(4) appears to be exactly what I'm looking for, but there doesn't appear to be anything I can find on a port to FreeBSD. http://www.openbsd.org/cgi-bin/man.cgi?query=trunk&sektion=4 I've been tasked with setting up a system that will have 2x Intel Pro/1000 network adapters linked to an HP ProCurve 5300XL modular switch. I stumbled across ng_fec(4), but it refers explicitly to Cisco Fast EtherChannel; some information suggests that this is supported by the HP switch... would using Netgraph with ng_fec achieve the same end result? Has anyone successfully used it as such? Cheers Antony From owner-freebsd-net@FreeBSD.ORG Thu Aug 3 07:00:35 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0496116A4ED for ; Thu, 3 Aug 2006 07:00:35 +0000 (UTC) (envelope-from ru@FreeBSD.org.ua) Received: from frdp.freebsd.org.ua (82.193.106.18.ipnet.kiev.ua [82.193.106.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0B6943D5E for ; Thu, 3 Aug 2006 07:00:22 +0000 (GMT) (envelope-from ru@FreeBSD.org.ua) Received: from frdp.freebsd.org.ua (localhost [127.0.0.1]) by frdp.freebsd.org.ua (8.13.6/8.13.6) with ESMTP id k7372SDW027765; Thu, 3 Aug 2006 10:02:28 +0300 (EEST) (envelope-from ru@FreeBSD.org.ua) Received: (from ru@localhost) by frdp.freebsd.org.ua (8.13.6/8.13.6/Submit) id k7372SLi027764; Thu, 3 Aug 2006 10:02:28 +0300 (EEST) (envelope-from ru) Date: Thu, 3 Aug 2006 10:02:28 +0300 From: Ruslan Ermilov To: Antony Mawer Message-ID: <20060803070228.GD87627@freebsd.org.ua> References: <44D18EAF.1010907@mawer.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NtwzykIc2mflq5ck" Content-Disposition: inline In-Reply-To: <44D18EAF.1010907@mawer.org> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-net@freebsd.org Subject: Re: Plans to port OpenBSD trunk(4)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 07:00:35 -0000 --NtwzykIc2mflq5ck Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 03, 2006 at 03:50:39PM +1000, Antony Mawer wrote: > Hi list, >=20 > Is there any interest or plans underway to port the trunk(4) feature=20 > from OpenBSD? OpenBSD's trunk(4) appears to be exactly what I'm looking= =20 > for, but there doesn't appear to be anything I can find on a port to=20 > FreeBSD. >=20 > http://www.openbsd.org/cgi-bin/man.cgi?query=3Dtrunk&sektion=3D4 >=20 > I've been tasked with setting up a system that will have 2x Intel=20 > Pro/1000 network adapters linked to an HP ProCurve 5300XL modular switch. >=20 > I stumbled across ng_fec(4), but it refers explicitly to Cisco Fast=20 > EtherChannel; some information suggests that this is supported by the HP= =20 > switch... would using Netgraph with ng_fec achieve the same end result?= =20 > Has anyone successfully used it as such? >=20 ng_one2many(4) can do it; search for "bonding" in the FreeBSD mail archives for details. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --NtwzykIc2mflq5ck Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFE0Z+EqRfpzJluFF4RAld0AJ9mcQiyLew/1StGhO81W7KQFbeXkQCfdsAX PwQxfVRzOqEAv2k1AyAIla8= =VrUj -----END PGP SIGNATURE----- --NtwzykIc2mflq5ck-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 3 11:06:39 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAD2916A4E8; Thu, 3 Aug 2006 11:06:39 +0000 (UTC) (envelope-from joe@tao.org.uk) Received: from mailhost.tao.org.uk (transwarp.tao.org.uk [87.74.4.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECC2A43DDB; Thu, 3 Aug 2006 11:05:33 +0000 (GMT) (envelope-from joe@tao.org.uk) Received: from genius.tao.org.uk (genius.tao.org.uk [87.74.4.41]) by mailhost.tao.org.uk (Postfix) with ESMTP id AC72E5C1B; Thu, 3 Aug 2006 12:05:30 +0100 (BST) Received: by genius.tao.org.uk (Postfix, from userid 100) id 65B5C4054; Thu, 3 Aug 2006 12:05:25 +0100 (BST) Date: Thu, 3 Aug 2006 12:05:25 +0100 From: Josef Karthauser To: Phil Regnauld Message-ID: <20060803110525.GE804@genius.tao.org.uk> Mail-Followup-To: Josef Karthauser , Phil Regnauld , Chris , freebsd-net@freebsd.org, freebsd-current@freebsd.org References: <20060628103238.GA815@genius.tao.org.uk> <20060628103949.GJ2005@catpipe.net> <3aaaa3a0606281940k63c77ebfga84a854b2cd4ed84@mail.gmail.com> <20060801084156.GD3440@genius.tao.org.uk> <20060801084053.GE22731@catpipe.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="brEuL7wsLY8+TuWz" Content-Disposition: inline In-Reply-To: <20060801084053.GE22731@catpipe.net> User-Agent: Mutt/1.5.11 Cc: Chris , freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Can I pursuade someone to commit this patch? (Re: Multiple IP addresses in a jail.) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 11:06:39 -0000 --brEuL7wsLY8+TuWz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 01, 2006 at 10:40:53AM +0200, Phil Regnauld wrote: > Josef Karthauser (joe) writes: > > Dear current folk, I'm forwarding this thread from the -net list where I > > asked the question, is it possible to have more than one IP address in a > > jail? The answer is yes, with Pawel's patch. The question here is can > > I pursuade anyone to commit this to head and MFC it please? The > > motivation is simple. I need to run a second SSL web server inside of a > > jail, however that needs another IP address because SSL is incompatible > > with HTTP/1.1. >=20 > We have been using these patches all the way back since 5-CURRENT and > they work very stable for us. I seem to remember that there were > some reservations about the way it was being done, but for that matter > it wouldn't be the first hack in jail (like u_int32_t for the ip_number > in struct jail :) >=20 I no longer have a commit bit, so I can't commit these myself.... :/. Joe --=20 Josef Karthauser (joe@tao.org.uk) http://www.josef-k.net/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An eclectic mix of fact an= d theory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --brEuL7wsLY8+TuWz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iEYEARECAAYFAkTR2HQACgkQXVIcjOaxUBYnEwCgsALSsYUym1Kka31eqMyPWYjb vs4AoOp2QbTgKfQ6PX7tuPu511f6rE6H =Bcb8 -----END PGP SIGNATURE----- --brEuL7wsLY8+TuWz-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 3 11:10:21 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2EEE16A4E0; Thu, 3 Aug 2006 11:10:21 +0000 (UTC) (envelope-from flz@FreeBSD.org) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E1F543E4C; Thu, 3 Aug 2006 11:08:11 +0000 (GMT) (envelope-from flz@FreeBSD.org) Received: from smtp.xbsd.org (xbsd.org [82.233.2.192]) by smtp1-g19.free.fr (Postfix) with ESMTP id 3026686BCB; Thu, 3 Aug 2006 13:07:56 +0200 (CEST) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id 7E46611B9A; Thu, 3 Aug 2006 13:07:55 +0200 (CEST) Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29261-10; Thu, 3 Aug 2006 13:07:44 +0200 (CEST) Received: from mayday.esat.net (mayday.esat.net [193.95.134.156]) by smtp.xbsd.org (Postfix) with ESMTP id 566FA11B9F; Thu, 3 Aug 2006 13:07:44 +0200 (CEST) From: Florent Thoumie To: Jonathan Herriott In-Reply-To: <6a56d69c0608021501l52690648y4f9b4a6c0a70999c@mail.gmail.com> References: <6a56d69c0608021501l52690648y4f9b4a6c0a70999c@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-3zfYyyor5A/leP8M40Ce" Date: Thu, 03 Aug 2006 12:07:59 +0100 Message-Id: <1154603279.92929.9.camel@mayday.esat.net> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port X-Virus-Scanned: amavisd-new at xbsd.org Cc: freebsd-net@FreeBSD.org, freebsd-ports@freebsd.org Subject: Re: ipw-firmware port (Intel Pro/Wireless 2100) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 11:10:21 -0000 --=-3zfYyyor5A/leP8M40Ce Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2006-08-02 at 18:01 -0400, Jonathan Herriott wrote: > Hi All! >=20 > I have been having trouble using the ipw-firmware port. I am able to > get it up and running, and it is even associated to my wireless > network. I use dhclient to get a lease and set everything up, which > works fine (this is after I enter the encryption and stuff). >=20 > The problem is when I try to ping or access any other IP address, even > my router I'm connected to. Just pinging my router yields no results. > I have loaded wlan_wep and provided the correct key (tried retyping > the key several times) to make sure I provided that portion correctly. > I also tried disabling wep in my router to make sure it was not a > problem with the wlan_wep module. >=20 > Here's a dump of ifconfig ipw0 >=20 > ipw0: flags=3D8847 mtu 1500 > inet6 fe80::204:23ff:fe6b:37ad%ipw0 prefixlen 64 scopeid 0x5 > inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 > ether 00:04:23:6b:37:ad > media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) > status: associated > ssid JONNET channel 11 bssid 00:09:5b:6a:ad:bc > authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpowmax 100 > bintval 100 >=20 > I tried specifying the debug option, but I do not where I will get the > output (could not find a specified log file). >=20 >=20 > I was wondering what other information I may need to provide to help > in troubleshooting this issue or if anyone knows what is going on. Followup to -net, as it's not a ports issue. I think you can define ipw.debug to something > 0. Check the output of 'sysctl -a | grep ipw | grep debug' to find the right sysctl. --=20 Florent Thoumie flz@FreeBSD.org FreeBSD Committer --=-3zfYyyor5A/leP8M40Ce Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQBE0dkPMxEkbVFH3PQRAi0+AJ90pmRNjwXxAEhWk6oz+TBN0cHONACgjBV5 TAVOUgDxVIR3Ymq6RWQuC0s= =3+2f -----END PGP SIGNATURE----- --=-3zfYyyor5A/leP8M40Ce-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 3 11:26:08 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CDE516A4DE for ; Thu, 3 Aug 2006 11:26:08 +0000 (UTC) (envelope-from pavol@cierny.sk) Received: from pavol.slovenska.sk (t0uch.slovenska.sk [212.5.219.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9519843D45 for ; Thu, 3 Aug 2006 11:26:06 +0000 (GMT) (envelope-from pavol@cierny.sk) Received: (qmail 55046 invoked by uid 98); 3 Aug 2006 11:26:05 -0000 Received: from 87.197.129.100 by pavol.slovenska.sk (envelope-from , uid 82) with qmail-scanner-1.25 (uvscan: v4.4.00/v4786. spamassassin: 3.0.2. Clear:RC:0(87.197.129.100):SA:0(1.0/5.0):. Processed in 1.254067 secs); 03 Aug 2006 11:26:05 -0000 X-Spam-Status: No, hits=1.0 required=5.0 X-Spam-Level: + X-Qmail-Scanner-Mail-From: pavol@cierny.sk via pavol.slovenska.sk X-Qmail-Scanner: 1.25 (Clear:RC:0(87.197.129.100):SA:0(1.0/5.0):. Processed in 1.254067 secs) Received: from unknown (HELO adsl-d100.87-197-129.telecom.sk) (scorp@87.197.129.100) by ns.slovenska.sk with AES256-SHA encrypted SMTP; 3 Aug 2006 11:26:03 -0000 Date: Thu, 3 Aug 2006 13:25:58 +0200 From: =?ISO-8859-2?Q?Pavol_=C8ierny?= X-Mailer: The Bat! (v3.5.30) Professional Organization: WEBY.SLOVENSKA.SK X-Priority: 3 (Normal) Message-ID: <1093989648.20060803132558@cierny.sk> To: "David (Controller AE) Christensen" In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD90301954339@NT-IRVA-0750.brcm.ad.broadcom.com> References: <09BFF2FA5EAB4A45B6655E151BBDD90301954339@NT-IRVA-0750.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Broadcom 5780 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-8859-2?Q?Pavol_=C8ierny?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 11:26:08 -0000 Hello, I wrote some weeks ago about broadcom 5780 that wasn't detected in FreeBSD 6.1R After trying CURRENT, it was detected, but as Broadcom 5714 (i didn't know it was 5714).... In the documentation of bge in FreeBSD 5.x and 6.x it says that the driver already has support for 5714... What can I do that FreeBSD detects my NICs? I don't want to use CURRENT on the server... Thanks for any help --- Best regards Pavol Čierny > I don't maintain that driver so I don't know the answer to that. > Dave >> -----Original Message----- >> From: Pavol Čierny [mailto:pavol@cierny.sk] >> Sent: Wednesday, July 19, 2006 11:43 AM >> To: David (Controller AE) Christensen >> Cc: freebsd-net@freebsd.org >> Subject: Re: Broadcom 5780 >> >> Thanks for the info. >> >> Any chances it get's into STABLE in a near term? >> Could I use the driver code and compile it in STABLE? :) >> >> --- >> S pozdravom >> Pavol Čierny >> >> >> > Pavol, >> >> > The 5780 is functionally equivalent to the 5714. Support for the >> > 5780 was added to -CURRENT on June 29, 2006 in version 1.135 of >> > if_bge.c. >> >> > Dave >> >> >> -----Original Message----- >> >> From: owner-freebsd-net@freebsd.org >> >> [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Pavol Cierny >> >> Sent: Wednesday, July 19, 2006 7:17 AM >> >> To: freebsd-net@freebsd.org >> >> Subject: Broadcom 5780 >> >> >> >> Hello, >> >> >> >> has anyone information about implementing Broadcom 5780 to the bge >> >> driver? >> >> >> >> Just bought a Fujitsu-Siemens RX220 server, and the NICs >> don't work :( >> >> >> >> >> >> >> >> >> >> >> >> --- >> >> Best regards >> >> Pavol Čierny >> >> >> >> _______________________________________________ >> >> freebsd-net@freebsd.org mailing list >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> >> To unsubscribe, send any mail to >> >> "freebsd-net-unsubscribe@freebsd.org" >> >> >> >> >> >> > _______________________________________________ >> > freebsd-net@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net >> > To unsubscribe, send any mail to >> > "freebsd-net-unsubscribe@freebsd.org" >> >> >> From owner-freebsd-net@FreeBSD.ORG Thu Aug 3 12:49:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33F4116A4DA for ; Thu, 3 Aug 2006 12:49:10 +0000 (UTC) (envelope-from pavol@cierny.sk) Received: from pavol.slovenska.sk (t0uch.slovenska.sk [212.5.219.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7119143D45 for ; Thu, 3 Aug 2006 12:49:09 +0000 (GMT) (envelope-from pavol@cierny.sk) Received: (qmail 78969 invoked by uid 98); 3 Aug 2006 12:49:07 -0000 Received: from 87.197.129.100 by pavol.slovenska.sk (envelope-from , uid 82) with qmail-scanner-1.25 (uvscan: v4.4.00/v4786. spamassassin: 3.0.2. Clear:RC:0(87.197.129.100):SA:0(1.0/5.0):. Processed in 1.101618 secs); 03 Aug 2006 12:49:07 -0000 X-Spam-Status: No, hits=1.0 required=5.0 X-Spam-Level: + X-Qmail-Scanner-Mail-From: pavol@cierny.sk via pavol.slovenska.sk X-Qmail-Scanner: 1.25 (Clear:RC:0(87.197.129.100):SA:0(1.0/5.0):. Processed in 1.101618 secs) Received: from unknown (HELO adsl-d100.87-197-129.telecom.sk) (scorp@87.197.129.100) by ns.slovenska.sk with AES256-SHA encrypted SMTP; 3 Aug 2006 12:49:06 -0000 Date: Thu, 3 Aug 2006 14:49:01 +0200 From: =?ISO-8859-2?Q?Pavol_=C8ierny?= X-Mailer: The Bat! (v3.5.30) Professional Organization: WEBY.SLOVENSKA.SK X-Priority: 3 (Normal) Message-ID: <137586891.20060803144901@cierny.sk> To: ovidiu ene In-Reply-To: References: <09BFF2FA5EAB4A45B6655E151BBDD90301954339@NT-IRVA-0750.brcm.ad.broadcom.com> <1093989648.20060803132558@cierny.sk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Broadcom 5780 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-8859-2?Q?Pavol_=C8ierny?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 12:49:10 -0000 Hi, today I noticed that the STABLE bge driver was modified yesterday (2006-08-02), and it looks like it supports also 5780, so the NICs could work Now I have trouble compiling kernel :-( make: don't know how to make /usr/src/sys/crypto/rijndael/rijndael-alg-fst.c. Stop *** Error code 2 --- S pozdravom Pavol Čierny > On Aug 3, 2006, at 2:25 PM, Pavol Čierny wrote: >> Hello, >> >> I wrote some weeks ago about broadcom 5780 that wasn't detected in >> FreeBSD 6.1R >> >> After trying CURRENT, it was detected, but as Broadcom 5714 (i didn't >> know it was 5714).... >> >> In the documentation of bge in FreeBSD 5.x and 6.x it says that the >> driver already has support for 5714... >> >> What can I do that FreeBSD detects my NICs? >> I don't want to use CURRENT on the server... >> >> Thanks for any help >> >> --- >> Best regards >> Pavol Čierny >> >> >>> I don't maintain that driver so I don't know the answer to that. >> >>> Dave >> >>>> -----Original Message----- >>>> From: Pavol Čierny [mailto:pavol@cierny.sk] >>>> Sent: Wednesday, July 19, 2006 11:43 AM >>>> To: David (Controller AE) Christensen >>>> Cc: freebsd-net@freebsd.org >>>> Subject: Re: Broadcom 5780 >>>> >>>> Thanks for the info. >>>> >>>> Any chances it get's into STABLE in a near term? >>>> Could I use the driver code and compile it in STABLE? :) >>>> >>>> --- >>>> S pozdravom >>>> Pavol Čierny >>>> >>>> >>>>> Pavol, >>>> >>>>> The 5780 is functionally equivalent to the 5714. Support for the >>>>> 5780 was added to -CURRENT on June 29, 2006 in version 1.135 of >>>>> if_bge.c. >>>> >>>>> Dave >>>> >>>>>> -----Original Message----- >>>>>> From: owner-freebsd-net@freebsd.org >>>>>> [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Pavol Cierny >>>>>> Sent: Wednesday, July 19, 2006 7:17 AM >>>>>> To: freebsd-net@freebsd.org >>>>>> Subject: Broadcom 5780 >>>>>> >>>>>> Hello, >>>>>> >>>>>> has anyone information about implementing Broadcom 5780 to the bge >>>>>> driver? >>>>>> >>>>>> Just bought a Fujitsu-Siemens RX220 server, and the NICs >>>> don't work :( >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> --- >>>>>> Best regards >>>>>> Pavol Čierny >>>>>> >>>>>> _______________________________________________ >>>>>> freebsd-net@freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>>> To unsubscribe, send any mail to >>>>>> "freebsd-net-unsubscribe@freebsd.org" >>>>>> >>>>>> >>>> >>>>> _______________________________________________ >>>>> freebsd-net@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>> To unsubscribe, send any mail to >>>>> "freebsd-net-unsubscribe@freebsd.org" >>>> >>>> >>>> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to >> "freebsd-net-unsubscribe@freebsd.org" > I had the same problem (same fujitsu server model), I think for now > the only way is to use CURRENT (5714) > best regards > ovidiu From owner-freebsd-net@FreeBSD.ORG Thu Aug 3 15:42:41 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADCE616A4DA for ; Thu, 3 Aug 2006 15:42:41 +0000 (UTC) (envelope-from admin@intron.ac) Received: from intron.ac (unknown [210.51.165.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2FB043D49 for ; Thu, 3 Aug 2006 15:42:40 +0000 (GMT) (envelope-from admin@intron.ac) Received: from localhost (localhost [127.0.0.1]) (uid 1003) by intron.ac with local; Thu, 03 Aug 2006 23:42:39 +0800 id 00102C04.44D2196F.00002805 From: "Intron" To: freebsd-net@freebsd.org Date: Thu, 03 Aug 2006 23:42:39 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Subject: Dynamic Rule Corpses of IPFW 2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 15:42:41 -0000 I've set up a stateful IPFW rule to resist DoS attach. The rule is allow tcp from any to me tcpflags syn limit src-addr 10 But I found that there're many corpses in dynamic rules, which may resist normal accesses. There isn't correspondence between those corpses and existing TCP connections. How to deal with those impedient corpses? #ipfw -d show | grep myclient ; netstat -an | grep myclient 10010 4 192 (111s) LIMIT tcp myclient 50719 <-> myserver 443 10010 4 192 (80s) LIMIT tcp myclient 50700 <-> myserver 443 10010 4 192 (124s) LIMIT tcp myclient 50743 <-> myserver 443 10010 4 192 (119s) LIMIT tcp myclient 50735 <-> myserver 443 10010 3570 544131 (300s) LIMIT tcp myclient 50828 <-> myserver 22 10010 0 0 (3s) PARENT 10 tcp myclient 0 <-> 0.0.0.0 0 10010 4 192 (44s) LIMIT tcp myclient 50617 <-> myserver 443 10010 4 192 (59s) LIMIT tcp myclient 50652 <-> myserver 443 10010 4 192 (59s) LIMIT tcp myclient 50650 <-> myserver 443 10010 4 192 (57s) LIMIT tcp myclient 50645 <-> myserver 443 10010 2 96 (300s) LIMIT tcp myclient 50890 <-> myserver 443 tcp4 0 0 myserver.443 myclient.50817 TIME_WAIT tcp4 0 0 myserver.443 myclient.50815 TIME_WAIT tcp4 0 0 myserver.443 myclient.50813 TIME_WAIT tcp4 0 0 myserver.443 myclient.50809 TIME_WAIT tcp4 0 146 myserver.443 myclient.50706 ESTABLISHED tcp4 0 146 myserver.443 myclient.50688 ESTABLISHED tcp4 0 146 myserver.443 myclient.50679 ESTABLISHED tcp4 0 0 myserver.443 myclient.50668 ESTABLISHED tcp4 0 0 myserver.443 myclient.50618 ESTABLISHED tcp4 0 0 myserver.443 myclient.50611 ESTABLISHED tcp4 0 146 myserver.443 myclient.50493 FIN_WAIT_1 tcp4 0 146 myserver.443 myclient.50026 FIN_WAIT_1 tcp4 0 0 myserver.22 myclient.50828 ESTABLISHED ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-net@FreeBSD.ORG Thu Aug 3 16:46:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06D3016A4DA for ; Thu, 3 Aug 2006 16:46:24 +0000 (UTC) (envelope-from nayak_purushotham@yahoo.com) Received: from web56103.mail.re3.yahoo.com (web56103.mail.re3.yahoo.com [216.252.110.197]) by mx1.FreeBSD.org (Postfix) with SMTP id 592C443D4C for ; Thu, 3 Aug 2006 16:46:21 +0000 (GMT) (envelope-from nayak_purushotham@yahoo.com) Received: (qmail 88170 invoked by uid 60001); 3 Aug 2006 16:46:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kBI0AXA81Y3p2FgyzJZC/xiLcV4qU5prE7WQkOauc0pmwZOpt2iWekPY9CuQwSVal7PjYchkU/q4OEC/IOL3GnFYLCbM9nFt49RjsmsfAemNEqfGft6x0PwdAx01RCrdV1R723ndazkSrhV2fl/XhRF6g3e1GjnTbVTJqk/2hqQ= ; Message-ID: <20060803164620.88168.qmail@web56103.mail.re3.yahoo.com> Received: from [209.136.0.128] by web56103.mail.re3.yahoo.com via HTTP; Thu, 03 Aug 2006 09:46:20 PDT Date: Thu, 3 Aug 2006 09:46:20 -0700 (PDT) From: Purushotham Nayak To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ethernet bridge and dhcpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 16:46:24 -0000 Hi All, I have a routerboard with two ethernet ports (sis0 and sis1) with FreeBSD 6.0 on it. I've been trying to setup a bridge between them and also run the dhcpd server on the routerboard. I've setup sis0 with an IP address and sis1 is just marked "up" in rc.conf. The bridge seems to work because if I statically assign an IP address to a laptop and connect it to sis1 I can ping the routers IP which is what is assigned to sis0. But the laptop cannot get an IP using DHCP. tcpdumping on sis0 doesn't show me the DHCPREQUEST from the laptop that's coming in through sis1 (but it doesn't show me any traffic during ping request either but that's not broadcast so I guess that's expected). Can anyone tell me what I'm doing wrong ?. Here's my rc.conf ------------------------------------------------------------------------------------ inetd_enable="YES" ifconfig_sis0="inet 10.1.1.1 netmask 255.255.255.0" ifconfig_sis1="up" ifconfig_ath0="down" gateway_enable="YES" dhcpd_enable="YES" dhcpd_flags="-q" dhcpd_conf=/usr/local/etc/dhcpd.conf" ----------------------------------------------------------------------------------- And here is my dhcpd.conf ----------------------------------------------------------------------------------- ddns-update-style ad-hoc; default-lease-time 600; max-lease-time 7200; subnet 10.1.1.0 netmask 255.255.255.0 { range 10.1.1.64 10.1.1.250; option routers 10.1.1.1; } ---------------------------------------------------------------------- --------------------------------- Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail Beta. From owner-freebsd-net@FreeBSD.ORG Thu Aug 3 17:23:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B043B16A4E1 for ; Thu, 3 Aug 2006 17:23:51 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAA8043D58 for ; Thu, 3 Aug 2006 17:23:43 +0000 (GMT) (envelope-from davidch@broadcom.com) Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 03 Aug 2006 10:23:23 -0700 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 93EAB2AF; Thu, 3 Aug 2006 10:23:23 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 6816D2AE; Thu, 3 Aug 2006 10:23:23 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EBQ67992; Thu, 3 Aug 2006 10:23:22 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 346F469CA3; Thu, 3 Aug 2006 10:23:22 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Aug 2006 10:23:20 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD90301AB6B6E@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <1093989648.20060803132558@cierny.sk> Thread-Topic: Broadcom 5780 Thread-Index: Aca276bG1ZR8WFmATE24HfuveDKtIQAMOT7w From: "David (Controller AE) Christensen" To: "=?iso-8859-2?Q?Pavol_=C8ierny?=" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006080306; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230332E34344432333039442E303032332D412D; ENG=IBF; TS=20060803172336; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006080306_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 68CCEE811OO10318432-01-01 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: RE: Broadcom 5780 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 17:23:51 -0000 The best solution would be to MFC the driver from -CURRENT to 6.1R, the = second alternative would be to add the 5780 PCI vendor/device ID to the = 6.1R driver, add a BGE_ASICREV_BCM5780 definition to if_bgereg.h, and = make sure that any references to the 5714 also include a reference to = the 5780. (Try a diff between 1.134 and 1.135 on -CURRENT to quickly = identify the relevant changes.) Dave > -----Original Message----- > From: Pavol =C8ierny [mailto:pavol@cierny.sk]=20 > Sent: Thursday, August 03, 2006 4:26 AM > To: David (Controller AE) Christensen > Cc: freebsd-net@freebsd.org > Subject: Re: Broadcom 5780 >=20 > Hello, >=20 > I wrote some weeks ago about broadcom 5780 that wasn't detected in > FreeBSD 6.1R >=20 > After trying CURRENT, it was detected, but as Broadcom 5714 (i didn't > know it was 5714).... >=20 > In the documentation of bge in FreeBSD 5.x and 6.x it says that the > driver already has support for 5714... >=20 > What can I do that FreeBSD detects my NICs? > I don't want to use CURRENT on the server... >=20 > Thanks for any help >=20 > --- > Best regards > Pavol =C8ierny >=20 >=20 > > I don't maintain that driver so I don't know the answer to that. >=20 > > Dave=20 >=20 > >> -----Original Message----- > >> From: Pavol =C8ierny [mailto:pavol@cierny.sk]=20 > >> Sent: Wednesday, July 19, 2006 11:43 AM > >> To: David (Controller AE) Christensen > >> Cc: freebsd-net@freebsd.org > >> Subject: Re: Broadcom 5780 > >>=20 > >> Thanks for the info. > >>=20 > >> Any chances it get's into STABLE in a near term? > >> Could I use the driver code and compile it in STABLE? :) > >>=20 > >> --- > >> S pozdravom > >> Pavol =C8ierny > >>=20 > >>=20 > >> > Pavol, > >>=20 > >> > The 5780 is functionally equivalent to the 5714. Support for the > >> > 5780 was added to -CURRENT on June 29, 2006 in version 1.135 of > >> > if_bge.c. > >>=20 > >> > Dave=20 > >>=20 > >> >> -----Original Message----- > >> >> From: owner-freebsd-net@freebsd.org=20 > >> >> [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Pavol Cierny > >> >> Sent: Wednesday, July 19, 2006 7:17 AM > >> >> To: freebsd-net@freebsd.org > >> >> Subject: Broadcom 5780 > >> >>=20 > >> >> Hello, > >> >>=20 > >> >> has anyone information about implementing Broadcom 5780=20 > to the bge > >> >> driver? > >> >>=20 > >> >> Just bought a Fujitsu-Siemens RX220 server, and the NICs=20 > >> don't work :( > >> >>=20 > >> >>=20 > >> >>=20 > >> >>=20 > >> >>=20 > >> >> --- > >> >> Best regards > >> >> Pavol =C8ierny > >> >>=20 > >> >> _______________________________________________ > >> >> freebsd-net@freebsd.org mailing list > >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> >> To unsubscribe, send any mail to > >> >> "freebsd-net-unsubscribe@freebsd.org" > >> >>=20 > >> >>=20 > >>=20 > >> > _______________________________________________ > >> > freebsd-net@freebsd.org mailing list > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> > To unsubscribe, send any mail to > >> > "freebsd-net-unsubscribe@freebsd.org" > >>=20 > >>=20 > >>=20 >=20 >=20 >=20 From owner-freebsd-net@FreeBSD.ORG Thu Aug 3 18:06:42 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1736316A4E6 for ; Thu, 3 Aug 2006 18:06:42 +0000 (UTC) (envelope-from pavol@cierny.sk) Received: from pavol.slovenska.sk (t0uch.slovenska.sk [212.5.219.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F4DE43D70 for ; Thu, 3 Aug 2006 18:06:29 +0000 (GMT) (envelope-from pavol@cierny.sk) Received: (qmail 65109 invoked by uid 98); 3 Aug 2006 18:06:28 -0000 Received: from 87.197.129.100 by pavol.slovenska.sk (envelope-from , uid 82) with qmail-scanner-1.25 (uvscan: v4.4.00/v4786. spamassassin: 3.0.2. Clear:RC:0(87.197.129.100):SA:0(1.0/5.0):. Processed in 1.001259 secs); 03 Aug 2006 18:06:28 -0000 X-Spam-Status: No, hits=1.0 required=5.0 X-Spam-Level: + X-Qmail-Scanner-Mail-From: pavol@cierny.sk via pavol.slovenska.sk X-Qmail-Scanner: 1.25 (Clear:RC:0(87.197.129.100):SA:0(1.0/5.0):. Processed in 1.001259 secs) Received: from unknown (HELO adsl-d100.87-197-129.telecom.sk) (scorp@87.197.129.100) by ns.slovenska.sk with AES256-SHA encrypted SMTP; 3 Aug 2006 18:06:27 -0000 Date: Thu, 3 Aug 2006 20:06:22 +0200 From: =?ISO-8859-2?Q?Pavol_=C8ierny?= X-Mailer: The Bat! (v3.5.30) Professional Organization: WEBY.SLOVENSKA.SK X-Priority: 3 (Normal) Message-ID: <1195480652.20060803200622@cierny.sk> To: "David (Controller AE) Christensen" In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD90301AB6B6E@NT-IRVA-0750.brcm.ad.broadcom.com> References: <1093989648.20060803132558@cierny.sk> <09BFF2FA5EAB4A45B6655E151BBDD90301AB6B6E@NT-IRVA-0750.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Broadcom 5780 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-8859-2?Q?Pavol_=C8ierny?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 18:06:42 -0000 Problem solved. The bge driver in STABLE has been modified yesterday, and it works if_bge.c,v 1.91.2.15 2006/08/02 15:01:59 glebius although it detects the NIC as 5714... maybe it's 5714 and not 5780 ... but it works... :) Thanks for the hints --- Best regards Pavol Čierny > The best solution would be to MFC the driver from -CURRENT to > 6.1R, the second alternative would be to add the 5780 PCI > vendor/device ID to the 6.1R driver, add a BGE_ASICREV_BCM5780 > definition to if_bgereg.h, and make sure that any references to the > 5714 also include a reference to the 5780. (Try a diff between > 1.134 and 1.135 on -CURRENT to quickly identify the relevant > changes.) > Dave >> -----Original Message----- >> From: Pavol Čierny [mailto:pavol@cierny.sk] >> Sent: Thursday, August 03, 2006 4:26 AM >> To: David (Controller AE) Christensen >> Cc: freebsd-net@freebsd.org >> Subject: Re: Broadcom 5780 >> >> Hello, >> >> I wrote some weeks ago about broadcom 5780 that wasn't detected in >> FreeBSD 6.1R >> >> After trying CURRENT, it was detected, but as Broadcom 5714 (i didn't >> know it was 5714).... >> >> In the documentation of bge in FreeBSD 5.x and 6.x it says that the >> driver already has support for 5714... >> >> What can I do that FreeBSD detects my NICs? >> I don't want to use CURRENT on the server... >> >> Thanks for any help >> >> --- >> Best regards >> Pavol Čierny >> >> >> > I don't maintain that driver so I don't know the answer to that. >> >> > Dave >> >> >> -----Original Message----- >> >> From: Pavol Čierny [mailto:pavol@cierny.sk] >> >> Sent: Wednesday, July 19, 2006 11:43 AM >> >> To: David (Controller AE) Christensen >> >> Cc: freebsd-net@freebsd.org >> >> Subject: Re: Broadcom 5780 >> >> >> >> Thanks for the info. >> >> >> >> Any chances it get's into STABLE in a near term? >> >> Could I use the driver code and compile it in STABLE? :) >> >> >> >> --- >> >> S pozdravom >> >> Pavol Čierny >> >> >> >> >> >> > Pavol, >> >> >> >> > The 5780 is functionally equivalent to the 5714. Support for the >> >> > 5780 was added to -CURRENT on June 29, 2006 in version 1.135 of >> >> > if_bge.c. >> >> >> >> > Dave >> >> >> >> >> -----Original Message----- >> >> >> From: owner-freebsd-net@freebsd.org >> >> >> [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Pavol Cierny >> >> >> Sent: Wednesday, July 19, 2006 7:17 AM >> >> >> To: freebsd-net@freebsd.org >> >> >> Subject: Broadcom 5780 >> >> >> >> >> >> Hello, >> >> >> >> >> >> has anyone information about implementing Broadcom 5780 >> to the bge >> >> >> driver? >> >> >> >> >> >> Just bought a Fujitsu-Siemens RX220 server, and the NICs >> >> don't work :( >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> --- >> >> >> Best regards >> >> >> Pavol Čierny >> >> >> >> >> >> _______________________________________________ >> >> >> freebsd-net@freebsd.org mailing list >> >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> >> >> To unsubscribe, send any mail to >> >> >> "freebsd-net-unsubscribe@freebsd.org" >> >> >> >> >> >> >> >> >> >> > _______________________________________________ >> >> > freebsd-net@freebsd.org mailing list >> >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net >> >> > To unsubscribe, send any mail to >> >> > "freebsd-net-unsubscribe@freebsd.org" >> >> >> >> >> >> >> >> >> From owner-freebsd-net@FreeBSD.ORG Thu Aug 3 18:08:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2299216A4E6 for ; Thu, 3 Aug 2006 18:08:46 +0000 (UTC) (envelope-from cybercorecentre@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6395B43DC5 for ; Thu, 3 Aug 2006 18:07:27 +0000 (GMT) (envelope-from cybercorecentre@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so2630275uge for ; Thu, 03 Aug 2006 11:07:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=qZ2OlSsk18yOFZxv5YprW7xh5fHt4dzHfy/32Zqkvx/0Scy2o1+YpbyuduDFSqjCyRmqeAwOZEroP5J1qT/4SkeOO1oApZgPK610Tanms9+k6UlXFao0R2ZGsKkVGWrg/LEmxjjOMxQyHr1jw6X/vim5KGQeaWY5WFKXY6Ujxu0= Received: by 10.66.221.19 with SMTP id t19mr3203808ugg; Thu, 03 Aug 2006 11:07:21 -0700 (PDT) Received: from ?192.0.0.52? ( [62.77.228.138]) by mx.gmail.com with ESMTP id k2sm7648490ugf.2006.08.03.11.07.20; Thu, 03 Aug 2006 11:07:21 -0700 (PDT) Message-ID: <44D23B4C.6060202@gmail.com> Date: Thu, 03 Aug 2006 20:07:08 +0200 From: Jax User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20060801160141.73380.qmail@web56101.mail.re3.yahoo.com> In-Reply-To: <20060801160141.73380.qmail@web56101.mail.re3.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ethernet bridge and dhcpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 18:08:46 -0000 Purushotham Nayak wrote: > Hi All, > > Hey! Sorry you dind't get my answer first because I sent in wrong format, so i post it again: Here is a thought, don't setup dhcp server on a bridge. I tried to use firewalling on this but it works differently than in linux where you can control the traffic with --physdev-in -out, you can't determine that which card where the traffic come from and which where it goes, i read something in a handbook but dont remember atm so try to accept all packet on the firewall. You can try to tell dhcpd which interface you want to use but it's possible it won't work. > I have a routerboard with two ethernet ports (sis0 and sis1). I've been trying top setup a bridge and also run the dhcpd server on it. I've setup sis0 with an IP address and sis1 is just marked up in rc.conf. The bridge seems to work because if I statically assign an IP address to a laptop and connect it to sis1 I can ping the routers IP which is what is assigned to sis0. But the laptop cannot get an IP using DHCP. tcpdumping on sis0 doesn't show me the DHCPREQUEST from the laptop that's coming in through sis1 (but it doesn't show me any traffic during ping request either but that's not broadcast so I guess that's expected). > > Here's my rc.conf > > ------------------------------------------------------------------------------------- > inetd_enable="YES" > ifconfig_sis0="inet 10.1.1.1 netmask 255.255.255.0" > broadcast parameter? > ifconfig_sis1="up" > ifconfig_ath0="down" > > gateway_enable="YES" > > this not requied for a bridge > dhcpd_enable="YES" > dhcpd_flags="-q" > try to setup the interface as i told > dhcpd_conf=/usr/local/etc/dhcpd.conf" > ----------------------------------------------------------------------- > > And here is my dhcpd.conf > > ------------------------------------------------------------------------- > ddns-update-style ad-hoc; > default-lease-time 600; > max-lease-time 7200; > > subnet 10.1.1.0 netmask 255.255.255.0 { > range 10.1.1.64 10.1.1.250; > option routers 10.1.1.1; > } > ------------------------------------------------------------------- > > Can anyone please let me know if there is something I'm doing wrong. > > nayak > > I hope it will help. Regards, JaX From owner-freebsd-net@FreeBSD.ORG Fri Aug 4 02:01:14 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9042816A4DA for ; Fri, 4 Aug 2006 02:01:14 +0000 (UTC) (envelope-from lukem@cse.unsw.edu.au) Received: from note.orchestra.cse.unsw.EDU.AU (note.orchestra.cse.unsw.EDU.AU [129.94.242.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB53343D45 for ; Fri, 4 Aug 2006 02:01:13 +0000 (GMT) (envelope-from lukem@cse.unsw.edu.au) Received: From wagner.orchestra.cse.unsw.EDU.AU ([129.94.242.19]) (ident-user root) (cse-authentic-sender lukem) By note With Smtp ; Fri, 4 Aug 2006 12:01:05 +1000 Received: From wagner With LocalMail ; Fri, 4 Aug 2006 12:01:05 +1000 From: lukem.freebsd@cse.unsw.edu.au Sender: lukem@cse.unsw.edu.au To: Antony Mawer Date: Fri, 4 Aug 2006 12:01:05 +1000 (EST) In-Reply-To: <44D18EAF.1010907@mawer.org> Message-ID: References: <44D18EAF.1010907@mawer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Plans to port OpenBSD trunk(4)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 02:01:14 -0000 On Thu, 3 Aug 2006, Antony Mawer wrote: > Is there any interest or plans underway to port the trunk(4) feature from > OpenBSD? OpenBSD's trunk(4) appears to be exactly what I'm looking for, but > there doesn't appear to be anything I can find on a port to FreeBSD. > > http://www.openbsd.org/cgi-bin/man.cgi?query=trunk&sektion=4 > > I've been tasked with setting up a system that will have 2x Intel Pro/1000 > network adapters linked to an HP ProCurve 5300XL modular switch. > > I stumbled across ng_fec(4), but it refers explicitly to Cisco Fast > EtherChannel; some information suggests that this is supported by the HP > switch... would using Netgraph with ng_fec achieve the same end result? Has > anyone successfully used it as such? You HP switch will probably support FEC trunking (the ones I have do), so using the ng_fec netgraph module is probably what you want to do. In fact, even if your switch uses something other than the FEC scheduler to distribute incoming packets, ng_fec will still work to distribute outgoing packets. Here is the config I use (on a 5.x system)... #!/bin/sh ngctl mkpeer fec dummy fec ngctl msg fec0: add_iface '"em0"' ngctl msg fec0: add_iface '"em1"' ngctl msg fec0: add_iface '"em2"' ngctl msg fec0: add_iface '"em3"' ifconfig fec0 192.168.1.1 255.255.255.0 #this next line should be implied by the previous, but... ifconfig fec0 up -- Luke From owner-freebsd-net@FreeBSD.ORG Fri Aug 4 14:38:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 468B216A538; Fri, 4 Aug 2006 14:38:38 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86E5943D5D; Fri, 4 Aug 2006 14:38:37 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.13.6/8.13.6) with ESMTP id k74EcUEc054325; Fri, 4 Aug 2006 18:38:30 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Fri, 4 Aug 2006 18:38:30 +0400 (MSD) From: Dmitry Morozovsky To: Josef Karthauser , Pawel Jakub Dawidek In-Reply-To: <20060803110525.GE804@genius.tao.org.uk> Message-ID: <20060804183146.N15526@woozle.rinet.ru> References: <20060628103238.GA815@genius.tao.org.uk> <20060628103949.GJ2005@catpipe.net> <3aaaa3a0606281940k63c77ebfga84a854b2cd4ed84@mail.gmail.com> <20060801084156.GD3440@genius.tao.org.uk> <20060801084053.GE22731@catpipe.net> <20060803110525.GE804@genius.tao.org.uk> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (woozle.rinet.ru [0.0.0.0]); Fri, 04 Aug 2006 18:38:30 +0400 (MSD) Cc: Chris , freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: Can I pursuade someone to commit this patch? (Re: Multiple IP addresses in a jail.) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 14:38:38 -0000 On Thu, 3 Aug 2006, Josef Karthauser wrote: JK> > > Dear current folk, I'm forwarding this thread from the -net list where I JK> > > asked the question, is it possible to have more than one IP address in a JK> > > jail? The answer is yes, with Pawel's patch. The question here is can JK> > > I pursuade anyone to commit this to head and MFC it please? The JK> > > motivation is simple. I need to run a second SSL web server inside of a JK> > > jail, however that needs another IP address because SSL is incompatible JK> > > with HTTP/1.1. JK> > JK> > We have been using these patches all the way back since 5-CURRENT and JK> > they work very stable for us. I seem to remember that there were JK> > some reservations about the way it was being done, but for that matter JK> > it wouldn't be the first hack in jail (like u_int32_t for the ip_number JK> > in struct jail :) JK> I no longer have a commit bit, so I can't commit these myself.... :/. I suppose pinging pjd@ did not work? ;) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-net@FreeBSD.ORG Fri Aug 4 15:00:58 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 631A516A4DE; Fri, 4 Aug 2006 15:00:58 +0000 (UTC) (envelope-from regnauld@macbook.catpipe.net) Received: from macbook.catpipe.net (flow.catpipe.net [195.249.214.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id E717F43D46; Fri, 4 Aug 2006 15:00:57 +0000 (GMT) (envelope-from regnauld@macbook.catpipe.net) Received: by macbook.catpipe.net (Postfix, from userid 1001) id 544CB135502; Fri, 4 Aug 2006 17:00:58 +0200 (CEST) Date: Fri, 4 Aug 2006 17:00:58 +0200 From: Phil Regnauld To: Dmitry Morozovsky Message-ID: <20060804150057.GP29827@catpipe.net> References: <20060628103238.GA815@genius.tao.org.uk> <20060628103949.GJ2005@catpipe.net> <3aaaa3a0606281940k63c77ebfga84a854b2cd4ed84@mail.gmail.com> <20060801084156.GD3440@genius.tao.org.uk> <20060801084053.GE22731@catpipe.net> <20060803110525.GE804@genius.tao.org.uk> <20060804183146.N15526@woozle.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060804183146.N15526@woozle.rinet.ru> X-Operating-System: Darwin 8.7.1 i386 Organization: catpipe Systems ApS User-Agent: Mutt/1.5.11 Cc: Chris , freebsd-current@freebsd.org, Pawel Jakub Dawidek , freebsd-net@freebsd.org Subject: Re: Can I pursuade someone to commit this patch? (Re: Multiple IP addresses in a jail.) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 15:00:58 -0000 Dmitry Morozovsky (marck) writes: > > I suppose pinging pjd@ did not work? ;) Good question -- why did Pawel not commit them himself if he could ? :) Phil From owner-freebsd-net@FreeBSD.ORG Fri Aug 4 20:39:03 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC5C816A4DA; Fri, 4 Aug 2006 20:39:03 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71D0743D49; Fri, 4 Aug 2006 20:39:02 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id B682C1FFDDC; Fri, 4 Aug 2006 22:39:00 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id C3F981FFACC; Fri, 4 Aug 2006 22:38:56 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 48FAB4448D6; Fri, 4 Aug 2006 20:38:34 +0000 (UTC) Date: Fri, 4 Aug 2006 20:38:34 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: FreeBSD current mailing list In-Reply-To: <20060804150057.GP29827@catpipe.net> Message-ID: <20060804203052.D26932@maildrop.int.zabbadoz.net> References: <20060628103238.GA815@genius.tao.org.uk> <20060628103949.GJ2005@catpipe.net> <3aaaa3a0606281940k63c77ebfga84a854b2cd4ed84@mail.gmail.com> <20060801084156.GD3440@genius.tao.org.uk> <20060801084053.GE22731@catpipe.net> <20060803110525.GE804@genius.tao.org.uk> <20060804183146.N15526@woozle.rinet.ru> <20060804150057.GP29827@catpipe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: FreeBSD net mailing list Subject: Re: Can I pursuade someone to commit this patch? (Re: Multiple IP addresses in a jail.) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 20:39:04 -0000 On Fri, 4 Aug 2006, Phil Regnauld wrote: > Dmitry Morozovsky (marck) writes: >> >> I suppose pinging pjd@ did not work? ;) > > Good question -- why did Pawel not commit them himself if he could ? :) quoting my last status report http://www.freebsd.org/news/status/report-apr-2006-jun-2006.html#Multi-IP-v4/v6-jails "As an intermediate step until FreeBSD will have full network stack virtualisation this work shall provide support for multi-IP IPv4/v6 jails. .... This is not considered to be the right thing todo so do not ask for official support or if this will be committed to the FreeBSD source repository. ... " I guess pjd was/is thinking about the same as I do - Pawel correct me if I am wrong? /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Fri Aug 4 21:18:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73F7116A628 for ; Fri, 4 Aug 2006 21:18:23 +0000 (UTC) (envelope-from victor.cruceru@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 086C143D70 for ; Fri, 4 Aug 2006 21:18:20 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: by nf-out-0910.google.com with SMTP id g2so561709nfe for ; Fri, 04 Aug 2006 14:18:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=FKxqKXGv52ytZcvIw3bb9SzBpkq5mHjFU/wIynypddWFuIHGd04Tp5JPRLKidbGHue+svQOiHHpp6a0o9sY6J5FCvlbbDrX9klrvv2tvfiM706MRnWQDqPmyKSqcp4zwNv6+59NwKdbmdQ5lipqJp0jlg0zE5QgIWVCWLud6wW0= Received: by 10.48.220.15 with SMTP id s15mr4746533nfg; Fri, 04 Aug 2006 14:18:19 -0700 (PDT) Received: by 10.70.47.19 with HTTP; Fri, 4 Aug 2006 14:18:19 -0700 (PDT) Message-ID: <49402550608041418j1b4d2ac9r66cae310c11e7ec5@mail.gmail.com> Date: Sat, 5 Aug 2006 00:18:19 +0300 From: "victor cruceru" To: freebsd-current@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: SMUX (RFC 1227) implementation for BSNMPd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soc-victor@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 21:18:23 -0000 Hi folks, I'm glad to announce an implementation of the venerable SNMP SMUX protocol for FreeBSD SNMP agent, bsnmpd. You can grab it from its wiki page http://wikitest.freebsd.org/SnmpSmux There you will find instructions about how to build it (it is a patch against -current) and how to play with it. For now it is only a bsnmpd module (the "server side") - but if someone is interested I have plans to write a libsmux library and API to be used in building smux peers (the "client side"). Any feedback is greatly appreciated. Thanks, -- victor cruceru ------------------------------------------------ Non est respondendum ad omnia. ( Cicero, Pro Murena Oratio ) ------------------------------------------------ From owner-freebsd-net@FreeBSD.ORG Sat Aug 5 15:37:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDD2516A4DA for ; Sat, 5 Aug 2006 15:37:16 +0000 (UTC) (envelope-from dylan@dylex.dylex.net) Received: from dylex.dylex.net (dsl092-008-121.sfo1.dsl.speakeasy.net [66.92.8.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8A1243D45 for ; Sat, 5 Aug 2006 15:37:15 +0000 (GMT) (envelope-from dylan@dylex.dylex.net) Received: from dylex.dylex.net (localhost.dylex.net [127.0.0.1]) by dylex.dylex.net (8.13.6/8.13.6) with ESMTP id k75FbFL5022466 for ; Sat, 5 Aug 2006 08:37:15 -0700 (PDT) (envelope-from dylan@dylex.dylex.net) Received: (from dylan@localhost) by dylex.dylex.net (8.13.6/8.13.6/Submit) id k75FbE76022465 for freebsd-net@freebsd.org; Sat, 5 Aug 2006 11:37:14 -0400 (EDT) (envelope-from dylan) Date: Sat, 5 Aug 2006 11:37:14 -0400 From: Dylan Alex Simon To: freebsd-net@freebsd.org Message-ID: <20060805153714.GA22424@dylex.dylex.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline Subject: wpa_supplicant on ndis cannot associate X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 15:37:16 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This is on latest RELENG_6_1. I'm using an ndis driver with a Dell TrueMobile 1300 (Latitude D610). Generally it's working fine: if I set the ssid/keys with ifconfig, it will associate and everything works wonderfully. wpa_supplicant, however, doesn't work so well. This is all with key_mgmt=NONE and no encryption, so authentication shouldn't be an issue. When I use the ndis driver (-D ndis), it can get scan results, but doesn't seem to properly set the ssid and never associates. There are lots of errors about ndis_get_oid and ndis_set_oid failing (but none about OID_802_11_SSID). While it's trying to associate, if I go and manually set the ssid with ifconfig (ifconfig ndis0 ssid XXX), it will then associate and then everything's okay. wpa_supplicant thinks things worked and completes, but it requires that manual step. (ndis.log with === annotations) I noticed that ifconfig is using the generic IEEE80211_IOC_SSID ioctls rather than the special ndis ones that the wpa_supplicant ndis driver does, so I decided to try -D bsd. With the freebsd driver, it gets scan results, properly sets the ssid, and then, while it's trying to associate, if I check ifconfig, it says associated and everything is okay. But wpa_supplicant doesn't notice the association, and times out and goes back to scanning. (bsd.log with === annotations) This happens with both ap_scan=1 and 2 and with scan_ssid=0 and 1. Does anyone have wpa_supplicant working on an ndis driver? :-Dylan --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Description: ndis.log Content-Disposition: attachment; filename="ndis.log" > wpa_supplicant -c /etc/wpa_supplicant.conf -i ndis0 -D ndis -d Initializing interface 'ndis0' conf '/etc/wpa_supplicant.conf' driver 'ndis' ctrl_interface 'N/A' Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf' Reading configuration file '/etc/wpa_supplicant.conf' ctrl_interface='/var/run/wpa_supplicant' ctrl_interface_group=0 (from group name 'wheel') ap_scan=1 Priority group 5 id=0 ssid='XXX' Initializing interface (2) 'ndis0' EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: KEY_RX entering state NO_KEY_RECEIVE EAPOL: SUPP_BE entering state INITIALIZE EAP: EAP entering state DISABLED EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 NDIS: Packet.dll version: FreeBSD WinPcap compatibility shim v1.0 NDIS: 1 adapter names found NDIS: 1 adapter descriptions found NDIS: 0 - ndis0 - ndis0 NDIS: Adapter description prefix 'ndis0' NDIS: Driver supports OID_802_11_CAPABILITY - NoOfPMKIDs 16 NoOfAuthEncrPairs 14 NDIS: driver capabilities: key_mgmt 0x1f enc 0xf auth 0x3 Own MAC address: 00:14:a5:50:67:9e wpa_driver_ndis_set_wpa: enabled=1 ndis_get_oid: oid=0xd010101 len (6) failed ndis_set_oid: oid=0xd010114 len (4) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_set_oid: oid=0xd010114 len (4) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_set_oid: oid=0xd010114 len (4) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_set_oid: oid=0xd010114 len (4) failed Setting scan request: 0 sec 100000 usec Added interface ndis0 State: DISCONNECTED -> SCANNING Starting AP scan (specific SSID) Scan SSID - hexdump_ascii(len=8): 58 58 58 XXX NDIS: turning radio on before the first scan ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed Scan timeout - try to get results Scan results: 3 Selecting BSS from priority group 5 0: 00:11:50:a6:19:92 ssid='XXX' wpa_ie_len=0 rsn_ie_len=0 caps=0x0 skip - no WPA/RSN IE 1: 00:14:a4:4d:59:06 ssid='140a' wpa_ie_len=0 rsn_ie_len=0 caps=0x10 skip - no WPA/RSN IE 2: 00:13:10:ee:a9:5e ssid='sam' wpa_ie_len=0 rsn_ie_len=0 caps=0x10 skip - no WPA/RSN IE selected non-WPA AP 00:11:50:a6:19:92 ssid='XXX' Trying to associate with 00:11:50:a6:19:92 (SSID='XXX' freq=2462 MHz) Cancelling scan request WPA: clearing own WPA/RSN IE Automatic auth_alg selection: 0x1 WPA: clearing AP WPA IE WPA: clearing AP RSN IE WPA: clearing own WPA/RSN IE No keys have been configured - skip key clearing State: SCANNING -> ASSOCIATING ndis_set_oid: oid=0xd010119 len (4) failed NDIS: Failed to set OID_802_11_PRIVACY_FILTER (0) Setting authentication timeout: 10 sec 0 usec EAPOL: External notification - portControl=ForceAuthorized ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed === Here, I can see: > ifconfig ndis0 | ndis0: flags=8843 mtu 1500 | inet 192.168.2.52 netmask 0xffffff00 broadcast 192.168.2.255 | ether 00:14:a5:50:67:9e | media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) | status: no carrier | ssid XXX channel 11 | authmode OPEN privacy OFF deftxkey 1 txpowmax 100 protmode CTS ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed Authentication with 00:00:00:00:00:00 timed out. Added BSSID 00:00:00:00:00:00 into blacklist State: ASSOCIATING -> DISCONNECTED No keys have been configured - skip key clearing EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 Setting scan request: 0 sec 0 usec State: DISCONNECTED -> SCANNING Starting AP scan (broadcast SSID) ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed Scan timeout - try to get results Scan results: 4 Selecting BSS from priority group 5 0: 00:14:a4:4d:59:06 ssid='140a' wpa_ie_len=0 rsn_ie_len=0 caps=0x10 skip - no WPA/RSN IE 1: 00:11:50:a6:19:92 ssid='XXX' wpa_ie_len=0 rsn_ie_len=0 caps=0x0 skip - no WPA/RSN IE 2: 00:13:10:ee:a9:5e ssid='sam' wpa_ie_len=0 rsn_ie_len=0 caps=0x10 skip - no WPA/RSN IE 3: 00:09:5b:ad:ed:5e ssid='Styx' wpa_ie_len=0 rsn_ie_len=0 caps=0x10 skip - no WPA/RSN IE selected non-WPA AP 00:11:50:a6:19:92 ssid='XXX' Trying to associate with 00:11:50:a6:19:92 (SSID='XXX' freq=2462 MHz) Cancelling scan request WPA: clearing own WPA/RSN IE Automatic auth_alg selection: 0x1 WPA: clearing AP WPA IE WPA: clearing AP RSN IE WPA: clearing own WPA/RSN IE No keys have been configured - skip key clearing State: SCANNING -> ASSOCIATING ndis_set_oid: oid=0xd010119 len (4) failed NDIS: Failed to set OID_802_11_PRIVACY_FILTER (0) Setting authentication timeout: 10 sec 0 usec EAPOL: External notification - portControl=ForceAuthorized ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed NDIS: ReqFixed=0x3 RespFixed=0x7 off_req=40 off_resp=82 len_req=42 len_resp=16ec 0 usec EAPOL: External notification - portControl=ForceAuthorized ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_get_oid: oid=0xd010101 len (6) failed === Here I run > ifconfig ndis0 ssid XXX ndis_get_oid: oid=0xd010101 len (6) failed NDIS: ReqFixed=0x3 RespFixed=0x7 off_req=40 off_resp=82 len_req=42 len_resp=16 NDIS: 4 BSSID items to process for AssocInfo Association info event req_ies - hexdump(len=42): 00 08 58 58 58 58 58 58 58 58 01 08 82 84 8b 96 24 30 48 6c 32 04 0c 12 18 60 dd 06 00 40 96 01 01 00 dd 06 00 10 18 02 00 00 resp_ies - hexdump(len=16): 01 04 82 84 8b 96 32 08 0c 12 18 24 30 48 60 6c beacon_ies - hexdump(len=54): 00 08 58 58 58 58 58 58 58 58 01 04 82 84 8b 96 03 01 0b 04 06 01 02 00 00 00 00 05 04 00 01 00 00 2a 01 02 32 08 0c 12 18 24 30 48 60 6c 04 06 00 02 00 00 00 00 WPA: clearing own WPA/RSN IE WPA: clearing AP WPA IE WPA: clearing AP RSN IE State: ASSOCIATING -> ASSOCIATED Associated to a new BSS: BSSID=00:11:50:a6:19:92 Associated with 00:11:50:a6:19:92 WPA: Association event - clear replay counter EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 EAPOL: External notification - portEnabled=1 EAPOL: SUPP_PAE entering state S_FORCE_AUTH EAPOL: SUPP_BE entering state IDLE Cancelling authentication timeout State: ASSOCIATED -> COMPLETED CTRL-EVENT-CONNECTED - Connection to 00:11:50:a6:19:92 completed (auth) ndis_get_oid: oid=0xd010101 len (6) failed Setting scan request: 0 sec 100000 usec Added BSSID 00:11:50:a6:19:92 into blacklist State: COMPLETED -> DISCONNECTED EAPOL: External notification - portEnabled=0 EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: SUPP_BE entering state INITIALIZE EAPOL: External notification - portValid=0 CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys State: DISCONNECTED -> SCANNING Starting AP scan (specific SSID) Scan SSID - hexdump_ascii(len=8): 58 58 58 XXX ndis_set_oid: oid=0xd01011a len (4) failed Failed to initiate AP scan. Setting scan request: 10 sec 0 usec ndis_get_oid: oid=0xd010101 len (6) failed NDIS: ReqFixed=0x3 RespFixed=0x7 off_req=40 off_resp=82 len_req=42 len_resp=16 NDIS: 1 BSSID items to process for AssocInfo Association info event req_ies - hexdump(len=42): 00 08 58 58 58 58 58 58 58 58 01 08 82 84 8b 96 24 30 48 6c 32 04 0c 12 18 60 dd 06 00 40 96 01 01 00 dd 06 00 10 18 02 00 00 resp_ies - hexdump(len=16): 01 04 82 84 8b 96 32 08 0c 12 18 24 30 48 60 6c beacon_ies - hexdump(len=46): 00 08 58 58 58 58 58 58 58 58 01 04 82 84 8b 96 03 01 0b 04 06 00 02 00 00 00 00 05 04 00 01 00 00 2a 01 02 32 08 0c 12 18 24 30 48 60 6c WPA: clearing own WPA/RSN IE WPA: clearing AP WPA IE WPA: clearing AP RSN IE State: SCANNING -> ASSOCIATED Associated to a new BSS: BSSID=00:11:50:a6:19:92 Associated with 00:11:50:a6:19:92 WPA: Association event - clear replay counter EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 EAPOL: External notification - portEnabled=1 EAPOL: SUPP_PAE entering state S_FORCE_AUTH EAPOL: SUPP_BE entering state IDLE Cancelling authentication timeout Removed BSSID 00:11:50:a6:19:92 from blacklist State: ASSOCIATED -> COMPLETED CTRL-EVENT-CONNECTED - Connection to 00:11:50:a6:19:92 completed (reauth) --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Description: bsd.log Content-Disposition: attachment; filename="bsd.log" > wpa_supplicant -c /etc/wpa_supplicant.conf -i ndis0 -D bsd -d Initializing interface 'ndis0' conf '/etc/wpa_supplicant.conf' driver 'bsd' ctrl_interface 'N/A' Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf' Reading configuration file '/etc/wpa_supplicant.conf' ctrl_interface='/var/run/wpa_supplicant' ctrl_interface_group=0 (from group name 'wheel') ap_scan=1 Priority group 5 id=0 ssid='XXX' Initializing interface (2) 'ndis0' EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: KEY_RX entering state NO_KEY_RECEIVE EAPOL: SUPP_BE entering state INITIALIZE EAP: EAP entering state DISABLED EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 Own MAC address: 00:14:a5:50:67:9e wpa_driver_bsd_set_wpa: enabled=1 wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1 wpa_driver_bsd_del_key: keyidx=0 wpa_driver_bsd_del_key: keyidx=1 wpa_driver_bsd_del_key: keyidx=2 wpa_driver_bsd_del_key: keyidx=3 wpa_driver_bsd_set_countermeasures: enabled=0 wpa_driver_bsd_set_drop_unencrypted: enabled=1 Setting scan request: 0 sec 100000 usec Added interface ndis0 State: DISCONNECTED -> SCANNING Starting AP scan (specific SSID) Scan SSID - hexdump_ascii(len=8): 58 58 58 XXX Received 0 bytes of scan results (1 BSSes) Scan results: 1 Selecting BSS from priority group 5 0: 00:11:50:a6:19:92 ssid='XXX' wpa_ie_len=0 rsn_ie_len=0 caps=0x0 skip - no WPA/RSN IE selected non-WPA AP 00:11:50:a6:19:92 ssid='XXX' Trying to associate with 00:11:50:a6:19:92 (SSID='XXX' freq=2462 MHz) Cancelling scan request WPA: clearing own WPA/RSN IE Automatic auth_alg selection: 0x1 WPA: clearing AP WPA IE WPA: clearing AP RSN IE WPA: clearing own WPA/RSN IE No keys have been configured - skip key clearing wpa_driver_bsd_set_drop_unencrypted: enabled=0 State: SCANNING -> ASSOCIATING wpa_driver_bsd_associate: ssid 'XXX' wpa ie len 0 pairwise 0 group 0 key mgmt 2 wpa_driver_bsd_associate: set PRIVACY 0 ioctl[SIOCS80211, op 21, len 42]: Invalid argument Association request to the driver failed Setting authentication timeout: 5 sec 0 usec EAPOL: External notification - portControl=ForceAuthorized Authentication with 00:00:00:00:00:00 timed out. Added BSSID 00:00:00:00:00:00 into blacklist State: ASSOCIATING -> DISCONNECTED No keys have been configured - skip key clearing EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 Setting scan request: 0 sec 0 usec - skip key clearing wpa_driver_bsd_set_drop_unencrypted: enabled=0 State: SCANNING -> ASSOCIATING wpa_driver_bsd_associate: ssid 'XXX' wpa ie len 0 pairwise 0 group 0 key mgmt 2 wpa_driver_bsd_associate: set PRIVACY 0 ioctl[SIOCS80211, op 21, len 42]: Invalid argument Association request to the driver failed Setting authentication timeout: 5 sec 0 usec EAPOL: External notification - portControl=ForceAuthorized Authentication with 00:00:00:00:00:00 timed out. Added BSSID 00:00:00:00:00:00 into blacklist State: ASSOCIATING -> DISCONNECTED No keys have been configured - skip key clearing EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 Setting scan request: 0 sec 0 usec State: DISCONNECTED -> SCANNING Starting AP scan (broadcast SSID) Received 0 bytes of scan results (3 BSSes) Scan results: 3 Selecting BSS from priority group 5 0: 00:11:50:a6:19:92 ssid='XXX' wpa_ie_len=0 rsn_ie_len=0 caps=0x1 skip - no WPA/RSN IE 1: 00:14:a4:4d:59:06 ssid='140a' wpa_ie_len=0 rsn_ie_len=0 caps=0x11 skip - no WPA/RSN IE 2: 00:13:10:ee:a9:5e ssid='sam' wpa_ie_len=0 rsn_ie_len=0 caps=0x11 skip - no WPA/RSN IE selected non-WPA AP 00:11:50:a6:19:92 ssid='XXX' Trying to associate with 00:11:50:a6:19:92 (SSID='XXX' freq=2462 MHz) Cancelling scan request WPA: clearing own WPA/RSN IE Automatic auth_alg selection: 0x1 WPA: clearing AP WPA IE WPA: clearing AP RSN IE WPA: clearing own WPA/RSN IE No keys have been configured - skip key clearing wpa_driver_bsd_set_drop_unencrypted: enabled=0 State: SCANNING -> ASSOCIATING wpa_driver_bsd_associate: ssid 'XXX' wpa ie len 0 pairwise 0 group 0 key mgmt 2 wpa_driver_bsd_associate: set PRIVACY 0 Setting authentication timeout: 10 sec 0 usec EAPOL: External notification - portControl=ForceAuthorized === Here, I see: > ifconfig ndis0 | ndis0: flags=8843 mtu 1500 | inet 192.168.2.52 netmask 0xffffff00 broadcast 192.168.2.255 | ether 00:14:a5:50:67:9e | media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) | status: associated | ssid XXX channel 11 bssid 00:11:50:a6:19:92 | authmode OPEN privacy OFF deftxkey 1 txpowmax 100 protmode CTS | roaming MANUAL Authentication with 00:00:00:00:00:00 timed out. BSSID 00:00:00:00:00:00 blacklist count incremented to 2 State: ASSOCIATING -> DISCONNECTED No keys have been configured - skip key clearing EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 Setting scan request: 0 sec 0 usec State: DISCONNECTED -> SCANNING --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Description: wpa_supplicant.conf Content-Disposition: attachment; filename="wpa.conf" ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel ap_scan=1 network={ ssid="XXX" scan_ssid=1 priority=5 key_mgmt=NONE eapol_flags=0 } --OXfL5xGRrasGEqWY-- From owner-freebsd-net@FreeBSD.ORG Sat Aug 5 18:53:50 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AFAC16A4DA for ; Sat, 5 Aug 2006 18:53:50 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.FreeBSD.org (Postfix) with SMTP id D51A043D4C for ; Sat, 5 Aug 2006 18:53:48 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 25936 invoked by uid 399); 5 Aug 2006 18:53:48 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 5 Aug 2006 18:53:48 -0000 Message-ID: <44D4E939.3060607@FreeBSD.org> Date: Sat, 05 Aug 2006 11:53:45 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.5 (X11/20060729) MIME-Version: 1.0 To: Dylan Alex Simon References: <20060805153714.GA22424@dylex.dylex.net> In-Reply-To: <20060805153714.GA22424@dylex.dylex.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: wpa_supplicant on ndis cannot associate X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 18:53:50 -0000 Dylan Alex Simon wrote: > This is on latest RELENG_6_1. > > I'm using an ndis driver with a Dell TrueMobile 1300 (Latitude D610). I have a 1400 on a D800. > Does anyone have wpa_supplicant working on an ndis driver? Are you by any chance not broadcasting the ssid on the WAP? I had problems similar to what you described when I turned that feature off, but when I turned it back on (so the WAP was broadcasting its ssid again) everything worked fine with wpa-psk and TKIP, and -D ndis. (I could not get any "higher" level of WPA working, but that's another story.) hth, Doug -- This .signature sanitized for your protection