Re: Question about NIC link state initialization
On Wed, 29 Jun 2011, per...@pluto.rain.com wrote: Steve Polyack kor...@comcast.net wrote: ... An occaisional fat-finger in /etc/fstab may cause one to end up in single-user mode ... some of these systems have a LOM (lights-out management) controller which shares the system's on-board NICs ... when the system drops out of init(8) and into single-user mode, the links on the interfaces never come up, and therefore the LOM becomes inaccessible. ... all one has to do is run ifconfig to cause the NIC's links to come up ... why do we have to run ifconfig(8) to bring the links up on the attached interfaces? When trying to troubleshoot a problem that was known or suspected to involve the network or its hardware, one might not _want_ the NICs Well, maybe, but if the system needs to boot into multi-user mode for the LOM to be available, what is the need for the LOM? At that point you can do everything you might need through the OS interface. Can I ask what is the brand of this so-called LOM? Is there any documentation implying something more useful? Do they describe doing a bare metal install of an OS? Daniel Feenberg ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/158426: [e1000] [panic] _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676
The following reply was made to PR kern/158426; it has been noted by GNATS. From: Sergey Kandaurov pluk...@gmail.com To: bug-follo...@freebsd.org, t...@vr-web.de Cc: Subject: Re: kern/158426: [e1000] [panic] _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676 Date: Thu, 30 Jun 2011 15:54:33 +0400 --0016e64aefda827b7b04a6ec9043 Content-Type: text/plain; charset=ISO-8859-1 The problem is that locking scope in MDL6 code is too wide. That results in that mld_set_version() is called with if_addr_mtx held, and then mld_set_version() locks it itself once again. Please try this patch (attached). -- wbr, pluknet --0016e64aefda827b7b04a6ec9043 Content-Type: text/plain; charset=US-ASCII; name=mld6.locking.txt Content-Disposition: attachment; filename=mld6.locking.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_gpjnoi020 SW5kZXg6IHN5cy9uZXRpbmV0Ni9tbGQ2LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25ldGluZXQ2L21s ZDYuYwkocmV2aXNpb24gMjIzMDczKQorKysgc3lzL25ldGluZXQ2L21sZDYuYwkod29ya2luZyBj b3B5KQpAQCAtNjgwLDcgKzY4MCw2IEBACiAKIAlJTjZfTVVMVElfTE9DSygpOwogCU1MRF9MT0NL KCk7Ci0JSUZfQUREUl9MT0NLKGlmcCk7CiAKIAkvKgogCSAqIFN3aXRjaCB0byBNTER2MSBob3N0 IGNvbXBhdGliaWxpdHkgbW9kZS4KQEAgLTcwMCw2ICs2OTksNyBAQAogCQkgKi8KIAkJQ1RSMihL VFJfTUxELCAicHJvY2VzcyB2MSBnZW5lcmFsIHF1ZXJ5IG9uIGlmcCAlcCglcykiLAogCQkgICAg aWZwLCBpZnAtPmlmX3huYW1lKTsKKwkJSUZfQUREUl9MT0NLKGlmcCk7CiAJCVRBSUxRX0ZPUkVB Q0goaWZtYSwgJmlmcC0+aWZfbXVsdGlhZGRycywgaWZtYV9saW5rKSB7CiAJCQlpZiAoaWZtYS0+ aWZtYV9hZGRyLT5zYV9mYW1pbHkgIT0gQUZfSU5FVDYgfHwKIAkJCSAgICBpZm1hLT5pZm1hX3By b3Rvc3BlYyA9PSBOVUxMKQpAQCAtNzA3LDYgKzcwNyw3IEBACiAJCQlpbm0gPSAoc3RydWN0IGlu Nl9tdWx0aSAqKWlmbWEtPmlmbWFfcHJvdG9zcGVjOwogCQkJbWxkX3YxX3VwZGF0ZV9ncm91cChp bm0sIHRpbWVyKTsKIAkJfQorCQlJRl9BRERSX1VOTE9DSyhpZnApOwogCX0gZWxzZSB7CiAJCS8q CiAJCSAqIE1MRHYxIEdyb3VwLVNwZWNpZmljIFF1ZXJ5LgpAQCAtNzI0LDcgKzcyNSw2IEBACiAJ CWluNl9jbGVhcnNjb3BlKCZtbGQtPm1sZF9hZGRyKTsKIAl9CiAKLQlJRl9BRERSX1VOTE9DSyhp ZnApOwogCU1MRF9VTkxPQ0soKTsKIAlJTjZfTVVMVElfVU5MT0NLKCk7CiAKQEAgLTg4OCw3ICs4 ODgsNiBAQAogCiAJSU42X01VTFRJX0xPQ0soKTsKIAlNTERfTE9DSygpOwotCUlGX0FERFJfTE9D SyhpZnApOwogCiAJbWxpID0gTUxEX0lGSU5GTyhpZnApOwogCUtBU1NFUlQobWxpICE9IE5VTEws ICgiJXM6IG5vIG1sZF9pZmluZm8gZm9yIGlmcCAlcCIsIF9fZnVuY19fLCBpZnApKTsKQEAgLTk2 NCw3ICs5NjMsNiBAQAogCX0KIAogb3V0X2xvY2tlZDoKLQlJRl9BRERSX1VOTE9DSyhpZnApOwog CU1MRF9VTkxPQ0soKTsKIAlJTjZfTVVMVElfVU5MT0NLKCk7CiAK --0016e64aefda827b7b04a6ec9043-- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/158426: [e1000] [panic] _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676
Synopsis: [e1000] [panic] _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676 State-Changed-From-To: open-feedback State-Changed-By: pluknet State-Changed-When: Thu Jun 30 12:16:24 UTC 2011 State-Changed-Why: Feedback requested. http://www.freebsd.org/cgi/query-pr.cgi?pr=158426 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Question about NIC link state initialization
On 6/30/2011 1:10 AM, per...@pluto.rain.com wrote: Steve Polyackkor...@comcast.net wrote: ... An occaisional fat-finger in /etc/fstab may cause one to end up in single-user mode ... some of these systems have a LOM (lights-out management) controller which shares the system's on-board NICs ... when the system drops out of init(8) and into single-user mode, the links on the interfaces never come up, and therefore the LOM becomes inaccessible. ... all one has to do is run ifconfig to cause the NIC's links to come up ... why do we have to run ifconfig(8) to bring the links up on the attached interfaces? When trying to troubleshoot a problem that was known or suspected to involve the network or its hardware, one might not _want_ the NICs alive. Short of patching init(8) (or perhaps the NIC drivers?), I don't see another way for me to ensure the links come up even when the system drops into single-user mode on boot. Something in /root/.profile, perhaps? That should get run when the single-user shell starts up, if it's started as a login shell. This won't work. When the system kicks you into single-user mode, you are prompted to enter the name of a shell or press enter for /bin/sh. If no one is there to press enter, or enter the path to an alternate shell, then a shell never starts. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Question about NIC link state initialization
On 6/30/2011 6:49 AM, Daniel Feenberg wrote: On Wed, 29 Jun 2011, per...@pluto.rain.com wrote: Steve Polyack kor...@comcast.net wrote: ... An occaisional fat-finger in /etc/fstab may cause one to end up in single-user mode ... some of these systems have a LOM (lights-out management) controller which shares the system's on-board NICs ... when the system drops out of init(8) and into single-user mode, the links on the interfaces never come up, and therefore the LOM becomes inaccessible. ... all one has to do is run ifconfig to cause the NIC's links to come up ... why do we have to run ifconfig(8) to bring the links up on the attached interfaces? When trying to troubleshoot a problem that was known or suspected to involve the network or its hardware, one might not _want_ the NICs Well, maybe, but if the system needs to boot into multi-user mode for the LOM to be available, what is the need for the LOM? At that point you can do everything you might need through the OS interface. Can I ask what is the brand of this so-called LOM? Is there any documentation implying something more useful? Do they describe doing a bare metal install of an OS? They are the Dell Remote Access Controllers (DRACs). Now, they do have their own dedicated NIC, which we use for anything that really needs the attention. However, the shared feature saves us a switchport per server we use it on. When both on-board NICs are cabled (i.e. for lagg(4) failover), then the DRAC's shared NIC mode *also* supports automatic failover between both on-board NICs. This doesn't help however if the operating system never turns on the links to either on-board NIC. I was able to fix the single-user mode behavior (which I agree, isn't necessarily broken) and get it to bring up the links by simply patching init(8) to call system(/sbin/ifconfig) before prompting for the single-user shell. It works, but I feel dirty. - Steve ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: fwd: kern/157188: [libpcap] [patch] incorporate patch from upstream
I suggest bugging bz@ as much as possible. :) Adrian On 28 June 2011 08:25, Wesley Shields w...@freebsd.org wrote: I'm still hoping someone who cares about IPv6 is willing to commit this fix for libpcap in the base before 9.0. Is anyone willing to tackle this? It's been in the port for a while now, and in upstream for even longer. -- WXS On Sun, May 22, 2011 at 03:30:07PM -0400, Wesley Shields wrote: I've updated the port to address this. The audit trail for this PR has a patch which touches more than just libpcap. I'm curious if anyone on this list has comments on it, and if any committer wants to commit it (at least the libpcap part, the others appear right to me). -- WXS On Sat, May 21, 2011 at 01:48:47AM -0500, Mark Linimon wrote: Apparently affects both the port and src. mcl On Thu, May 19, 2011 at 09:53:57PM +, Peter Losher wrote: Number: 157188 Category: misc Synopsis: libpcap Confidential: no Severity: non-critical Priority: medium Responsible: freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Thu May 19 22:00:27 UTC 2011 Closed-Date: Last-Modified: Originator: Peter Losher Release: 8.2-RELEASE Organization: Internet Systems Consortium Environment: FreeBSD freebsd8.lab.isc.org 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Description: One of our engineers @ISC discovered that there is a bug in the currently released version of libpcap (in base and in ports) that can be triggered when using an ip6 protochain filter. It's due to the fairly complicated BPF bytecode that libpcap generates for IPv6 header chasing combined with a sign extension bug when processing JA (jump absolute) opcodes. (JA is used to go backwards and without sign extension on 64 bit platforms the BPF interpreter incorrectly jumps forward... a lot.) How-To-Repeat: root@freebsd8:~# tcpdump -nr ip6-hopbyhop-icmp.pcap 'ip6 protochain 58' reading from file ip6-hopbyhop-icmp.pcap, link-type EN10MB (Ethernet) Segmentation fault: 11 (core dumped) Fix: There is a fix in the libpcap repository: https://github.com/mcr/libpcap/commit/ecdc5c0a7f7591a7cd4aff696e42757c677fbbf7 but the tcpdump-workers have been pretty tardy about putting out newer code, so it sits there stalled. With the patch applied, it all works well and you should see something like this: -=- $ tcpdump -nr ip6-hopbyhop-icmp.pcap 'ip6 protochain 58' reading from file ip6-hopbyhop-icmp.pcap, link-type EN10MB (Ethernet) 18:43:07.098489 IP6 fe80::208:7dff:feb7:2cca ff02::1: HBH ICMP6, multicast listener queryv2 [gaddr ::], length 28 -=- Release-Note: Audit-Trail: Unformatted: ___ freebsd-b...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Bridging Two Tunnel Interfaces For ALTQ
On 6/29/11 11:28 AM, Michael MacLeod wrote: I use pf+ALTQ to achieve some pretty decent traffic shaping results at home. However, recently signed up to be part of an IPv6 trial with my ISP, and they've given me a second (dual-stacked) PPPoE login with which to test with. The problem is that the second login lacks my static IP or my routed /29. I can have both tunnels up simultaneously, but that becomes a pain to traffic shape since I can't have them both assigned to the same ALTQ. ... unless there is some way for me to turn the ng interfaces (I'm using mpd5) into ethernet interfaces that could be assigned to an if_bridge. I could easily disable IPv4 on the IPv6 tunnel, which would clean up any routing issues, assign both tunnels to the bridge, and put the ALTQ on the bridge. It just might have the effect I'm looking for. Bonus points if the solution can be extended to allow it to work with a gif tunnel as well, so that users of 6in4 tunnels could use it (my ISPs IPv6 beta won't let me do rDNS delegation, so I might want to try a tunnel from he.net instead). I spent some time this morning trying to make netgraph do this with the two ng interfaces, but didn't have any luck. Google didn't turn up anyone trying to do anything similar that I could find; closest I got was this: http://lists.freebsd.org/pipermail/freebsd-net/2004-November/005598.html This is all assuming that the best way to use ALTQ on multiple outbound connections is with a bridge. If there is another or more elegant solution, I'd love to hear it. rather than trying to shoehorn ng into if_bridge, why not use the netgraph bridge itility, or maybe one of the many other netgraph nodes that can split traffic. fofr example the ng_bpf filter can filter traffic on an almost arbitrary manner that you program using the bpf filter language. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
