watchdog timeout
Hello, i did sent this mine message to stable mail list, then i found that your address is a manteiner for some bugs. I'm asking if this one article: http://www.freebsd.org/cgi/query-pr.cgi?pr=129352 Has updates, since i haven't found any new, 'cause it's talking about PRERELEASE and i'm working on 6.4-STABLE, also how can it is possible to have a compiled kernel on january and it have this bug still present? Thand in advance for a your responce Regards -- From: "xer" Sent: Wednesday, April 08, 2009 10:41 AM To: Subject: watchdog timeout Hello I have some problems with 3Com nics, after a upgrade from 5.5-STABLE to 6.4-STABLE. This machine has two 3com nics (one is LAN other is WAN) and i see too much "watchdog timeout" on both cards. This on/off up/down on cards, affect the interrupt to clients that are downloading from apache web server, especially on large files. xer:/root# dmesg xl1: watchdog timeout xl1: link state changed to DOWN xl1: link state changed to UP xl1: watchdog timeout xl1: link state changed to DOWN xl1: link state changed to UP xl1: watchdog timeout xl1: link state changed to DOWN xl1: link state changed to UP - xer:/root# cat /var/run/dmesg.boot | grep xl xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xec00-0xec7f mem 0xfceffc00-0xfceffc7f irq 23 at device 11.0 on pci2 miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:01:02:e0:04:1b xl1: <3Com 3c905C-TX Fast Etherlink XL> port 0xe880-0xe8ff mem 0xfceff800-0xfceff87f irq 20 at device 12.0 on pci2 miibus1: on xl1 xlphy1: <3c905C 10/100 internal PHY> on miibus1 xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl1: Ethernet address: 00:01:02:df:fe:ed - Another doubt would be my kernel config, maybe there is something wrong that i cannot see, i'll post at the end of this post, 'cause is too long. As you can see, the cards are 3c905C-TX model. Someone told me to change drivers, but i cannot understand this advice. I got same errors with same cards but with another mainboard, same problem, watchdog appears after an upgrade from 5.4-STABLE to 6.4-STABLE. I don't think that to change nic's pci slots, will solve the problem, i think that maybe change the nics would resolve the matter, but i cannot access to both FreeBSD phisically, cause the boxes are too far from me (about 3500 km). I'm asking you some advices, and i can i fix this problem. p.s. with both 5.4 or 5.5 old kernel, the nics was fine. Regards Xer --kernel config --- xer:/root# cat /usr/src/sys/i386/conf/ASUS # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.429.2.18 2008/07/28 02:20:29 yongari Exp $ # # custom kernel ASUS 01.15.2009 machine i386 cpu I686_CPU ident ASUS options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_GPT# GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic
Re: kern/131310: [netgraph] [panic] 7.1 panics with mpd netgraph interface changes
The following reply was made to PR kern/131310; it has been noted by GNATS. From: Mikolaj Golub To: bug-follo...@freebsd.org,Vitaly Dodonov Cc: Semenchuk Oleg Subject: Re: kern/131310: [netgraph] [panic] 7.1 panics with mpd netgraph interface changes Date: Fri, 10 Apr 2009 15:09:38 +0300 This pr is closely related to kern/130977. You can try the patch from it, which adds if_delgroup(ifp, IFG_ALL) to if_detach(). -- Mikolaj Golub ___ 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: IPv6 window scaling factor always 1 on initial SYN
On Tue, 7 Apr 2009, sth...@nethelp.no wrote: I changed it, and that worked like a dream. Now I get basically the same throughput with IPv4 and IPv6. There are of course still issues like lots of IPv6 tunnels that add extra latency - but that's not the fault of FreeBSD. Anyway, thanks for your work. Below is a context diff (against 7-STABLE cvsupped last night). Do we need a PR to get this into FreeBSD? It's in HEAD now as of SVN r190800. Excellent news, thank you! And presumably we'll get a MFC after a suitable settling time? If 3 days were suitable;) It'll be part of 7.2-R as it is in stable/7 now. Thanks a lot for reporting and testing! /bz -- Bjoern A. Zeeb The greatest risk is not taking one. ___ 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/131310: commit references a PR
The following reply was made to PR kern/131310; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/131310: commit references a PR
Date: Fri, 10 Apr 2009 14:42:02 + (UTC)
Author: mlaier
Date: Fri Apr 10 14:41:51 2009
New Revision: 190895
URL: http://svn.freebsd.org/changeset/base/190895
Log:
Remove interfaces from IFG_ALL on detach. This cures a couple of pf panics
when using the "self" keyword in tables or as ()-style host address and
fixes "ifconfig -g all" output.
PR: kern/130977, kern/131310
Submitted by:Mikolaj Golub
MFC after: 3 days
Modified:
head/sys/net/if.c
Modified: head/sys/net/if.c
==
--- head/sys/net/if.c Fri Apr 10 14:24:12 2009(r190894)
+++ head/sys/net/if.c Fri Apr 10 14:41:51 2009(r190895)
@@ -887,6 +887,7 @@ if_detach(struct ifnet *ifp)
rt_ifannouncemsg(ifp, IFAN_DEPARTURE);
EVENTHANDLER_INVOKE(ifnet_departure_event, ifp);
devctl_notify("IFNET", ifp->if_xname, "DETACH", NULL);
+ if_delgroup(ifp, IFG_ALL);
IF_AFDATA_LOCK(ifp);
for (dp = domains; dp; dp = dp->dom_next) {
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-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"
m_tag, malloc vs uma
Hello, Is there any plans on getting the mbuf tags sub-system integrated with the universal memory allocator? Getting tags for mbufs is still calling malloc in uipc_mbuf.c ... What would be the benefits of using uma instead? Karim. ___ 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: Multi-BSS problem with Atheros 5212
Sam Leffler wrote: Sam Leffler wrote: Boris Kochergin wrote: Ahoy. I'm having trouble with multiple hostap-mode wlan pseudo-devices. The machine is an 8-CURRENT from yesterday: # uname -a FreeBSD test 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Tue Apr 7 16:54:56 UTC 2009 r...@test:/usr/obj/usr/src/sys/GENERIC i386 # dmesg | grep ath ath0: mem 0xf410-0xf410 irq 11 at device 13.0 on pci0 ath0: [ITHREAD] ath0: AR2413 mac 7.9 RF2413 phy 4.5 # cat /etc/rc.conf wlans_ath0="wlan0 wlan1 wlan2" create_args_wlan0="wlanmode hostap bssid" create_args_wlan1="wlanmode hostap bssid" create_args_wlan2="wlanmode hostap bssid" ifconfig_wlan0="ssid wlan0 wepmode off up" ifconfig_wlan1="ssid wlan1 wepmode off up" ifconfig_wlan2="ssid wlan2 wepmode off up" # ifconfig ath0: flags=8843 metric 0 mtu 2290 ether 00:18:e7:33:5e:24 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running fxp0: flags=8843 metric 0 mtu 1500 options=8 ether 00:90:27:72:c4:f3 inet 10.0.0.128 netmask 0xff00 broadcast 10.0.0.255 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 wlan0: flags=8843 metric 0 mtu 1500 ether 00:18:e7:33:5e:24 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid wlan0 channel 11 (2462 Mhz 11g) bssid 00:18:e7:33:5e:24 country US ecm authmode OPEN privacy OFF txpower 23 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs wlan1: flags=8843 metric 0 mtu 1500 ether 06:18:e7:33:5e:24 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid wlan1 channel 11 (2462 Mhz 11g) bssid 06:18:e7:33:5e:24 country US ecm authmode OPEN privacy OFF txpower 23 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs wlan2: flags=8843 metric 0 mtu 1500 ether 0a:18:e7:33:5e:24 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid wlan2 channel 11 (2462 Mhz 11g) bssid 0a:18:e7:33:5e:24 country US ecm authmode OPEN privacy OFF txpower 23 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs The client is a 7.0 machine with another 5212 card: # uname -a FreeBSD peer 7.0-RELEASE-p10 FreeBSD 7.0-RELEASE-p10 #0: Mon Mar 23 09:26:18 EDT 2009 r...@peer:/usr/obj/usr/src/sys/PEER i386 # dmesg | grep ath ath_hal: 0.10.5.6 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417) ath0: mem 0xa841-0xa841 irq 11 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: Ethernet address: 00:14:d1:42:21:5a ath0: mac 7.9 phy 4.5 radio 5.6 The three SSIDs configured on the CURRENT machine show up in a scan: # ifconfig ath0 scan | grep wlan wlan0 00:18:e7:33:5e:24 11 54M -66:-93 100 ES WME wlan1 06:18:e7:33:5e:24 11 54M -65:-93 100 ES WME wlan2 0a:18:e7:33:5e:24 11 54M -65:-93 100 ES WME The client is only able to associate with wlan1, however. When scanning channels while attempting to associate with any of the other ones, it gets stuck on channel 11 for a while before moving on, which seems relevant. Also interesting is the fact that if i do "ifconfig ath0 down" on the CURRENT machine, followed by, for example, "ifconfig ath0 ssid wlan0" (which did not associate before) on the client, followed by "ifconfig ath0 up" on the CURRENT machine, the client will associate with wlan0, but will not be able to associate with wlan1 or wlan2. Any ideas? wlandebug scan+auth+assoc on the client machine will show you why you cannot associate. You can also enable the same info on the ap side to see what it thinks is happening. FWIW I just setup 3 vap's as you did above and hooked them into a bridge. I verified I could associate and pass traffic using a MBPro. No problems. I also destroyed the bridge and re-tested w/o issues. Regardless the debug msgs should identify what your problem is. Sam ___ 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" I booted the hostap machine up and set wlandebug to scan+auth+assoc on wlan0, wlan1, and wlan2. I then inserted the PCMCIA card into the client machine, set wlandebug to scan+auth+assoc on it (ath0), and executed "ifconfig ath0 ssid wlan0 up". I let it scan around for a bit. The client-side debug messages are at http://acm.poly.edu/~spawk/wlan/wlan0.client, and the hostap machine did not emit any debug messages during the association attempts. I then ejected the card from the client and repeated the process for wlan1 (it associated). The
Re: m_tag, malloc vs uma
On Fri, 10 Apr 2009, Karim Fodil-Lemelin wrote: Is there any plans on getting the mbuf tags sub-system integrated with the universal memory allocator? Getting tags for mbufs is still calling malloc in uipc_mbuf.c ... What would be the benefits of using uma instead? Hi Karim: Right now there are no specific plans for changes along these lines, although we have talked about moving towards better support for deep objects in m_tags. Right now, MAC requires a "deep" copy, because labels may be complex objects, and this is special-cased in the m_tag code. One way to move in that direction would be to move from an explicit m_tag free pointer to a pointer to a vector of copy, free, etc, operations. This would make it easier to support more flexible memory models there, rather than forcing the use of malloc(9). That said, malloc(9) for "small" memory types is essentially a thin wrapper accounting around a set of fixed-size UMA zones: ITEM SIZE LIMIT USED FREE REQUESTS FAILURES 16:16,0, 3703, 966, 55930783,0 32:32,0, 1455, 692, 30720298,0 64:64,0, 4794, 1224, 38352819,0 128: 128,0, 3169, 341, 5705218,0 256: 256,0, 1565, 535, 48338889,0 512: 512,0, 386, 494, 9962475,0 1024:1024,0, 66, 354, 3418306,0 2048:2048,0, 314, 514,29945,0 4096:4096,0, 250, 279, 4567645,0 For larger memory sizes, malloc(9) becomes instead a thin wrapper around VM allocation of kernel address space and pages. So as long as you're using smaller objects, malloc(9) actually offers most of the benefits of slab allocation. Because m_tag(9) is an interface used for a variety of base system and third party parts, changes to the KPI would need to be made with a major FreeBSD release -- for example with 8.0. Such a change is definitely not precluded at this point, but in a couple of months we'll hit feature freeze and it won't be possible to make those changes after that time. Robert N M Watson Computer Laboratory University of Cambridge ___ 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/131310: commit references a PR
The following reply was made to PR kern/131310; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/131310: commit references a PR
Date: Fri, 10 Apr 2009 19:16:29 + (UTC)
Author: mlaier
Date: Fri Apr 10 19:16:14 2009
New Revision: 190903
URL: http://svn.freebsd.org/changeset/base/190903
Log:
Follow up for r190895 It's not only the "all" group that is affected, but
all groups on the given interface.
PR: kern/130977, kern/131310
MFC after: 3 days (%vnet)
Modified:
head/sys/net/if.c
Modified: head/sys/net/if.c
==
--- head/sys/net/if.c Fri Apr 10 18:46:46 2009(r190902)
+++ head/sys/net/if.c Fri Apr 10 19:16:14 2009(r190903)
@@ -141,6 +141,7 @@ static int if_delmulti_locked(struct ifn
static void do_link_state_change(void *, int);
static intif_getgroup(struct ifgroupreq *, struct ifnet *);
static intif_getgroupmembers(struct ifgroupreq *);
+static void if_delgroups(struct ifnet *);
#ifdef INET6
/*
@@ -887,7 +888,7 @@ if_detach(struct ifnet *ifp)
rt_ifannouncemsg(ifp, IFAN_DEPARTURE);
EVENTHANDLER_INVOKE(ifnet_departure_event, ifp);
devctl_notify("IFNET", ifp->if_xname, "DETACH", NULL);
- if_delgroup(ifp, IFG_ALL);
+ if_delgroups(ifp);
IF_AFDATA_LOCK(ifp);
for (dp = domains; dp; dp = dp->dom_next) {
@@ -1025,6 +1026,54 @@ if_delgroup(struct ifnet *ifp, const cha
}
/*
+ * Remove an interface from all groups
+ */
+static void
+if_delgroups(struct ifnet *ifp)
+{
+ INIT_VNET_NET(ifp->if_vnet);
+ struct ifg_list *ifgl;
+ struct ifg_member *ifgm;
+ char groupname[IFNAMSIZ];
+
+ IFNET_WLOCK();
+ while (!TAILQ_EMPTY(&ifp->if_groups)) {
+ ifgl = TAILQ_FIRST(&ifp->if_groups);
+
+ strlcpy(groupname, ifgl->ifgl_group->ifg_group, IFNAMSIZ);
+
+ IF_ADDR_LOCK(ifp);
+ TAILQ_REMOVE(&ifp->if_groups, ifgl, ifgl_next);
+ IF_ADDR_UNLOCK(ifp);
+
+ TAILQ_FOREACH(ifgm, &ifgl->ifgl_group->ifg_members, ifgm_next)
+ if (ifgm->ifgm_ifp == ifp)
+ break;
+
+ if (ifgm != NULL) {
+ TAILQ_REMOVE(&ifgl->ifgl_group->ifg_members, ifgm,
+ ifgm_next);
+ free(ifgm, M_TEMP);
+ }
+
+ if (--ifgl->ifgl_group->ifg_refcnt == 0) {
+ TAILQ_REMOVE(&V_ifg_head, ifgl->ifgl_group, ifg_next);
+ EVENTHANDLER_INVOKE(group_detach_event,
+ ifgl->ifgl_group);
+ free(ifgl->ifgl_group, M_TEMP);
+ }
+ IFNET_WUNLOCK();
+
+ free(ifgl, M_TEMP);
+
+ EVENTHANDLER_INVOKE(group_change_event, groupname);
+
+ IFNET_WLOCK();
+ }
+ IFNET_WUNLOCK();
+}
+
+/*
* Stores all groups from an interface in memory pointed
* to by data
*/
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-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: m_tag, malloc vs uma
Robert Watson wrote:
On Fri, 10 Apr 2009, Karim Fodil-Lemelin wrote:
Is there any plans on getting the mbuf tags sub-system integrated
with the universal memory allocator? Getting tags for mbufs is still
calling malloc in uipc_mbuf.c ... What would be the benefits of using
uma instead?
Hi Karim:
Right now there are no specific plans for changes along these lines,
although we have talked about moving towards better support for deep
objects in m_tags. Right now, MAC requires a "deep" copy, because
labels may be complex objects, and this is special-cased in the m_tag
code. One way to move in that direction would be to move from an
explicit m_tag free pointer to a pointer to a vector of copy, free,
etc, operations. This would make it easier to support more flexible
memory models there, rather than forcing the use of malloc(9).
That said, malloc(9) for "small" memory types is essentially a thin
wrapper accounting around a set of fixed-size UMA zones:
ITEM SIZE LIMIT USED FREE REQUESTS
FAILURES
16:16,0, 3703, 966,
55930783,0
32:32,0, 1455, 692,
30720298,0
64:64,0, 4794, 1224,
38352819,0
128: 128,0, 3169, 341,
5705218,0
256: 256,0, 1565, 535,
48338889,0
512: 512,0, 386, 494,
9962475,0
1024:1024,0, 66, 354,
3418306,0
2048:2048,0, 314, 514,
29945,0
4096:4096,0, 250, 279,
4567645,0
For larger memory sizes, malloc(9) becomes instead a thin wrapper
around VM allocation of kernel address space and pages. So as long as
you're using smaller objects, malloc(9) actually offers most of the
benefits of slab allocation.
Because m_tag(9) is an interface used for a variety of base system and
third party parts, changes to the KPI would need to be made with a
major FreeBSD release -- for example with 8.0. Such a change is
definitely not precluded at this point, but in a couple of months
we'll hit feature freeze and it won't be possible to make those
changes after that time.
Robert N M Watson
Computer Laboratory
University of Cambridge
Hi Robert,
Thank you for the answer, clear and concise. I asked the question
because I had modified pf_get_mtag() to use uma directly in the hope
that it would be faster then calling malloc. But since pf_mtag is
20bytes, malloc will end up using a fixed 32bytes zone and I shouldn't
expect much speed gain from using something like (except some savings
from not having to select the 32bytes zone):
extern uma_zone_t pf_mtag_zone;
static __inline struct pf_mtag *
pf_get_mtag(struct mbuf *m)
{
struct m_tag*mtag;
if ((mtag = m_tag_find(m, PACKET_TAG_PF, NULL)) == NULL) {
mtag = uma_zalloc(pf_mtag_zone, M_NOWAIT);
if (mtag == NULL)
return (NULL);
m_tag_setup(mtag, MTAG_ABI_COMPAT, PACKET_TAG_PF, sizeof(struct
pf_mtag));
mtag->m_tag_free = pf_mtag_delete;
bzero(mtag + 1, sizeof(struct pf_mtag));
m_tag_prepend(m, mtag);
}
return ((struct pf_mtag *)(mtag + 1));
}
Where pf_mtag_delete is a wrapper around uma_zfree().
Regards,
Karim.
___
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: m_tag, malloc vs uma
On Fri, 10 Apr 2009, Karim Fodil-Lemelin wrote:
Thank you for the answer, clear and concise. I asked the question because I
had modified pf_get_mtag() to use uma directly in the hope that it would be
faster then calling malloc. But since pf_mtag is 20bytes, malloc will end up
using a fixed 32bytes zone and I shouldn't expect much speed gain from using
something like (except some savings from not having to select the 32bytes
zone):
There is another small overhead, the critical section used to protect the
consistency of the per-CPU malloc type alloc and free counters, but it's also
very small.
I think it would be desirable to make a change to more flexible m_tag types
for 8.0, but I'm not sure I have time to implement/test it. Is this something
you might be interested in working on? I'm thinking of basically replacing
the m_tag_free pointer with a pointer to a small vector of operations,
possibly something along these lines:
struct m_tag_ops {
void(*m_tag_free)(struct m_tag *);
struct m_tag(*m_tag_copy)(struct m_tag *);
};
If the m_tag_ops pointer is NULL, we go with today's default (requiring
minimal change of existing consumers). I'm not sure if there are any other
function pointers we'd need at this point?
Robert N M Watson
Computer Laboratory
University of Cambridge
___
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: misc/129580: Netgear WG311v3 (ndis) causes kenel trap at boot.
The following reply was made to PR kern/129580; it has been noted by GNATS. From: Glen Barber To: bug-follo...@freebsd.org Cc: Subject: Re: misc/129580: Netgear WG311v3 (ndis) causes kenel trap at boot. Date: Fri, 10 Apr 2009 16:04:33 -0400 Since malo(4) is available, I believe this PR can be closed. Thanks. -- Glen Barber ___ 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/133572: [ppp] [hang] incoming PPTP connection hangs the system
Old Synopsis: incoming PPTP connection hangs the system New Synopsis: [ppp] [hang] incoming PPTP connection hangs the system Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Apr 10 21:11:38 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=133572 ___ 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/133572: [ppp] [hang] incoming PPTP connection hangs the system
The following reply was made to PR kern/133572; it has been noted by GNATS. From: Max Laier To: bug-follo...@freebsd.org, dennis.melent...@gmail.com Cc: Subject: Re: kern/133572: [ppp] [hang] incoming PPTP connection hangs the system Date: Fri, 10 Apr 2009 23:47:55 +0100 Is it possible for you to turn on WITNESS on this machine to obtain possible LORs that might be responsible for the hang? Also, do you have the possibility to enable DDB and drop into it from the console (if it is not a hard hang but a live lock)? -- Max ___ 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: bridge(4) and IPv6 link-local address
Bjoern A. Zeeb wrote: > On Mon, 30 Jun 2008, Eugene M. Kim wrote: > > A quick question: Is bridge(4) supposed /not/ to automatically configure an > > IPv6 link-local address? > > yes there is a check for this in the code and if remoed (tried that > lately) more things go wrong. > > > I'm trying to use it to bridge a wired segment and a wireless segment, and > > router advertisement over bridge0 wouldn't work because, with bridge0 > > lacking > > a LL address, the router uses a non-LL address as the source address for > > RA > > packets, which then is ignored as invalid by other IPv6 nodes. > > yes, seem something similar lately but ETIMEOUT on debugging. The > problem basically was: > > lanbridgeath --- wlan client > > the LL address was on the "lan" interface. > > ping6 LL on lan from wlan client did not work. I could see the packets > being bridged and visible on all interfaces and even the router on lan > noticed them but there was no reply going to the client. ping6 from > the bridge ``box'' to the wlan client and everything was fine as nd > was seeded. > > Removing the check we ended up with the same LL address on both bridge > and the lan interface if I can remember correctly and you do not want > that... it's a bit tricky and there is something that does not work as > expected, right. If you find the time to debug it I'll happily test > patches;-) I seem to be reviving a fairly old thread here, but this is what I found when I went searching for the issue. I am personally bridging a wireless NIC (ath0) with a VLAN interface (vlan10). The bridge does not receive a link-local address. The bridge interface (bridge0) is the default gateway for my LAN, both for v4 and v6. My Mac was logging this message in response to router advertisements: | Apr 10 18:16:54 administrators-imac configd[29]: RTADV_VERIFY_PACKET: | invalid RA with non link-local source from 2001:4830:1679:10::1 on en0 and was refusing to acknowledge them. My solution was to assign a link-local address to bridge0 based on the ethernet address (I think I did the EUI-48 stuff correctly): | bridge0: flags=8843 metric 0 mtu 1500 | ether 92:db:a2:b4:8e:ba | inet 10.1.10.1 netmask 0xff00 broadcast 10.1.10.255 | inet6 2001:4830:1679:10::1 prefixlen 64 | inet6 fe80::90db:a2ff:feb4:83ba%bridge0 prefixlen 64 scopeid 0xc | id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 | maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 | root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 According to ifconfig(8): | Basic IPv6 node operation requires a link-local address on each interface | configured for IPv6. Normally, such an address is automatically config- | ured by the kernel on each interface added to the system; this behaviour | may be disabled by setting the sysctl MIB variable | net.inet6.ip6.auto_linklocal to 0. The bridge(4) page does not add any disclaimer about bridge interfaces. Neither man page gives a good how-to on assigning your own link-local address (I guessed and got it right with the % notation). Shouldn't the kernel assign link-local addresses to these interfaces? Should this address be based on the ethernet address of the bridge interface? I'm not sure I really understood the challenges with the implementation. -- Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley pgp7il6F6D7lF.pgp Description: PGP signature
