diff: ignore mandatory rx-connect-speed avp
add handling of `rx connect speed' avp to ignore the bug of xl2tpd. reported by sebastia@ on misc@. ok? Index: usr.sbin/npppd/l2tp/l2tp_call.c === RCS file: /cvs/src/usr.sbin/npppd/l2tp/l2tp_call.c,v retrieving revision 1.9 diff -u -p -r1.9 l2tp_call.c --- usr.sbin/npppd/l2tp/l2tp_call.c 18 Jan 2012 03:13:04 - 1.9 +++ usr.sbin/npppd/l2tp/l2tp_call.c 20 Jan 2012 06:57:38 - @@ -504,6 +504,14 @@ l2tp_call_recv_ICCN(l2tp_call *_this, u_ case L2TP_AVP_TYPE_MESSAGE_TYPE: AVP_SIZE_CHECK(avp, ==, 8); continue; + case L2TP_AVP_TYPE_RX_CONNECT_SPEED: + /* +* As RFC 2661 this AVP is not mandatory. But `xl2tpd' +* sends this as a mandatory AVP. Handle this to +* ignore the xl2tpd' bug. +*/ + AVP_SIZE_CHECK(avp, ==, 10); + continue; case L2TP_AVP_TYPE_TX_CONNECT_SPEED: AVP_SIZE_CHECK(avp, ==, 10); tx_conn_speed = avp_get_val32(avp);
diff: ingress filter of npppd/pipex.
The diff will make the ingress filter of pipex and npppd configurable
and disable it by default. After this change we need to add
ppp.ingress_filter: true
to npppd.conf if it is needed. I promise to write about this
configuration in the man page when the man page becomes available.
ok? comment?
Index: sys/net/pipex.c
===
RCS file: /cvs/src/sys/net/pipex.c,v
retrieving revision 1.24
diff -u -p -r1.24 pipex.c
--- sys/net/pipex.c 18 Jan 2012 02:02:53 - 1.24
+++ sys/net/pipex.c 20 Jan 2012 00:58:18 -
@@ -1124,15 +1124,16 @@ pipex_ip_input(struct mbuf *m0, struct p
goto drop;
}
#endif
-
- /* ingress filter */
- ip = mtod(m0, struct ip *);
- if ((ip->ip_src.s_addr & session->ip_netmask.sin_addr.s_addr) !=
- session->ip_address.sin_addr.s_addr) {
- pipex_session_log(session, LOG_DEBUG,
- "ip packet discarded by ingress filter (src %s)",
- inet_ntoa(ip->ip_src));
- goto drop;
+ if (ISSET(session->ppp_flags, PIPEX_PPP_INGRESS_FILTER)) {
+ /* ingress filter */
+ ip = mtod(m0, struct ip *);
+ if ((ip->ip_src.s_addr & session->ip_netmask.sin_addr.s_addr) !=
+ session->ip_address.sin_addr.s_addr) {
+ pipex_session_log(session, LOG_DEBUG,
+ "ip packet discarded by ingress filter (src %s)",
+ inet_ntoa(ip->ip_src));
+ goto drop;
+ }
}
/* idle timer */
Index: sys/net/pipex.h
===
RCS file: /cvs/src/sys/net/pipex.h,v
retrieving revision 1.10
diff -u -p -r1.10 pipex.h
--- sys/net/pipex.h 15 Oct 2011 03:24:11 - 1.10
+++ sys/net/pipex.h 20 Jan 2012 00:58:18 -
@@ -89,6 +89,7 @@ struct pipex_session_req {
#definePIPEX_PPP_MPPE_REQUIRED 0x0040
#definePIPEX_PPP_HAS_ACF 0x0080
#definePIPEX_PPP_ADJUST_TCPMSS 0x0100
+#definePIPEX_PPP_INGRESS_FILTER0x0200
int8_t pr_ccp_id; /* CCP current packet id */
int pr_ppp_id; /* PPP Id. */
uint16_tpr_peer_mru;/* Peer's MRU */
Index: usr.sbin/npppd/npppd/npppd.c
===
RCS file: /cvs/src/usr.sbin/npppd/npppd/npppd.c,v
retrieving revision 1.14
diff -u -p -r1.14 npppd.c
--- usr.sbin/npppd/npppd/npppd.c18 Jan 2012 03:13:04 - 1.14
+++ usr.sbin/npppd/npppd/npppd.c20 Jan 2012 00:58:19 -
@@ -887,10 +887,10 @@ npppd_network_output(npppd *_this, npppd
pip = (struct ip *)pktp;
}
-#ifndefNO_INGRES_FILTER
- if ((pip->ip_src.s_addr & ppp->ppp_framed_ip_netmask.s_addr) !=
- (ppp->ppp_framed_ip_address.s_addr &
- ppp->ppp_framed_ip_netmask.s_addr)) {
+ if (ppp->ingress_filter != 0 &&
+ (pip->ip_src.s_addr & ppp->ppp_framed_ip_netmask.s_addr)
+ != (ppp->ppp_framed_ip_address.s_addr &
+ ppp->ppp_framed_ip_netmask.s_addr)) {
char logbuf[80];
strlcpy(logbuf, inet_ntoa(pip->ip_dst), sizeof(logbuf));
ppp_log(ppp, LOG_INFO,
@@ -899,7 +899,6 @@ npppd_network_output(npppd *_this, npppd
return;
}
-#endif
if (ppp->timeout_sec > 0 && !ip_is_idle_packet(pip, lbuf))
ppp_reset_idle_timeout(ppp);
@@ -942,6 +941,8 @@ pipex_setup_common(npppd_ppp *ppp, struc
if (ppp->adjust_mss != 0)
req->pr_ppp_flags |= PIPEX_PPP_ADJUST_TCPMSS;
+ if (ppp->ingress_filter != 0)
+ req->pr_ppp_flags |= PIPEX_PPP_INGRESS_FILTER;
req->pr_ip_srcaddr = ppp->pppd->iface[0].ip4addr;
req->pr_ip_address = ppp->ppp_framed_ip_address;
Index: usr.sbin/npppd/npppd/ppp.c
===
RCS file: /cvs/src/usr.sbin/npppd/npppd/ppp.c,v
retrieving revision 1.11
diff -u -p -r1.11 ppp.c
--- usr.sbin/npppd/npppd/ppp.c 18 Jan 2012 03:13:04 - 1.11
+++ usr.sbin/npppd/npppd/ppp.c 20 Jan 2012 00:58:19 -
@@ -162,7 +162,8 @@ ppp_init(npppd *pppd, npppd_ppp *_this)
ppp_config_str_equal(_this, "log.in.pktdump", "true", 0);
_this->log_dump_out =
ppp_config_str_equal(_this, "log.out.pktdump", "true", 0);
-
+ _this->ingress_filter = ppp_config_str_equal(_this, "ingress_filter",
+ "true", 0);
#ifdef USE_NPPPD_MPPE
mppe_init(&_this->mppe, _this);
Index: usr.sbin/npppd/npppd/ppp.h
===
RCS file: /cvs/src/usr.sbin/npppd/npppd/ppp.h,v
retrieving revision 1.8
di
Re: calendar in Debian
On Thu, Jan 19, 2012 at 09:38:06PM +0100, Otto Moerbeek wrote: > On Thu, Jan 19, 2012 at 05:46:48PM +0100, Otto Moerbeek wrote: > > > On Thu, Jan 19, 2012 at 05:09:25PM +0100, Michael Meskes wrote: > > > > > On Thu, Jan 19, 2012 at 12:30:15PM +0100, Otto Moerbeek wrote: > > > > I looked through some of the diffs and noted your are introducing a > > > > race in calendar_fifo.diff. Why are you changing this code? > > > > > > Because the old code blocks if a named pipe is used as a calendar file, a > > > bug > > > report is here: > > > > > > http://bugs.launchpad.net/ubuntu/+source/bsdmainutils/+bug/357055 > > > > > > Michael > > > -- > > > Michael Meskes > > > Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) > > > Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org > > > Jabber: michael.meskes at googlemail dot com > > > VfL Borussia! ForC'a BarC'a! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL > > > > > > Introducing a race is never the right solution, imo. > > > > By the way, your fix does not catch an included file being a fifo > > either. So while introducing a race, it actually does not fix the > > problem. > > With a hint from Paul Jantzen I did test this a bit further. There's That is, Paul Janzen, sorry about that. > code to avoid having a child runing too long. If you have 20s > patience, you'll see this: > > calendar: uid 1000 did not finish in time > > So imo, the debian diff not only is wrong, but it also tries to solve a > problem that isn't actually a problem. > > -Otto
cwm: tab-completion
Sometimes I want to type something like "xterm -e top" in "exec" menu,
and feel the need for tab completion.
Not sure about the FALLTHROUGH thing, though.
Index: menu.c
===
RCS file: /cvs/xenocara/app/cwm/menu.c,v
retrieving revision 1.33
diff -u -p -u -r1.33 menu.c
--- menu.c 8 Sep 2011 12:00:50 - 1.33
+++ menu.c 19 Jan 2012 20:58:45 -
@@ -37,7 +37,7 @@
enum ctltype {
CTL_NONE = -1,
CTL_ERASEONE = 0, CTL_WIPE, CTL_UP, CTL_DOWN, CTL_RETURN,
- CTL_ABORT, CTL_ALL
+ CTL_TAB, CTL_ABORT, CTL_ALL
};
struct menu_ctx {
@@ -254,6 +254,14 @@ menu_handle_key(XEvent *e, struct menu_c
mc->searchstr[0] = '\0';
mc->changed = 1;
break;
+ case CTL_TAB:
+ if ((mi = TAILQ_FIRST(resultq)) != NULL) {
+ (void)strlcpy(mc->searchstr,
+ mi->text, sizeof(mc->searchstr));
+ mc->changed = 1;
+ break;
+ }
+ /* FALLTHROUGH */
case CTL_ALL:
mc->list = !mc->list;
break;
@@ -475,6 +483,9 @@ menu_keycode(KeyCode kc, u_int state, en
break;
case XK_Return:
*ctl = CTL_RETURN;
+ break;
+ case XK_Tab:
+ *ctl = CTL_TAB;
break;
case XK_Up:
*ctl = CTL_UP;
--
Alexander Polakov | plhk.ru
Re: calendar in Debian
On Thu, Jan 19, 2012 at 05:46:48PM +0100, Otto Moerbeek wrote: > On Thu, Jan 19, 2012 at 05:09:25PM +0100, Michael Meskes wrote: > > > On Thu, Jan 19, 2012 at 12:30:15PM +0100, Otto Moerbeek wrote: > > > I looked through some of the diffs and noted your are introducing a > > > race in calendar_fifo.diff. Why are you changing this code? > > > > Because the old code blocks if a named pipe is used as a calendar file, a > > bug > > report is here: > > > > http://bugs.launchpad.net/ubuntu/+source/bsdmainutils/+bug/357055 > > > > Michael > > -- > > Michael Meskes > > Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) > > Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org > > Jabber: michael.meskes at googlemail dot com > > VfL Borussia! ForC'a BarC'a! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL > > > Introducing a race is never the right solution, imo. > > By the way, your fix does not catch an included file being a fifo > either. So while introducing a race, it actually does not fix the > problem. With a hint from Paul Jantzen I did test this a bit further. There's code to avoid having a child runing too long. If you have 20s patience, you'll see this: calendar: uid 1000 did not finish in time So imo, the debian diff not only is wrong, but it also tries to solve a problem that isn't actually a problem. -Otto
Re: Add OPENBSD-CARP-MIB to snmpd(8)
On Fri, Jan 13, 2012 at 2:53 PM, Joel Knight wrote: > Hi, > > This diff integrates my existing snmp MIB for carp(4) into the base > snmpd. I brought the MIB straight across with no changes. The only > limitation I'm aware of is that it doesn't support the multiple > carpnodes style loadbalancing; it only reports status on the main > carpnode. > > http://www.packetmischief.ca/files/openbsd/patches/snmpd.carp.diff > > The MIB definition is here: > http://www.packetmischief.ca/files/openbsd/snmp/OPENBSD-CARP-MIB.txt Has anyone tried running this or read through the diff? .joel
Re: small change to the scandir(3) manual page
I see. There are clues in dir(5) actually, so perhaps a note in scandir(3) is vacuous. On Jan 19, 2012 6:59 PM, "Joerg Sonnenberger" wrote: > On Thu, Jan 19, 2012 at 06:32:45PM +, Edd Barrett wrote: > > On Thu, Jan 19, 2012 at 10:17:02AM -0800, Philip Guenther wrote: > > > On Thu, Jan 19, 2012 at 4:18 AM, Edd Barrett wrote: > > > > I recently got caught out by scandir's quirky memory allocation. > Should > > > > we add a note so that others don't have to go through this pain too? > > > > > > Could you elaborate on how this affected your code? I'm trying to > > > think of some way for code to depend on this that isn't undefined > > > behavior by the POSIX standard and (sorry) just a bad idea in > > > practice... > > > > I tried to memcpy() one of these dirents into a new buffer: > > > > memcpy(dest, src, sizeof(struct dirent)); > > > > This overran the read buffer, as most dirents allocated by scandir() are > > not this big. > > POSIX explicitly says that d_name has unspecified size. > > Joerg
Re: small change to the scandir(3) manual page
On Thu, Jan 19, 2012 at 06:32:45PM +, Edd Barrett wrote: > On Thu, Jan 19, 2012 at 10:17:02AM -0800, Philip Guenther wrote: > > On Thu, Jan 19, 2012 at 4:18 AM, Edd Barrett wrote: > > > I recently got caught out by scandir's quirky memory allocation. Should > > > we add a note so that others don't have to go through this pain too? > > > > Could you elaborate on how this affected your code? I'm trying to > > think of some way for code to depend on this that isn't undefined > > behavior by the POSIX standard and (sorry) just a bad idea in > > practice... > > I tried to memcpy() one of these dirents into a new buffer: > > memcpy(dest, src, sizeof(struct dirent)); > > This overran the read buffer, as most dirents allocated by scandir() are > not this big. POSIX explicitly says that d_name has unspecified size. Joerg
Re: small change to the scandir(3) manual page
On Thu, Jan 19, 2012 at 10:17:02AM -0800, Philip Guenther wrote: > On Thu, Jan 19, 2012 at 4:18 AM, Edd Barrett wrote: > > I recently got caught out by scandir's quirky memory allocation. Should > > we add a note so that others don't have to go through this pain too? > > Could you elaborate on how this affected your code? I'm trying to > think of some way for code to depend on this that isn't undefined > behavior by the POSIX standard and (sorry) just a bad idea in > practice... I tried to memcpy() one of these dirents into a new buffer: memcpy(dest, src, sizeof(struct dirent)); This overran the read buffer, as most dirents allocated by scandir() are not this big. -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: small change to the scandir(3) manual page
On Thu, Jan 19, 2012 at 4:18 AM, Edd Barrett wrote: > I recently got caught out by scandir's quirky memory allocation. Should > we add a note so that others don't have to go through this pain too? Could you elaborate on how this affected your code? I'm trying to think of some way for code to depend on this that isn't undefined behavior by the POSIX standard and (sorry) just a bad idea in practice... Philip
Re: calendar in Debian
On Thu, Jan 19, 2012 at 05:09:25PM +0100, Michael Meskes wrote: > On Thu, Jan 19, 2012 at 12:30:15PM +0100, Otto Moerbeek wrote: > > I looked through some of the diffs and noted your are introducing a > > race in calendar_fifo.diff. Why are you changing this code? > > Because the old code blocks if a named pipe is used as a calendar file, a bug > report is here: > > http://bugs.launchpad.net/ubuntu/+source/bsdmainutils/+bug/357055 > > Michael > -- > Michael Meskes > Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) > Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org > Jabber: michael.meskes at googlemail dot com > VfL Borussia! ForC'a BarC'a! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL Introducing a race is never the right solution, imo. By the way, your fix does not catch an included file being a fifo either. So while introducing a race, it actually does not fix the problem. -Otto
Re: calendar in Debian
On Thu, Jan 19, 2012 at 12:30:15PM +0100, Otto Moerbeek wrote: > I looked through some of the diffs and noted your are introducing a > race in calendar_fifo.diff. Why are you changing this code? Because the old code blocks if a named pipe is used as a calendar file, a bug report is here: http://bugs.launchpad.net/ubuntu/+source/bsdmainutils/+bug/357055 Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! ForC'a BarC'a! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
small change to the scandir(3) manual page
Hi, I recently got caught out by scandir's quirky memory allocation. Should we add a note so that others don't have to go through this pain too? Index: scandir.3 === RCS file: /cvs/src/lib/libc/gen/scandir.3,v retrieving revision 1.10 diff -u -p -u -r1.10 scandir.3 --- scandir.3 26 Mar 2010 19:30:40 - 1.10 +++ scandir.3 19 Jan 2012 12:08:15 - @@ -27,7 +27,7 @@ .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" SUCH DAMAGE. .\" -.Dd $Mdocdate: March 26 2010 $ +.Dd $Mdocdate: January 19 2012 $ .Dt SCANDIR 3 .Os .Sh NAME @@ -53,6 +53,24 @@ It returns the number of entries in the A pointer to the array of directory entries is stored in the location referenced by .Fa namelist . +.Pp +Note that after a call to +.Fn scandir +the allocation size of each +.Fa dirent +structure within the +.Fa namelist +array is not necessarily +.Fa sizeof(struct direct) . +For each directory entry, +.Fn scandir +will allocate space for the integer fields plus as many bytes as is +required to store the NULL-terminated string +.Fa d_name +rounded up to a 4-byte boundary. See +.Xr dir 5 +for the exact layout of +.Fa struct dirent . .Pp The .Fa select -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: calendar in Debian
On Thu, Jan 19, 2012 at 10:40:13AM +0100, Michael Meskes wrote: > Hi, > > I'm working on the Debian package bsdmainutils which includes calendar from > OpenBSD. > > In an effort to fix bugs and improve the feature set we added several patches > to calendar. Some are Linux specific, but the majority would also be > applicable to OpenBSD. Maybe you're interested in adding these changes to your > sources. > > You can find the patches here: > > http://anonscm.debian.org/gitweb/?p=bsdmainutils/bsdmainutils.git;a=tree;f=debian/patches;hb=HEAD > > I'm absolutely willing to explain what we did with each patch and why. I looked through some of the diffs and noted your are introducing a race in calendar_fifo.diff. Why are you changing this code? -Otto > > Feel free to redirect me or forward this email to the right place/person if > this list is not the right place. > > Michael > > -- > Michael Meskes > Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) > Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org > Jabber: michael.meskes at googlemail dot com > VfL Borussia! ForC'a BarC'a! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL > -- > Michael Meskes > Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) > Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org > Jabber: michael.meskes at googlemail dot com > VfL Borussia! ForC'a BarC'a! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
calendar in Debian
Hi, I'm working on the Debian package bsdmainutils which includes calendar from OpenBSD. In an effort to fix bugs and improve the feature set we added several patches to calendar. Some are Linux specific, but the majority would also be applicable to OpenBSD. Maybe you're interested in adding these changes to your sources. You can find the patches here: http://anonscm.debian.org/gitweb/?p=bsdmainutils/bsdmainutils.git;a=tree;f=debian/patches;hb=HEAD I'm absolutely willing to explain what we did with each patch and why. Feel free to redirect me or forward this email to the right place/person if this list is not the right place. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! ForC'a BarC'a! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! ForC'a BarC'a! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: athn(4) device timeout
Hi Tech, On 16 January 2012 21:28, Ishwor Gurung wrote: [...] > I'll be enabling the athn specific debug on my Atheros card and see > what comes out of it. > > Hopefully, something will make sense :-) > > I'll also make sure I post the log here. Here's the output of debug: athn0: device timeout athn0: begin active scan athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 11 mode 11g athn0: received beacon from 00:26:f2:56:f8:c2 rssi 17 mode 11g athn0: received beacon from c4:3d:c7:61:49:ba rssi 31 mode 11g athn0: received beacon from 00:60:64:55:2c:08 rssi 41 mode 11g athn0: received beacon from c4:3d:c7:61:49:ba rssi 32 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 12 mode 11g athn0: received beacon from 00:60:64:55:2c:08 rssi 40 mode 11g athn0: received beacon from 00:60:64:55:2c:08 rssi 41 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 13 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 14 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 1 mode 11g athn0: received beacon from 08:76:ff:4e:bf:10 rssi 19 mode 11g athn0: received beacon from 00:26:44:50:73:21 rssi 19 mode 11g athn0: received beacon from 08:76:ff:4e:bf:10 rssi 19 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 2 mode 11g athn0: received beacon from 00:26:44:50:73:21 rssi 18 mode 11g athn0: received beacon from 08:76:ff:4e:bf:10 rssi 15 mode 11g athn0: received beacon from 00:26:44:50:73:21 rssi 18 mode 11g athn0: received beacon from 08:76:ff:4e:bf:10 rssi 14 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 3 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 4 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 5 mode 11g athn0: received beacon from 94:44:52:4d:80:84 rssi 22 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 6 mode 11g athn0: received beacon from 08:76:ff:45:46:3c rssi 16 mode 11g athn0: received beacon from 94:44:52:4d:80:84 rssi 24 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 7 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 8 mode 11g athn0: received probe_resp from c4:3d:c7:61:49:ba rssi 18 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 9 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 10 mode 11g athn0: received beacon from 00:60:64:55:2c:08 rssi 40 mode 11g athn0: received beacon from 00:60:64:55:2c:08 rssi 38 mode 11g athn0: received beacon from c4:3d:c7:61:49:ba rssi 33 mode 11g athn0: received beacon from 00:1f:33:88:a6:da rssi 21 mode 11g athn0: end active scan athn0: sending auth to c4:3d:c7:61:49:ba on channel 10 mode 11g athn0: received auth from c4:3d:c7:61:49:ba rssi 30 mode 11g athn0: sending assoc_req to c4:3d:c7:61:49:ba on channel 10 mode 11g athn0: received assoc_resp from c4:3d:c7:61:49:ba rssi 31 mode 11g athn0: associated with c4:3d:c7:61:49:ba ssid "abs" channel 10 start 1Mb short preamble short slot time protection enabled athn0: received msg 1/4 of the 4-way handshake from c4:3d:c7:61:49:ba athn0: sending msg 2/4 of the 4-way handshake to c4:3d:c7:61:49:ba athn0: received msg 3/4 of the 4-way handshake from c4:3d:c7:61:49:ba athn0: sending msg 4/4 of the 4-way handshake to c4:3d:c7:61:49:ba [~] $ ifconfig athn0 athn0: flags=8947 mtu 1500 lladdr 54:37:8f:20:83:ae priority: 4 groups: wlan egress media: IEEE802.11 autoselect (DS1 mode 11g) status: active ieee80211: nwid abs chan 10 bssid c4:3d:c7:61:49:ba 32dB wpakey wpaprotos wpa2 wpaakms psk wpaciphers tkip wpagroupcipher tkip inet6 fe80::5637:8fff:fe20:83ae%athn0 prefixlen 64 scopeid 0x2 inet 10.1.1.2 netmask 0xff00 broadcast 10.1.1.255 I was expecting log entries prior to the device timeout (after enabling driver-dependent debugging code) but it seems all I can see is the wpa scan and associate after the reset. Is this something I should be looking at by upgrading to -current / -stable ? Thanks! -- Best regards, Ishwor
