Re: manual patch for isakmpd's FIFO r
On Thu, Jul 11, 2013 at 03:25:36PM +0200, Anders Berggren wrote: The following patch clarifies that sending r over the FIFO doesn't produce the exact same results as SIGUSR1. Or do you prefer that we change the behaviour of the FIFO's r to match SIGUSR1, for example by changing ui_report() to something similar to ui_report_sa(); opening a file, and rewrite a few _report functions to use fprintf instead of LOG_DBG()? ...and here's the patch, in the right direction --- sbin/isakmpd/isakmpd.8.orig Thu Jul 11 14:44:58 2013 +++ sbin/isakmpd/isakmpd.8 Thu Jul 11 14:51:52 2013 @@ -494,13 +494,10 @@ .It Ic r Report .Nm -internal state to a file. -See the -.Fl R -option. -Same as when sent a +internal state to log destination. +Same output as when sent a .Dv SIGUSR1 -signal. +signal, except that it is not written to the same file. .Pp .It Ic S Report information on all known SAs to the can i ask, if you use r do you have to specify the filename to log to then? note that we currently document: option -R: -R report-file fifo r: r jmc
Getting help with updating ral(4) for 35xx chipset.
Over the past couple weeks, I've been working on getting the ral(4) driver updated for the 35xx chipset. Specifically version 0x3060 from an Edimax EW-7128Gn. Although the mailing list page says tech@ is not a tech support, I was privately directed from misc@ to post in tech@. I've previously tried getting a hold of mediatek (Linux vendor code providers) and dam...@openbsd.org (from ral(4) manpage, mailer daemon - failure to deliver). I've been having trouble comparing the vendor provided code against the ral(4) driver. The hard part, is that I don't know the correct information for certain registers (because I have nothing to compare the 3060 eeprom against). Is there anyone else I can contact about this? or anyone running ral(4) (2860 or 3090) who would like to enable the debugging? I've made the needed changes to /usr/src/sys/dev/pci/pcidevs, and enabled the debugging macro of ral(4)'s sys/dev/ic/rt2860.c driver. Here is the associated output of dmesg: ral0 at pci4 dev 0 function 0 Ralink RT3060 rev 0x00attaching ralink driver: apic 2 int 20EFUSE_CTRL=0x80008800 EEPROM rev=1, FAE=0 EEPROM region code=0x0001 (8x:) BBP255=0xff (10x:) RF255=0xff EEPROM freq offset 30 EEPROM LED mode=0x01, LEDs=0x0110/0xfad9/0x88cc EEPROM RF rev=0x08 chains=1T1R EEPROM CFG 0x0086 chan 1: power1=16, power2=5 chan 2: power1=17, power2=5 chan 3: power1=17, power2=5 chan 4: power1=18, power2=5 chan 5: power1=18, power2=5 chan 6: power1=19, power2=5 chan 7: power1=19, power2=5 chan 8: power1=20, power2=5 chan 9: power1=21, power2=5 chan 10: power1=21, power2=5 chan 11: power1=22, power2=5 chan 12: power1=22, power2=5 chan 13: power1=23, power2=5 chan 14: power1=24, power2=5 chan 36-161: power1=-1, power2=-1 chan 165-173: power1=0, power2=-1 chan 0: power1=0, power2=-1 power compensation=0 (2GHz), 0 (5GHz) ridx 0: power 20MHz=0x, 40MHz/2GHz=0x, 40MHz/5GHz=0x ridx 1: power 20MHz=0x6688, 40MHz/2GHz=0x6688, 40MHz/5GHz=0x6688 ridx 2: power 20MHz=0x6688, 40MHz/2GHz=0x6688, 40MHz/5GHz=0x6688 ridx 3: power 20MHz=0x6688, 40MHz/2GHz=0x6688, 40MHz/5GHz=0x6688 ridx 4: power 20MHz=0x6688, 40MHz/2GHz=0x6688, 40MHz/5GHz=0x6688 TSSI 2GHz: 0x22 0x19 0x16 0x13 0x10 0x0d 0x0a 0x08 0x06 step=1 TSSI 5GHz: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff step=255 tx mixer gain=3 (2GHz) invalid LNA for channel group 2 invalid LNA for channel group 3 , address 80:1f:02:95:57:17 ral0: MAC/BBP RT3572 (rev 0x0223), RF RT3022 (MIMO 1T1R) ... MCU command=0x30 slot=0 status=0x01 MCU command=0x31 slot=0 status=0x01 Then a ton of tx stat 0x, GP timeout state=1, and sending frame qid=## wcid=## nsegs=## ridx=## spamming my console (Note, GP timeout state=1 means that the At first I thought the 3060 used eeprom, but I'm now certain it uses efuse. Because this information is correct: MAC Address (80:1F:02 = Edimax Brand) MAC/BBP RT3572 (comment in vendor code states: 35xx chips all report 3572 from eeprom) MIMO 1T1R, (3060 has 1tx ring, and 1rx ring) (TSSI 5GHz seems to be correct, the 3060 doesn't have 5GHz support AFAIK) Everything else I cannot prove to be correct. Furthermore, I'm fairly certain EEPROM region code=0x0001 is incorrect. Wikipedia's list of WLAN channels for the USA matches the vendor code definition of region 9. Eeprom (from 2860 code) reports region 12, which includes 3 channels not used in the USA. I've profiled all the vendor code between 2860 and 35xx. Now I'm going to profile between 35xx and 3090. In the meantime, I was hoping to get in contact with someone who knew more about the ral(4) driver, or wireless drivers in particular. Thanks! Nathan Goings
Re: SSLHonorCipherOrder for OpenBSD's httpd
Example lines for the config file. ok? -Otto Index: httpd.conf === RCS file: /cvs/src/usr.sbin/httpd/conf/httpd.conf,v retrieving revision 1.26 diff -u -p -r1.26 httpd.conf --- httpd.conf 3 Jun 2009 18:28:21 - 1.26 +++ httpd.conf 12 Jul 2013 09:19:27 - @@ -1035,6 +1035,9 @@ SSLEngine on # See the mod_ssl documentation for a complete list. #SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP +# If on, use server's order of preference for ciphers. +#SSLHonorCipherOrder on + # Server Certificate: # Point SSLCertificateFile at a PEM encoded certificate. If # the certificate is encrypted, then you will be prompted for a Index: httpd.conf-dist === RCS file: /cvs/src/usr.sbin/httpd/conf/httpd.conf-dist,v retrieving revision 1.20 diff -u -p -r1.20 httpd.conf-dist --- httpd.conf-dist 1 Apr 2009 06:47:34 - 1.20 +++ httpd.conf-dist 12 Jul 2013 09:19:27 - @@ -1045,6 +1045,9 @@ SSLEngine on # See the mod_ssl documentation for a complete list. SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL +# If on, use server's order of preference for ciphers. +#SSLHonorCipherOrder on + # Server Certificate: # Point SSLCertificateFile at a PEM encoded certificate. If # the certificate is encrypted, then you will be prompted for a
Stop calling IPsec and pf under splnet
Hi,
As it was pointed out by dhill there are some rogue splnets in
the tcp_input that shouldn't be there really. The only reason
they're still there is to match overzealous splnets in bridge_
broadcast. bridge_ifenqueue is the only function call in there
that requires splnet protection since it's dealing with send
queues. Narrowing the range of the splnet protection allows us
to remove all splnet protection of the IPsec SPD and TDB code.
This as well removes the only pf_test call done under IPL_NET.
Below are essentially two diffs that are rather hard to separate.
I've tested the diff with the gif-to-ethernet IPsec bridge but
some additional IPsec and bridge testing won't hurt.
mpi@ has provided some feedback already, so I'm really looking
for OK's on this.
diff --git sys/net/if_bridge.c sys/net/if_bridge.c
index 41d7b67..0ca2710 100644
--- sys/net/if_bridge.c
+++ sys/net/if_bridge.c
@@ -969,12 +969,10 @@ bridge_output(struct ifnet *ifp, struct mbuf *m, struct
sockaddr *sa,
return (ENOBUFS);
}
eh = mtod(m, struct ether_header *);
dst = (struct ether_addr *)eh-ether_dhost[0];
- s = splnet();
-
/*
* If bridge is down, but original output interface is up,
* go ahead and send out that interface. Otherwise the packet
* is dropped below.
*/
@@ -1007,11 +1005,10 @@ bridge_output(struct ifnet *ifp, struct mbuf *m, struct
sockaddr *sa,
*/
if ((mtag = m_tag_find(m, PACKET_TAG_IPSEC_OUT_CRYPTO_NEEDED,
NULL)) != NULL) {
ipsp_skipcrypto_unmark((struct tdb_ident *)(mtag + 1));
m_freem(m);
- splx(s);
return (0);
}
#endif /* IPSEC */
bridge_span(sc, NULL, m);
@@ -1074,22 +1071,24 @@ bridge_output(struct ifnet *ifp, struct mbuf *m, struct
sockaddr *sa,
m1-m_pkthdr.len = len;
}
mc = m1;
}
+ s = splnet();
error = bridge_ifenqueue(sc, dst_if, mc);
+ splx(s);
if (error)
continue;
}
if (!used)
m_freem(m);
- splx(s);
return (0);
}
sendunicast:
bridge_span(sc, NULL, m);
+ s = splnet();
if ((dst_if-if_flags IFF_RUNNING) == 0) {
m_freem(m);
splx(s);
return (ENETDOWN);
}
@@ -1251,13 +1250,11 @@ bridgeintr_frame(struct bridge_softc *sc, struct mbuf
*m)
* If the packet is a multicast or broadcast OR if we don't
* know any better, forward it to all interfaces.
*/
if ((m-m_flags (M_BCAST | M_MCAST)) || dst_if == NULL) {
sc-sc_if.if_imcasts++;
- s = splnet();
bridge_broadcast(sc, src_if, eh, m);
- splx(s);
return;
}
/*
* At this point, we're dealing with a unicast frame going to a
@@ -1496,13 +1493,11 @@ bridge_broadcast(struct bridge_softc *sc, struct ifnet
*ifp,
struct ether_header *eh, struct mbuf *m)
{
struct bridge_iflist *p;
struct mbuf *mc;
struct ifnet *dst_if;
- int len, used = 0;
-
- splassert(IPL_NET);
+ int len, s, used = 0;
TAILQ_FOREACH(p, sc-sc_iflist, next) {
/*
* Don't retransmit out of the same interface where
* the packet was received from.
@@ -1587,11 +1582,13 @@ bridge_broadcast(struct bridge_softc *sc, struct ifnet
*ifp,
len += ETHER_VLAN_ENCAP_LEN;
#endif
if ((len - ETHER_HDR_LEN) dst_if-if_mtu)
bridge_fragment(sc, dst_if, eh, mc);
else {
+ s = splnet();
bridge_ifenqueue(sc, dst_if, mc);
+ splx(s);
}
}
if (!used)
m_freem(m);
@@ -1643,11 +1640,11 @@ bridge_span(struct bridge_softc *sc, struct
ether_header *eh,
struct mbuf *morig)
{
struct bridge_iflist *p;
struct ifnet *ifp;
struct mbuf *mc, *m;
- int error;
+ int s, error;
if (TAILQ_EMPTY(sc-sc_spanlist))
return;
m = m_copym2(morig, 0, M_COPYALL, M_NOWAIT);
@@ -1679,11 +1676,13 @@ bridge_span(struct bridge_softc *sc, struct
ether_header *eh,
if (mc == NULL) {
sc-sc_if.if_oerrors++;
continue;
}
+ s = splnet();
error = bridge_ifenqueue(sc, ifp, mc);
+ splx(s);
if (error)
Re: a.out in gcc-local(1)
On Fri, Jul 12, 2013 at 12:07:43AM +0300, Alexey Suslikov wrote: Hi tech@ Just found no longer relevant block in gcc-local(1): - On a.out platforms (i.e. vax), gcc uses a linker wrapper to write stubs that call global constructors and destructors. Those platforms use gcc 2.95.3, and those calls can be traced using -Wl,-trace-ctors-dtors, using syslog_r(3). Cheers, Alexey fixed, thanks. jmc
list colon modifiers in mail(1) manpage
This diff adds colon modifiers which could be used to specify lists. Index: mail.1 === RCS file: /cvs/src/usr.bin/mail/mail.1,v retrieving revision 1.60 diff -u -p -r1.60 mail.1 --- mail.1 7 Nov 2010 08:05:56 - 1.60 +++ mail.1 12 Jul 2013 10:43:23 - @@ -206,14 +206,28 @@ Thus deletes messages 1 and 2, while .Ic delete 1\-5 deletes messages 1 through 5. -The special name -.Sq * -addresses all messages and -.Sq $ -addresses -the last message; thus the command +.Pp +Some special names could be used to specify a list: +.Bl -tag -width :u +.It * +all messages +.It $ +last message +.It :n +new messages +.It :o +old messages +.It :r +read messages +.It :u +unread messages +.It :d +deleted messages +.El +.Pp +For example, .Ic top -which prints the first few lines of a message could be used in +which prints the first few lines of a message could as well be used as .Ic top * to print the first few lines of all messages. .Ss Replying to or originating mail
ix(4) driver update to latest FreeBSD/Intel source code
Hi, The following diff updates most of the ix(4) driver to what FreeBSD and Intel have today. Most importantly it introduces support for the Ethernet flow control. Please test and report. OK's are welcome as well. http://theapt.org/~mike/ix.diff http://theapt.org/~mike/ix-w.diff (less whitespace changes)
Re: manual patch for isakmpd's FIFO r
The following patch clarifies that sending r over the FIFO doesn't produce the exact same results as SIGUSR1. Or do you prefer that we change the behaviour of the FIFO's r to match SIGUSR1, for example by changing ui_report() to something similar to ui_report_sa(); opening a file, and rewrite a few _report functions to use fprintf instead of LOG_DBG()? New diff, produced and prettified by jmc Index: isakmpd.8 === RCS file: /cvs/src/sbin/isakmpd/isakmpd.8,v retrieving revision 1.111 diff -u -r1.111 isakmpd.8 --- isakmpd.8 25 Sep 2012 13:58:00 - 1.111 +++ isakmpd.8 12 Jul 2013 13:24:11 - @@ -494,7 +494,8 @@ .It Ic r Report .Nm -internal state to a file. +internal state to +.Xr syslog 3 . See the .Fl R option.
man.conf(5) _subdir search order
Hi,
i'm moving this thread from misc@ to tech@ because i propose a patch.
When replying, please make sure you do not cross-post.
Jérémie Courrèges-Anglas wrote on Fri, Jul 12, 2013 at 02:05:48PM +0200:
Jan Stary h...@stare.cz writes:
The mdoc(7) manpage says about .Bl that
The -width and -offset arguments accept scaling widths
as described in roff(7) or use the length of the given string.
The words width or offset do not appear anywhere in roff(7).
You're looking at the roff(7) manpage that comes with groff.
Your pager probably prints /usr/local/man/cat7/roff.0 at the
bottom of your screen.
To find out how man(1) resolves your query string to a manual page file,
you can also use
$ man -w roff
/usr/local/man/cat7/roff.0
/usr/share/man/man7/roff.7
Without the -w, man(1) will display the first one.
That's the ordering resulting from the default man.conf(5):
ports override the base system.
I consider that a bug, thanks for reporting it!
You could use man -a and then enter :n to get the base manpage.
Much easier:
$ man 7 roff
...
Doubtless, now you wonder why explicitly specifying the section
gives you the other (correct) ordering, but indeed it does:
$ man -w 7 roff
/usr/share/man/man7/roff.7
/usr/local/man/cat7/roff.0
To understand what's going on here, let's look at the default
file /etc/man.conf. When explicitly specifying the section,
the following entry takes effect:
7 /usr/{share,X11R6,local}/man/{cat,man}7
That expands to, as it should:
/usr/share/man/cat7
/usr/share/man/man7
/usr/X11R6/man/cat7
/usr/X11R6/man/man7
/usr/local/man/cat7
/usr/local/man/man7
When not specifying the section, the following entries take effect:
_subdir ... cat7 man7 ...
_default /usr/{share,X11R6,local,ports/infrastructure}/man/
That *first* expands to
/usr/{share,X11R6,local,ports/infrastructure}/man/cat7
/usr/{share,X11R6,local,ports/infrastructure}/man/man7
and *then* to
/usr/share/man/cat7
/usr/X11R6/man/cat7
/usr/local/man/cat7
/usr/ports/infrastructure/man/cat7
/usr/share/man/man7
/usr/X11R6/man/man7
/usr/local/man/man7
/usr/ports/infrastructure/man/man7
which is the wrong ordering.
Here is the fix, making sure that section 1 from ports still
overrides section 6 from base, but cat from ports does *not*
override man from base.
OK?
Yours,
Ingo
Index: man.conf
===
RCS file: /cvs/src/etc/man.conf,v
retrieving revision 1.17
diff -u -r1.17 man.conf
--- man.conf11 Apr 2011 14:45:41 - 1.17
+++ man.conf12 Jul 2013 15:25:14 -
@@ -9,7 +9,7 @@
_whatdb/usr/X11R6/man/whatis.db
# Subdirectories for paths ending in '/', IN SEARCH ORDER.
-_subdircat1 man1 cat8 man8 cat6 man6 cat2 man2 cat3 man3 cat5
man5 cat7 man7 cat4 man4 cat9 man9 cat3p man3p cat3f man3f catn mann
+_subdir{cat,man}1 {cat,man}8 {cat,man}6 {cat,man}2 {cat,man}3
{cat,man}5 {cat,man}7 {cat,man}4 {cat,man}9 {cat,man}3p {cat,man}3f {cat,man}n
# Files typed by suffix and their commands.
# Note the order: .Z must come after .[1-9n].Z, or it will match first.
Re: man.conf(5) _subdir search order
On Fri, Jul 12, 2013 at 5:51 PM, Ingo Schwarze schwa...@usta.de wrote:
Here is the fix, making sure that section 1 from ports still
overrides section 6 from base, but cat from ports does *not*
override man from base.
Definitely makes sense.
OK?
Ok with me.
Yours,
Ingo
ciao,
David
Index: man.conf
===
RCS file: /cvs/src/etc/man.conf,v
retrieving revision 1.17
diff -u -r1.17 man.conf
--- man.conf11 Apr 2011 14:45:41 - 1.17
+++ man.conf12 Jul 2013 15:25:14 -
@@ -9,7 +9,7 @@
_whatdb/usr/X11R6/man/whatis.db
# Subdirectories for paths ending in '/', IN SEARCH ORDER.
-_subdircat1 man1 cat8 man8 cat6 man6 cat2 man2 cat3 man3
cat5 man5 cat7 man7 cat4 man4 cat9 man9 cat3p man3p cat3f man3f catn mann
+_subdir{cat,man}1 {cat,man}8 {cat,man}6 {cat,man}2
{cat,man}3 {cat,man}5 {cat,man}7 {cat,man}4 {cat,man}9 {cat,man}3p
{cat,man}3f {cat,man}n
# Files typed by suffix and their commands.
# Note the order: .Z must come after .[1-9n].Z, or it will match first.
Set of 14 potential bugs
Hi, as I did for NetBSD, here is a list of 14 potential bugs/errors found by my code scanner in OpenBSD: http://M00nBSD.net/e5ab5f6e59d6a0feb7d1a518acc8233d.html I do not provide patches.
Re: Set of 14 potential bugs
On Fri, Jul 12, 2013 at 08:24:30PM +0200, Maxime Villard wrote:
Hi,
as I did for NetBSD, here is a list of 14 potential bugs/errors
found by my code scanner in OpenBSD:
http://M00nBSD.net/e5ab5f6e59d6a0feb7d1a518acc8233d.html
I do not provide patches.
You are right about macppc/stand/boot.mac/fixcoff.c. Only Old-World Macs are
affected where we don't really run anyway...
Here is the diff which fixes the RCS IDs as bonus.
Index: elf32_powerpc_merge.x
===
RCS file: /cvs/src/sys/arch/macppc/stand/boot.mac/elf32_powerpc_merge.x,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 elf32_powerpc_merge.x
--- elf32_powerpc_merge.x 5 Dec 2006 20:30:26 - 1.1
+++ elf32_powerpc_merge.x 12 Jul 2013 19:54:14 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: */
+/* $OpenBSD$ */
OUTPUT_ARCH(powerpc)
SECTIONS
{
Index: fixcoff.c
===
RCS file: /cvs/src/sys/arch/macppc/stand/boot.mac/fixcoff.c,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 fixcoff.c
--- fixcoff.c 5 Dec 2006 20:30:26 - 1.1
+++ fixcoff.c 12 Jul 2013 19:54:14 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: */
+/* $OpenBSD$ */
/* $NetBSD: fixcoff.c,v 1.10 2006/04/07 02:34:55 gdamore Exp $ */
/*
@@ -143,7 +143,7 @@ main(int argc, char *argv[])
}
if ((fd = open(argv[0], O_RDWR, 0)) == -1)
- err(i, %s, argv[0]);
+ err(1, %s, argv[0]);
/*
* Make sure it looks like an xcoff file..
Re: netbt, Bluetooth kernel code
Making it better requires a bigger effort. However, ones you get part way along the line you might see oh, lower level abstration good. If you get to that point, and make the next steps forward, you'll be a hero. Thanks. I've received several helpful comments and contributions from others who are interested in this, but I appreciate the broad delineation of what experienced OpenBSD developers view as an acceptable standard for kernel device driver subsystem code. Thanks for the encouragement. I'll continue to study the USB code Ted recommends as a good model. Whoa. I think USB was just called a good model. Good? I'm not sure on that point. A better idea for a model? Yeah, kind of like much less worse.
Re: netbt, Bluetooth kernel code
On 13/07/2013, Theo de Raadt dera...@cvs.openbsd.org wrote: Whoa. I think USB was just called a good model. Good? I'm not sure on that point. A better idea for a model? Yeah, kind of like much less worse. I'll readily study any better model. But let's be realistic. I've already started studying USB and I'm prepared to apply any useful principles I find there in future code that may be submitted to OpenBSD. If there is a good argument for further development of Bluetooth in OpenBSD, in any case, it won't just be my enthusiasm.
