misc/176344: Add support for firewall deny lists (workstation type)
>Number: 176344
>Category: misc
>Synopsis: Add support for firewall deny lists (workstation type)
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: update
>Submitter-Id: current-users
>Arrival-Date: Fri Feb 22 10:10:01 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Noor Dawod
>Release:9.1-PRERELEASE Wed Nov 21 UTC 2012
>Organization:
>Environment:
FreeBSD hidden 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Wed Nov 21 08:36:35
UTC 2012 root@hidden:/usr/obj/usr/src/sys/CUSTOM amd64
>Description:
ipfw has a handly configuration section in rc.conf to ease firewalling. In the
'workstation' type, however, there is a way to allow full access for selected
clients, but no way for denying it for others.
The attached patches would add that support. Since lists of IP's could grow
big, I've opted to using files to host the list of addresses, as opposed to
writing the list in rc.conf.
>How-To-Repeat:
>Fix:
Patch attached with submission follows:
--- /etc/defaults/rc.conf 2013-02-22 09:37:36.0 +
+++ /etc/defaults/rc.conf-new 2013-02-22 09:37:44.0 +
@@ -153,6 +153,11 @@
# firewall.
firewall_trusted=""# List of IPs which have full access to this
# host for "workstation" firewall.
+firewall_denied="" # List of files containing IPv4 and/or IPv6
+# addresses that have no access to this host.
+firewall_denied_rule="550" # ipfw rule number used to host all rules
+# denying access to hosts listed in the files
+# in $firewall_denied.
firewall_logdeny="NO" # Set to YES to log default denied incoming
# packets for "workstation" firewall.
firewall_nologports="135-139,445 1026,1027 1433,1434" # List of TCP/UDP ports
--- /etc/rc.firewall2012-11-21 09:08:57.0 +
+++ /etc/rc.firewall-new2013-02-22 09:40:30.0 +
@@ -433,6 +433,12 @@
#This option can seriously degrade
#the level of protection provided by
#the firewall.
+ # firewall_denied: List of files containing IPv4 and/or
+ #IPv6 addresses that have no access
+ #to this host.
+ # firewall_denied_rule:ipfw rule number used to host all
+ #rules denying access to hosts listed
+ #in the files in $firewall_denied.
# firewall_logdeny:Boolean (YES/NO) specifying if the
#default denied packets should be
#logged (in /var/log/security).
@@ -498,6 +504,31 @@
${fwcmd} add pass ip from $i to me
done
+ # If specified, deny hosts from reaching this machine.
+ for i in ${firewall_denied} ; do
+ # check that file exists first.
+ if [ -f $i ]; then
+ oldIFS=$IFS
+ IFS="
+"
+ # Go over all IPs listed in the file.
+ for ip in `cat $i` ; do
+ # Block IP if first character isn't a dash.
+ i=${ip%${ip#?}}
+ if [ $i != "#" ]; then
+ # Cut string when first space is found.
+ # Practical for Postfix files and
geographic
+ # CIDR's obtained from online sources.
+ ip=`echo $ip | cut -d " " -f 1`
+
+ # Add block rule for target IP.
+ ${fwcmd} add ${firewall_denied_rule}
deny ip from $ip to me
+ fi
+ done
+ IFS=$oldIFS
+ fi
+ done
+
${fwcmd} add 65000 count ip from any to any
# Drop packets to ports where we don't want logging
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/176347: Add support for firewall deny lists (workstation type)
>Number: 176347
>Category: misc
>Synopsis: Add support for firewall deny lists (workstation type)
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: update
>Submitter-Id: current-users
>Arrival-Date: Fri Feb 22 10:50:01 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Noor Dawod
>Release:9.1-PRERELEASE Wed Nov 21 UTC 2012
>Organization:
>Environment:
FreeBSD hidden 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Wed Nov 21 08:36:35
UTC 2012 root@hidden:/usr/obj/usr/src/sys/CUSTOM amd64
>Description:
ipfw has a handly configuration section in rc.conf to ease firewalling. In the
'workstation' type, however, there is a way to allow full access for selected
clients, but no way for denying it for others.
The attached patches would add that support. Since lists of IP's could grow
big, I've opted to using files to host the list of addresses, as opposed to
writing the list in rc.conf.
I've made it possible so that either all IP-related traffic is blocked, or
specific TCP ports are blocked. The user can decide that easily via rc.conf.
Please pay attention that this supersedes pr=176344 which I had sent an hour
ago; this PR adds support for selective TCP ports.
>How-To-Repeat:
>Fix:
Patch attached with submission follows:
--- /etc/defaults/rc.conf 2013-02-22 09:37:36.0 +
+++ /etc/defaults/rc.conf-new 2013-02-22 10:42:15.0 +
@@ -153,6 +153,14 @@
# firewall.
firewall_trusted=""# List of IPs which have full access to this
# host for "workstation" firewall.
+firewall_denied="" # List of files containing IPv4 and/or IPv6
+ # addresses that have no access to this host.
+firewall_denied_rule="550" # ipfw rule number used to host all rules
+ # denying access to this host.
+firewall_denied_services="*" # List of TCP ports on which this host
+ # denies services for "workstation" firewall.
+ # If '*' is entered, then all services will
+ # be blocked, TCP or UDP.
firewall_logdeny="NO" # Set to YES to log default denied incoming
# packets for "workstation" firewall.
firewall_nologports="135-139,445 1026,1027 1433,1434" # List of TCP/UDP ports
--- /etc/rc.firewall2012-11-21 09:08:57.0 +
+++ /etc/rc.firewall-new2013-02-22 10:39:02.0 +
@@ -433,6 +433,18 @@
#This option can seriously degrade
#the level of protection provided by
#the firewall.
+ # firewall_denied: List of files containing IPv4 and/or
+ #IPv6 addresses that have no access
+ #to this host.
+ # firewall_denied_rule:ipfw rule number used to host all
+ #rules denying access to hosts listed
+ #in the files in $firewall_denied.
+ # firewall_denied_rule:ipfw rule number used to host all rules
+ #denying access to this host.
+ # firewall_denied_services:List of TCP ports on which this host
+ #denies services for "workstation"
firewall.
+ #If '*' is entered, then all services
+ #will be blocked, TCP or UDP.
# firewall_logdeny:Boolean (YES/NO) specifying if the
#default denied packets should be
#logged (in /var/log/security).
@@ -498,6 +510,36 @@
${fwcmd} add pass ip from $i to me
done
+ # If specified, deny hosts from reaching this machine.
+ ds=`echo ${firewall_denied_services} | sed 's/ /,/g'`
+ for i in ${firewall_denied} ; do
+ # check that file exists first.
+ if [ -f $i ]; then
+ oldIFS=$IFS
+ IFS="
+"
+ # Go over all IPs listed in the file.
+ for ip in `cat $i` ; do
+ # Block IP if first character isn't a dash.
+ i=${ip%${ip#?}}
+ if [ $i != "#" ]; then
+ # Cut string when first space is found.
+ # Practical for Postfix files and
geographic
+ # CIDR's obtained from online sources.
+
kern/162036: [geom] Fatal trap 12: page fault while in kernel mode -- Stopped at atomic_subtract_int+0x4
The following reply was made to PR kern/162036; it has been noted by GNATS. From: Fabian Keil To: bug-follo...@freebsd.org Cc: Subject: kern/162036: [geom] Fatal trap 12: page fault while in kernel mode -- Stopped at atomic_subtract_int+0x4 Date: Fri, 22 Feb 2013 17:59:13 +0100 --Sig_/ygxLXwLUVd3B0XBB6PqOfsd Content-Type: multipart/mixed; boundary="MP_/KEOJ2TQS+uSTGDSq0NXG=p3" --MP_/KEOJ2TQS+uSTGDSq0NXG=p3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The problem still exists with a current kernel but apparently the atomic_subtract_int() call has been relocated. As the result there are now two related panics caused by g_eli_read_done() and (sometimes) g_eli_crypto_read_done() being called with: (kgdb) p bp->bio_parent->bio_to->geom->softc $1 =3D (void *) 0x0 The attached patch adds the missing pointer checks and seems to prevent the panics for me. So far I haven't seen similar panics in the g_*_write_done() functions, although they look rather similar. Fabian --MP_/KEOJ2TQS+uSTGDSq0NXG=p3 Content-Type: text/x-patch Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=kern-162036-Let-g_eli_-read_done-deal-with-lost-devices.patch =46rom 52a4fac396edd7a79a0d4311f38bdc3d3141 Mon Sep 17 00:00:00 2001 From: Fabian Keil Date: Tue, 19 Feb 2013 14:42:00 +0100 Subject: [PATCH 1/2] Let g_eli_*read_done() deal with lost devices without causing panics Seems to fix kern/162036 for me. --- sys/geom/eli/g_eli.c | 3 ++- sys/geom/eli/g_eli_privacy.c | 6 -- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/sys/geom/eli/g_eli.c b/sys/geom/eli/g_eli.c index 4e35297..24969b0 100644 --- a/sys/geom/eli/g_eli.c +++ b/sys/geom/eli/g_eli.c @@ -183,7 +183,8 @@ g_eli_read_done(struct bio *bp) pbp->bio_driver2 =3D NULL; } g_io_deliver(pbp, pbp->bio_error); - atomic_subtract_int(&sc->sc_inflight, 1); + if (sc !=3D NULL) + atomic_subtract_int(&sc->sc_inflight, 1); return; } mtx_lock(&sc->sc_queue_mtx); diff --git a/sys/geom/eli/g_eli_privacy.c b/sys/geom/eli/g_eli_privacy.c index f353832..938883a 100644 --- a/sys/geom/eli/g_eli_privacy.c +++ b/sys/geom/eli/g_eli_privacy.c @@ -88,7 +88,8 @@ g_eli_crypto_read_done(struct cryptop *crp) bp->bio_error =3D crp->crp_etype; } sc =3D bp->bio_to->geom->softc; - g_eli_key_drop(sc, crp->crp_desc->crd_key); + if (sc !=3D NULL) + g_eli_key_drop(sc, crp->crp_desc->crd_key); /* * Do we have all sectors already? */ @@ -105,7 +106,8 @@ g_eli_crypto_read_done(struct cryptop *crp) * Read is finished, send it up. */ g_io_deliver(bp, bp->bio_error); - atomic_subtract_int(&sc->sc_inflight, 1); + if (sc !=3D NULL) + atomic_subtract_int(&sc->sc_inflight, 1); return (0); } =20 --=20 1.8.1.3 --MP_/KEOJ2TQS+uSTGDSq0NXG=p3-- --Sig_/ygxLXwLUVd3B0XBB6PqOfsd Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBCAAGBQJRJ6PlAAoJEGkYIpGLojccDGMP/064LFc70F8+/Zn6ofTr1sgM 4s0euYG6ebtB3nOFuiaEoNqfcbga+2+FSJBnxEogc1/MMA9r/CAsqee8HUvT3HGo psjeefN6K3k5Emk1GywLqZetgGzMbtqtZEZ5Qppd/Z7m2VzznnKZ+5UPx/tcxo7y krPELZjj2qRITBRPX5AN+xTmbYKCqtoOHKxXJIQN8Cf+9zoVhidaWu3Q2GG0AQo5 lvcWVAWPQcRNoS+lRyyeX4dO+miOPSMUBcNvSmcGxFHjaQxnr61aR4kztu0DNkAz rJznXgoEb05f0EZ8bc5sP0nVnv1B+Uo1gEM5JHZ3IR0RugXLJv+nkaSzD0JM9iAd X7dmU798cpWiF4wXliIeTxCHeOKxLYeSFnPMams319FQrDyHrGiZl3jWcQh6PHbr 0SjqB8GGAyb5cV7BkD6szQjJbErmRCcmwFUHEt9Ra13lFl83ZBPHEr2EYf8VfJnt 2w4xMPx5Z1vu7YHk/cKliVYnl9uoplG9ob6HksDm7VNkxlTyeUqCAGNVNHK8nMi1 pPy95t3KgM7rgdRlxIldMyJpl5gUX/wWhmieGV8FQ2vh0JiK67ude3KlDATk9pKW 4BbiTmgfiAcMQvmwDsRI5FhlSK2KhwIFIRQUpW9LIkF0t1LHOHYboqHs4YCx/L3n NNw9YRVwLPUQb1G5q4ft =L8cH -END PGP SIGNATURE- --Sig_/ygxLXwLUVd3B0XBB6PqOfsd-- ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
The patch effectively reverts a previous change, which was to cap rxmax and density by what the AP is capable of. I think the better approach would be to initialize rxmax and density with the VAP capabilities before the condition and use MIN() in STA mode to limit to AP caps. -- Bernhard ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
Hm, we need to use MIN(rxmax) and MAX(density) regardless, right? If an AP is transmitting to a STA that has a lower rxmax or higher density, it should obey that. The same rules apply for mesh, ibss, tdma operational modes. So yes, what we should do is: * initialise rxmax/density with the VAP capabilities * track what the remote node rxmax/density is * have a couple of functions that return the density and rxmax based on the destination node and current VAP config * teach the 11n drivers to use that. Thanks, Adrian ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
On Friday, February 22, 2013 07:04:39 PM Adrian Chadd wrote: > Hm, we need to use MIN(rxmax) and MAX(density) regardless, right? > > If an AP is transmitting to a STA that has a lower rxmax or higher > density, it should obey that. > > The same rules apply for mesh, ibss, tdma operational modes. > > So yes, what we should do is: > > * initialise rxmax/density with the VAP capabilities > * track what the remote node rxmax/density is > * have a couple of functions that return the density and rxmax based > on the destination node and current VAP config > * teach the 11n drivers to use that. Don't make it to complex, it's one-liner, not sure it's worth a function. The STA case is handled here because there is no later position to do so, AP already told us what it is capable of (ni_htparams) now it's the STA's job to do the same. The AP case is handled somewhere else, assoc req I guess, and that just uses the VAP params to verify the limits aren't above device caps. Using plain ni_htparams after that is just fine. If also done right in STA mode, ni_htparams will always contain a value which doesn't exceed either the AP's or the STA's or the device's limits (might have to change the value exactly there), so, using it directly is fine in drivers. I don't want to get into IBSS mode just yet, it's way to complex to get my head around that atm. Though, I think, it's a per-node and not a global parameter so the handling should match that from the AP? -- Bernhard ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
Hi, Why isn't it a per-node thing for the AP case? Ie, what should the AP do if the ampdu density it supports is 0 but the STA AMPDU density on the RX side is 8? Adrian ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
On Friday, February 22, 2013 07:34:30 PM Adrian Chadd wrote: > Hi, > > Why isn't it a per-node thing for the AP case? > > Ie, what should the AP do if the ampdu density it supports is 0 but > the STA AMPDU density on the RX side is 8? What made you think it isn't? ni_htparams is per-node(ni)? If you kept the original mail it might be easier to figure out what you are refering to. :) If you ment the stuff I wrote about IBSS, well, as I said, IBSS is way to complex for me right to think about.. -- Bernhard ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
Ah, damn. Sorry. I was thinking about the node versus vap configuration and got confused. IBSS is the same as the APmode of operation - you advertise what you're capable of and sending stations just calculate the MIN(ampdusize) and MAX(ampdudensity) when sending to you. Exactly the same needs to be done for AP mode. STA mode should do the same too - it just happens there's only one node (the AP.) We have the same issue with 2040, shortgi, stbc, ldpc - ni_htparams includes what the peer node has, not necessarily what you've negotiated. So in the ath(4) driver I needed to look at both what _my_ capabilities are _and_ the remote capabilities before I decide whether to use 40mhz, shortgi, etc. It'd be shinier if there were some net80211 functions that did this for me. Adrian ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
Hm, it's possible in my sleep deprived state that I'm on the right but wrong track here. The OP problem is that we're not advertising the right capabilities when we associate, right? Why aren't we just advertising the VAP ampdumax and ampdudensity no matter what the operating mode? Why are we capping those parameters to the learnt-from-AP parameters? Adrian ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
On Friday, February 22, 2013 07:52:47 PM Adrian Chadd wrote: > Hm, it's possible in my sleep deprived state that I'm on the right but > wrong track here. > > The OP problem is that we're not advertising the right capabilities > when we associate, right? Correct. > Why aren't we just advertising the VAP ampdumax and ampdudensity no > matter what the operating mode? Why are we capping those parameters to > the learnt-from-AP parameters? Because the AP would otherwise deny the association request. That's at least how I read the commit (r173865). -- Bernhard ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
bin/176361: [PATCH] Add recursive option to ctags
>Number: 176361
>Category: bin
>Synopsis: [PATCH] Add recursive option to ctags
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Fri Feb 22 20:20:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Fernando
>Release:9.0-RELEASE
>Organization:
OpenSistemas
>Environment:
FreeBSD beastie 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC
2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
>Description:
The ctags version shipped with FreeBSD lacks the -R (recursive) option that is
extremely useful.
The patch I propose implements this feature by simply using ftw(3). It is a non
intrusive patch as it changes nothing regarding the text analysis itself. I
tested it with several pieces of C source code and filesystem links and seems
to work fine.
The patch also updates the manual page.
>How-To-Repeat:
Just try ctags -R :)
>Fix:
Apply the attached patch.
It applies cleanly to FreeBSD 9.0-RELEASE sources.
Patch attached with submission follows:
diff -ruN /usr/src/usr.bin/ctags/ctags.1 ctags/ctags.1
--- /usr/src/usr.bin/ctags/ctags.1 2012-01-03 04:23:52.0 +0100
+++ ctags/ctags.1 2013-02-01 20:33:23.0 +0100
@@ -76,6 +76,8 @@
Use forward searching patterns
.Pq Li /.../
(the default).
+.It Fl R
+Recurse subdirectories.
.It Fl T
Do not create tags for typedefs, structs, unions, and enums.
.It Fl a
diff -ruN /usr/src/usr.bin/ctags/ctags.c ctags/ctags.c
--- /usr/src/usr.bin/ctags/ctags.c 2012-01-03 04:23:52.0 +0100
+++ ctags/ctags.c 2012-11-09 14:13:19.0 +0100
@@ -45,6 +45,7 @@
__FBSDID("$FreeBSD: release/9.0.0/usr.bin/ctags/ctags.c 216370 2010-12-11
08:32:16Z joel $");
#include
+#include
#include
#include
#include
@@ -71,6 +72,7 @@
intlineno; /* line number of current line */
intdflag; /* -d: non-macro defines */
+intrflag; /* -R: recursive search */
inttflag; /* -t: create tags for typedefs */
intvflag; /* -v: vgrind style index output */
intwflag; /* -w: suppress warnings */
@@ -85,6 +87,24 @@
static void usage(void);
int
+ftw_callback(const char *path, const struct stat *f_stat, int flags)
+{
+ curfile = strdup(path);
+
+ if (flags == FTW_F) {
+ if (!(inf = fopen(curfile, "r"))) {
+ warn("%s", curfile);
+ return (1);
+ } else {
+ find_entries(curfile);
+ fclose(inf);
+ }
+ }
+
+ return (0);
+}
+
+int
main(int argc, char **argv)
{
static const char *outfile = "tags"; /* output file */
@@ -98,7 +118,7 @@
aflag = uflag = NO;
tflag = YES;
- while ((ch = getopt(argc, argv, "BFTadf:tuwvx")) != -1)
+ while ((ch = getopt(argc, argv, "BFRTadf:tuwvx")) != -1)
switch(ch) {
case 'B':
searchar = '?';
@@ -106,6 +126,9 @@
case 'F':
searchar = '/';
break;
+ case 'R':
+ rflag = YES;
+ break;
case 'T':
tflag = NO;
break;
@@ -146,16 +169,23 @@
init();
- for (exit_val = step = 0; step < argc; ++step)
- if (!(inf = fopen(argv[step], "r"))) {
- warn("%s", argv[step]);
- exit_val = 1;
- }
+ for (exit_val = step = 0; step < argc; ++step) {
+ curfile = argv[step];
+ if (rflag)
+ exit_val = ftw(curfile, ftw_callback, /* UNUSED */ 1);
else {
- curfile = argv[step];
- find_entries(argv[step]);
- (void)fclose(inf);
+ if (!(inf = fopen(argv[step], "r"))) {
+ warn("%s", argv[step]);
+ exit_val = 1;
+ }
+ else {
+ find_entries(argv[step]);
+ (void)fclose(inf);
+ }
+
}
+ }
+
if (head) {
if (xflag)
diff -ruN /usr/src/usr.bin/ctags/tree.c ctags/tree.c
--- /usr/src/usr.bin/ctags/tree.c 2012-01-03 04:23:52.0 +0100
+++ ctags/tree.c2012-11-07 18:36:29.0 +0100
@@ -127,6 +127,7 @@
if (node->right)
free_tree(node->right);
node_next = node->left;
+ free(node->file);
kern/176362: Graphics screen comes back blank after switching to the text terminal on Intel Mobile 945GME chipset
>Number: 176362 >Category: kern >Synopsis: Graphics screen comes back blank after switching to the text >terminal on Intel Mobile 945GME chipset >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Feb 22 21:00:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Yuri >Release:9.1 >Organization: n/a >Environment: >Description: Graphics starts fine, but if I switch to text terminal (Ctrl-Alt F1) and back (Alt-F9) graphics comes back blank. After I kill and restart xorg its starts up fine again. Relevant xorg.conf portion: Section "Device" Identifier "Card0" Driver "intel" VendorName "Intel Corporation" BoardName "Mobile 945GME Express Integrated Graphics Controller" BusID "PCI:0:2:0" EndSection Relevant Xorg.0.log portion: <...skipped...> (II) Loading /usr/local/lib/xorg/modules//drivers/intel_drv.so <...skipped...> (II) intel: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, IGD_GM, IGD_G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, Mobile Intel® GM45 Express Chipset, Intel Integrated Graphics Device, G45/G43, Q45/Q43, G41 (II) Primary Device is: PCI 00@00:02:0 <...skipped...> Hardware: Lenovo S10-2 netbook, Intel Atom CPU OS: FreeBSD-9.0 I first reported this to XOrg, but they claim that this is FreeBSD kernel bug: https://bugs.freedesktop.org/show_bug.cgi?id=27864 >How-To-Repeat: >Fix: n/a >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
On Fri, Feb 22, 2013 at 12:05 PM, Bernhard Schmidt wrote: > On Friday, February 22, 2013 07:52:47 PM Adrian Chadd wrote: >> Hm, it's possible in my sleep deprived state that I'm on the right but >> wrong track here. >> >> The OP problem is that we're not advertising the right capabilities >> when we associate, right? > > Correct. I didn't patch it right, but all of us agree on sta isn't sending correct param at association. With current code, sta sends back whatever it has received in probe resp packet. > >> Why aren't we just advertising the VAP ampdumax and ampdudensity no >> matter what the operating mode? Why are we capping those parameters to >> the learnt-from-AP parameters? > > Because the AP would otherwise deny the association request. Should ap only allow node which caps match ap's to associate? (By the way, can anyone point me to the code does denial? I couldn't find it.) AK ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Dead console on FreeBSD 9.1
I have now observed this on more than one machine so it's time to report it rather than ignore it as a fluke. Over a month ago, I saw this several times on FreeBSD/ppc64 9.1-RC. The ppc64 port is not exactly solid, so with more pressing issues to deal with I ignored it. Now, I see the same on a box running FreeBSD/amd64 9.1-STABLE. Seeing the same issue on multiple machines indicates it's a real problem. What happens when the console goes dead is that there is no further output and there is no response to the keyboard. There should be output to the console from a running program. The program continues to run, but the screen is not updated. I cannot switch virtual consoles using the keyboard. I can ssh in and continue to use the machine. Everything seems to run fine and I can see further output in dmesg. I always considered the console as the last resort, so to loose it when the box is still running is very troublesome indeed. The only correlation I can come up with is that both machine have disks on a SAS card using the mpt driver and there may have been a device disconnecting from the bus at the time of the console hang. It is impossible to tell exactly when the console hung so I can't be sure that the output from mpt in dmesg correlates to the moment of the hang. On the ppc64 machine, I was using ddrescue on a troublesome disk which periodically disconnects from the SAS bus when the firmware takes too long attempting to correct errors. I just wanted to get through imaging the disk, so I let it run and used ssh to check the status. The active virtual console was running ddrescue, which continued to run without interruption after the console hang. Any output from the driver would have been on the first virtual console, which was not the active one at the time, and without the ability to switch to it I can only look at the end of dmesg and take a guess. On the amd64 machine, I was doing a zfs send/receive from one pool to another. Again, a troublesome disk is present which periodically disconnects. The active virtual console was running "zpool iostat -v 1" to monitor the status. The zfs send/recive pipe was in another virtual console and I had top running in yet another. Again, the console hangs, I cannot switch to the first virtual console to see what it might say, but I can see mpt errors at the end of dmesg. I left it be to finish the zfs send/receive operation while monitoring status via ssh. The important work is done for the moment. I have not rebooted the system so it has a dead console but I still have ssh access. Any suggestions what to look at while it is in this state to attempt to determine the cause? ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
On 22 February 2013 13:26, PseudoCylon wrote: >>> The OP problem is that we're not advertising the right capabilities >>> when we associate, right? >> >> Correct. > > I didn't patch it right, but all of us agree on sta isn't sending > correct param at association. With current code, sta sends back > whatever it has received in probe resp packet. Right, but Bernhard points out the original code did return its own configuration, and this causes some APs to reject stations. Hence why it's doing this. >>> Why aren't we just advertising the VAP ampdumax and ampdudensity no >>> matter what the operating mode? Why are we capping those parameters to >>> the learnt-from-AP parameters? >> >> Because the AP would otherwise deny the association request. > > Should ap only allow node which caps match ap's to associate? (By the > way, can anyone point me to the code does denial? I couldn't find it.) I don't think so. The whole point here is to _support_ nodes whose density/ampdusize is less than what we have configured. The only reason we'd want to reject them is if we have some concept of "minimum acceptable density/ampdurx" (like "minimum basic rates"), rather than "what is it we support." Adrian ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
